GeoDNS: 위치 기반 DNS 라우팅

도쿄에 있는 누군가가 여러분의 웹사이트를 방문할 때, 그들은 아시아의 서버에 연결되어야 합니다. 런던에 있는 누군가가 같은 사이트를 방문할 때는 유럽 서버에 연결되어야 하죠. GeoDNS는 DNS 쿼리가 어디서 왔는지에 따라 서로 다른 IP 주소를 반환함으로써 이것을 가능하게 합니다.

같은 도메인 이름, 다른 목적지. DNS는 더 이상 전화번호부가 아닙니다. 서 있는 위치를 보고 가장 가까운 문을 가리켜 주는 교통경찰이 되는 셈이죠.

GeoDNS란 무엇인가?

GeoDNS는 누가 묻느냐에 따라 다른 답을 주는 DNS입니다. 모든 사람에게 같은 IP 주소를 반환하는 대신, GeoDNS가 활성화된 권한 네임서버는 요청이 어디서 왔는지 확인하고, 지리적 위치를 파악한 뒤, 가까운 서버의 IP 주소로 응답합니다.

GeoDNS 제공업체가 www.example.com에 대한 쿼리를 받으면, DNS 리졸버의 출발지 IP 주소를 확인하고, 지리 데이터베이스를 이용해 위치를 파악하고, 여러분의 라우팅 정책을 참조합니다. 그 정책은 이런 식일 수 있습니다: 아시아에서 오는 쿼리는 203.0.113.10으로, 유럽에서 오는 쿼리는 198.51.100.20으로, 북미에서 오는 쿼리는 192.0.2.30으로.

사용자들은 자신이 어디에 있든 같은 도메인 이름을 입력합니다. DNS 시스템은 조용히 그들을 최적의 엔드포인트로 라우팅합니다.

위치 감지는 어떻게 작동하는가

GeoDNS는 여러분의 위치를 파악하기 위해 두 가지 방법을 사용하며, 두 방법 모두 맹점이 있습니다.

리졸버 IP 지오로케이션은 전통적인 방식입니다. GeoDNS 서버는 쿼리를 보낸 DNS 리졸버의 IP 주소를 확인하고, 데이터베이스(MaxMind GeoIP2 같은)를 사용해 그 리졸버가 어디에 있는지 파악합니다.

문제는 리졸버의 위치가 당신의 위치와 다를 수 있다는 점입니다. 싱가포르에 있지만 Google의 공개 DNS인 8.8.8.8을 사용한다면, 쿼리가 Google의 캘리포니아 인프라를 통해 라우팅될 수 있습니다. GeoDNS 서버는 당신을 미국인으로 인식하고 북미 서버로 보내버립니다 — 정작 당신은 아시아에 앉아서 왜 이렇게 느린지 고개를 갸웃하면서요.

**EDNS 클라이언트 서브넷(ECS)**이 이 문제를 해결합니다. ECS는 DNS 리졸버가 쿼리에 실제 IP 주소의 일부를 포함하도록 합니다. 권한 서버가 "이 쿼리는 8.8.8.8에서 왔다"고만 보는 대신, "이 쿼리는 203.0.113.0/24의 클라이언트를 대신해 8.8.8.8에서 왔다"고 볼 수 있게 됩니다. 이제 서버는 실제 사용자 위치를 기반으로 라우팅할 수 있습니다.

Google Public DNS 같은 주요 리졸버들은 ECS를 지원합니다. 프라이버시를 중시하는 리졸버들은 대개 지원하지 않습니다 — 의도적으로 클라이언트 정보를 노출하지 않으려 하기 때문입니다. APNIC Labs의 2024년 연구에 따르면, 인터넷 사용자의 약 12%가 ECS를 사용하는 리졸버를 통해 서비스를 받습니다¹. 제대로 된 GeoDNS 구현은 두 시나리오 모두를 처리하며, ECS가 없을 때는 리졸버 기반 지오로케이션으로 대체합니다.

GeoDNS가 중요한 이유

**콘텐츠 전송 네트워크(CDN)**가 가장 일반적인 사용 사례입니다. CDN은 전 세계 수십 또는 수백 개의 엣지 위치에 콘텐츠를 캐시합니다. GeoDNS는 사용자를 가장 가까운 캐시로 보내 지연 시간을 크게 줄입니다. 50개 도시에 엣지 서버를 둔 스트리밍 서비스는 지능적으로 라우팅하는 단일 호스트명을 통해 모든 사람에게 서비스를 제공할 수 있습니다.

