로드 밸런싱과 고가용성 (2) - DNS 기반 로드 밸런싱 - soo:bak
작성일 :
DNS로 어떻게 트래픽을 분산하는가
Part 1에서 로드 밸런서의 기본 원리를 살펴보았습니다.
로드 밸런서는 클라이언트와 서버 사이에 위치하지만, 로드 밸런서 자체가 병목이 될 수도 있습니다. 더 앞단에서 분산할 수는 없을까요?
이 질문에 대한 답이 바로 DNS입니다. DNS를 활용하면 클라이언트가 로드 밸런서에 도달하기 전에 트래픽을 분산할 수 있습니다.
DNS 라운드 로빈
DNS는 도메인 이름을 IP 주소로 변환하는데, 하나의 도메인에 여러 IP 주소를 등록할 수 있습니다.
1
2
3
example.com. IN A 203.0.113.1
example.com. IN A 203.0.113.2
example.com. IN A 203.0.113.3
DNS 서버는 응답할 때마다 IP 주소의 순서를 바꿔서 반환합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
첫 번째 쿼리 응답:
203.0.113.1
203.0.113.2
203.0.113.3
두 번째 쿼리 응답:
203.0.113.2
203.0.113.3
203.0.113.1
세 번째 쿼리 응답:
203.0.113.3
203.0.113.1
203.0.113.2
대부분의 클라이언트는 첫 번째 IP를 사용하기 때문에, 결과적으로 트래픽이 분산됩니다.
DNS 라운드 로빈의 한계
그러나 이 방식에는 몇 가지 한계가 있습니다.
헬스 체크 없음:
- DNS는 서버가 죽었는지 모름
- 죽은 서버의 IP도 계속 응답
캐싱 문제:
- 클라이언트, 리졸버가 결과를 캐시
- 변경 사항이 즉시 반영되지 않음
불균등 분산:
- 기업 NAT 뒤의 수천 명이 같은 캐시 사용
- 한 IP로 트래픽 쏠림
세션 지속성 없음:
- 다음 DNS 쿼리에서 다른 IP를 받을 수 있음
단순한 분산에는 괜찮지만, 정교한 제어가 필요하면 부족합니다. 이러한 한계를 보완하기 위해 더 발전된 DNS 기반 분산 방식이 등장했습니다.
지리 기반 라우팅 (GeoDNS)
GeoDNS는 클라이언트의 위치에 따라 다른 IP를 응답하여, 사용자를 가장 가까운 서버로 안내합니다.
1
2
3
한국 사용자: example.com → 1.2.3.4 (서울 서버)
미국 사용자: example.com → 5.6.7.8 (버지니아 서버)
유럽 사용자: example.com → 9.10.11.12 (프랑크푸르트 서버)
클라이언트 위치 추정
그런데 DNS 쿼리에는 원래 클라이언트 IP가 포함되지 않습니다. DNS 서버는 리졸버의 IP만 볼 수 있어서, 위치 추정이 부정확해질 수 있습니다.
1
2
3
4
5
6
7
8
클라이언트 (한국)
│
▼
리졸버 (미국 Google DNS: 8.8.8.8)
│
▼
권위 DNS 서버
(8.8.8.8을 보고 미국으로 판단 → 잘못된 응답!)
EDNS Client Subnet (ECS)
이 문제를 해결하기 위해 RFC 7871로 정의된 EDNS Client Subnet이 등장했습니다. 이 확장을 통해 리졸버가 클라이언트의 서브넷을 권위 DNS에 전달합니다.
1
2
3
4
5
6
7
8
9
클라이언트: 203.0.113.42
│
▼
리졸버 (Google DNS):
쿼리에 포함: EDNS-CLIENT-SUBNET: 203.0.113.0/24
│
▼
권위 DNS 서버:
203.0.113.0/24는 한국 → 한국 서버 IP 응답
프라이버시를 고려하여 전체 IP가 아닌 서브넷(/24 등)만 전송하기 때문에 대략적인 위치만 노출됩니다.
GSLB (Global Server Load Balancing)
GSLB는 데이터센터 간 트래픽을 분산하는 기술로, DNS와 로드 밸런싱을 결합한 형태입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌─────────────────────────────────────────────────────────────┐
│ GSLB │
│ │
│ - 각 데이터센터의 상태 모니터링 │
│ - 클라이언트 위치 기반 최적 데이터센터 선택 │
│ - 장애 시 다른 데이터센터로 자동 전환 │
│ │
└──────────────────────────┬──────────────────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 서울 │ │ 도쿄 │ │ 싱가포르 │
│ DC │ │ DC │ │ DC │
└─────────┘ └─────────┘ └─────────┘
GSLB의 결정 요소
지리적 거리:
- 클라이언트와 가까운 데이터센터
- 지연 시간 최소화
서버 상태:
- 헬스 체크로 데이터센터 가용성 확인
- 장애 데이터센터 자동 제외
부하 상태:
- 각 데이터센터의 현재 부하 확인
- 과부하 데이터센터 회피
정책:
- 특정 지역은 특정 데이터센터로 고정
- 규정 준수 (데이터 주권 등)
Anycast
Anycast는 같은 IP 주소를 여러 위치에서 광고하는 방식입니다. BGP 라우팅 프로토콜이 자동으로 클라이언트를 가장 가까운 서버로 안내합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Anycast IP: 203.0.113.1
┌──────────────────────────────────────┐
│ 인터넷 │
│ │
│ BGP가 최단 경로 선택 │
│ │
└──────────┬───────────┬───────────────┘
│ │
┌──────────┼───────────┼──────────────┐
│ │ │ │
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 서울 │ │ 도쿄 │ │ 런던 │ │ 뉴욕 │
│203.0.113.1│ │203.0.113.1│ │203.0.113.1│ │203.0.113.1│
└─────────┘ └─────────┘ └─────────┘ └─────────┘
한국 사용자 → 자동으로 서울 서버로 라우팅
Anycast의 특징
장점:
- DNS 수정 없이 자동 분산
- BGP 기반으로 빠른 장애 전환
- DDoS 공격 분산
단점:
- TCP 연결 문제 (경로 변경 시 연결 끊김)
- BGP 수렴 시간 필요
- 복잡한 운영
이러한 특성 때문에 Anycast는 주로 DNS 서버, CDN 에지처럼 짧은 UDP 트랜잭션에 적합합니다.
DNS TTL과 장애 복구
TTL(Time To Live)은 DNS 레코드의 캐시 유지 시간으로, 장애 복구 속도에 직접적인 영향을 미칩니다.
1
2
3
example.com. 300 IN A 203.0.113.1
│
└── TTL: 300초 (5분)
낮은 TTL의 트레이드오프
낮은 TTL (예: 60초)은 빠른 변경 반영과 장애 복구가 가능하지만, DNS 쿼리 증가로 권위 DNS 부하와 클라이언트 지연이 증가합니다.
반면 높은 TTL (예: 86400초 = 24시간)은 DNS 쿼리와 부하가 감소하지만, 변경 사항 반영에 최대 24시간이 걸리고 장애 시 복구가 지연됩니다.
장애 복구 시나리오
서울 데이터센터에 장애가 발생했고 DNS TTL이 1시간인 경우를 살펴봅시다.
1
2
3
4
5
6
7
8
9
10
11
12
13
시간 0: 장애 발생
- GSLB가 서울 DC 제외
- 새 DNS 응답에서 서울 IP 제거
시간 0~60분:
- 기존 캐시가 유효
- 일부 사용자는 여전히 서울로 접속 시도
- 연결 실패
시간 60분 후:
- 캐시 만료
- 새 쿼리 → 정상 DC의 IP 수신
- 서비스 복구
DNS 캐시 문제
TTL을 낮춰도 모든 리졸버가 이를 존중하지 않습니다. 일부 ISP 리졸버는 부하 감소를 위해 최소 TTL을 강제하거나 TTL을 무시하며, 브라우저와 OS도 자체적으로 DNS 결과를 캐시합니다.
완벽한 즉시 전환은 DNS만으로 불가능하다는 뜻입니다.
해결책: 다중 방어 계층
따라서 DNS TTL만으로 장애 복구에 의존하면 안 됩니다. 실무에서는 다음과 같은 다중 방어 계층을 구축합니다.
1. 클라이언트 측 재시도 로직:
- 첫 번째 IP로 연결 실패 시 다음 IP로 자동 재시도
- 애플리케이션이나 SDK에 내장
2. 낮은 TTL + GSLB 헬스체크 조합:
- TTL을 60초 정도로 설정
- GSLB가 실시간으로 장애 서버 제외
3. Anycast와 BGP 기반 장애 전환:
- 경로 철회로 수초 내 자동 전환
- DNS 캐시와 무관하게 작동
4. CDN/프록시 계층 추가:
- CloudFlare, AWS CloudFront 등 앞단 배치
- CDN이 오리진 장애 감지 후 다른 오리진으로 전환
1
2
3
4
5
6
7
8
9
10
┌─────────────────────────────────────────────────────────────┐
│ 다중 방어 계층 예시 │
│ │
│ 클라이언트 ─► CDN (Anycast) ─► LB ─► 서버 │
│ │ │ │ │
│ 재시도 로직 즉시 전환 헬스체크 │
│ │ │ │ │
│ DNS 캐시와 BGP 기반 장애 서버 │
│ 독립적 복구 수초 복구 자동 제외 │
└─────────────────────────────────────────────────────────────┘
핵심은 DNS만 의존하지 않고 여러 계층에서 장애를 감지하고 복구하는 것입니다.
다중 레벨 로드 밸런싱
지금까지 살펴본 기술들을 종합하면, 실제 대규모 서비스는 여러 계층의 로드 밸런싱을 조합하여 사용합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
사용자
│
▼
┌─────────────────────────────────────────┐
│ DNS/GSLB (글로벌 분산) │
│ - 지역별 데이터센터 선택 │
└─────────────────────┬───────────────────┘
│
▼
┌────────────────────────┐
│ CDN 에지 (정적 콘텐츠) │
│ - Anycast 기반 │
└────────────┬───────────┘
│
▼
┌────────────────────────┐
│ L4 로드 밸런서 │
│ - 대용량 처리 │
│ - TCP 연결 분산 │
└────────────┬───────────┘
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ L7 로드 │ │ L7 로드 │ │ L7 로드 │
│ 밸런서 │ │ 밸런서 │ │ 밸런서 │
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ 서버들 │ │ 서버들 │ │ 서버들 │
└─────────┘ └─────────┘ └─────────┘
실제 구현: Route 53, CloudFlare, Akamai
앞서 설명한 DNS 기반 로드 밸런싱은 다양한 클라우드 서비스에서 제공됩니다.
Amazon Route 53
AWS의 관리형 DNS 서비스로, 다양한 라우팅 정책을 지원합니다.
라우팅 정책:
- Simple: 기본 라운드 로빈
- Weighted: 가중치 기반 분산
- Latency: 지연 시간 기반 선택
- Geolocation: 지역 기반
- Failover: Active-Passive 장애 복구
헬스 체크와 연동:
1
건강한 엔드포인트만 응답에 포함
CloudFlare
CloudFlare는 CDN, DNS, 보안을 통합 제공하는 서비스입니다.
특징:
- 글로벌 Anycast 네트워크
- 자동 헬스 체크
- DDoS 보호
- 로드 밸런싱 (유료)
Akamai
Akamai는 세계 최대 CDN 중 하나로, GTM(Global Traffic Management)을 통해 정교한 트래픽 관리를 제공합니다.
GTM의 특징:
- 실시간 성능 데이터 기반 라우팅
- 다양한 로드 밸런싱 알고리즘
- 복잡한 장애 복구 정책
정리: DNS는 첫 번째 관문
DNS 기반 로드 밸런싱은 글로벌 분산의 첫 단계로서, 별도 장비 없이 지역/대륙 단위 트래픽을 분산할 수 있습니다. 그러나 정밀한 제어가 어렵고, 캐싱으로 인한 지연과 헬스 체크 연동의 복잡성이라는 한계가 있습니다.
DNS는 첫 번째 관문의 역할을 담당합니다. 정밀한 분산과 신속한 장애 복구는 그 뒤의 로드 밸런서가 책임집니다.
Part 3에서는 고가용성 아키텍처를 살펴봅니다.
관련 글