03. CDN Origin과 Purge 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• CDN edge, origin, cache key, purge가 백엔드 장애 분석에서 어떤 의미를 갖는가?
• purge가 왜 오래된 응답을 지우는 동시에 origin 장애를 만들 수 있는가?
• CDN 설정을 인프라 팀과 맞출 때 어떤 정보를 API 팀이 제공해야 하는가?

개요

CDN은 사용자 가까운 edge에서 응답을 제공하는 분산 reverse proxy cache다. 정적 파일과 공개 컨텐츠에는 강력하지만, API 응답을 캐시할 때는 cache key, header 전달, cookie/auth 처리, purge 전략을 정확히 설계해야 한다.

• CDN HIT이면 origin app까지 요청이 가지 않을 수 있다.
• cache key는 URL만이 아니라 query, header, cookie, device, language를 포함할 수 있다.
• purge는 캐시를 지우지만 edge miss를 늘려 origin traffic spike를 만들 수 있다.
• origin shielding은 여러 edge miss를 한 중간 계층으로 모아 origin 부하를 줄일 수 있다.

원리

기본 흐름은 다음과 같다.

Client
  -> CDN Edge
     -> cache HIT: edge response
     -> cache MISS: request origin
  -> Origin LB
  -> Application

장애 분석에서는 “사용자가 받은 응답이 어느 계층에서 생성됐는가”가 첫 질문이다. Age, Via, X-Cache, CF-Cache-Status, X-Served-By 같은 header가 단서가 된다.

Cache Key 설계

cache key는 캐시 저장소의 주소다. key가 너무 좁으면 응답이 섞이고, 너무 넓으면 HIT율이 떨어진다.

구분	key 포함 판단
query string	검색/필터 결과가 바뀌면 포함
Accept-Encoding	압축 표현이 다르면 포함 또는 Vary
Origin	CORS 응답이 origin별이면 포함 또는 Vary: Origin
cookie	개인화에 쓰이면 공유 cache 금지 또는 별도 key
Authorization	기본적으로 공유 cache 금지
language/device	응답이 다르면 key 또는 Vary 필요

API 팀은 endpoint별로 “어떤 요청 요소가 응답을 바꾸는가”를 인프라 팀에 알려야 한다.

Purge와 Versioning

purge는 이미 저장된 cache entry를 지우는 작업이다. 하지만 purge를 배포의 기본 수단으로만 쓰면 위험하다.

• 전역 purge는 모든 edge에서 MISS를 만들 수 있다.
• 인기 리소스 purge는 origin thundering herd를 만들 수 있다.
• purge API 실패나 지연은 지역별 stale 응답을 남길 수 있다.
• rollback 때 이전 asset이 purge되어 있으면 복구가 어려워질 수 있다.

정적 asset은 가능하면 app.8f3a1.js처럼 fingerprinted URL과 긴 TTL을 사용한다. URL이 바뀌면 purge 없이도 새 파일을 받는다. purge는 잘못된 응답 제거, 긴 TTL 컨텐츠 긴급 교체, 법적 삭제 요청처럼 필요한 곳에 쓴다.

코드와 명령으로 확인하기

CDN 경유와 origin 직접 요청을 비교한다.

curl -I https://cdn.example.com/assets/app.8f3a1.js
 
curl -I --resolve cdn.example.com:443:203.0.113.10 \
  https://cdn.example.com/assets/app.8f3a1.js

origin을 직접 찌를 수 있는 내부 환경에서는 CDN과 origin header를 비교한다.

curl -I https://origin.internal.example.com/assets/app.8f3a1.js \
  -H 'Host: cdn.example.com'

확인할 것은 Cache-Control, Age, CDN status header, ETag, Vary, response size, origin log 도달 여부다.

Purge 후 관찰

purge는 실행보다 관찰이 중요하다.

for i in {1..5}; do
  curl -sI https://cdn.example.com/assets/app.8f3a1.js \
    | awk 'BEGIN{IGNORECASE=1}/^(age|cache-control|etag|cf-cache-status|x-cache):/{print}'
  sleep 2
done

purge 직후 MISS가 늘고 Age가 낮아지는 것은 자연스럽다. 동시에 origin latency, 5xx, connection pool, autoscaling을 관찰해야 한다.

인프라 협업 포인트

• API 팀은 endpoint별 cache 가능 여부, key 구성 요소, 허용 stale 시간, purge 필요 이벤트를 제공한다.
• 인프라 팀은 CDN rule 우선순위, header override, purge 방식, propagation 기대 시간을 공유한다.
• 장애 때는 CDN request id와 origin request id가 연결되도록 header 전달을 맞춘다.
• WAF, bot protection, image optimization, compression이 cache key와 응답 header를 바꾸는지 확인한다.

실전 팁

• 전역 purge는 마지막 수단으로 둔다. path/tag/key 단위 purge가 가능하면 범위를 줄인다.
• purge 전후에는 origin capacity를 고려한다. 대형 이벤트 직전 purge는 신중해야 한다.
• stale-if-error는 origin 장애 때 사용자 경험을 지켜 주지만, 오래된 정보를 보여 줘도 되는 도메인인지 확인한다.
• CDN vendor header 이름에 익숙해져야 한다. Cloudflare, Fastly, CloudFront가 각자 다른 힌트를 제공한다.
• 개인 프로젝트에서도 CDN을 붙이면 “캐시됐는지”를 보는 smoke test를 배포 체크에 넣는다.

위험 신호!

• cache key 정책을 인프라만 알고 API 팀은 모른다.
• purge 성공 응답만 보고 실제 edge에서 새 응답이 내려오는지 확인하지 않는다.
• query string을 무시하는 CDN rule이 검색/필터 API에 적용되어 있다.
• origin 장애인데 CDN HIT 때문에 모니터링이 늦게 울린다.

확인 질문

확인 질문

• CDN HIT이면 origin log가 없는 이유는 무엇인가?
  • edge가 cached response를 바로 제공했기 때문에 origin app까지 요청이 전달되지 않았을 수 있기 때문이다.
• purge가 origin 장애를 만들 수 있는 이유는 무엇인가?
  • 많은 edge cache가 동시에 비워지면 요청이 origin으로 몰려 connection, CPU, DB 부하가 급증할 수 있기 때문이다.
• cache key 설계에서 API 팀이 알려야 할 정보는 무엇인가?
  • query, header, cookie, auth, language처럼 응답을 바꾸는 요청 요소와 허용 가능한 stale 시간을 알려야 한다.

참고 문서

• Cloudflare, Default Cache Behavior
• AWS CloudFront, Manage How Long Content Stays in the Cache
• Fastly, Purging Cached Content
• RFC 9111, HTTP Caching