캐싱 전략¶

개요¶

이 문서에서는 캐싱의 핵심 전략과 패턴을 다룹니다. Cache-Aside, Read-Through, Write-Through, Write-Behind 패턴의 차이를 이해하고, 캐시 무효화, TTL 설정, 그리고 캐시 침투/눈사태/핫키 문제와 해결책을 학습합니다.

난이도: ⭐⭐⭐ 예상 학습 시간: 2-3시간 선수 지식: 05_Reverse_Proxy_API_Gateway.md

목차¶

캐싱이란?
캐싱 전략 패턴
캐시 무효화
캐시 문제와 해결책
CDN 캐싱
연습 문제
다음 단계
참고 자료

1. 캐싱이란?¶

1.1 캐싱의 정의¶

┌─────────────────────────────────────────────────────────────────┐
│                      캐싱이란?                                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "자주 사용하는 데이터를 빠른 저장소에 임시 저장"               │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  캐시 없이:                                                │ │
│  │                                                            │ │
│  │  Client ──▶ Server ──▶ Database                            │ │
│  │         ◀──────────────    (매번 DB 조회)                  │ │
│  │         ~100ms                                             │ │
│  │                                                            │ │
│  │  캐시 사용:                                                │ │
│  │                                                            │ │
│  │  Client ──▶ Server ──▶ Cache (Hit!) ──▶ 응답              │ │
│  │         ◀────────────    ~1ms                              │ │
│  │                                                            │ │
│  │  Cache Miss 시:                                            │ │
│  │  Server ──▶ Database ──▶ Cache 저장 ──▶ 응답              │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  100배 이상 빠른 응답 가능!                                     │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

1.2 캐시 계층¶

┌─────────────────────────────────────────────────────────────────┐
│                      캐시 계층                                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Client                                                         │
│    │                                                            │
│    ├── 브라우저 캐시 (가장 빠름)                                │
│    │     L1: 메모리 캐시                                        │
│    │     L2: 디스크 캐시                                        │
│    │                                                            │
│    ├── CDN 캐시 (Edge)                                          │
│    │     지리적으로 가까운 서버                                 │
│    │                                                            │
│    ├── 리버스 프록시 캐시                                       │
│    │     Nginx, Varnish                                         │
│    │                                                            │
│    ├── 애플리케이션 캐시                                        │
│    │     로컬 캐시 (in-memory)                                  │
│    │     분산 캐시 (Redis, Memcached)                           │
│    │                                                            │
│    └── 데이터베이스 캐시                                        │
│          Query Cache, Buffer Pool                               │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │       빠름                              느림                │ │
│  │  ◀───────────────────────────────────────────────▶         │ │
│  │  브라우저 → CDN → 프록시 → App Cache → DB                  │ │
│  │                                                            │ │
│  │       작음                              큼                  │ │
│  │  ◀───────────────────────────────────────────────▶         │ │
│  │        (저장 용량)                                         │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

1.3 캐시 히트율¶

┌─────────────────────────────────────────────────────────────────┐
│                    캐시 히트율                                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Cache Hit Rate = (캐시 적중 수) / (전체 요청 수) × 100%        │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  예시: 1000 요청, 950 Hit, 50 Miss                         │ │
│  │  Hit Rate = 950 / 1000 = 95%                               │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  히트율에 따른 효과:                                            │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  Hit Rate   │ DB 부하 감소  │ 평균 응답 시간               │ │
│  │  ───────────┼───────────────┼────────────────              │ │
│  │  50%        │ 50%           │ 50ms (예시)                  │ │
│  │  90%        │ 90%           │ 10ms                         │ │
│  │  95%        │ 95%           │ 5ms                          │ │
│  │  99%        │ 99%           │ 2ms                          │ │
│  │                                                            │ │
│  │  높은 히트율 = 더 빠른 응답 + DB 보호                      │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  히트율 향상 전략:                                              │
│  • 적절한 TTL 설정                                              │
│  • 캐시 크기 최적화                                             │
│  • 핫 데이터 사전 로딩                                          │
│  • 캐시 키 설계 최적화                                          │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

2. 캐싱 전략 패턴¶

2.1 Cache-Aside (Lazy Loading)¶

