DNS 장애 조치와 고가용성

DNS에는 근본적인 문제가 있습니다. 빠르게 작동하려면 캐싱이 필수적이지만, 장애 조치가 작동하려면 캐시가 만료되어야 합니다. 두 가지를 동시에 가질 수는 없습니다.

이 긴장 관계는 모든 DNS 기반 고가용성 시스템의 핵심에 자리하고 있습니다. 서버가 다운되면 DNS 레코드를 밀리초 단위로 업데이트할 수 있습니다. 하지만 수백만 개의 리졸버가 여전히 예전 주소의 캐시를 보유하고 있다면 그 업데이트는 아무 의미가 없습니다. 리졸버들은 캐시가 만료될 때까지 다운된 서버로 계속 트래픽을 보냅니다.

이 한계를 이해하고, 엔지니어들이 만들어온 영리한 해결책들을 파악하는 것이 실제로 안정적인 시스템을 설계하는 핵심입니다.

DNS 장애 조치의 작동 방식

DNS 장애 조치는 서버를 모니터링하고 문제가 발생했을 때 자동으로 DNS 레코드를 업데이트합니다. 사람이 장애를 인지하고, 관리 패널에 로그인하고, 레코드를 수정하는 대신, 자동화된 상태 검사가 장애를 감지하고 수 초 내에 백업 서버 주소로 교체합니다.

메커니즘은 단순합니다. DNS 제공업체가 HTTP, TCP, 또는 ICMP ping을 통해 서버를 지속적으로 점검하여 응답 여부를 확인합니다. 검사에 실패하면 제공업체는 DNS 응답에서 다운된 서버의 IP를 제거하거나 백업으로 교체합니다. 원래 서버가 복구되면 다시 추가됩니다.

이러한 자동화가 중요한 이유는 사람이 직접 대응하기에는 너무 느리기 때문입니다. 누군가 장애를 인지하고, 원인을 파악하고, 조치를 취할 때쯤이면 고객들은 이미 서비스 중단을 경험한 후입니다. 자동화된 장애 조치는 평균 복구 시간을 수분 또는 수 시간에서 수 초로 단축합니다.

실제로 작동하는 상태 검사

ping은 서버에 도달할 수 있음을 증명합니다. 하지만 애플리케이션이 정상 실행 중임을 증명하지는 않습니다.

웹 서버 프로세스가 충돌하거나, 데이터베이스 연결이 끊기거나, 애플리케이션이 모든 요청에 500 오류를 반환하더라도 서버는 ping에는 정상 응답할 수 있습니다. 단순한 상태 검사는 이런 장애를 전혀 감지하지 못합니다.

효과적인 상태 검사는 중요한 것, 즉 애플리케이션 전체를 검증합니다. HTTP 상태 검사는 전용 엔드포인트(/health 또는 /status)에 요청을 보내고 예상된 내용과 함께 200 OK가 반환되는지 확인합니다. 더 나은 검사는 데이터베이스를 조회하고, 캐시 연결을 확인하고, 서드파티 API에 접근 가능한지 검증합니다. 사용자가 실제로 궁금해하는 질문에 답하는 것입니다. "이 서버가 내 요청을 제대로 처리할 수 있을까?"

시간 설정도 중요합니다. 30초마다 검사하고 연속 세 번 실패를 기준으로 하면 장애 감지에 최대 90초가 걸립니다. 10초마다 검사하고 한 번 실패를 기준으로 하면 더 빨리 문제를 감지하지만, 일시적인 네트워크 불안정으로 인한 오탐 위험이 있습니다. 적절한 균형은 감지되지 않은 다운타임 1분과 불필요한 장애 조치 중 어느 쪽 비용이 더 큰지에 달려 있습니다.

지리적 위치도 상황을 복잡하게 만듭니다. 버지니아에서는 서버가 다운된 것처럼 보이지만 프랑크푸르트에서는 완벽하게 응답할 수 있습니다. 네트워크 라우팅 문제는 특정 경로에만 영향을 미치기 때문입니다. 정교한 제공업체는 여러 글로벌 위치에서 점검을 수행하고, 복수의 관측 지점에서 동시에 실패가 확인될 때만 장애 조치를 실행합니다.

TTL 트레이드오프

TTL(Time To Live)은 리졸버가 DNS 레코드를 캐시하는 시간을 결정합니다. 동시에 장애 조치 속도를 제어하는 조절 장치이기도 합니다.

TTL이 3600초라면 리졸버는 레코드를 최대 한 시간 동안 캐시할 수 있습니다. DNS를 업데이트하여 백업 서버를 가리키도록 해도, 일부 클라이언트는 59분 동안 다운된 서버로 요청을 보낼 수 있습니다. 중요한 서비스에서는 치명적입니다.

