CDN POP 선택 원리: DNS·Anycast·HTTP 리디렉션은 어떻게 다른가

CDN에서 사용자를 가까운 POP로 보낸다는 설명은 결과만 말한다. 실제 경로는 provider와 product에 따라 DNS 응답, Anycast routing, load balancer, HTTP redirect 같은 여러 기법을 조합한다. 이들을 하나의 ‘POP 선택 알고리즘’으로 묶으면 어느 시점에 누가 결정을 내리는지 놓치게 된다.

POP와 cache는 같은 말이 아니다

POP(Point of Presence) 또는 edge location은 CDN provider가 client traffic을 받는 네트워크 거점이다. 한 POP 안에 proxy, TLS termination, security service와 cache server가 함께 있을 수 있다. provider마다 ‘POP’, ‘edge location’, ‘data center’를 정의하고 공개하는 범위가 다르므로 물리 server 한 대와 동일시하지 않는다.

요청이 특정 POP에 도착했다는 사실과 content가 그 POP의 cache에 있다는 사실도 다르다.

client
  → 선택된 edge/POP
      → cache hit: edge에서 응답
      → cache miss: 상위 cache 또는 origin에서 가져옴

cache key, Cache-Control, cookie와 query 처리, object 인기와 eviction 정책에 따라 같은 POP에서도 hit와 miss가 달라진다. 일부 CDN은 POP와 origin 사이에 regional·tiered cache를 둔다. 따라서 POP 선택만 빠르게 해도 cache miss와 느린 origin fetch가 계속되면 전체 latency는 높을 수 있다.

DNS 기반 steering은 DNS 응답 단계의 결정이다

DNS 기반 CDN에서는 authoritative DNS가 client가 사용할 edge hostname이나 IP를 응답한다. 이때 관찰되는 위치는 최종 client가 아니라 recursive resolver의 위치일 수 있다. EDNS Client Subnet을 사용하는 경우도 있지만 항상 제공되는 정보가 아니며 privacy와 cache 효율의 trade-off가 있다.

DNS steering의 특징은 다음과 같다.

• DNS 응답 전에 health, capacity, policy와 측정 정보를 반영할 수 있다.
• TTL과 recursive resolver cache 때문에 변경이 모든 client에 즉시 반영되지는 않는다.
• 동일 hostname도 resolver와 조회 시각에 따라 다른 answer를 받을 수 있다.
• ‘지리적으로 가장 가까운 곳’보다 관측 latency와 network 정책상 더 적절한 곳을 고를 수 있다.

AWS CloudFront 문서는 DNS가 요청을 가장 잘 처리할 POP로 보내며 일반적으로 latency 관점에서 가까운 위치라고 설명한다. 이 설명을 모든 CDN의 내부 scoring 공식으로 확장해서는 안 된다. provider는 세부 mapping logic과 실시간 signal을 모두 공개하지 않을 수 있다.

DNS의 recursive·authoritative 경계는 DNS resolver가 주소를 찾는 과정에서 더 자세히 볼 수 있다.

Anycast는 같은 IP를 여러 위치에서 알리는 routing 방식이다

Anycast에서는 여러 거점이 같은 IP prefix를 광고한다. Internet의 BGP routing 결과에 따라 packet이 한 거점으로 들어간다. 여기서 ‘가까움’은 지도상의 직선거리보다 BGP path, peering, routing policy와 장애 상태에 가깝다.

같은 service IP
  ├─ POP A에서 BGP 광고
  ├─ POP B에서 BGP 광고
  └─ POP C에서 BGP 광고

client packet → 현재 routing 결과가 선택한 POP

Anycast가 POP의 CPU와 memory를 packet마다 직접 비교해 가장 한가한 server를 고른다고 설명하면 부정확하다. provider는 route announcement와 traffic engineering을 조절할 수 있지만, Internet routing과 POP 내부 load balancing은 서로 다른 결정 단계다. Cloudflare도 Anycast traffic이 지리적으로 가장 가까운 data center가 아닌 곳으로 갈 수 있으며 reliability를 위해 경로가 달라질 수 있다고 명시한다.

