13장 : 실무 네트워크 인프라
CDN
지금까지 네트워크의 계층별 동작 원리와 프로토콜을 살펴보았습니다. 이제 실제 서비스를 운영할 때 필수적인 네트워크 인프라 구성 요소를 다루겠습니다. 첫 번째는 CDN(Content Delivery Network)입니다.
왜 CDN이 필요한가
서울에 있는 서버에서 브라질 사용자에게 웹 페이지를 보낸다고 합시다. 빛의 속도로도 서울과 상파울루 간 왕복 시간은 약 300ms입니다.
CDN 없이
브라질 사용자 ──300ms──→ 서울 서버
TCP 핸드셰이크: 300ms (1 RTT)
TLS 핸드셰이크: 600ms (2 RTT)
HTML 요청/응답: 300ms (1 RTT)
CSS/JS 요청: 300ms (1 RTT)
총 첫 화면: ~1500ms
CDN 사용
브라질 사용자 ──20ms──→ 상파울루 엣지 서버 (캐시 히트)
TCP 핸드셰이크: 20ms
TLS 핸드셰이크: 40ms
HTML: 20ms
CSS/JS: 20ms (캐시)
총 첫 화면: ~100ms (15배 빠름!)CDN은 전 세계에 분산된 엣지 서버에 콘텐츠의 복사본을 캐시하고, 사용자에게 가장 가까운 서버에서 응답합니다.
CDN의 동작 원리
사용자 브라우저
│
│ 1. DNS 질의: cdn.example.com
▼
┌─────────┐
│ DNS │── CDN의 Authoritative DNS가
└────┬────┘ 사용자 위치 기반으로 가장 가까운
│ 엣지 서버 IP 반환
▼
┌──────────────┐ 캐시 히트?
│ 엣지 서버 │──── Yes ──→ 즉시 응답 (빠름!)
│ (PoP) │
│ 상파울루 │──── No ──→ 오리진 서버에 요청
└──────┬───────┘ │
│ ▼
│ ┌──────────────┐
│ │ 오리진 서버 │
│ │ (서울) │
│ └──────┬───────┘
│ 캐시 저장 ←──────────┘
│ + 사용자에게 응답
▼
이후 같은 지역의 다른 사용자 → 캐시에서 즉시 응답캐시의 유효 기간은 HTTP의 Cache-Control 헤더로 제어합니다.
Cache-Control: max-age=86400 → 브라우저 + CDN 24시간
Cache-Control: s-maxage=3600 → CDN만 1시간
Cache-Control: no-cache → 매번 오리진에 검증
Cache-Control: no-store → 캐시 금지
Cache-Control: stale-while-revalidate=60 → 만료 후 60초간
캐시 응답 + 백그라운드 갱신캐시 무효화 전략
코드를 배포했을 때 CDN 캐시가 갱신되지 않으면, 사용자는 여전히 이전 버전을 받습니다.
| 전략 | 방식 | 장점 | 단점 |
|---|---|---|---|
| 파일명 해싱 | main.abc123.js | 가장 확실, 자동화 | 빌드 도구 필요 |
| 퍼지(Purge) | API로 캐시 삭제 | 즉시 적용 | 수동, 전파 시간 |
| 캐시 태그 | 태그별 그룹 무효화 | 유연한 관리 | CDN별 구현 다름 |
| 단기 TTL | max-age=60 | 자동 갱신 | 캐시 효율 감소 |
| 버전 쿼리스트링 | ?v=2 | 간단 | 일부 CDN 무시 |
대표 CDN 서비스
서비스 특징 무료 플랜 용도
─────────────────────────────────────────────────────────────────
Cloudflare CDN+DDoS+WAF+DNS 통합 ✓ 범용
AWS CloudFront AWS 생태계 통합 ✗ (프리티어) AWS 서비스
Akamai 원조 CDN, 최대 PoP ✗ 대기업
Fastly 실시간 퍼지, Edge ✗ API/동적
Vercel/Netlify 프론트엔드 배포 통합 ✓ 정적 사이트CDN은 정적 파일에만 유용한 것이 아닙니다. API 응답 캐싱, 엣지에서의 요청 조작(Edge Functions), 이미지 최적화(리사이징, 포맷 변환) 등 점점 더 많은 로직이 엣지로 이동하고 있습니다.
다음 절에서는 트래픽을 여러 서버로 분배하는 로드 밸런서를 다루겠습니다.