TTL을 60초로 낮추면 장애 조치가 1~2분 내에 전파됩니다. 하지만 이제 모든 리졸버가 1시간에 한 번이 아닌 매분마다 네임서버를 조회합니다. 쿼리 양이 급격히 증가하고, 잦은 조회로 인해 지연 시간도 약간 늘어납니다.

대부분의 프로덕션 시스템은 장애 조치가 필요할 수 있는 레코드에 대해 60~300초를 선택합니다. 일부는 동적 TTL을 구현하기도 합니다. 정상 운영 중에는 긴 값을 유지하다가, 상태 검사에서 불안정이 감지되면 자동으로 단축하는 방식입니다.

그런데 불편한 진실이 있습니다. TTL은 명령이 아니라 제안에 불과합니다. 일부 리졸버는 이를 무시하고 더 오래 캐시합니다. 운영 체제는 자체적인 캐싱 레이어를 추가합니다. 브라우저는 또 다른 캐시를 유지합니다. TTL이 60초라도 모든 캐시 레이어가 만료될 때까지 일부 사용자는 지연을 경험합니다.

네임서버 이중화

애플리케이션은 서버 간에 장애 조치할 수 있습니다. 하지만 DNS 자체가 다운되면 어떻게 될까요?

모든 도메인은 여러 네임서버를 등록합니다. 보통 두 개에서 네 개입니다. 이들은 서로 다른 IP 주소, 서로 다른 네트워크, 이상적으로는 서로 다른 지역에 분산되어야 합니다. 하나의 네임서버에 접근할 수 없게 되면 리졸버는 자동으로 나머지를 조회합니다. 이 이중화 기능은 DNS 프로토콜에 기본으로 내장되어 있습니다.

하지만 어떻게 분산하느냐가 중요합니다. 같은 데이터 센터에 네 개의 네임서버가 있다면 해당 데이터 센터가 전원을 잃었을 때 아무런 도움이 되지 않습니다. 같은 네트워크 사업자에 네 개의 네임서버를 두는 것도 그 사업자의 장애에는 무력합니다. 진정한 이중화는 여러 자율 시스템(AS)에 걸쳐 지리적으로 분산되어야 합니다.

많은 조직이 하이브리드 구성을 운영합니다. 자체 인프라에 두 개의 네임서버를, Cloudflare나 Route 53 같은 상용 제공업체에 두 개를 두는 방식입니다. 이를 통해 자체 인프라 장애와 제공업체 수준의 중단 모두에 대비할 수 있습니다.

애니캐스트: 네트워크 속도로 이루어지는 장애 조치

애니캐스트는 불가능하게 들리는 일을 합니다. 여러 위치에서 동일한 IP 주소를 동시에 알리는 것입니다.

애니캐스트 DNS 주소에 쿼리를 보내면, 인터넷의 라우팅 프로토콜인 BGP가 자동으로 쿼리를 가장 가까운 노드로 안내합니다. 같은 IP 주소가 도쿄, 런던, 뉴욕에 동시에 존재합니다. 라우팅 프로토콜 입장에서는 어디에 무엇이 있는지 알 필요도, 신경 쓸 필요도 없습니다. 그저 가장 가까운 경로를 찾을 뿐입니다.

이는 DNS로는 결코 달성할 수 없는 속도로 장애 조치를 제공합니다. 데이터 센터가 오프라인 상태가 되면 BGP는 수 초 내에 그곳으로의 트래픽 라우팅을 중단합니다. 상태 검사도, TTL 만료도, 전파 지연도 없습니다. 트래픽은 자동으로 다음으로 가까운 위치로 흐릅니다.

애니캐스트는 부하를 전 세계적으로 분산시키기도 합니다. 한 위치의 서버를 압도하는 DDoS 공격이 다른 위치에는 영향을 미치지 않습니다. 쿼리는 문제를 우회합니다. 성능도 향상됩니다. 가까운 서버가 응답하면 쿼리가 대륙을 넘을 필요가 없습니다.

자체 애니캐스트 네트워크를 구축하려면 IP 주소 할당, BGP 피어링 협약, 전 세계에 분산된 인프라가 필요합니다. 그래서 대부분의 조직은 이미 이를 구축한 Cloudflare, Google, Route 53 같은 전문 DNS 제공업체를 이용합니다.

DNS 장애 조치의 한계

DNS 장애 조치는 가치 있는 도구입니다. 하지만 한계도 분명합니다. 이 한계를 이해해야 실제로 장애에서 살아남는 시스템을 만들 수 있습니다.

