무엇을 캐싱할지, 그리고 얼마나 오래(TTL) 캐싱할지 어떻게 결정하나요?

Question

Accepted Answer

**생성 비용이 크고, 자주 읽히며, 거의 변하지 않는** 데이터를 캐싱하세요 — 캐싱이 가장 큰 이득을 주는 지점입니다. **TTL**(time to live)은 **신선도**(데이터가 얼마나 최신이어야 하는가)와 **stale 허용도**(얼마나 오래 틀려도 되는가) 사이의 트레이드오프입니다.

## 무엇을 캐싱할까

좋은 캐시 후보는 세 가지 모두에서 높은 점수를 받습니다:

- **비용이 큼** — 무거운 DB join, aggregation, 외부 API 호출, 렌더링된 HTML.
- **자주 읽힘** — 많은 요청이 치는 인기 key가 비용을 amortize함.
- **거의 변하지 않음** — 또는 약간의 stale이 허용되는 경우.

계산이 저렴하거나, 쓰기가 많거나, 신선도가 정확해야 하는 사용자별 비밀 데이터(예: 거래 시점의 계좌 잔액)는 캐싱하지 마세요.

## TTL 선택

```text
stale 허용도 → TTL:
  config / 정적 참조 데이터        → 김  (수 시간~수 일)
  상품 목록, 기사 본문             → 중간 (수 분)
  가격, 재고, 리더보드             → 짧음 (수 초)
  항상 정확해야 함                 → 캐싱하지 말거나 명시적 invalidation 사용
```

예측 불가하게 변하는 데이터의 정확성을 위해 TTL과 **명시적 invalidation**을 결합하세요: write-through 또는 delete-on-write로, 만료를 기다리지 않고 소스가 변하는 순간 캐시를 무효화합니다.

```text
on update(record):
  db.save(record)
  cache.delete(key(record))   // 지금 invalidate, TTL까지 stale을 제공하지 않음
```

## 신호: hit ratio

```text
hit ratio = hits / (hits + misses)
  높음 (>90%) → 캐시가 제 역할을 함
  낮음         → TTL이 너무 짧거나, key가 너무 세분화됐거나, 데이터가 캐싱 불가
```

TTL을 튜닝하려면 **cache hit ratio**를 지켜보세요: 비율이 낮으면 거의 캐싱하지 못하는 것이고, 비율이 높은데 stale 불만이 있으면 TTL이 너무 긴 것입니다.

## 왜 중요한가

무엇을 캐싱할지와 TTL을 올바르게 정하는 것이 효과적인 캐싱의 핵심입니다. 잘못된 것을 캐싱하면 이득 없이 복잡성만 늘고, TTL을 너무 길게 잡으면 stale 데이터를 제공하며, 너무 짧으면 이득을 잃습니다. stale 허용도로 TTL을 고르고, 정확성을 위해 명시적 invalidation을 더하며, hit ratio를 지켜보는 것이 원칙적이고 측정 가능한 캐싱 방법을 제공합니다.