글로벌 로드 밸런싱은 트래픽을 여러 대륙의 데이터 센터에 분산시킵니다. 모든 트래픽을 한 곳으로 집중시키는 대신, 기업들은 각 사용자를 가장 가까운 시설로 라우팅합니다. 유럽 데이터 센터가 다운되면, GeoDNS는 자동으로 유럽 사용자를 북미나 아시아로 보냅니다.

규제 준수는 점점 더 GeoDNS를 필요로 합니다. GDPR 같은 데이터 현지화 법은 특정 데이터가 특정 국경 안에 머물도록 요구합니다. GeoDNS는 애플리케이션 코드가 실행되기 전에 EU 사용자가 EU 서버에 연결되도록 보장합니다. 라우팅 정책이 인프라 수준에서 법적 경계를 강제하는 것입니다.

재해 복구는 자동화된 페일오버를 위해 GeoDNS를 활용합니다. 한 지역이 오프라인이 되면, DNS는 영향받은 사용자를 정상 지역으로 리다이렉트합니다. 즉각적이지는 않습니다 — 캐시된 DNS 응답은 TTL이 만료될 때까지 유지됩니다 — 하지만 수동 개입 없이 인프라 수준의 복구를 제공합니다.

핵심 가정 (그리고 실패하는 경우)

GeoDNS는 근접성이 성능을 예측한다고 가정합니다. 사용자를 가까운 서버로 라우팅하면 지연 시간이 낮아집니다. 보통은 맞습니다. 때로는 틀립니다.

지도 위의 최단 경로가 네트워크 위의 최단 경로는 아닙니다. 80킬로미터밖에 떨어지지 않은 두 도시도 서로 다른 나라에 있다면 최적 라우팅이 완전히 달라질 수 있습니다. 국경은 근접성을 무시하는 네트워크 경계를 만들어냅니다. 밴쿠버의 사용자는 같은 캐나다인 토론토보다 미국의 시애틀에서 더 나은 성능을 얻을 수도 있습니다.

지오로케이션 데이터베이스는 완벽하지 않습니다. 북미와 유럽에서는 정확도가 괜찮지만, 다른 지역에서는 불안정합니다. 모바일 네트워크, VPN, 기업 네트워크는 이러한 데이터베이스를 자주 혼란시킵니다. IP 주소 할당은 끊임없이 변하고, 데이터베이스는 그 뒤를 따라가기가 벅찹니다.

DNS 캐싱이 모든 것을 지연시킵니다. GeoDNS 라우팅을 즉시 업데이트해도, 캐시된 응답을 가진 클라이언트는 TTL이 만료될 때까지 계속 그것을 사용합니다. TTL을 낮추면 페일오버가 빨라지지만 권한 서버의 쿼리 볼륨이 높아집니다.

모든 사람이 ECS를 사용하지는 않습니다. 많은 리졸버가 ECS를 지원하지 않으며, 지원하더라도 프라이버시 정책이 공유되는 서브넷 정보를 제한합니다. ECS가 없을 때도 구현이 제대로 작동해야 합니다.

GeoDNS를 제대로 작동시키기

넓게 시작하세요. 도시 수준의 정밀도를 시도하기 전에 대륙이나 국가 수준으로 라우팅하세요. 넓은 지역은 더 신뢰할 수 있고 지오로케이션 오류에 덜 취약합니다. 실제 트래픽 패턴을 이해한 뒤에 세분화를 높이세요.

가정된 성능이 아닌 실제 성능을 측정하세요. 지리적 근접성이 낮은 지연 시간을 보장하지는 않습니다. 실제 사용자 모니터링을 활용해 다른 지역에서 다른 엔드포인트까지의 실제 연결 시간을 측정하세요. 네트워크가 실제로 연결되는 방식 때문에 더 먼 데이터 센터에서 더 나은 성능을 얻는 경우도 있습니다.

적절한 TTL을 설정하세요. 300초(5분)는 응답성과 쿼리 볼륨 사이의 균형을 잘 잡아줍니다. 특별한 요구사항이 있고 부하를 감당할 수 있는 경우가 아니라면 60초 미만의 TTL은 피하세요.

헬스 체크를 구현하세요. GeoDNS 제공업체는 엔드포인트를 적극적으로 모니터링하고 헬스 체크에 실패한 곳으로의 라우팅을 중단해야 합니다. 헬스 체크 없이는, GeoDNS가 죽은 인프라로도 기꺼이 사용자를 안내하게 됩니다.

