GSLB + Service Flow 정리 2
GLSB의 기능에 대해 정리 합니다.
가중치 (Weighted or Ratio )
- 가령, 특정한 서버 또는 Node로 DNS request 를 더 많이 보낼수도 있습니다. 예를 들면.. 특정 IDC의 트래픽을 종량제로 계약을 했다면 .. 즉 1달간 3G 정도를 무료로 사용할수 있다면
그쪽으로 트래픽을 좀더 흘려 보내서 비용을 절약할수도 있습니다. 아니면, IDC별 회선 단가비율에 따라, 조절을 할수도 있겠습니다 . 인프라를 관리하는 사람이라면 회선비용을 무시할수
없을 것입니다.
또는 WEB 서버의 성능에 따라, 비율조정을 해 줄수도 있습니다. (가중치를 높히면 더 많은 request 를 받고, 트래픽은 상승하겠죠..)
한가지 주의할 점은.. GSLB는 L4가 아니라는 점.. R/R이 정확하게 1:1 로 떨어지지는 않습니다. TTL 을 다라 갑니다.
Static Flow
- GLSB는 기본적으로 GEOIP를 가지고 있습니다. ( maxmind에서 구매해서 넣을수도 있고, 자체적으로 조절해서 운영할수도 있습니다. )
사용자의 LDNS정보에 따라, 지리적인 분산처리가 가능합니다. 중요한 부분은 LDNS라는 것입니다. Client의 IP 가 아닙니다. 즉, US에 있는 사용자의 LDNS가 KT-DNS면, US에
EDGE가 있더라도 KR에 있는 EDGE로 보내지게 됩니다.. 할상 고객의 LDNS의 상황을 고려 하여야 합니다.
보통 CDN업체는 이런 정보들은 자체적으로 관리하고 있어 정확도를 높이게 됩니다.
MAX return IP Flow
- GSLB는 IP를 여려개 던저줄수 있습니다. 가령 2개의 IP를 던저 주고 선택적으로 사용할수도 있겠습니다. 앞단의 APP이 좀더 다이나믹하게 동작해 줘야 하는 이슈가 있습니다.
즉, 2개의 IP를 App이 받아, 좀더 응답이 빠는 것 ( TTFB 가 될수도 있고..) 선택할수도 있겠습니다. 만약 Live Edge 라고 생각해 본다면.. 1.1.1.1 이 fail이 발생할 경우 Domain Lookup를
다시 하지 않고 2.2.2.2로 바로 적옹해 Timeout 줄일수도 있을 것입니다. 활용방법은 여러가지가 있겠습니다.
장애대비 Flow
- 장애 대비는 2가지를 생각해 볼수 있습니다. 첫째, 전체 장애시 특정서버(default) 또는 Node로 보낼수 있습니다. 둘째는 등록된 모든 서버(또는 응답가능한 ..)의 IP를 뿌려 줄수도 있습니다.
첫째는 web일 경우, 장애페이지를 띄워준다고 생각하면 되고, 둘째는 느리긴 해도 응답이 서비를 유지 하고 싶을때 사용할수 있습니다 개인적으로 . 단순한 서비스라면 default 로 넘기는 방법이
좋겠지만,, 중요도가 높다면, 느리긴 해도 응답을 주는 쪽이 좋다고 생각합니다. (서비스가 느리다는 것은 예를 들면 GeoIP로 분산처리가 되어 있다고 가정 했을때.. US의 Edge 전체가 장애 발생시
KR에서 대신 처리 한다면 고객은 느리다고 판단하겠지만 .. 서비스 유지는 될것입니다. --- 장애의 판단유무는 좀더 고민인 필요 할것이구요..)
