지난 시간에 이어 오늘은 "GSLB가 어떤 기준으로 사이트/서버를 선택하는지?" GSLB Policy에 대해서 설명 드리도록 하겠습니다.

GSLB Policy

오늘과 다음 시간을 통해 소개해 드리는 Policy Metrics는 총 8가지이며, 이는 외산 벤더 기술문서 몇개를 참조하여 정리한 내용입니다. 

  ① Server Health -  살아있는 사이트 선택

사이트/서버 선택 과정은 1번 단계를 시작으로 8번 단계까지 순차적으로 진행되며, 만약 1번 단계에서 사이트/서버가 선택이 되면 2번 단계로 넘어가지 않고 종료 되며 1번에서 결정이 나지 않으면 2번으로 넘어 가는 식입니다. 또한 운영자는 설정을 통해 각 단계를 enable/disable 할 수 있으며, 1번 ~ 8번의 순서 변경도 가능합니다.

1. Server Health

SLB(Server Load Balancing)가 서버들로 Layer 3 ICMP, Layer 4 TCP or UDP, Layer 7 HTTP Health Check 메시지를 보내어 서버 & 응용의 Health 상태를 모니터링하고, 그 결과를 GSLB로 전달하여 GSLB는 Server Health 상태를 기반으로 사이트를 선택합니다.

1. 한국 사이트에 SLB1은 Server 1, 2의 Health 상태를, 미국 사이트에 SLB2는 Server 3, 4의 Health 상태를 주기적으로 모니터링하고,
2. 그 결과를 GSLB로 주기적으로 보고합니다. 따라서 GSLB는 각 서버의 현재 Health 상태를 알고 있게 됩니다.
3. 사용자가 Local DNS 서버로 DNS Query를 보내면
4. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
5. GSLB는 각 서버의 현재 Health 상태를 기반으로 사이트를 선택합니다. 현재 미국 사이트의 Server 3, 4가 모두 다운된 상태이고 따라서 GSLB는 한국 사이트 SLB1의 주소(Virtual IP) 1.1.1.1을 DNS Response에 실어 응답합니다. 
6. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
7. 사용자는 SLB1으로 HTTP GET 요청을 합니다.
8. 이를 수신한 SLB1은 나름의 정책(서버 Health/부하 상태 등 고려)에 따라 Server 1, 2 중에 하나를 선택하여(여기서는 Server 1이라 가정), 사용자가 보낸 HTTP GET의 Destination IP = 1.1.1.1을 10.1.1.10으로 변경하여 Server 1으로 전달합니다.

2. SLB Session & Network Capacity Threshold

1번 과정(Server Health 기반 사이트 선택)에서 한국과 미국 사이트 서버가 모두 살아 있는 경우, (1) SLB의 현재 Session 수와 (2) SLB의 Network Usage 값을 참조하여 과부하(Over-loaded) 상태가 아닌 사이트를 선택합니다. 여기서 SLB의 Session 수란 SLB에 오픈되어 있는(유지하고 있는) TCP 혹은 UDP 연결수이고(예. SLB1을 통해 Sever1에 300,000개 TCP 세션 연결, Server2에 100,000개 TCP 세션이 연결되어 있으면 현재 SLB1의 Session 수는 총 400,000개임), Network Usage란 현재 SLB를 통해 송수신되는 트래픽 대역폭(bps)입니다.

1. 각 사이트에 SLB1과 SLB2는 자신의 현재 Session 수와 Network Usage를 GSLB로 주기적으로 보고합니다. 
2. 사용자가 Local DNS 서버로 DNS Query를 보내면
3. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
4. GSLB는 SLB1과 SLB2의 현재 Session 수와 Network Usage를 기반으로 사이트를 선택합니다. 이를 위해 각 SLB에는 Session 수 및 Network Usage에 대한 임계치(Threshold)가 미리 설정되어 있고 그 값은 GSLB도 알고 있습니다(Session 수 임계치=900,000, Network Usage 임계치=900Mbps). 미국 사이트 SLB2의 현재 Session 수가 임계치 수준까지 올라간 상황이므로 GSLB는 Session 수에 여유가 있는 한국 사이트 SLB1의 주소(Virtual IP) 1.1.1.1을 DNS Response에 실어 응답합니다. 
5. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
6. 사용자는 SLB1으로 HTTP GET 요청을 합니다.
7. 이를 수신한 SLB1은 정책(서버 Health/부하 상태 등 고려)에 따라 Server 1, 2 중에 하나를 선택하여 해당 Server로 HTTP GET을 전달합니다.

