[네트워크]글로벌 서버 부하 분산 (GSLB, Global Server Load Balancing)

1. GSLB란 무엇인가?

일반적인 로드 밸런서(L4/L7 스위치)는 단일 데이터 센터(IDC) 내부에서 여러 대의 서버로 트래픽을 분산합니다. 반면, GSLB는 전 세계 혹은 전국 여러 곳에 분산된 데이터 센터 간의 트래픽을 분산하는 기술입니다.

쉽게 말해, 서울, 런던, 뉴욕에 각각 똑같은 웹 서비스 서버를 두고, 사용자가 접속했을 때 가장 가깝고 상태가 좋은 데이터 센터로 연결해 주는 대규모 교통정리 시스템입니다.

💡 왜 L4/L7 스위치만으로 부족할까?

• 인프라의 한계: 특정 IDC 전체가 정전되거나 지진 등의 재해로 마비되면, 그 안의 L4/L7 스위치도 함께 죽습니다.
• 물리적 거리(Latency): 뉴욕에 있는 사용자가 서울 IDC에 있는 L4 스위치로 접속하면, 빛의 속도 한계 때문에 네트워크 지연(Latency)이 발생할 수밖에 없습니다.

2. GSLB의 핵심 동작 원리: "DNS의 진화"

GSLB는 본질적으로 지능형 DNS(Domain Name System) 서버처럼 동작합니다.

일반 DNS는 도메인 이름을 주면 단순히 지정된 IP 주소만을 반환합니다. 하지만 GSLB는 도메인 요청이 들어왔을 때, 여러 데이터 센터의 상태를 실시간으로 확인한 후 최적의 데이터 센터 IP를 골라서 반환합니다.

🔄 트래픽 흐름 (Workflow)

1. 사용자 요청: 사용자가 브라우저에 example.com을 입력합니다.
2. Local DNS Query: 사용자의 Local DNS(KT, SKT 등 ISP의 DNS)가 해당 도메인의 권한을 가진 GSLB 서버로 IP를 문의합니다.
3. 상태 및 위치 체크: GSLB는 질의를 보낸 Local DNS의 IP 주소(위치)와 대상 데이터 센터들의 헬스 체크 상태를 확인합니다.
4. 최적의 IP 반환: GSLB는 사용자에게 가장 가깝고 건강한 데이터 센터 A의 IP(예: 1.1.1.1)를 Local DNS를 거쳐 사용자에게 반환합니다.
5. 직접 접속: 사용자는 반환받은 IP(1.1.1.1)로 데이터 센터 A에 직접 접속하여 서비스를 이용합니다.

3. GSLB의 주요 기술 및 판단 기준 (Metric)

GSLB가 "어떤 데이터 센터의 IP를 줄 것인가?"를 결정하는 핵심 알고리즘이자 기술들입니다.

• Health Check (상태 모니터링): 각 데이터 센터의 서버나 L4/L7 스위치가 살아있는지 주기적으로 검사합니다. 만약 뉴욕 IDC가 다운되면, GSLB는 뉴욕 IDC의 IP를 DNS 응답에서 즉시 제외합니다. (재해 복구, DR 시스템의 핵심)
• Geo-DNS (지리적 위치 기반): 요청을 보낸 Local DNS의 IP를 기반으로 사용자의 대략적인 위치를 파악합니다. 한국 사용자에게는 서울 IDC IP를, 미국 사용자에게는 버지니아 IDC IP를 반환합니다.
• RTT (Round Trip Time, 왕복 시간) 측정:
• GSLB가 각 지역의 Local DNS와 데이터 센터 간의 네트워크 응답 속도(RTT)를 실시간/주기적으로 측정하여 가장 빠른 경로의 IDC로 유도합니다.
• 가중치 분산 (Weighted Round Robin):
• 특정 데이터 센터의 인프라 용량이 더 크다면, 그쪽으로 트래픽이 더 많이 가도록 비율(예: 서울 70%, 뉴욕 30%)을 설정할 수 있습니다.

4. 핵심 프로토콜 및 관련 기술

① DNS 프로토콜 및 TTL (Time To Live)

