HTTP 캐싱과 CDN

캐시를 사용자에게 얼마나 가까이 둘 수 있느냐 — 이게 읽기 성능 최적화의 본질이야. 클라이언트 브라우저 캐시에서 시작해서, 서버 앞의 리버스 프록시, 그리고 지구 곳곳에 뿌려진 CDN까지. 한 단계씩 더 가까이 가는 이야기지.

HTTP 캐싱의 동작 방식부터 보자. 정적 리소스(JS, CSS)는 요청마다 안 바뀌니까 캐시할 수 있잖아. 클라이언트가 리소스를 요청하면 서버는 Cache-Control(TTL)과 ETag(버전 식별자)를 응답에 포함해. 다음 요청 때 캐시가 신선도를 확인하고, 만료됐으면 조건부 요청(If-None-Match + ETag)으로 변경 여부를 물어봐. 안 변했으면 304 Not Modified만 오지. 이상적으로 정적 리소스는 **불변(immutable)**으로 취급하는 게 좋아 — "영원히" 캐시하고 변경이 필요하면 새 URL을 만드는 거야. 읽기 경로와 쓰기 경로를 분리하는 CQRS 패턴의 가장 단순한 형태지.

리버스 프록시는 클라이언트와 서버 사이에 위치하는 서버 측 프록시야. 브라우저 캐시보다 훨씬 효과적인 이유가 있어 — 캐시가 모든 클라이언트 간에 공유되기 때문이거든. 거기다 인증, 압축, Rate limiting, 로드 밸런싱까지 처리할 수 있어. NGINX, HAProxy가 대표적이지. 하지만 리버스 프록시는 여전히 오리진 서버 근처에 있어. 사용자가 지구 반대편이면?

여기서 **CDN(Content Delivery Network)**이 등장해. 지리적으로 분산된 캐싱 서버 네트워크야. 근데 CDN의 진짜 가치는 캐싱이 아니야. 오버레이 네트워크가 핵심이거든. 공용 인터넷의 BGP는 성능을 전혀 안 봐 — 홉 수만으로 경로를 평가하고 지연이나 혼잡은 무시해. CDN은 인터넷 위에 구축된 오버레이로 이 문제를 우회하지. 아무리 서버가 빨라도 빛의 속도 한계 때문에 지구 반대편이면 RTT가 100ms를 넘어 — 물리 법칙은 최적화 못 해. 콘텐츠를 사용자 가까이 두는 것이 유일한 답이야.

클라이언트를 가장 가까운 클러스터로 보내는 건 글로벌 DNS 로드 밸런싱이 담당해. CDN 서버는 **인터넷 교환점(IXP)**에도 배치되어서 통신 대부분이 CDN 네트워크를 타게 돼. 캐시할 수 없는 동적 리소스도 이 오버레이를 통해 더 빠르게 전달할 수 있고, DDoS 방어 계층도 되지. CDN은 여러 캐싱 레이어를 가질 수 있는데, 에지가 많으면 더 넓은 지역을 커버하지만 각 에지의 캐시 히트율은 낮아져. 이걸 완화하려고 중간 캐싱 클러스터를 더 적은 위치에 배치해서 히트율을 높이는 거야.

---

정리

9장 읽고 기억할 거 세 가지:

1. HTTP 캐싱은 Cache-Control + ETag로 동작해 — 정적 리소스는 불변으로 취급하고 URL을 바꾸는 게 가장 깔끔하지
2. CDN의 진짜 가치는 캐싱이 아니라 오버레이 네트워크야 — BGP의 성능 무시 문제를 우회하고 물리적 거리를 줄여줘
3. 에지 클러스터 수와 캐시 히트율은 반비례해 — 중간 캐싱 레이어가 이 트레이드오프를 완화하지