3. Network Proximity

2번 과정(SLB Session & Network Capacity Threshold 기반 사이트 선택)에서 한국과 미국 사이트의 Session/Network Usage가 임계치를 넘지 않은 경우, Network Proximity 기반으로 사이트를 선택합니다. Network Proximity란 "네트워크 관점에서(지리적 관점이 아님)" 사용자와 가까운 사이트를 선택해 주는 것으로 여기서 "가까움"이란 Delay가 작음(Low Latency)를 의미합니다.

1. 사용자가 Local DNS 서버로 DNS Query를 보내면
2. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
3. GSLB는 SLB1과 SLB2에게 Local DNS 서버의 IP 주소를 전달하여, RTT(Round Trip Time) 측정을 요청합니다.
4. 이제 한국과 미국 사이트의 SLB는 ICMP를 이용하여 자신과 Local DNS 서버 간의 RTT를 측정하고,
5. 그 결과를 GSLB에게 전달합니다. 현재 사용자는 미국에 위치해 있으므로(그래서 Local DNS 서버도 미국에 있다고 가정) SLB1에서 측정한 RTT는 200ms인 반면 SLB2에서 측정한 RTT는 30ms입니다. 따라서 GSLB는 미국 사이트를 선택하고 그 결과로 SLB2의 주소(Virtual IP) 2.2.2.2를 DNS Response에 실어 응답합니다. 
6. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
7. 사용자는 SLB2로 HTTP GET 요청을 합니다.
8. 이를 수신한 SLB2는 정책(서버 Health/부하 상태 등 고려)에 따라 Server 3, 4 중에 하나를 선택하여 해당 Server로 HTTP GET을 전달합니다.

▶ 역자 주 1: 정확한 Network Proximity 측정을 위해서는 측정 구간이 "SLB ~ Local DNS 서버"가 아닌 "SLB ~ 사용자 단말"이어야 하겠으나, 현 DNS 프로토콜 표준은 사용자의 IP 주소를 상위 DNS 서버(여기서는 GSLB)로 전달하지 않습니다. 따라서 GSLB가 사용자 단말의 IP 주소를 알 수 없어 Local DNS 서버로 대신합니다. 하지만 보통 DHCP를 통해 IP 주소를 할당 받는 사용자 단말 환경에서는 사용자와 인접한 DNS 서버가 설정되기 때문에 Network Proximity 측면에서 큰 문제는 없습니다. (예. 한국 KT망 사용자는 DHCP에 의해서 KT DNS 서버가 Local DNS로 자동 설정이 되고, 미국 AT&T 사용자는 AT&T DNS 서버가 Local DNS로 자동 설정됨)

▶ 역자 주 2: ICMP(Ping) 요청을 막아 놓은 Local DNS 서버의 경우(Ping 응답을 안하는 경우), RTT 측정이 불가능하며, 이 경우 아래 4번 과정으로 넘어 가게 됩니다.

4. Geographic Proximity

3번 과정(Network Proximity 기반 사이트 선택)에서 Local DNS 서버가 ICMP에 응답을 하지 않거나 혹은 두 사이트의 RTT 결과가 유사한 경우, 지리적으로 사용자와 가까운 사이트를 선택하게 됩니다.

1. 사용자가 Local DNS 서버로 DNS Query를 보내면
2. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
3. GSLB는 Local DNS 서버의 IP 주소로 IP Geolocation DB를 검색하여 지리적으로 가까운 사이트를 선택합니다. 사용자는 홍콩에 위치해 있으며 Local DNS 서버의 IP 주소는 홍콩 대역인 11.1.1.1입니다. GSLB는 IP Goelocation DB를 검색하여 이 IP 주소는 Asia 대역이며 한국 사이트 SLB1으로 지정되어 있음을 알게 되고, 따라서 GSLB는 SLB1의 주소(Virtual IP) 1.1.1.1을 DNS Response에 실어 응답합니다. 
4. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
5. 사용자는 SLB1으로 HTTP GET 요청을 합니다.
6. 이를 수신한 SLB1은 정책(서버 Health/부하 상태 등 고려)에 따라 Server 1, 2 중에 하나를 선택하여 해당 Server로 HTTP GET을 전달합니다.

다음 시간에는 나머지 5번 ~ 8번 과정에 대해서 설명 드리도록 하겠습니다.