캐시 전략(Cache Strategies) 정리

서비스를 운영하다 보면 성능 최적화와 트래픽 비용 절감을 위해 캐시(Cache)를 적극적으로 활용하게 됩니다.

하지만 단순히 Redis 같은 캐시 서버를 붙인다고 끝나는 게 아니라, 어떤 전략으로 캐시를 운용할지에 따라 성능, 안정성, 일관성에서 큰 차이가 납니다.

 

오늘은 자주 쓰이는 대표적인 캐시 전략들을 정리해보겠습니다.

 

---

1. Cache-Aside (Lazy Loading)

가장 많이 사용되는 기본 캐시 전략

• 흐름
  1. 애플리케이션이 캐시에서 데이터 조회
  2. 없으면 DB 조회 후 캐시에 저장
  3. 이후 요청은 캐시에서 처리
• 특징
  • 읽기 많은 API에 적합
  • TTL(Time-To-Live)을 설정하여 데이터 유효기간 관리
  • TTL 만료 시 동시에 많은 요청이 몰리면 Cache Stampede(스탬피드 현상) 발생 가능 → 락(Lock) / Soft-TTL(백그라운드 리프레시) 기법으로 방지

---

2. Write-Through

항상 최신 데이터 유지가 중요한 경우

• 흐름
  1. 쓰기 요청이 오면 DB에 쓰기
  2. 동시에 캐시도 갱신
• 특징
  • 캐시와 DB가 항상 동기화
  • 쓰기 지연 없음 (캐시에 바로 반영)
  • 단점: 쓰기 부하가 큰 서비스에서는 오히려 오버헤드 증가
  • 최신성이 중요한 데이터(예: 사용자 프로필, 주문 상태)에서 유용
• 변형
  • 이벤트 기반 무효화 + 짧은 TTL을 조합하여 최신성을 보장하는 경우도 많음

---

3. Refresh-Ahead

핫 키(Hot Key) 안정화 전략

• 흐름
  1. 자주 조회되는 캐시 키를 미리 감지
  2. TTL 만료 전에 백그라운드에서 데이터를 갱신
• 특징
  • 트래픽이 몰리는 핫 데이터에 효과적
  • 캐시 만료 순간에도 항상 데이터가 존재 → 스파이크 방지
  • 모든 키에 적용하면 리소스 낭비 → 상위 트래픽 Key만 선택적으로 적용

---

4. Write-Behind (Write-Back)

쓰기 비용 줄이고 일관성에 조금 관대할 때

 

• 흐름
  1. 쓰기 요청 시 캐시에 먼저 반영
  2. DB에는 비동기적으로(배치 처리) 기록
• 특징
  • 쓰기 속도 빠름 (사용자 응답 시간 ↓)
  • 캐시가 장애 나면 DB 반영이 누락될 위험 → 리플레이/재처리 로직 필수
  • 로그 데이터, 분석 데이터처럼 일관성보다 처리량이 중요한 경우 적합

 

 

---

5. 부분 캐싱 (Partial Caching)

대용량 리스트/페이지 캐싱 전략

 

• 흐름
  • 무한 스크롤 / 페이지네이션 API 같은 경우 전체를 캐싱하지 않고,
  • 상위 N페이지, 인기 섹션만 캐싱
  • 데이터 변경 시 이벤트 기반 무효화
• 특징
  • 전체 캐싱 부담 ↓
  • 실제로는 상위 구간만 많이 조회되는 패턴에서 효과적
  • SNS 피드, 쇼핑몰 리스트, 검색 결과 등에 유용

---

마무리 

캐시는 단순히 “DB 부담 줄이기” 이상의 역할을 합니다.

서비스의 특성과 데이터의 성격에 따라 적절한 캐시 전략을 선택해야 성능 최적화와 안정성 두 마리 토끼를 잡을 수 있습니다.

 

• 읽기 많은 API → Cache-Aside (+ TTL, Stampede 방지)
• 항상 최신성 중요 → Write-Through / 이벤트 무효화
• 핫 키 안정화 → Refresh-Ahead
• 쓰기 비용 절감 → Write-Behind
• 대용량 목록 → 부분 캐싱