상황
이미지 리사이징 서버 앞단에 CloudFront CDN이 구축되어 있었습니다. 그러나 CDN이 있다는 것과 CDN이 효과적으로 작동한다는 것은 다른 문제입니다. 정적 이미지와 동적으로 생성되는 리사이징 이미지에 동일한 캐싱 정책이 적용되고 있었고, 결과적으로 CDN을 통과해도 리사이징 서버에 과다한 요청이 도달하여 응답 지연과 비용 증가가 발생했습니다.
문제
핵심 원인은 캐싱 정책의 획일화였습니다.
- 자주 변경되지 않는 정적 자산(로고, 고정 배너)과 요청마다 파라미터가 달라지는 리사이징 이미지(크기, 포맷, 품질)가 동일한 TTL로 관리됐습니다.
- 리사이징 이미지는
width,height,format,quality조합이 무수히 많아 캐시 키 충돌이 빈번했습니다. - 결과적으로 캐시 미스가 잦았고, 리사이징 서버가 상시 과부하 상태였습니다.
접근과 판단
CloudFront 구성에 Nginx 리버스프록시를 추가하여 캐싱 레이어를 분리했습니다.
CloudFront 단독으로는 요청 헤더·파라미터 기반의 세밀한 캐싱 정책을 적용하기 어렵습니다. CloudFront와 리사이징 서버 사이에 Nginx를 배치하면, 콘텐츠 유형별로 다른 캐싱 규칙을 적용할 수 있습니다.
클라이언트 요청 헤더 기반 동적 캐싱 기간을 설계했습니다.
Cache-Control: max-age=N 헤더를 클라이언트에서 명시적으로 보내고, Nginx가 이를 읽어 캐싱 기간을 동적으로 결정하는 구조로 전환했습니다. 콘텐츠 유형별 기본값을 정의하되, 호출부에서 오버라이드할 수 있도록 설계했습니다.
모니터링 지표를 먼저 정의하고 변경했습니다.
캐시 적중률, 응답시간, 오류율을 Datadog에서 모니터링하도록 설정한 뒤 변경을 적용했습니다. "개선됐다"는 느낌이 아니라 수치로 효과를 검증하기 위해서입니다.
결과
| 항목 | 비교 | 값 (%) |
|---|---|---|
| 캐시 적중률 Before | 85 % | |
| 캐시 적중률 After | 95 % |
- 캐시 적중률 85% → 95%: CloudFront 대시보드 기준
- 리사이징 서버 부하 40% 감소: Datadog 서버 메트릭 기준
- 이미지 로딩 평균 1.8초 단축: Datadog 이미지 서빙 시간 측정 기준
배운 것
CDN은 구축이 아니라 운영입니다. CDN을 앞에 놓는다고 자동으로 캐시 효율이 오르지 않습니다. 어떤 콘텐츠를 얼마나 캐시할 것인가, 캐시 키를 어떻게 설계할 것인가에 대한 전략이 없으면 CDN은 비싼 프록시에 불과합니다.
인프라 변경은 수치로 검증해야 합니다. Nginx를 추가하는 것은 아키텍처 변경입니다. 모니터링 지표를 먼저 정의하고, 변경 전후를 비교하는 습관이 없으면 "좋아진 것 같다"는 주관에 머물게 됩니다.