┌─────────────────────────────────────────────────────────────────┐
│                    Cache-Aside 패턴                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "애플리케이션이 캐시를 직접 관리"                              │
│                                                                  │
│  읽기 (Read):                                                   │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  Application                                               │ │
│  │      │                                                     │ │
│  │      │ 1. 캐시에서 조회                                    │ │
│  │      ▼                                                     │ │
│  │   [Cache] ──Hit?──▶ Yes ──▶ 데이터 반환                    │ │
│  │      │                                                     │ │
│  │     No (Miss)                                              │ │
│  │      │                                                     │ │
│  │      │ 2. DB에서 조회                                      │ │
│  │      ▼                                                     │ │
│  │  [Database] ──▶ 데이터 반환                                │ │
│  │      │                                                     │ │
│  │      │ 3. 캐시에 저장                                      │ │
│  │      ▼                                                     │ │
│  │   [Cache] (업데이트)                                       │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  쓰기 (Write):                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  Application                                               │ │
│  │      │                                                     │ │
│  │      │ 1. DB에 쓰기                                        │ │
│  │      ▼                                                     │ │
│  │  [Database] (업데이트)                                     │ │
│  │      │                                                     │ │
│  │      │ 2. 캐시 무효화 (삭제)                               │ │
│  │      ▼                                                     │ │
│  │   [Cache] (삭제)                                           │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  코드 예시:                                                     │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │  def get_user(user_id):                                    │ │
│  │      # 1. 캐시 확인                                        │ │
│  │      user = cache.get(f"user:{user_id}")                   │ │
│  │      if user:                                              │ │
│  │          return user  # Cache Hit                          │ │
│  │                                                            │ │
│  │      # 2. DB 조회 (Cache Miss)                             │ │
│  │      user = db.query(f"SELECT * FROM users WHERE id={id}") │ │
│  │                                                            │ │
│  │      # 3. 캐시 저장                                        │ │
│  │      cache.set(f"user:{user_id}", user, ttl=3600)          │ │
│  │                                                            │ │
│  │      return user                                           │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  장점:                                                          │
│  • 필요한 데이터만 캐싱 (메모리 효율)                           │
│  • 캐시 장애 시에도 DB로 동작                                   │
│                                                                  │
│  단점:                                                          │
│  • 첫 요청은 항상 느림 (Cache Miss)                             │
│  • 캐시-DB 불일치 가능성                                        │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

2.2 Read-Through¶

┌─────────────────────────────────────────────────────────────────┐
│                   Read-Through 패턴                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "캐시가 DB 조회를 대행"                                        │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  Application                                               │ │
│  │      │                                                     │ │
│  │      │ 1. 캐시에 요청 (항상)                               │ │
│  │      ▼                                                     │ │
│  │   [Cache] ──Hit?──▶ Yes ──▶ 데이터 반환                    │ │
│  │      │                                                     │ │
│  │     No (Miss)                                              │ │
│  │      │                                                     │ │
│  │      │ 2. 캐시가 DB 조회 (자동)                            │ │
│  │      ▼                                                     │ │
│  │  [Database]                                                │ │
│  │      │                                                     │ │
│  │      │ 3. 캐시에 저장 + 반환                               │ │
│  │      ▼                                                     │ │
│  │  Application                                               │ │
│  │                                                            │ │
│  │  애플리케이션은 캐시만 바라봄!                             │ │
│  │  DB 조회 로직이 캐시에 내장됨                              │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  Cache-Aside vs Read-Through:                                   │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │  Cache-Aside: 앱이 캐시와 DB 모두 관리                     │ │
│  │  Read-Through: 앱은 캐시만 사용, 캐시가 DB 관리            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  장점:                                                          │
│  • 애플리케이션 코드 단순화                                     │
│  • 캐시 로직 중앙화                                             │
│                                                                  │
│  단점:                                                          │
│  • 캐시 시스템에 로더 구현 필요                                 │
│  • 유연성 감소                                                  │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

2.3 Write-Through¶

