일반적인 웹 스택에는 어떤 캐시 계층들이 있나요?

Question

Accepted Answer

요청은 **여러 캐시 계층**을 거치며, 사용자에게 가까운 계층일수록 더 빠르게 응답하지만 담을 수 있는 양은 적습니다. 핵심은 가능한 한 바깥쪽(클라이언트에 가까운 곳)에서 응답하고, 상위 어느 계층도 응답할 수 없을 때만 origin까지 내려가는 것입니다.

## 바깥에서 안쪽으로, 계층들

```text
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(사용자에 가장 가까움, 가장 빠름)                       (데이터에 가장 가까움)
```

- **Browser cache** — 정적 자산(JS, CSS, 이미지)과 캐시 가능한 응답을 사용자 기기에 저장. TTL은 `Cache-Control`/`ETag`로 제어하며, 자산은 해시된 파일명과 함께 긴 TTL(일~년)을 자주 가짐.
- **CDN** (CloudFront, Cloudflare) — 사용자 근처 edge 노드에서 정적 콘텐츠와 때로는 동적 콘텐츠를 캐싱. TTL은 수 분(HTML)에서 1년(불변 자산)까지.
- **Reverse proxy** (Varnish, nginx) — 앱 앞단에서 전체 페이지나 fragment를 캐싱. 인기 페이지는 수 초~수 분 TTL; 변경 시 purge 지원.
- **Application / object cache** (Redis, Memcached) — 계산 결과, DB 쿼리 결과, 세션, 렌더링된 fragment를 캐싱. 수 초~수 시간 TTL에 명시적 invalidation 추가.
- **OPcache** — **컴파일된 PHP 바이트코드**를 메모리에 캐싱하여 요청마다 스크립트를 재파싱하지 않게 함. 코드 배포 전까지 사실상 지속됨.
- **DB query / buffer cache** — 데이터베이스가 인기 페이지와 (일부 엔진에서는) 쿼리 결과를 메모리에 유지하여 디스크 읽기를 피함.

## 사고하는 방법

```text
바깥 → 안쪽 각 계층마다:
  계층에 신선한 복사본이 있으면 → 반환 (여기서 멈춤)   // hit; 가능한 가장 저렴
  없으면 → 다음 계층에 질의                          // miss; 계속 내려감
origin (app + DB) → 실제 작업을 수행하고, 돌아 나오며 캐시를 채움
```

각 계층은 **신선도와 속도를 맞바꿉니다**: 바깥 계층은 가장 빠르지만 가장 stale 되기 쉬우므로, 진짜 정적인 것에는 긴 TTL + content hashing을, 동적인 것에는 짧은 TTL + invalidation을 두세요.

## 왜 중요한가

웹 스택에서 latency와 부하 감소의 대부분은 올바른 계층에서의 캐싱에서 나옵니다. 각 계층이 무엇을 담고 TTL이 얼마인지 알면 캐시를 실제로 도움이 되는 곳에 배치하고, stale 데이터 제공을 피하며, 변경이 왜 반영되지 않았는지(어느 계층이 여전히 옛 복사본을 제공 중인지) 추론할 수 있습니다.