CDN

지금까지 네트워크의 계층별 동작 원리와 프로토콜을 살펴보았습니다.

이제 실제 서비스를 운영할 때 필수적인 네트워크 인프라 구성 요소를 다루겠습니다.

첫 번째는 CDN(Content Delivery Network)입니다.

왜 CDN이 필요한가

서울에 있는 서버에서 브라질 사용자에게 웹 페이지를 보낸다고 합시다.

광섬유 안의 빛은 진공보다 느리고 실제 해저 케이블 경로도 직선이 아니므로, 서울과 상파울루 사이의 왕복 지연은 물리적 하한만으로도 매우 큽니다.

실제 왕복 시간에는 라우팅·장비 처리·혼잡도 더해집니다. 지명만으로 고정 지연을 정할 수 없으므로 서비스 경로에서 측정해야 합니다.

CDN은 전 세계에 분산된 엣지 서버에 콘텐츠의 복사본을 캐시하고, 사용자에게 네트워크상 가까운 엣지에서 응답합니다.

이 “가까움”은 단순한 지도상의 거리뿐 아니라 DNS 응답, Anycast 라우팅, ISP 피어링, 엣지의 부하 상태에 따라 결정됩니다.

CDN의 동작 원리

공유 캐시의 기본 분기는 아래와 같습니다. 캐시 키·Vary가 맞는지, 요청과 응답 지시문이 재사용을 허용하는지까지 판단하며 stale 확장 정책은 별도로 적용합니다.

캐시의 유효 기간은 HTTP의 Cache-Control 헤더로 제어합니다.

s-maxage는 공유 캐시에만 적용되는 신선도 수명이며 그 캐시에서 max-age보다 우선합니다. no-cache는 저장 금지가 아니라 재사용 전 성공적인 검증이 필요하다는 뜻입니다. 상위 캐시가 검증에 응답할 수도 있어 항상 원본 서버까지 도달하는 것은 아닙니다.

Cache-Control: max-age=86400       → 신선도 수명 24시간
Cache-Control: s-maxage=3600       → 공유 캐시의 신선도 수명 1시간
Cache-Control: no-cache            → 재사용 전에 검증 필요
Cache-Control: no-store            → 저장 금지
Cache-Control: stale-while-revalidate=60  → 신선도 만료 후 60초 동안
                                          재검증 중 낡은 응답 사용 허용

max-age는 저장을 강제하거나 수신 시점부터 그 시간만큼 항상 신선하다는 뜻이 아닙니다. 응답의 나이(Age)와 다른 지시문도 적용됩니다. 개인화 응답은 private·no-store와 캐시 키를 함께 설계해야 합니다.

예시: 같은 응답의 공유 캐시와 브라우저 수명 응답에 max-age=86400, s-maxage=3600이 있고, 캐시가 계산한 현재 나이(current_age)가 2,400초라고 합시다. 저장은 허용되어 있고 캐시 키·Vary도 맞으며 다른 재검증 지시문은 없습니다. 공유 캐시는 s-maxage를 택하므로 남은 신선도는 3,600 − 2,400 = 1,200초입니다. 브라우저의 개인 캐시는 s-maxage를 적용하지 않아 86,400 − 2,400 = 84,000초입니다. 두 캐시가 같은 응답을 가지고도 재검증 시점이 다른 이유입니다. 여기의 현재 나이는 응답 헤더와 전송·보관 시간을 반영해 이미 계산된 값이며, 수신한 Age 숫자만 무조건 빼는 실험은 아닙니다.

재검증을 독립 판단하기 같은 URL과 Vary에 맞는 저장 응답이 있고 현재 나이는 1,200초입니다. 응답에 max-age=3600, no-cache가 함께 있다면 지금 저장 본문을 바로 사용할 수 있을까요? 원래 응답의 강한 ETag를 조건으로 보냈고, 그 태그와 맞는 304 응답을 받았을 때의 행동도 설명해 보세요.

캐시 무효화 전략

코드를 배포했을 때 CDN 캐시가 갱신되지 않으면, 사용자는 여전히 이전 버전을 받습니다.

대표 CDN 서비스

아래는 제품군을 구분하는 예시입니다. 플랜·무료 한도와 제공 기능은 시점 및 계약에 따라 달라지므로 적용 시 각 서비스의 현재 조건을 확인해야 합니다. Cloudflare, CloudFront, Fastly, Vercel, Netlify의 플랜은 서로 같은 무료 사용 범위를 뜻하지 않습니다.

서비스             특징                   진입 방식              용도
──────────────────────────────────────────────────────────────────────────
Cloudflare        CDN+DDoS+WAF+DNS 통합   무료/유료 플랜          범용
AWS CloudFront    AWS 생태계 통합         무료 플랜+유료 플랜     AWS 서비스
Akamai            대형 글로벌 CDN         엔터프라이즈 중심       대기업
Fastly            실시간 퍼지, Edge       무료 한도+사용량/계약     API/동적
Vercel/Netlify    프론트엔드 배포 통합    무료 플랜+사용량 제한   정적 사이트

CDN은 정적 파일에만 유용한 것이 아닙니다.

API 응답 캐싱, 엣지에서의 요청 조작(Edge Functions), 이미지 최적화(리사이징, 포맷 변환) 등 점점 더 많은 로직이 엣지로 이동하고 있습니다.

캐시 적중률만 높이는 대신 원본 요청 수, Age와 제공 버전, 퍼지 전파를 함께 봅니다. 갑작스러운 미스가 원본에 몰릴 때는 요청 병합이나 origin shield의 적용 범위도 확인합니다.

다음 절에서는 트래픽을 여러 서버로 분배하는 로드 밸런서를 다루겠습니다.