CDN은 DNS로 전 세계 트래픽을 어떻게 라우팅할까

CDN의 핵심 약속은 하나의 고정된 원본 서버가 전 세계를 상대하는 대신, 각 방문자와 물리적으로 가까운 서버에서 콘텐츠를 제공하는 것입니다. 대부분의 구현에서 이를 가능하게 하는 메커니즘은 DNS이며, 구체적으로는 똑같은 쿼리에 방문자마다 서로 다른 응답을 주는 것입니다.

같은 도메인, 다른 응답, 모두 의도된 것입니다

도메인 앞단에 CDN을 두면 DNS 레코드는 대개 단일 원본 IP가 아니라 (흔히 CNAME을 통해) CDN 제공업체의 자체 인프라를 가리킵니다. 그러면 CDN의 네임서버는 쿼리가 어디에서 온 것으로 보이는지를 기준으로 각 쿼리에 응답하며, 해당 방문자에게 가장 가깝거나 부하가 가장 적은 엣지 위치의 IP 주소를 돌려줍니다. 지구 반대편에서 같은 도메인을 질의하는 두 사람이 전혀 다른 IP 주소를 받는 것은 정상입니다.

• 그러므로 하나의 도메인-IP 조회를 서로 다른 위치에서 두 번 수행했을 때 결과가 다르더라도 버그가 아닙니다. 시스템이 의도대로 동작하는 것입니다.
• CDN 앞단에 있는 도메인이 반복 조회할 때 여러 주소로 확인되는 경향이 있는 이유이기도 합니다. “정답”은 하나가 아니라 현재 적합한 답만 있을 뿐입니다.
• 이런 레코드에는 짧은 TTL이 흔히 쓰입니다. 긴 캐시 만료를 기다리지 않고 CDN이 문제가 생긴 엣지 위치에서 트래픽을 빠르게 다른 곳으로 돌리기 위해서입니다.

디버깅할 때 이것이 의미하는 바

CDN 앞단에 있는 사이트가 일부 방문자에게만 이상하게 동작한다면, 여러 관측 지점에서 이 도메인이 실제로 어떤 주소로 확인되는지 살펴보는 것이 문제가 원본이나 애플리케이션이 아니라 특정 엣지 위치에 있는지 확인하는 가장 빠른 방법인 경우가 많습니다. 브라우저의 자체 DNS 캐시를 거치지 않고 직접 조회해 원본 응답을 보여 주는 도구를 쓰면, 지금 특정 지역에 실제로 어떤 응답이 제공되는지 더 깔끔하게 파악할 수 있습니다.

원본 서버의 실제 주소는 의도적으로 숨겨져 있습니다

알아 둘 만한 부수 효과가 있습니다. CDN 앞단에 있는 도메인을 조회하면 그 뒤의 원본 서버가 아니라 엣지 네트워크의 주소가 나오며, 이는 대개 우연이 아니라 설계된 동작입니다. 원본의 실제 IP를 공개 DNS에 노출하지 않는 것은, CDN이 앞단에서 갖춘 훨씬 큰 용량이 아니라 실제 인프라를 직접 겨냥한 서비스 거부 공격에 맞서는 사이트의 가장 단순하고 효과적인 방어 수단 중 하나입니다. 또한 도메인 조회만으로는 사이트가 “실제로” 어디에 호스팅되어 있는지 알 수 없다는 뜻이기도 합니다. 알 수 있는 것은 트래픽이 현재 CDN 네트워크에 진입하는 지점뿐이며, 이는 의미가 상당히 다른 질문입니다.

확인된 주소의 WHOIS 또는 ASN 조회하기

도메인이 CDN 뒤에 있는지 확인하는 간단하고 실용적인 방법은 도메인 조회와는 별도로, 확인된 IP 주소를 실제로 누가 소유하는지 살펴보는 것입니다. 확인된 주소가 잘 알려진 CDN이나 클라우드 제공업체의 자율 시스템 번호(ASN)로 등록되어 있다면, 원본 서버가 아니라 엣지 네트워크를 보고 있다는 강한 신호입니다. 또한 아무 문제가 없는데도 같은 도메인이 지역에 따라 다른 주소로 보이는 이유를 바로 설명해 줍니다. 조회를 대체하는 것이 아니라 조회 다음에 하는 유용한 두 번째 단계입니다. DNS 응답은 현재 주소를 알려 주고, 소유자 조회는 그 주소가 어떤 종류의 인프라에 속하는지 알려 줍니다.