올 9월 초에 KT에서 기업용 유클라우드(ucloud) 고객 대상으로 GSLB를 이용한 무중단 서비스를 출시하였다고 밝힌 바 있습니다. (기사 링크)
기사(아래)에 따르면 본 서비스를 통해 다음과 같은 장점을 제공할 수 있다고 설명 되어 있는데요.
이번 시간에는 KT 유클라우드에 적용된 GSLB 서비스 로직에 대해서 알아보도록 하겠습니다.
"GSLB 서비스는 동일한 기능을 수행할 수 있는 여러 대의 클라우드 서버 중 최적 상태의 서버와 연결함으로써 고객 시스템의 안정성을 향상시키며, 부하를 분산시켜 일부 서버에 트래픽이 집중되는 것을 막기 때문에 서버의 가용성을 높일 수 있다.
클라우드 환경에서의 기존 로드밸런싱 솔루션은 서버의 상태와 관계없이 서비스 요청을 하는 것에 비해 유클라우드의 GSLB 서비스는 서버의 상태 확인 후 정상적인 서버에만 연결하므로 보다 신속한 트래픽 처리 및 장애 대응이 가능해진다."
※ Active-Backup 구성 예시이며, Active-Active 구성시에는 부하분산 서비스가 가능합니다.
KT GSLB 서비스 흐름도
위 그림을 좀 더 자세히 그려 보았습니다.
■ 준비 작업 (Pre-Configuration)
GSLB는 어떤 기준으로 서버를 선택할까? (GSLB Policy)
위 그림 5번에서 GSLB의 "서버 선택 기준"에 대해서 알아 보도록 하겠습니다. 일단 일반적인 GSLB 기능에 대해서 설명 드린 후, KT에서 적용한 방법을 소개해 드리겠습니다.
■ Server Health Check
GSLB는 서버들로 IGMP(Ping), UDP, TCP, HTTP 메시지를 보내고 그 응답 여부를 통해 서버 혹은 서버의 응용(예. HTTP server)이 살아 있음을 주기적으로 확인하여 서비스가 가능한 서버를 선택합니다.
▶ 그림에서 GSLB 1은 1.1.1.1, 2.2.2.2 서버에 대해 TCP 및 HTTP Health Check 수행
GSLB 2 역시 1.1.1.1, 2.2.2.2 서버에 대해 TCP 및 HTTP Health Check 수행
■ Geographic Proximity (between Local DNS and Server)
DNS Query를 보낸 Local DNS 서버의 IP 주소를 확인하여 지역적으로 가까운 서버를 선택합니다. 우리나라와 같이 전국 어디에서나 RTT(Round Trip Time) 10ms 이하 수준인 경우 별 상관이 없지만 미국과 같이 동부-서부간에 RTT가 큰 나라의 경우 사용자(정확히는 사용자 단말에 설정된 Local DNS 서버)에게 가까운 서버를 선택해 줌으로써 빠른 응답 속도를 제공합니다.
■ Admin Policy
운영자의 정책에 따라 서버를 선택합니다. 그 정책의 예는 다음과 같습니다.
1. Random하게 서버 선택
2. Round-Robin 방식으로 서버 선택 (예. 1.1.1.1 -> 2.2.2.2 -> 1.1.1.1 -> 2.2.2.2 -> ....)
3. Weighted Round Robin 방식으로 서버 선택 (예. 1.1.1.1 서버 성능이 높아 1.1.1.1과 2.2.2.2 서버에 2:1로 배분)
KT의 GSLB Policy
KT GSLB 방식은 크게 2가지 입니다. 하나는 Active-Backup 방식(한 서버만 서비스 제공)이고, 또 하나는 Active-Active 방식(두 서버 모두 서비스 제공)입니다.
■ Active-Backup 방식에서의 GSLB Policy
Server Health Check을 통해 Active Server가 살아 있으면 항상 그 서버를 선택합니다.
■ Active-Active 방식에서의 GSLB Policy
Server Health Check을 통해 Active Server들(1.1.1.1과 2.2.2.2)이 살아 있으면 Round-Robin으로 서버를 선택합니다.
아래 그림은 KT GSLB 설정 화면입니다.
3줄 요약
다음 시간에는 Citrix, Broacade, F5 등의 Enterprise 대상 GSLB 솔루션 개념에 대해서 알아 보도록 하겠습니다.
이 경우에도 서버의 상태(Health) 및 운영자의 정책(Round-Robin)에 따라 서버를 선택하는 것이 가능할런지요??
Brocade GSLB 자료를 보면, TTL 값을 10초로 (default value) 짧게 설정하여 이 문제를 해결하였습니다.
아래는 관련 내용입니다.
The client’s local DNS server might cache DNS replies from the authoritative server. Normally, these cached
responses would prevent the global SLB from taking place, since the local DNS server would respond directly to
the client without sending a recursive query to the authoritative DNS server. However, the GSLB ServerIron, as a
proxy for the authoritative DNS server, automatically resets the Time-to-Live (TTL) parameter in each DNS record
from the authoritative server. By default, the GSLB ServerIron sets the TTL to 10 seconds. As a result, other DNS
servers that receive the records retain them in their databases for only 10 seconds. After the ten seconds expire,
subsequent requests from the client initiate another query to the authoritative DNS server. As a result, the client
always receives fresh information and the address of the site that is truly the best site for the client.
NOTE: You also can change the TTL if needed. However, Brocade Communications Systems recommends that
you do not change the TTL to 0, because this can be interpreted as an error by some older DNS servers.
결국 로컬 DNS의 TTL이 time-out되기 전까지 다른 서버는 선택할 수 없다..라는 의미로 볼 수 있겠군요.
GSLB에 의해 최초 선택된 서버 장애 시 일정 시간은(Brocade GSLB는 최소 10초 이상 이겠죠) 서비스 장애를 겪을 수 밖에 없는데(TTL을 "0"으로 하는건 비추이므로..), KT에서 표현한 무중단 서비스 지원이라는 말은 좀 과장(?)된 면이 있는 듯 합니다. ^^;
하지만 GLB를 노드 내부 SLB 역할까지 맡기게 되면 되면 nexpert님 말씀대로 캐시타임아웃 까지는 장애이니 TTL 값을 극단적으로 낮춰야 장애시간이 짧아지겠죠. F5 Big IP의 경우 30초가 기본 설정이었던 기억입니다.