캐싱이 모든 것을 지연시킵니다. DNS를 즉시 업데이트할 수 있지만, 클라이언트는 TTL이 만료될 때까지 캐시된 값을 사용합니다. 반면 애플리케이션 수준의 장애 조치, 즉 로드 밸런서가 다운된 백엔드를 감지하고 우회하는 방식은 즉시 적용됩니다.

DNS는 서버 부하를 파악하지 못합니다. 서버 간에 트래픽을 리디렉션하지만, CPU 사용률, 응답 시간, 대기열 깊이를 기반으로 지능적인 결정을 내릴 수 없습니다. 애플리케이션 수준의 로드 밸런서는 실시간 서버 상태를 기반으로 트래픽을 분산할 수 있습니다.

세션이 끊깁니다. 서버 A에서 활성 세션을 가진 사용자는 장애 조치 후 서버 B로 리디렉션됩니다. 세션 공유를 구현하지 않았다면 세션은 사라집니다. 애플리케이션 수준의 장애 조치는 세션 선호도를 더 안정적으로 유지합니다.

부분 장애는 감지하기 어렵습니다. 응답이 느리거나 10%의 요청에 실패하는 서버는 상태 검사를 통과할 수 있습니다. 완전히 다운된 게 아니라 저하된 상태입니다. DNS 상태 검사는 일반적으로 이 차이를 구분하지 못합니다. 애플리케이션 수준의 서킷 브레이커는 저하 상태를 감지하고 대응할 수 있습니다.

해결책은 DNS와 애플리케이션 수준의 장애 조치 중 하나를 선택하는 것이 아닙니다. 둘 다 사용하는 것입니다. DNS 장애 조치는 데이터 센터 간의 굵직한 이중화를 담당합니다. 애플리케이션 수준의 장애 조치는 서버 간의 세밀한 라우팅을 처리합니다. 함께 사용하면 계층적 방어가 만들어집니다. 어떤 계층에서든 발생한 장애를 다른 계층이 잡아냅니다.

DNS 장애 조치에 관해 자주 묻는 질문

DNS 장애 조치가 실제로 얼마나 빨리 트래픽을 전환할 수 있나요?

DNS 업데이트 자체는 수 초 안에 이루어집니다. 하지만 클라이언트는 캐시된 레코드가 만료될 때까지 변경 사항을 인지하지 못합니다. TTL이 60초이고 10초마다 상태 검사가 이루어진다면, 대부분의 트래픽은 1~2분 내에 전환됩니다. 적극적인 캐싱을 사용하는 일부 클라이언트는 더 오래 걸릴 수 있습니다. 애플리케이션 수준의 장애 조치는 훨씬 빠릅니다. 수분이 아닌 밀리초 단위입니다.

더 빠른 장애 조치를 위해 TTL을 가능한 한 낮춰야 할까요?

낮을수록 항상 좋은 것은 아닙니다. TTL이 5초라면 네임서버에 대한 쿼리 양이 급격히 증가하고, 잦은 조회로 지연 시간도 늘어나며, 실제로 60초와 큰 차이도 없습니다. 대부분의 프로덕션 시스템은 합리적인 균형점으로 60~300초를 사용합니다.

DNS 장애 조치가 로드 밸런서를 대체할 수 있나요?

아닙니다. DNS 장애 조치와 로드 밸런서는 서로 다른 문제를 해결합니다. DNS 장애 조치는 인프라 간, 보통 데이터 센터나 가용 영역 간에 트래픽을 전환합니다. 로드 밸런서는 해당 인프라 내의 서버 간에 트래픽을 분산하고, 세션 지속성을 처리하며, 장애에 즉시 대응합니다. 일반적으로 둘 다 필요합니다.

DNS 제공업체 자체가 다운되면 어떻게 되나요?

이것이 바로 네임서버 이중화가 중요한 이유입니다. 도메인의 네임서버는 여러 제공업체와 지리적 위치에 분산되어 있어야 합니다. 한 제공업체가 장애를 일으켜도 리졸버는 다른 제공업체에 쿼리를 보냅니다. 일부 조직이 상용 제공업체와 함께 자체 네임서버를 직접 운영하는 이유가 바로 이 때문입니다.

DNS 장애 조치 후에도 일부 사용자가 여전히 다운된 서버에 접속하는 이유는 무엇인가요?

여러 캐싱 레이어 때문입니다. 사용자가 쓰는 재귀 리졸버, 운영 체제의 DNS 캐시, 브라우저의 내부 캐시가 있습니다. 각 레이어가 만료되어야 새로운 주소가 적용됩니다. 일부 리졸버는 TTL을 무시하고 지정된 것보다 더 오래 캐시하기도 합니다. 그래서 DNS 장애 조치는 완전한 해결책이 아닌 첫 번째 방어선입니다.