┌─────────────────────────────────────────────────────────────────┐
│                  Write-Through 패턴                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "쓰기 시 캐시와 DB 동시 업데이트 (동기)"                       │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  Application                                               │ │
│  │      │                                                     │ │
│  │      │ 1. 캐시에 쓰기                                      │ │
│  │      ▼                                                     │ │
│  │   [Cache] ─────────────────────────────────────┐           │ │
│  │      │                                         │           │ │
│  │      │ 2. 캐시가 DB에 쓰기 (동기)              │           │ │
│  │      ▼                                         │ 동시에    │ │
│  │  [Database]                                    │ 완료      │ │
│  │      │                                         │           │ │
│  │      │ 3. 완료 후 응답                         │           │ │
│  │      ▼                                         │           │ │
│  │  Application ◀─────────────────────────────────┘           │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  특징:                                                          │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  • 캐시와 DB가 항상 동기화 (강한 일관성)                   │ │
│  │  • Read-Through와 함께 사용하면 효과적                     │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  장점:                                                          │
│  • 데이터 일관성 보장                                           │
│  • 데이터 손실 없음                                             │
│                                                                  │
│  단점:                                                          │
│  • 쓰기 지연 (두 곳에 쓰기)                                     │
│  • 불필요한 데이터도 캐싱될 수 있음                             │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

2.4 Write-Behind (Write-Back)¶

┌─────────────────────────────────────────────────────────────────┐
│                 Write-Behind (Write-Back) 패턴                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "캐시에 먼저 쓰고, DB에는 나중에 쓰기 (비동기)"                │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  Application                                               │ │
│  │      │                                                     │ │
│  │      │ 1. 캐시에 쓰기                                      │ │
│  │      ▼                                                     │ │
│  │   [Cache] ──────────────▶ 즉시 응답                        │ │
│  │      │                                                     │ │
│  │      │ 2. 나중에 DB에 쓰기 (비동기)                        │ │
│  │      │    ┌─────────────────────────────┐                  │ │
│  │      │    │ Write Queue                 │                  │ │
│  │      │    │ [data1, data2, data3, ...]  │                  │ │
│  │      │    └─────────────────────────────┘                  │ │
│  │      │              │                                      │ │
│  │      │              │ 배치 처리                            │ │
│  │      │              ▼                                      │ │
│  │      └─────────▶ [Database]                                │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  시간대별 동작:                                                 │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  T=0: Write 1 → Cache (즉시 완료)                          │ │
│  │  T=1: Write 2 → Cache (즉시 완료)                          │ │
│  │  T=2: Write 3 → Cache (즉시 완료)                          │ │
│  │  ...                                                       │ │
│  │  T=10: 배치로 DB에 Write 1,2,3 한 번에 저장                │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  장점:                                                          │
│  • 쓰기 성능 우수 (캐시에만 쓰고 응답)                          │
│  • DB 부하 감소 (배치 처리)                                     │
│  • 쓰기 병합 가능 (같은 키 여러 번 쓰기 → 마지막만 저장)        │
│                                                                  │
│  단점:                                                          │
│  • 데이터 손실 위험 (캐시 장애 시)                              │
│  • 구현 복잡                                                    │
│  • 일관성 문제 (DB에 아직 없는 데이터)                          │
│                                                                  │
│  사용 사례:                                                     │
│  • 로그 수집                                                    │
│  • 조회수/좋아요 카운터                                         │
│  • 실시간성보다 성능이 중요한 경우                              │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

2.5 패턴 비교 요약¶

패턴	읽기	쓰기	일관성	성능	복잡도
Cache-Aside	앱이 관리	DB 직접, 캐시 무효화	약함	좋음	낮음
Read-Through	캐시가 관리	-	-	좋음	중간
Write-Through	-	캐시→DB 동기	강함	보통	중간
Write-Behind	-	캐시 먼저, DB 나중	약함	매우 좋음	높음

3. 캐시 무효화¶

3.1 무효화 전략¶

