Akamai Diversity

Akamai 블로그

지리적 위치와 DNS 트래픽 관리

GTM이란?

GTM(Global Traffic Management)은 애플리케이션 소유자에게 기존의 온프레미스 솔루션과 비교할 수 없는 높은 수준의 유연성과 인사이트를 제공하는 DNS 기반의 부하 분산 서비스입니다. 뛰어난 확장성과 내고장성을 갖추고 있고 엔드포인트 사이에 하나의 추상화된 레이어를 제공하기 때문에 트래픽이 목표 지점 사이를 원활하게 이동할 수 있습니다. GTM은 탄력적으로 부하를 분산할 뿐만 아니라 클라이언트 위치, 네트워크 상태, 오리진 서버 가용성을 기반으로 지능적인 라우팅 결정을 내립니다. 이런 모든 기능 뿐만 아니라 GTM의 자동적인 데이터 기반의 라우팅 최적화 엔진은 모두 Akamai의 인터넷에 대한 탁월한 가시성을 기반으로 합니다.

이 글에서는 GTM의 Geo-IP 인텔리전스 기능을 살펴보고, 사용자의 지리적 위치 탐지와 관련된 DNS 프로토콜의 알려진 제약사항을 Akamai 플랫폼이 어떻게 해결하는지 설명합니다.


DNS와 지리적 위치 제약사항

DNS 프로토콜의 미니멀리즘적 특성은 복잡한 부하 분산 요구사항에 직면했을 때 문제를 야기합니다. 예를 들어, 애플리케이션 소유자가 GTM과 같은 DNS 트래픽 관리 플랫폼을 설정하여 사용자 위치(클라이언트 IP 주소로부터 얻은 정보)를 기반으로 핸드아웃 결정을 동적으로 실행하고 싶어할 수 있습니다. 수신되는 DNS 쿼리는 일반적으로 요청하는 리커시브 리졸버의 IP 주소만 전파하고, 실제 클라이언트 IP는 공개하지 않습니다.[1] 로컬 리커시브 리졸버는 요청하는 머신 가까이에 위치한 경우가 대부분이지만, 멀리 있는 프록시 서버가 사용자를 대신해 DNS 룩업을 하는 경우에는 지리적 위치 탐지가 왜곡될 수 있습니다. HTTP와 달리 DNS는 'X-Forwarded-For'가 없기 때문에 응답하는 네임서버가 실제 최초 클라이언트 IP를 알 수 없어 지오 라우팅 결정이 어려워집니다. 아래 그림을 보면, 네임서버는 사용자의 IP(1.2.3.4)를 확인할 수 없고 리커시브 리졸버 주소(3.4.5.6)만 알 수 있습니다.

newgtmone.png


백엔드 GTM

Akamai의 관점에서 봤을 때, 이 시나리오는 Akamai 엣지 서버가 GTM 프로퍼티에 대해 DNS 룩업을 수행하고 클라이언트 요청에 대응하기에 가장 적합한 '오리진' 데이터센터를 결정하려는 경우에 해당합니다. 이런 설정은 보통 '백엔드' GTM으로 분류되는데, 아래 그림에서 두 번째 원으로 표시되어 있습니다[2]:

newgtmtwo.png

Akamai GTM은 클라이언트의 리커시브 리졸버 위치를 확인할 수 있는 IP 인텔리전스를 포함합니다. 따라서 애플리케이션 소유자는 이 정보를 바탕으로 트래픽 라우팅 결정을 설정하여 사용자를 지리적으로 가장 적합한 데이터 센터로 라우팅할 수 있습니다. 하지만 백엔드 GTM의 경우에는 Akamai 서버가 GTM 프로퍼티를 쿼리하므로 GTM 네임서버는 실제 사용자가 아닌 이 엣지 노드의 위치만 알 수 있습니다. 다행히 234개국에 위치한 25만여 대의 엣지 서버로 이루어진 Akamai 플랫폼의 방대한 규모 덕분에 사용자는 지리적으로 가까운 엣지 서버로 지능적으로 라우팅됩니다. 따라서 백엔드 GTM인 경우에도 위치 기반 핸드아웃 결정의 정확도가 최대한 높게 유지됩니다.

하지만 여러 대의 Akamai 서버가 관여되는 경우에는 어떤 일이 일어날까요? Akamai CDN의 주요 특징 중 하나는 바로 2단계 캐시 계층입니다. 최초 엣지 서버의 디스크나 메모리에 캐시 가능한 파일이 없는 경우, 해당 요청은 다른 Akamai 서버(캐시 페어런트)로 전달되어 캐시 히트를 반환할 확률을 극대화합니다.

newgtmthree.png

이 단계에서도 캐시에 오브젝트가 없는 경우, 두 번째 '페어런트' 서버가 GTM 프로퍼티에 대해 '백엔드' DNS 룩업을 실행하여 해당 오리진 IP를 확인합니다. 이와 같은 계층 분산 모델은 부하 분산이라는 측면에서 최적의 성능을 보입니다. 하지만 요청 흐름에 Akamai 홉을 하나 더 추가할 경우 두 번째 Akamai 서버가 최초 엣지 노드(위 그림의 '차일드' 서버)와 동일한 지역에 있다는 보장이 없기 때문에 사용자의 실제 위치에 대한 GTM의 가시성이 저하됩니다. 이를 고려하지 않을 경우 GTM IP 인텔리전스는 페어런트 서버의 위치를 기준으로 요청을 라우팅하게 되는데, 이는 바람직한 경우가 아닙니다.

