한국 사용자가 미국 origin server 의 데이터 받기 — 직접 가면 RTT 150ms+. CDN edge 가 한국 IDC 에 cache → 5ms. 그게 CDN. 그런데 edge 가 어떻게 알아서 가까운 곳? cache miss 때는? purge 는? DDoS 막는 건 어떻게? 이 가이드는 CDN 의 내부 동작을 정리한다.
Edge POP + BGP Anycast — 가까운 곳에 자동 라우팅
Cloudflare 의 300+ POP (Point of Presence):
- 도쿄, 서울, 싱가포르, 시드니, LA, 런던, ...
CDN 의 IP (예: 1.1.1.1) 는 BGP anycast 로 발표:
- 모든 POP 가 같은 IP 광고
- ISP 의 BGP router 가 "가장 짧은 path" 선택
- 한국 사용자 → 서울 POP, 일본 사용자 → 도쿄 POP
→ DNS 마법이 아닌 routing layer 마법. URL/IP 그대로 가까운 곳 도달.
비교:
GeoDNS (CloudFront 옛 모델): DNS 응답이 user IP 별로 다른 IP 반환
→ DNS resolver caching 때문에 부정확
Anycast (modern): IP 자체가 routed → 항상 정확Cache Miss 시 흐름
User (한국)
↓ GET /image.jpg
Seoul POP
↓ cache miss
Origin shield (Tokyo regional cache)
↓ cache miss
Origin (US East data center)
← image data
Origin shield (Tokyo)
← cache + relay
Seoul POP
← cache + relay
User
← image data
다음 요청부터:
User → Seoul POP (cache hit, 5ms) → 응답.
3 단계 hierarchy 의 의도:
- Seoul POP 단독 hit 시 가장 빠름
- miss 시에도 Tokyo regional 이 origin 부담 1/N (모든 POP 이 origin 직접 X)
- "origin shield" 가 origin 의 traffic 1000× 줄임Cache-Control 헤더 — CDN 동작 결정
Cache-Control: public, max-age=60, s-maxage=3600, stale-while-revalidate=86400
각 의미:
- public: 모든 cache 가능 (CDN + browser)
- max-age=60: browser cache 60 초
- s-maxage=3600: CDN cache 1 시간 (s = shared)
- stale-while-revalidate=86400: 만료 후 86400 초 동안 stale 응답 가능,
background refresh
→ CDN 은 1 시간 cache, browser 는 1분 cache.
→ origin update 후 user 가 즉시 보는 게 아니라 최대 1 시간 stale 가능.
다른 directive:
- no-store: 절대 cache 안 함
- private: browser 만 cache, CDN cache 안 함
- must-revalidate: stale 후 반드시 origin 확인
- immutable: cache 동안 절대 변경 X (해시 박힌 asset)Purge — 즉시 무효화
TTL 만료 기다리지 않고 즉시 cache 삭제:
URL 기반:
CDN API: POST /purge {url: "https://example.com/page-A"}
→ 모든 POP 에 broadcast (10-30 초)
Tag 기반 (Cloudflare, Fastly):
origin 응답 헤더: Cache-Tag: product-42, category-shoes
나중에 product 42 update 시:
POST /purge {tag: "product-42"}
→ 그 tag 박힌 모든 cache 무효
→ URL 모르고도 일괄 처리
전체 purge:
POST /purge {everything: true}
→ 거의 안 씀 (origin 부담 폭발). 사고 복구용.CDN = DDoS 방어
origin 의 capacity: 1000 req/s
attacker: 100,000 req/s 의 DDoS
직접 origin 받으면 → down.
CDN 가운데 있으면:
1. CDN 의 300 POP 가 traffic 분산 (한 POP 가 1000 req/s 보지만 300 POP 합치면 300K)
2. CDN 의 anti-DDoS (rate limiting, IP reputation, bot detection)
3. cache hit traffic 은 origin 안 봄 (대부분의 attack 가 cache 가능 URL)
4. anomaly 감지 시 challenge (CAPTCHA)
→ CDN provider (Cloudflare, Akamai 등) 가 사실상 "DDoS 방어 service" 도.
이게 CDN 의 두 번째 가치 (첫째 = latency).관련 도구
- HTTP 상태 코드 — Cache 관련 status code (304 Not Modified 등)
흔한 함정
- Cache-Control 안 박음 — default 가 cache X. 모든 static asset 에 명시.
- cookies / Authorization 가 있어 cache 안 됨 — Vary 헤더로 조정 또는 별도 path.
- asset 의 immutable 활용 안 함 — webpack hash 박힌 .js / .css 는 immutable + max-age=1year.
- HTML 의 long TTL — HTML 은 short (1-5min) 또는 stale-while-revalidate. 안 그러면 update 즉시 반영 X.
- cookies 박힌 응답 cache — 한 user 의 session cookie 다른 user 에. CDN 의 default 안전 동작 검증.
마무리
CDN 의 본질 — edge 의 cache + anycast routing. latency 큰 폭 절감 + origin 부담 ↓ + DDoS 방어. modern web 의 거의 필수.
실용 — CDN provider (Cloudflare / Fastly / CloudFront) 의 default 에 의존하기보다, Cache-Control 명시 + Cache-Tag 로 fine-grained purge + monitoring (cache hit rate). 90%+ hit rate 가 목표.