┌─────────────────────────────────────────────────────────────────┐
│                    캐시 무효화 전략                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "캐시된 데이터를 언제, 어떻게 삭제/갱신할 것인가?"             │
│                                                                  │
│  1. TTL (Time To Live) 기반                                     │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  cache.set("user:123", data, ttl=3600)  # 1시간 후 만료    │ │
│  │                                                            │ │
│  │  T=0:     [user:123] 저장                                  │ │
│  │  T=3600:  [user:123] 자동 삭제                             │ │
│  │                                                            │ │
│  │  장점: 단순, 자동                                          │ │
│  │  단점: TTL 동안 오래된 데이터 서빙 가능                    │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  2. 명시적 삭제 (Explicit Invalidation)                         │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  # 데이터 수정 시                                          │ │
│  │  db.update_user(user_id, new_data)                         │ │
│  │  cache.delete(f"user:{user_id}")  # 캐시 삭제              │ │
│  │                                                            │ │
│  │  장점: 즉시 일관성 회복                                    │ │
│  │  단점: 삭제 로직 필요, 실수 가능                           │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  3. 이벤트 기반 무효화                                          │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  DB 변경 ──▶ 이벤트 발행 ──▶ 캐시 무효화                   │ │
│  │                                                            │ │
│  │  [DB] ──CDC──▶ [Kafka] ──▶ [Cache Invalidator]             │ │
│  │                                                            │ │
│  │  장점: 느슨한 결합, 확장성                                 │ │
│  │  단점: 복잡도 증가, 지연 가능                              │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

3.2 TTL 설정 가이드¶

┌─────────────────────────────────────────────────────────────────┐
│                     TTL 설정 가이드                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  데이터 특성별 TTL 권장:                                        │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  거의 변하지 않는 데이터:                                  │ │
│  │  • 설정 값, 메타데이터: 24시간 ~ 7일                       │ │
│  │  • 국가/지역 정보: 7일+                                    │ │
│  │                                                            │ │
│  │  자주 변하지 않는 데이터:                                  │ │
│  │  • 사용자 프로필: 1시간 ~ 24시간                           │ │
│  │  • 상품 정보: 1시간 ~ 6시간                                │ │
│  │                                                            │ │
│  │  자주 변하는 데이터:                                       │ │
│  │  • 재고 수량: 1분 ~ 5분                                    │ │
│  │  • 실시간 통계: 30초 ~ 1분                                 │ │
│  │                                                            │ │
│  │  실시간 데이터:                                            │ │
│  │  • 캐싱하지 않거나 매우 짧은 TTL (초 단위)                 │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  TTL 결정 공식:                                                 │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  TTL = f(변경 빈도, 일관성 요구, 트래픽 패턴)              │ │
│  │                                                            │ │
│  │  • 변경 빈도 낮음 → TTL 길게                               │ │
│  │  • 일관성 중요 → TTL 짧게 또는 명시적 무효화               │ │
│  │  • 트래픽 높음 → TTL 길게 (히트율 중요)                    │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  TTL Jitter (지터):                                             │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  문제: 같은 TTL → 동시 만료 → 캐시 스탬피드                │ │
│  │                                                            │ │
│  │  해결: TTL에 랜덤 값 추가                                  │ │
│  │                                                            │ │
│  │  base_ttl = 3600  # 1시간                                  │ │
│  │  jitter = random(-300, 300)  # ±5분                        │ │
│  │  ttl = base_ttl + jitter  # 55분 ~ 65분                    │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

4. 캐시 문제와 해결책¶

4.1 캐시 침투 (Cache Penetration)¶

┌─────────────────────────────────────────────────────────────────┐
│                    캐시 침투                                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "존재하지 않는 데이터를 계속 요청 → DB 과부하"                 │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  공격자: GET /user?id=-1 (존재하지 않는 ID)                │ │
│  │                                                            │ │
│  │  매번:                                                     │ │
│  │  1. 캐시 확인 → Miss                                       │ │
│  │  2. DB 조회 → 결과 없음                                    │ │
│  │  3. 캐시 저장 안 함 (없으니까)                             │ │
│  │  4. 다음 요청도 같은 과정 반복!                            │ │
│  │                                                            │ │
│  │  Request ──▶ [Cache] ──Miss──▶ [DB] ──▶ Empty              │ │
│  │  Request ──▶ [Cache] ──Miss──▶ [DB] ──▶ Empty (반복)       │ │
│  │  Request ──▶ [Cache] ──Miss──▶ [DB] ──▶ Empty              │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 1: Null 값 캐싱                                         │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  data = cache.get(key)                                     │ │
│  │  if data is None:                                          │ │
│  │      data = db.query(key)                                  │ │
│  │      if data is None:                                      │ │
│  │          cache.set(key, "NULL", ttl=60)  # 짧은 TTL        │ │
│  │      else:                                                 │ │
│  │          cache.set(key, data, ttl=3600)                    │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 2: Bloom Filter                                         │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  [Bloom Filter] ──"key 존재할 수 있음?"                    │ │
│  │       │                                                    │ │
│  │       ├── 확실히 없음 → 바로 반환 (DB 조회 안 함)          │ │
│  │       │                                                    │ │
│  │       └── 있을 수 있음 → 캐시/DB 조회                      │ │
│  │                                                            │ │
│  │  Bloom Filter: 메모리 효율적인 존재 확인 자료구조          │ │
│  │  False Positive 가능, False Negative 불가                  │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