Akamai는 이와 같은 DNS 제약사항을 해결하기 위해 백엔드 GTM 지리적 위치 로직이 계층 분산과 상호 운용될 수 있도록 메타데이터 태그를 개발했습니다. 메타데이터 태그는 항상 최초의 Akamai 차일드 서버에서 오리진 DNS 룩업을 수행하도록 플랫폼에 지시하며, 오리진 서버에 접속해야 하는 경우 결과가 해당 페어런트 서버로 전달됩니다[3]. 차일드 서버가 지리적으로 사용자를 대신하고 있기 때문에 이를 통해 지역 기반의 GTM 결정의 정확도를 보장할 수 있습니다.[4]


Akamai의 ALB(Application Load Balancer)

Akamai의 방대한 분산 네트워크와 앞에서 설명한 메타데이터 태그가 뒷받침되면, 트래픽 라우팅 결정이 국가 또는 대륙 수준에서 평가될 경우 백엔드 GTM 지오 라우팅의 정확도를 유지할 수 있습니다. 또한, 주 또는 도시 단위의 보다 세부적인 로직이 필요한 경우 Akamai의 Application Load Balancer(ALB) Cloudlet의 7계층 지리적 위치 타게팅을 사용할 수 있습니다. ALB는 GTM과 달리 HTTP 요청에 대한 인사이트를 확보하고 있기 때문에 실제 사용자의 위치를 확인할 수 있습니다. 결과적으로, 주, 국가 또는 도시 수준에서 지오 타게팅을 수행해야 하는 경우에는 GTM보다 ALB가 적합합니다. ALB는 사용자 위치에 대한 폭넓은 가시성을 갖고 있을 뿐만 아니라 세션 동기화, 즉각적인 장애 복구와 같은 7계층 트래픽 관리 기능을 제공합니다.


ALB Plus GTM

ALB이 추가로 7계층 기능을 제공한다면, GTM에는 HTTP 요청이 이루어지기 전에 트래픽 결정을 실행하는 기능(프론트엔드 GTM)이 있습니다. 애플리케이션의 요구사항에 따라 둘 중 적합한 솔루션을 선택해야 하고, 두 가지 솔루션을 모두 사용하는 경우도 많습니다. 일부 부서의 탄력적인 운영을 보장하기 위해 GTM을 구축하고 특정 애플리케이션을 지원하기 위해 ALB를 구축하는 등 다양한 아키텍처가 만들어질 수 있습니다. ALB와 GTM을 결합하면 DevOps, 네트워크 아키텍트, 시스템 엔지니어에게 최적의 클라우드 기반 GSLB 솔루션을 선택할 수 있는 유연성을 제공합니다. Akamai가 제공하는 인라인 경험을 관리하기 위해 Cloudlet ALB 기능이 필요한 애플리케이션 아키텍트도 있습니다. 이와 동시에 멀티 클라우드 배포와 사업자 사이에서 트래픽을 분산해야 하는 네트워크 아키텍트도 있습니다. 시스템 엔지니어와 애플리케이션 개발자는 GTM과 ALB를 동시에 사용할 경우 그 결합 효과를 십분 활용할 수 있습니다.


Akamai의 GTM 및 ALB에 대해 자세히 알아보기

Akamai.co.kr의 '문의하기' 아이콘을 클릭하여 Akamai 담당자와 채팅하고 Akamai의 GTM과 ALB 서비스에 대해 자세히 알아보시기 바랍니다. 아래 링크에서 관련 자료를 확인하실 수 있습니다.


[1] 계층 분산 모델은 캐싱이 가능한 오브젝트에만 적용됩니다. 캐싱이 불가능한 요청일 경우 Akamai의 SureRoute 기능이 적용되고, 이 기능은 항상 차일드 서버 단계에서 오리진 DNS 룩업을 수행합니다. 따라서 태그는 캐싱이 가능한 파일의 경우에만 필요합니다.

[2] 보안 목적으로 페어런트 서버를 제공하는 Site Shield를 사용하는 경우에도 태그를 적용할
수 있습니다.

[3] 최적의 Akamai 엣지 서버는 실제 클라이언트 머신(원 1)에 의해 시작된 DNS 룩업을 통해서도 결정됩니다. 이 단계에서도 GTM 프로퍼티가 사용될 수 있습니다(프론트엔드 GTM).

[4] 일부 리커시브 DNS 공급업체의 경우 DNS 레코드를 요청하는 실제 머신의 소스 IP 정보를 전달하는 확장(EDNS0)을 구현합니다. 하지만 이 경우에도 최초의 실제 클라이언트 IP를 확인할 수 없기 때문에 앞서 설명한 프록시 구현이 DNS 지리적 탐지 로직을 왜곡할 수 있습니다.