지난 시간에 KT 유클라우드 가입자를 위한 GSLB 서비스 로직에 대해서 소개해 드렸었습니다.

오늘은 서버를 여러 지역에 분산시켜 운영하는 Enterprise(기업)에서 GSLB 적용을 통해 얻게 되는 장점과 서비스 로직에 대해 설명 드리도록 하겠습니다.

 

 

기존 DNS 방식 대비 GSLB의 장점

 

한국(KR)과 미국(US) 사이트(데이터센터)에 서버가 분산되어 있는 환경에서, 좌측은 Round-Robin 기반의 DNS 방식을 우측은 GSLB 기반의 방식을 보이고 있습니다. 

 

 

1. Disaster Recovery

• [DNS 방식] DNS 서버는 응용 서버의 Health 상태(살았니? 죽었니?)를 알 수 없기 때문에 그림과 같이 미국 사이트 서버가 다운되어도 사용자 중 50%(Round-Robin DNS 이므로)는 다운된 서버로 연결 요청을 하게 되는 반면,
• [GSLB 방식] GSLB 서버는 주기적으로 응용 서버들의 Health 상태를 모니터링할 수 있어 다운된 서버로 사용자가 연결되지 않도록 합니다.

 

2. Site Load Balancing

• [DNS 방식] DNS 서버는 응용 서버의 부하 상태를 알 수 없기 때문에 그림과 같이 한국 사이트 서버 부하가 임계치 이상으로 올라가도(Over-load 상태) 사용자 중 50%는 과부하 상태의 서버로 연결 요청을 하게 되는 반면,
• [GSLB 방식] GSLB 서버는 응용 서버의 부하 상태를 주기적으로 체크할 수 있어 Over-load된 서버로 사용자가 연결되지 않도록 합니다.

▶ 역자 주: 정확히는 응용 서버 부하를 체크하는 것이 아니고 SLB의 부하 상태(현재 가용한 Session 수, Network Usage 등)를 체크하는 것임 (다음 편에서 설명)

 

3. Network Proximity

• [DNS 방식] DNS 서버는 사용자와 응용 서버 사이 Network 구간의 RTT(Round Trip Time)를 측정할 수 없기 때문에 현재의 망 상태를 고려한 서버 선택이 불가능한 반면,
• [GSLB 방식] GSLB 서버는 사용자와 응용 서버 사이 Network 구간의 RTT 측정을 통해 응답이 빠른(망 상태가 좋은) 서버로 사용자가 연결되도록 합니다.

▶ 역자 주: 정확히는 사용자와 응용 서버 사이 구간의 RTT를 측정하는 것이 아니고 Local DNS 서버(사용자 단말에 설정 된 DNS 서버)와 SLB 사이의 RTT를 측정하는 것임 (다음 편에서 설명)

 

4. Geographic Proximity

• [DNS 방식] DNS 서버는 사용자의 지리적 위치를 고려하여 응용 서버를 선택할 수 없지만, 그래서 한국에 있는 사용자가 미국 사이트 서버에 연결 될 수도 있지만
• [GSLB 방식] GSLB 서버는 사용자의 지리적 위치를 고려하여 응용 서버를 선택해 줄 수 있어 사용자는 지리적으로 가장 가까운 서버와 접속할 수 있습니다. 

▶ 역자 주: 일반적으로 지리적으로 가까우면 RTT도 작기 때문에 3번과 4번의 결과는 동일 한 경우가 많지만, Network Failure/Congestion 발생시에는 다른 결과를 가져 올 수도 있음

 

이와 같이 지역적으로 서버가 분산된 환경에서 GSLB를 이용하여 아래와 같은 이점을 얻을 수 있습니다.

(1) 서비스 가용성 제공 (Disaster Recovery)

(2) 서버 부하 분산 (Server/Site Load Balancing)

(3) 빠른 서비스 응답 (Low Latency by Network Proximity)

(4) 가까운 곳으로 접속 (Nearest by Geographic Proximity)

 

 

GSLB 서비스 로직

 

GSLB(Global Server Load Balancing)는 SLB(Server Load Balancing)에서 발전된 개념으로, SLB가 한 사이트 내에서 L4 스위칭 기능을 통해 서버의 상태 체크(죽었니? 살았니?) 및 부하 분산 기능을 제공하였다면, GSLB는 이 개념을 지리적으로 확장시켜 복수개의 사이트에서 동일 기능을 제공합니다.

 

 

■ 구성

• 총 4대의 www.example.com 웹서버 중, 2대는 한국(KR) 사이트에 2대는 미국(US) 사이트에 위치함
• 각 사이트 웹서버 앞단에는 SLB가 위치하여 사용자는 www.example.com 웹서버의 IP 주소(10.1.1.10 ~ 13)가 아닌 SLB의 Virtual IP 주소(1.1.1.1, 2.2.2.2)로 접속을 요청하고, SLB가 Destination IP 주소 변환 후 웹서버로 전달
• 한국 사이트에는 GSLB와 example.com DNS 서버가 위치함 

1. 사용자가 www.example.com에 접속하기 위해 Local DNS 서버로 DNS Query를 보내고, Local DNS 서버는 Root DNS, .com DNS 서버를 거쳐
2. GSLB로 www.example.com에 대한 DNS Query를 보냅니다.
3. GSLB는 DNS Proxy로 동작하며, 따라서 이 DNS Query를 그대로 example.com DNS 서버로 전달합니다.
4. example.com DNS 서버는 www.example.com에 대한 IP 주소(SLB의 Virtual IP) 1.1.1.1과 2.2.2.2가 미리 등록되어 있어 그 값을 GSLB로 전달해 줍니다. 전달 시 TTL은 300초라고 가정하겠습니다.
5. GSLB는 나름의 정책(뒤에서 설명)을 통해 1.1.1.1과 2.2.2.2 중에 사용자를 위한 최적의 사이트를 결정하고 또한 TTL을 작은 값으로 변경(예. 10초)합니다. TTL 값 변경은 Local DNS 서버가 바인딩 정보(www.example.com에 대한 IP 주소)를 최소 시간 동안만 캐싱하게 하기 위함입니다. 
6. GSLB의 정책(GSLB Policy)을 통해 결정된 웹서버 IP 1.1.1.1(혹은 IP 주소 리스트의 순서를 바꿔 1.1.1.1, 2.2.2.2로)과 변경된 TTL 값이 Local DNS로 전달되고,
7. Local DNS는 사용자 단말에게 그 값을 전달합니다.
8. 이제 사용자는 www.example.com의 IP 주소 1.1.1.1을 목적지로 하여 한국 사이트 SLB1으로 HTTP GET을 보내고, SLB1은 다시 나름의 정책(서버 Health/Load 등 고려)을 적용하여 최종 서버인 10.1.1.10으로 HTTP GET 메시지를 전달합니다.

 

 

GSLB의 사이트/서버 선택 정책은 아래 그림과 같습니다. 오늘은 그림만 보여 드리고, 설명은 다음 시간에 드리도록 하겠습니다.