4.2 캐시 눈사태 (Cache Avalanche)¶

┌─────────────────────────────────────────────────────────────────┐
│                    캐시 눈사태                                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "대량의 캐시가 동시에 만료 → DB 폭주"                          │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  T=0: 캐시 워밍 (1000개 항목, TTL=3600)                    │ │
│  │                                                            │ │
│  │  T=3600: 1000개 동시 만료!                                 │ │
│  │          ──▶ 1000개 동시 DB 조회                           │ │
│  │          ──▶ DB 과부하 / 장애                              │ │
│  │                                                            │ │
│  │  [Cache] ═════════════════════════════════════             │ │
│  │          │  All Expired!  │                                │ │
│  │          └────────────────┘                                │ │
│  │                   │                                        │ │
│  │          ┌────────┴────────┐                               │ │
│  │          │ DB 동시 요청   │                                │ │
│  │          │ 1000개!       │                                │ │
│  │          └────────────────┘                                │ │
│  │                   │                                        │ │
│  │                   ▼                                        │ │
│  │              [DB] 💥 과부하                                │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 1: TTL 분산 (Jitter)                                    │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  ttl = base_ttl + random(0, 600)  # 0~10분 랜덤 추가       │ │
│  │                                                            │ │
│  │  → 만료 시점이 분산됨                                      │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 2: 캐시 워밍 (Pre-loading)                              │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  • 서버 시작 시 핫 데이터 미리 로딩                        │ │
│  │  • 만료 전에 백그라운드에서 갱신                           │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 3: 다중 캐시 레이어                                     │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  [L1 Cache] ──Miss──▶ [L2 Cache] ──Miss──▶ [DB]            │ │
│  │   (로컬)               (분산)                              │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 4: 뮤텍스/락                                            │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  캐시 Miss 시 하나의 요청만 DB 조회, 나머지 대기           │ │
│  │                                                            │ │
│  │  def get_with_lock(key):                                   │ │
│  │      data = cache.get(key)                                 │ │
│  │      if data:                                              │ │
│  │          return data                                       │ │
│  │                                                            │ │
│  │      if cache.setnx(f"lock:{key}", 1, ttl=10):             │ │
│  │          # 락 획득 성공 → DB 조회                          │ │
│  │          data = db.query(key)                              │ │
│  │          cache.set(key, data)                              │ │
│  │          cache.delete(f"lock:{key}")                       │ │
│  │      else:                                                 │ │
│  │          # 락 획득 실패 → 잠시 대기 후 재시도              │ │
│  │          sleep(0.1)                                        │ │
│  │          return cache.get(key)                             │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

4.3 핫키 문제 (Hot Key)¶

┌─────────────────────────────────────────────────────────────────┐
│                      핫키 문제                                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "특정 키에 트래픽 집중 → 해당 캐시 노드 과부하"                │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  예: 인기 연예인 게시글, 플래시 세일 상품                  │ │
│  │                                                            │ │
│  │       product:12345 (핫 상품)                              │ │
│  │             │                                              │ │
│  │    ┌────────┼────────┐                                     │ │
│  │    │        │        │                                     │ │
│  │    ▼        ▼        ▼                                     │ │
│  │  [요청]   [요청]   [요청]  ×10000                          │ │
│  │             │                                              │ │
│  │             ▼                                              │ │
│  │    [Redis Node 1] 💥 과부하                                │ │
│  │                                                            │ │
│  │  다른 노드들은 한가한데 한 노드만 과부하!                  │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 1: 로컬 캐시 추가                                       │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  [App Server 1] ──[Local Cache]                            │ │
│  │  [App Server 2] ──[Local Cache]                            │ │
│  │  [App Server 3] ──[Local Cache]                            │ │
│  │          │               │                                 │ │
│  │          └───────────────┘                                 │ │
│  │                  │                                         │ │
│  │                  ▼                                         │ │
│  │            [Redis Cluster]                                 │ │
│  │                                                            │ │
│  │  로컬 캐시로 핫키 분산!                                    │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 2: 키 복제 (Key Replication)                            │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  원래: product:12345                                       │ │
│  │                                                            │ │
│  │  복제: product:12345:0                                     │ │
│  │        product:12345:1                                     │ │
│  │        product:12345:2                                     │ │
│  │        ...                                                 │ │
│  │        product:12345:N                                     │ │
│  │                                                            │ │
│  │  조회 시: product:12345:{random(0, N)}                     │ │
│  │  → 여러 노드에 분산!                                       │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  해결책 3: 읽기 복제본                                          │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  [Master] ──복제──▶ [Replica 1]                            │ │
│  │               ──▶ [Replica 2]                              │ │
│  │               ──▶ [Replica 3]                              │ │
│  │                                                            │ │
│  │  읽기 요청을 복제본들에 분산                               │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