• 내용: GSLB는 DNS 기반이기 때문에 UDP 53번 포트를 사용합니다.
• 교재 포인트: GSLB에서 가장 중요한 개념 중 하나가 TTL 관리입니다. TTL이 지나치게 길면 데이터 센터가 죽었을 때 사용자가 여전히 기존 IP(죽은 서버)로 접속을 시도하게 됩니다. 따라서 GSLB 환경에서는 일반 DNS보다 TTL을 매우 짧게 설정해야 합니다.
• GSLB의 핵심 목적은 "재해 복구(DR)"와 "실시간 트래픽 최적화"입니다. TTL이 길어지면 GSLB가 아무리 똑똑하게 동작해도 무용지물이 됩니다. 두 가지 시나리오를 통해 그 기술적 배경을 이해할 수 있습니다.
  1. 서울 IDC와 뉴욕 IDC가 정상 가동 중이며, 한국 사용자가 접속하여 GSLB가 서울 IDC IP(1.1.1.1)를 반환했습니다.
  2. 사용자의 Local DNS는 이 IP를 1시간 동안 캐싱합니다.
  3. [장애 발생]: 5분 뒤, 서울 IDC에 화재가 발생하여 전송이 완전히 중단되었습니다.
  4. GSLB의 헬스 체크 시스템이 이를 감지하고, 서울 IDC IP를 리스트에서 지운 뒤 뉴욕 IDC IP(2.2.2.2)를 줄 준비를 마쳤습니다.
  5. [문제 발생]: 하지만 한국 사용자가 다시 접속할 때, Local DNS는 GSLB에 물어보지 않고 캐시에 남아있는 서울 IDC IP(1.1.1.1)를 그대로 반환합니다.
  6. 결과적으로 사용자는 남은 55분 동안 계속해서 죽은 서버로 접속을 시도하며 서비스 불통(Blackout)을 겪게 됩니다.
  시나리오 B: TTL이 짧을 때 (예: 10초~60초) — 신속한 우회 (Failover)
  1. 서울 IDC가 죽었음을 GSLB가 감지합니다.
  2. 사용자의 캐시 유효기간(10초)이 이미 지났기 때문에, Local DNS는 GSLB에 새로운 IP를 요구합니다.
  3. GSLB는 즉시 살아있는 뉴욕 IDC IP(2.2.2.2)를 반환합니다.
  4. 사용자는 최대 10~60초 이내에 자동으로 정상적인 서버로 우회하여 접속할 수 있게 됩니다.
• 🚨 시나리오 A: TTL이 길 때 (예: 1시간 / 3600초) — 장애 복구 실패

② EDNS0 (Extension Mechanisms for DNS - Client Subnet)

• 내용: 원래 GSLB는 사용자가 아닌 Local DNS의 IP를 보고 위치를 판단합니다. 만약 한국 사용자가 구글 Public DNS(8.8.8.8, 미국에 본서버가 있음)를 사용하면, GSLB는 사용자가 미국에 있다고 오해하여 미국 IDC IP를 주는 문제가 발생합니다.
• 해결책: 이를 해결하기 위해 DNS 패킷에 실제 클라이언트의 서브넷(IP 대역) 정보를 포함해서 보내는 EDNS0 표준 프로토콜을 사용합니다. 이를 통해 GSLB는 정확한 사용자 맞춤형 IP를 찾아줄 수 있습니다.

③ Anycast (애니캐스트) 라우팅

• 내용: 전 세계 여러 GSLB 서버 또는 데이터 센터가 동일한 단 하나의 IP 주소를 공유하는 라우팅 기술입니다.
• 교재 포인트: BGP(Border Gateway Protocol) 라우팅을 이용해 사용자와 물리적으로 가장 가까운 네트워크 경로의 GSLB 서버가 자동으로 호출되도록 만드는 구조를 설명하면 좋습니다. 클라우드 서비스(AWS Route 53, Cloudflare 등)의 기반 기술이기도 합니다.

④ 헬스 체크 프로토콜 (Layer별 모니터링)

• L3 (ICMP): Ping을 날려 네트워크 연결성 자체를 확인.
• L4 (TCP Half Open / Connection): 특정 포트(예: 80, 443)가 열려있는지 확인.
• L7 (HTTP/HTTPS): 단순히 포트가 열린 것을 넘어, /health 같은 특정 URL에 요청을 보내 응답 코드 200 OK가 정상적으로 떨어지는지 확인하는 가장 정교한 방식.

5. GSLB vs CDN (Content Delivery Network) 비교

비교 항목	GSLB	CDN
주요 동작 계층	DNS 레벨 (Application/설정 기반)	네트워크 레벨 (L3/BGP 라우팅 기반)
위치 탐색 기술	GeoIP (Local DNS의 IP 기반 위치 추정)	Anycast (네트워크 경로상 가장 가까운 노드 맵핑)
반환 값	사용자가 접속할 실제 리전의 IP	CDN Edge Node의 Anycast IP
트래픽 처리	사용자를 특정 데이터센터로 토스만 함	콘텐츠를 캐싱하여 직접 응답, 필요시 오리진 프록시
핵심 목적	다중 데이터센터 간 부하 분산 및 재해 복구(DR)	정적/동적 콘텐츠의 전송 속도 가속화