Обновлено 1 месяц назад
DNS 부하 분산은 일종의 꼼수입니다—우아한 꼼수이지만요. "이게 어디 있지?"라는 질문에 답하도록 설계된 시스템을 "이걸 어디로 보내야 하지?"라는 질문에 답하는 시스템으로 전용하는 것입니다. 여러분이 마주치게 될 모든 한계는 바로 이 차이에서 비롯됩니다.
도메인 네임 시스템은 이름을 주소에 매핑합니다. 라우팅 결정을 내리도록 만들어진 시스템이 아닙니다. 하나의 도메인에 여러 IP 주소를 설정하면, DNS는 그것을 모두 반환합니다. 클라이언트가 그 중 하나를 선택합니다. 트래픽이 여러 서버에 분산됩니다. 작동은 합니다—하지만 망치로 나사를 박는 것과 같습니다. 상황에 따라 딱 맞을 수도 있지만, 이 도구에게 무엇을 요구하는지는 이해하고 있어야 합니다.
동작 원리
DNS 부하 분산은 하나의 도메인에 여러 A 레코드(IPv6의 경우 AAAA 레코드)를 설정하는 방식으로 작동합니다. 클라이언트가 쿼리를 보내면, DNS 서버는 여러 IP 주소를 응답으로 반환합니다. 클라이언트는 그 중 하나—보통 첫 번째—에 연결합니다. 어떤 주소가 첫 번째로 오는지를 바꿔가면서, DNS는 트래픽을 서버 풀 전체에 분산시킵니다.
이 과정은 사용자 눈에는 보이지 않게 이루어집니다. 사용자와 서버 사이에 추가 하드웨어가 필요하지 않습니다. 이미 보유하고 있는 DNS 레이어가 곧 부하 분산기가 됩니다.
핵심적인 제약이 곧바로 드러납니다: 바로 캐싱입니다. 재귀 확인자(recursive resolver)와 클라이언트 시스템은 TTL(Time-to-Live) 값에 따라 응답을 캐싱하는데—보통 수 분에서 수 시간까지입니다. 이 기간 동안 해당 클라이언트의 모든 요청은 서버 부하나 가용성에 관계없이 동일한 서버로 흘러갑니다.
DNS를 빠르게 만드는 캐싱이 바로 DNS 부하 분산을 조잡하게 만드는 원인이기도 합니다. 이 트레이드오프에서 벗어날 방법은 없습니다. 스펙트럼 어디에 위치할지를 선택할 수 있을 뿐입니다.
라운드 로빈 분산
라운드 로빈은 가장 단순한 기법입니다. 권한 있는 서버(authoritative server)가 여러 IP 주소를 유지하면서 그 순서를 돌아가며 바꿉니다. 어떤 클라이언트는 192.0.2.1, 192.0.2.2, 192.0.2.3을 받고, 다음 클라이언트는 192.0.2.2, 192.0.2.3, 192.0.2.1을 받습니다. 대부분의 클라이언트가 첫 번째 주소에 연결하기 때문에, 시간이 지나면서 트래픽이 서버들에 골고루 분산됩니다.
이 방식의 매력은 놀라울 만큼 단순하다는 데 있습니다. DNS 레코드를 여러 개 만들면 끝입니다.
한계도 그만큼 분명합니다. 라운드 로빈은 서버의 상태를 전혀 알지 못합니다. 용량의 두 배를 처리하고 있는 서버도, 부하에 허덕이는 서버도 똑같은 트래픽 몫을 받습니다. 시드니에 있는 서버가 스톡홀름의 연결 요청을 받는 동안 스웨덴에 있는 서버는 놀고 있을 수 있습니다. 서버가 장애를 일으켜도 DNS는 계속 그쪽으로 트래픽을 보냅니다—DNS는 서버가 죽었다는 사실을 모릅니다. 누군가가 레코드를 제거하기 전까지는 해당 주소를 계속 반환합니다.
TTL 값 설정은 이러지도 저러지도 못하는 상황을 만들어냅니다. 낮은 TTL(60초 이하)은 캐싱을 줄이지만 쿼리 양이 늘고 연결이 느려집니다. 높은 TTL은 성능을 향상시키지만 분산이 불균형해지고 장애 시간이 길어집니다. 어떤 값을 설정해도 두 가지 문제를 동시에 해결할 수 없습니다.
가중치 레코드
가중치 DNS는 비례 분산을 추가합니다. 모든 주소를 동등하게 취급하는 대신, 각 주소가 얼마나 자주 등장할지를 제어하는 가중치를 부여합니다.
서버 A의 가중치 100, 서버 B의 가중치 50, 서버 C의 가중치 25라면: DNS는 A의 주소를 B보다 두 배, C보다 네 배 더 자주 반환합니다. 트래픽 분산이 실제 서버 용량을 반영할 수 있게 됩니다.
클라우드 공급자—Route 53, Cloudflare, Google Cloud DNS—는 가중치 라우팅을 기본으로 지원합니다. 이는 마이그레이션 시 특히 유용합니다: 가중치를 조정하면서 기존 인프라에서 새 인프라로 점진적으로 트래픽을 이동할 수 있습니다. 갑작스러운 전환이 필요 없습니다.
하지만 가중치 DNS도 여전히 현재 상황을 파악하지 못합니다. 실제로 무슨 일이 벌어지고 있는지에 관계없이 정적인 설정에 따라 분산합니다. 서버가 과부하 상태이거나 오프라인이어도 DNS는 할당된 몫을 계속 보냅니다.
상태 확인 기반 장애 복구
상태 확인 DNS는 정적인 설정을 기본적인 모니터링으로 변환합니다. DNS 공급자가 서버를 주기적으로 확인하고—보통 10~30초마다—비정상 서버를 자동으로 응답에서 제외합니다.
서버가 연속적인 확인에 실패하면, 해당 서버는 DNS 응답에서 사라집니다. 복구되면 다시 등장합니다. 새 클라이언트는 정상적인 주소만 받게 됩니다. 수동 개입이 필요 없습니다.
구현 방식은 기본 TCP 연결 확인부터 HTTP 응답 검증, 콘텐츠 확인, 사용자 정의 상태 확인 스크립트까지 다양합니다. 지리적 장애 복구도 이를 확장한 것입니다: 한 지역에 기본 서버를, 다른 지역에 백업 서버를 유지하다가, 유럽 서버가 실패하면 트래픽이 자동으로 미국 서버로 이동합니다.
하지만 근본적인 제약은 여전히 남아 있습니다. 서버에 장애가 발생하면, 응답을 캐시한 클라이언트는 계속 연결을 시도합니다. 캐시된 TTL이 만료될 때까지 실패가 반복됩니다. 상태 확인이 장애를 감지하는 데는 수 초가 걸리지만, 클라이언트가 그 영향을 받는 시간은 수 분에 달합니다.
DNS 대 전용 부하 분산기
차이는 기능의 문제가 아니라 아키텍처의 문제입니다.
전용 부하 분산기—F5 BIG-IP 같은 하드웨어나, HAProxy, NGINX 같은 소프트웨어—는 클라이언트와 서버 사이에 위치합니다. 모든 연결을 받아 어떤 백엔드가 처리할지를 실시간으로 결정합니다. 실제 트래픽을 보고, 실제 부하를 알고, 장애를 즉시 감지하고, 즉시 재라우팅합니다.
DNS는 한 단계 떨어진 곳에서 작동합니다. 클라이언트가 어디로 갈지에 영향을 미치지만, 트래픽 자체는 절대 보지 못합니다. 방향만 알려줄 뿐, 직접 안내하지는 않습니다.
DNS 부하 분산:
- 추가 인프라 불필요
- 무한한 확장성 (DNS는 매일 수십억 건의 쿼리를 처리)
- DNS 공급자 이외의 단일 장애점 없음
- 추가 지연 없음
- TTL 단위의 거친 분산
- 실제 서버 부하를 전혀 파악하지 못함
- 세션 인식 불가
- 장애 복구에 수 분 소요 (밀리초가 아닌)
전용 부하 분산기:
- 배포 및 유지 관리가 필요한 추가 인프라
- 중요 경로(critical path) 구성 요소가 됨
- 실시간 부하 인식
- 상태 기반 애플리케이션을 위한 세션 지속성
- 1초 미만의 장애 복구
- SSL 종료, 헤더 조작, URL 라우팅
- 트래픽 검사 및 보안 기능
어느 쪽이 무조건 더 낫다고 할 수 없습니다. 근본적으로 다른 메커니즘으로 동일한 문제를 해결합니다.
DNS 부하 분산이 적합한 경우
지리적 분산. DNS는 이 영역에서 탁월합니다. 지리 위치 기반 라우팅은 유럽 클라이언트를 유럽 서버로, 아시아 클라이언트를 아시아 서버로 보냅니다. DNS 쿼리 자체에 위치 정보가 담겨 있습니다.
무상태(stateless) 서비스. 애플리케이션이 서버 측 상태를 유지하지 않는다면, DNS가 일관된 서버 선택을 보장하지 못하는 점은 문제가 되지 않습니다. 정적 콘텐츠, 무상태 API, 읽기 중심 워크로드는 효과적으로 분산됩니다.
예산 제약. DNS 부하 분산은 기존 DNS 서비스 비용 외에 추가 비용이 없습니다. 인프라 투자 없이 기본적인 이중화를 구현할 수 있습니다.
1단계 트래픽 분산. DNS를 이용해 지역 간 트래픽을 분산하고, 각 지역 내에서는 전용 부하 분산기를 배포합니다. DNS로 전 세계적인 규모를, 로컬에서는 세밀한 제어를 달성할 수 있습니다.
DNS 부하 분산이 실패하는 경우
세션 고정성 요구 사항. 사용자가 특정 서버에 계속 연결되어야 하는 경우—장바구니, 인증된 세션, WebSocket 연결—DNS의 예측 불가능한 라우팅이 사용자 경험을 망칩니다.
1초 미만의 장애 복구 필요. 60초 TTL과 즉각적인 상태 확인을 사용하더라도, 장애는 클라이언트에게 꼬박 1분간 영향을 미칩니다. 미션 크리티컬 시스템에는 전용 부하 분산기가 필요합니다.
트래픽 급증 패턴. DNS는 요청 양이 아닌 쿼리 양을 기준으로 분산합니다. 트래픽이 급증하면 일부 서버는 압도당하는 동안 다른 서버는 놀고 있습니다.
고급 트래픽 관리. SSL 종료, 헤더 조작, URL 라우팅, 웹 애플리케이션 방화벽—이 중 어느 것도 DNS 레이어에서는 존재하지 않습니다. DNS는 이름을 주소로 확인합니다. 그게 전부입니다.
냉정한 평가
DNS 부하 분산은 여러 IP 주소를 반환하고 클라이언트가 하나를 선택하게 합니다. 단순하고, 무료이며, 무한히 확장 가능합니다. 동시에 조잡하고, 실제 상황을 파악하지 못하며, 실시간이 아닌 TTL 단위로 장애를 처리합니다.
인터넷을 빠르게 만드는 캐싱이 DNS 부하 분산의 응답성을 제한합니다. 이에서 벗어날 수 없습니다. 분산 세분성과 조회 오버헤드 사이의 균형을 맞추는 TTL 값을 선택할 수 있을 뿐입니다.
지리적 분산과 무상태 서비스의 경우, DNS 부하 분산이 종종 딱 맞는 선택입니다. 세션 의존적인 애플리케이션과 미션 크리티컬 장애 복구에는 근본적으로 부적합합니다. 대부분의 프로덕션 환경은 이를 하나의 레이어로 사용합니다—DNS를 통한 글로벌 분산, 전용 부하 분산기를 통한 로컬 제어.
DNS는 이름 확인 시스템이 트래픽 안내자로 전용된 것입니다. 꼼수처럼 작동합니다—우아하게, 한계 내에서, 그리고 바로 그 전용에서 직접 비롯되는 트레이드오프와 함께.
DNS 부하 분산에 관한 자주 묻는 질문
DNS 부하 분산은 왜 장애가 난 서버로 계속 트래픽을 보내나요?
DNS는 디렉토리이지, 모니터링 시스템이 아닙니다. DNS에 물어보면, DNS는 설정에 있는 주소를 반환합니다—해당 주소가 실제로 작동하는지는 확인하지 않습니다. 상태 확인 DNS는 그 위에 모니터링을 추가하지만, 응답을 캐시한 클라이언트는 캐시가 만료될 때까지 오래된 주소를 계속 사용합니다. 장애 감지는 수 초가 걸릴 수 있지만, 클라이언트가 받는 영향은 TTL이 다할 때까지 지속됩니다.
DNS 부하 분산에 어떤 TTL을 사용해야 하나요?
완벽한 답은 없습니다. 낮은 TTL(3060초)은 더 빠른 장애 복구와 더 균등한 분산을 가능하게 하지만 DNS 쿼리 양이 증가합니다. 높은 TTL(515분)은 성능을 향상시키지만 분산이 불균형해지고 장애 시간이 길어집니다. 대부분의 구현은 타협점으로 60~300초를 선택합니다—하지만 이는 언제나 타협입니다.
DNS 부하 분산을 HTTPS와 함께 사용할 수 있나요?
네, 하지만 DNS는 HTTPS 아래 계층에서 작동합니다—도메인 이름을 IP 주소로만 확인합니다. SSL/TLS 협상은 클라이언트가 DNS가 선택한 서버에 연결한 후에 이루어집니다. 각 서버에는 해당 도메인에 유효한 인증서가 필요합니다. DNS는 SSL을 종료하거나 암호화된 트래픽을 검사할 수 없습니다.
DNS 부하 분산은 CDN과 어떻게 다른가요?
CDN은 더 큰 시스템의 한 구성 요소로 DNS(종종 지리 위치 기반 라우팅 포함)를 활용합니다. CDN은 또한 엣지 위치에서 콘텐츠를 캐싱하고, 전달 경로를 최적화하며, 오리진 장애 복구를 처리합니다. DNS 부하 분산은 단지 트래픽 방향 지정 부분입니다—클라이언트를 서버 쪽으로 가리키지만 콘텐츠를 캐싱하거나 최적화하지는 않습니다.
Была ли эта страница полезной?