4.4 문제 요약¶

문제	원인	영향	해결책
캐시 침투	없는 데이터 조회	DB 과부하	Null 캐싱, Bloom Filter
캐시 눈사태	동시 만료	DB 폭주	TTL Jitter, 락, 워밍
핫키	특정 키 집중	노드 과부하	로컬 캐시, 키 복제

5. CDN 캐싱¶

5.1 CDN 캐싱 개요¶

┌─────────────────────────────────────────────────────────────────┐
│                     CDN 캐싱                                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  "정적 콘텐츠를 엣지 서버에 캐싱"                               │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │              ┌─────────────┐                               │ │
│  │              │   Origin    │                               │ │
│  │              │   Server    │                               │ │
│  │              └──────┬──────┘                               │ │
│  │                     │                                      │ │
│  │        ┌────────────┼────────────┐                         │ │
│  │        │            │            │                         │ │
│  │        ▼            ▼            ▼                         │ │
│  │   ┌─────────┐  ┌─────────┐  ┌─────────┐                   │ │
│  │   │ Edge    │  │ Edge    │  │ Edge    │                   │ │
│  │   │ Seoul   │  │ Tokyo   │  │ NYC     │                   │ │
│  │   └────┬────┘  └────┬────┘  └────┬────┘                   │ │
│  │        │            │            │                         │ │
│  │        ▼            ▼            ▼                         │ │
│  │   한국 사용자    일본 사용자   미국 사용자                  │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  CDN 캐싱 대상:                                                 │
│  • 이미지, CSS, JavaScript                                      │
│  • 폰트, 동영상                                                 │
│  • API 응답 (GET, 캐시 가능한 것)                               │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

5.2 Cache-Control 헤더¶

┌─────────────────────────────────────────────────────────────────┐
│                  Cache-Control 헤더                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  주요 디렉티브:                                                 │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  max-age=3600                                              │ │
│  │    브라우저/CDN 캐싱 시간 (초)                             │ │
│  │                                                            │ │
│  │  s-maxage=86400                                            │ │
│  │    CDN/공유 캐시 전용 시간 (max-age보다 우선)              │ │
│  │                                                            │ │
│  │  public                                                    │ │
│  │    모든 캐시에서 저장 가능                                 │ │
│  │                                                            │ │
│  │  private                                                   │ │
│  │    브라우저만 캐시 가능 (CDN 불가)                         │ │
│  │                                                            │ │
│  │  no-cache                                                  │ │
│  │    캐시 전에 원본에 검증 필요                              │ │
│  │                                                            │ │
│  │  no-store                                                  │ │
│  │    캐싱 금지                                               │ │
│  │                                                            │ │
│  │  stale-while-revalidate=60                                 │ │
│  │    오래된 캐시 서빙하면서 백그라운드 갱신                  │ │
│  │                                                            │ │
│  │  immutable                                                 │ │
│  │    콘텐츠가 절대 변하지 않음 (버전이 URL에 포함)           │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  예시:                                                          │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                                                            │ │
│  │  # 정적 자산 (1년)                                         │ │
│  │  Cache-Control: public, max-age=31536000, immutable        │ │
│  │                                                            │ │
│  │  # API 응답 (CDN 1시간, 브라우저 5분)                      │ │
│  │  Cache-Control: public, max-age=300, s-maxage=3600         │ │
│  │                                                            │ │
│  │  # 개인 데이터 (브라우저만)                                │ │
│  │  Cache-Control: private, max-age=600                       │ │
│  │                                                            │ │
│  │  # 민감한 데이터 (캐싱 금지)                               │ │
│  │  Cache-Control: no-store                                   │ │
│  │                                                            │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