Google Cloud CDN처럼 global Anycast frontend와 load balancer를 결합하는 제품도 있다. 이 경우 Anycast가 edge 진입점을 만들고, 이후 provider 내부에서 backend·cache 처리가 이어진다. ‘DNS 방식 아니면 Anycast 방식’처럼 항상 양자택일하는 구조가 아니다.

HTTP redirect는 요청이 한 번 도착한 뒤의 steering이다

HTTP 3xx 응답은 client에게 다른 URL로 다시 요청하라고 지시한다. media manifest, download URL, 지역별 service endpoint처럼 application 또는 delivery system이 2차 위치를 고를 때 사용할 수 있다.

client → 첫 endpoint
       ← 302 Location: 다른 hostname 또는 URL
client → redirect된 endpoint

이 방식은 첫 요청이 이미 DNS와 routing을 거쳐 server에 도착한 뒤 동작한다. 추가 round trip이 생기고 client가 redirect를 따라야 하며, method 보존과 cache 정책도 status code에 따라 확인해야 한다. 모든 CDN이 일반 web object의 POP 선택에 HTTP redirect를 쓴다고 일반화할 수 없다.

DNS, Anycast, HTTP redirect를 결정 시점으로 나누면 다음과 같다.

방식	주된 결정 시점	관찰해야 할 것
DNS steering	address 조회	resolver 위치, answer, TTL, cache
Anycast	packet routing	BGP path, peering, 장애·traffic engineering
HTTP redirect	첫 HTTP 응답 이후	status, Location, 추가 RTT, cache
POP 내부 load balancing	edge 도착 이후	edge service와 provider 내부 상태

단순 가중치 Python 예제가 실제 알고리즘은 아니다

거리 50km, latency 10ms, load 0.3을 그대로 더해 0.4, 0.4, 0.2를 곱하는 예제는 단위와 scale이 달라 의미 있는 비교가 되지 않는다. 값의 정규화, 측정 시점, missing data, health gate와 급격한 경로 변경 방지까지 정의해야 한다. 무엇보다 실제 CDN은 client가 Python list에서 POP를 직접 고르는 구조가 아닐 수 있다.

개념적으로는 다음 순서가 더 안전하다.

1. 서비스·TLS·규정상 요청을 처리할 수 없는 POP를 제외한다.
2. health와 가용 capacity가 기준을 넘는 후보만 남긴다.
3. DNS 또는 routing 관점의 예상 성능과 정책을 적용한다.
4. 경로가 자주 흔들리지 않도록 hysteresis와 fallback을 둔다.
5. 실제 request latency, error, cache hit와 origin latency로 결과를 검증한다.

이는 특정 provider의 내부 구현을 재현한 algorithm이 아니라 설계 요소를 빠뜨리지 않기 위한 사고 순서다.

실제 경로를 확인할 때

사용자 위치 한 곳의 측정만으로 전 세계 POP 선택을 평가할 수 없다. 서로 다른 network와 resolver에서 같은 시각에 비교하고, DNS·connection·application 시간을 분리한다.

dig cdn.example.com
curl -sS -o /dev/null \
  -w 'remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://cdn.example.com/object

response header에 cache status나 edge code가 있다면 provider 문서에 따라 읽는다. header 이름은 표준이 아니며 위조 가능한 client-facing 값만으로 내부 topology를 단정하지 않는다. network edge와 propagation·transmission delay의 기본은 Network edge와 core에서 연결해 볼 수 있다.

참고 자료

• AWS CloudFront: How CloudFront delivers content
• Cloudflare: TCP connections and Anycast routing
• Cloudflare: Geographic traffic routing
• Google Cloud: Cloud CDN overview
• RFC 9110: Redirection 3xx