다양한 리졸버에서 테스트하세요. Google Public DNS에서 잘 작동하는 것이 ISP 리졸버나 기업 DNS에서는 다르게 라우팅될 수 있습니다. 여러 공개 리졸버, 기업 네트워크, 모바일 통신사에서 테스트하세요.

폴백 라우팅을 정의하세요. 지오로케이션이 실패하거나 모호한 결과를 반환할 때를 대비해 적절한 기본값을 마련해 두세요. 위치를 알 수 없는 경우에는 가장 크거나 가장 신뢰할 수 있는 데이터 센터로 라우팅하세요.

제공업체 옵션

여러 DNS 제공업체가 다양한 기능의 GeoDNS를 제공합니다:

• AWS Route 53은 대륙, 국가, 미국 주 수준의 지오로케이션 라우팅을 제공하며, 특정 리소스에 대한 트래픽을 가깝게 또는 멀리 편향시킬 수 있는 지리 근접 라우팅도 제공합니다²
• Cloudflare는 활성 헬스 체크와 함께 로드 밸런싱에 지리적 라우팅을 포함합니다
• IBM NS1 Connect는 지리적 근접성이 아닌 실제 성능에 기반해 라우팅하기 위해 실제 사용자 모니터링 데이터를 활용하는 정교한 트래픽 관리를 제공합니다³
• Oracle DNS(구 Dyn)와 UltraDNS는 상세한 분석이 포함된 엔터프라이즈급 GeoDNS를 제공합니다

제공업체를 평가할 때는 지오로케이션 데이터베이스 소스, 갱신 주기, ECS 지원, 헬스 체크 기능, 그리고 단순한 지리적 근접성이 아닌 실제 측정된 성능에 기반해 라우팅할 수 있는지를 살펴보세요.

GeoDNS에 관한 자주 묻는 질문

GeoDNS 위치 감지는 얼마나 정확한가?

정확도는 지역과 방법에 따라 다릅니다. EDNS 클라이언트 서브넷을 사용하면 선진 시장에서 국가 수준 정확도는 보통 95%를 넘습니다. ECS 없이는 리졸버 위치에 전적으로 의존하는데 — 전 세계에 분산된 인프라를 가진 공개 DNS 제공업체를 쓰는 사용자에게는 이 값이 완전히 틀릴 수도 있습니다. 도시 수준 정확도는 어디서나 덜 신뢰할 수 있으며, 모바일 네트워크는 특히 예측하기 어렵습니다.

GeoDNS는 VPN과 함께 작동하는가?

GeoDNS는 여러분이 어디에 있다고 파악되는지에 따라 라우팅합니다. VPN 사용자의 경우, 그 기준이 되는 것은 VPN 출구 지점입니다. 런던에 있지만 뉴욕을 통해 나가는 VPN을 사용한다면, GeoDNS는 여러분을 미국인으로 봅니다. 이게 VPN 사용자가 원하는 결과일 수도 있지만, GeoDNS의 성능 최적화는 무력화됩니다. 시스템은 설계된 대로 작동하고 있을 뿐입니다 — 다만 여러분이 자신의 위치에 대해 솔직하다고 가정하는 것이죠.

가장 가까운 서버가 다운되면 어떻게 되는가?

헬스 체크가 구성되어 있으면, GeoDNS는 실패한 엔드포인트를 자동으로 순환에서 제거합니다. 해당 서버로 라우팅될 뻔했던 사용자는 차선책으로 보내집니다. 헬스 체크 없이는, GeoDNS가 수동으로 설정을 업데이트할 때까지 죽은 인프라로 계속 라우팅합니다. 반드시 헬스 체크를 설정하세요.

GeoDNS 페일오버는 얼마나 빠른가?

페일오버 속도는 DNS TTL에 의해 제한됩니다. TTL이 300초라면, 캐시된 응답을 가진 사용자는 라우팅이 변경된 후 최대 5분 동안 이전 엔드포인트를 계속 사용합니다. 헬스 체크로 트리거된 페일오버는 새 쿼리에 대해 즉시 시작되지만, 캐시된 응답은 그동안 계속 유효합니다. 그래서 GeoDNS는 초기 DNS 확인 이후에도 리다이렉트할 수 있는 애플리케이션 수준의 페일오버 메커니즘과 함께 사용할 때 가장 효과적입니다.

출처