6. 연습 문제¶

문제 1: 캐싱 전략 선택¶

다음 시나리오에 적합한 캐싱 패턴을 선택하고 이유를 설명하세요.

a) 읽기 위주 서비스 (읽기:쓰기 = 100:1) b) 쓰기가 많은 로그 시스템 c) 강한 일관성이 필요한 재고 관리 d) 간단한 웹 애플리케이션

문제 2: TTL 설정¶

다음 데이터에 적절한 TTL을 설정하세요.

a) 사용자 프로필 (하루에 몇 번 변경) b) 상품 가격 (실시간 변동) c) 국가 목록 (거의 변하지 않음) d) 실시간 주식 가격

문제 3: 캐시 문제 해결¶

다음 상황의 문제를 식별하고 해결책을 제시하세요.

상황: "매일 자정에 캐시가 모두 만료되어 서버가 느려집니다."

문제 4: Cache-Control 작성¶

다음 요구사항에 맞는 Cache-Control 헤더를 작성하세요.

a) 정적 이미지 (버전 포함 URL, 1년 캐싱) b) API 응답 (CDN 10분, 브라우저 1분) c) 로그인 상태 확인 API (캐싱 금지)

정답¶

문제 1 정답¶

a) 읽기 위주 서비스: Cache-Aside
   - 읽기 시 캐시 우선 조회
   - 캐시 미스 시 DB 조회 후 캐싱
   - 읽기 최적화에 적합

b) 쓰기가 많은 로그 시스템: Write-Behind
   - 캐시에 빠르게 쓰고 응답
   - 배치로 DB에 저장
   - 쓰기 성능 극대화

c) 강한 일관성 재고 관리: Write-Through
   - 캐시와 DB 동시 업데이트
   - 항상 일관된 재고 수량
   - 과판매 방지

d) 간단한 웹 애플리케이션: Cache-Aside
   - 구현 단순
   - 캐시 장애 시에도 DB로 동작
   - 가장 범용적

문제 2 정답¶

a) 사용자 프로필: 1-4시간
   - 변경 빈도 낮음
   - 명시적 무효화와 함께 사용

b) 상품 가격: 1-5분 또는 캐싱 안 함
   - 가격 정확성 중요
   - 짧은 TTL 또는 이벤트 기반 무효화

c) 국가 목록: 24시간 ~ 7일
   - 거의 변하지 않음
   - 긴 TTL로 캐시 효율 극대화

d) 실시간 주식 가격: 캐싱하지 않음
   - 실시간성이 중요
   - 오래된 데이터는 위험

문제 3 정답¶

문제: 캐시 눈사태 (Cache Avalanche)
      모든 캐시가 자정에 동시 만료

해결책:
1. TTL Jitter
   base_ttl = 86400  # 24시간
   jitter = random(-3600, 3600)  # ±1시간
   ttl = base_ttl + jitter

2. 캐시 워밍
   - 자정 전에 백그라운드에서 갱신
   - 만료 1시간 전에 미리 DB 조회

3. Stale-While-Revalidate
   - 오래된 캐시 서빙하면서 비동기 갱신

4. 캐시 갱신 분산
   - 항목별로 다른 시간에 캐싱

문제 4 정답¶

a) 정적 이미지 (버전 포함)
   Cache-Control: public, max-age=31536000, immutable

b) API 응답
   Cache-Control: public, max-age=60, s-maxage=600

c) 로그인 상태 API
   Cache-Control: no-store
   (또는: Cache-Control: private, no-cache)

7. 다음 단계¶

캐싱 전략을 이해했다면, 분산 캐시 시스템을 학습하세요.

다음 레슨¶

07_Distributed_Cache_Systems.md

8. 참고 자료¶

문서¶

도구¶

참고 자료¶

Caching Strategies

문서 정보 - 최종 수정: 2024년 - 난이도: ⭐⭐⭐ - 예상 학습 시간: 2-3시간