들어가며
지금까지 5편에 걸쳐 캐시 패턴을 다뤘습니다. 이번 마지막 편에서는 실전 시나리오별로 어떤 전략을 선택해야 하는지 정리합니다.
시나리오별 전략
1. 상품 상세 페이지
- 읽기가 대부분, 쓰기는 가끔
- 동시 조회가 많을 수 있음 (인기 상품)
- 잠깐 옛날 데이터 보여줘도 큰일 아님
| 항목 | 설정 |
|---|---|
| 패턴 | Cache-Aside |
| TTL | 30분 |
| 무효화 | 수정 시 삭제 |
| Stampede 방지 | 분산락 + 캐시 워밍 (인기 상품) |
2. 카테고리별 상품 목록
- 여러 상품을 묶어서 캐싱
- 상품 하나가 수정돼도 목록 캐시 무효화 필요
- 페이지네이션 고려 필요
| 항목 | 설정 |
|---|---|
| 패턴 | Cache-Aside |
| TTL | 10분 (상세보다 짧게) |
| 무효화 | 상품 수정 이벤트로 카테고리 캐시 삭제 |
| 키 설계 | category:{id}:page:{page}:size:{size} |
3. 조회수 / 좋아요 수
- 쓰기가 매우 빈번
- 유실돼도 치명적이지 않음
- 정확한 실시간 값보다 성능이 중요
| 항목 | 설정 |
|---|---|
| 패턴 | Write-Behind |
| Flush 주기 | 5초 (조절 가능) |
| 유실 허용 | 최대 5초분 |
| DB 부하 | 최소화 |
4. 사용자 세션 / 인증 정보
- 사용자별로 격리된 데이터
- 로그아웃/권한 변경 시 즉시 무효화 필요
- 보안상 민감할 수 있음
| 항목 | 설정 |
|---|---|
| 패턴 | Cache-Aside (Redis가 Primary) |
| TTL | 2시간 (비즈니스 요구사항에 따라) |
| 무효화 | 로그아웃/권한 변경 시 즉시 삭제 |
| 키 설계 | session:{sessionId}, user-sessions:{userId} |
5. 실시간 랭킹
- 자주 변경됨
- 정렬된 데이터 필요
- Redis Sorted Set이 적합
| 항목 | 설정 |
|---|---|
| 자료구조 | Redis Sorted Set |
| TTL | 없음 (스케줄러로 리셋) |
| 특징 | 실시간 정렬, O(log N) 삽입/조회 |
6. 검색 결과
- 쿼리 조합이 다양함 (키워드, 필터, 정렬)
- 같은 검색어는 결과가 비슷함
- 인덱스 갱신 시 무효화 필요
| 항목 | 설정 |
|---|---|
| 패턴 | Cache-Aside |
| TTL | 5분 (검색 인덱스 갱신 주기 고려) |
| 키 설계 | 쿼리 해시 |
| 무효화 | TTL에 의존 (명시적 무효화 어려움) |
7. 재고 (캐시 사용 주의)
🚨
재고는 정확성이 매우 중요합니다! 캐시 불일치가 치명적이므로 특별히 주의해야 합니다.
- 정확성이 매우 중요 (돈과 연결)
- 동시성 제어 필수
- 캐시 불일치가 치명적
| 항목 | 설정 |
|---|---|
| 패턴 | 분산락 + Write-Through |
| TTL | 없음 또는 매우 짧게 |
| 무효화 | 변경 시 즉시 갱신 |
| 중요 | DB 트랜잭션과 Redis 동기화 |
전략 선택 체크리스트
1. 데이터 특성
- [ ] 읽기/쓰기 비율은?
- [ ] 얼마나 자주 변경되는가?
- [ ] 틀리면 얼마나 큰일인가?
2. 접근 패턴
- [ ] Hot data가 있는가? (인기 상품 등)
- [ ] 동시 접근이 많은가?
- [ ] 개인화된 데이터인가?
3. 요구사항
- [ ] 실시간 정확성이 필요한가?
- [ ] 유실이 허용되는가?
- [ ] 무효화 시점을 알 수 있는가?
4. 인프라
- [ ] Redis 클러스터 구성은?
- [ ] 장애 시 fallback은?
- [ ] 메모리 용량은 충분한가?
시리즈 총정리
패턴 선택 가이드
🌳
주요 사용 패턴은?
무효화 전략
| 전략 | 용도 |
|---|---|
| TTL | 모든 캐시의 기본 보험 |
| 명시적 삭제 | 수정 시 즉시 반영 |
| 이벤트 기반 | 연관 캐시 삭제 |
| 수동 무효화 | 관리자용, 긴급 대응 |
Stampede 방지
| 방법 | 특징 |
|---|---|
| 분산락 | 확실한 방지, 복잡도 높음 |
| 확률적 조기 만료 | 대부분 방지, 간단 |
| 캐시 워밍 | Hot data에 효과적 |
마치며
⚠️
캐시는 강력하지만 양날의 검입니다. 잘못 사용하면 오히려 문제가 됩니다.
1
"캐시가 틀리면 얼마나 큰일인가?"
이 질문을 먼저 하세요
2
TTL은 보험
항상 설정하세요
3
갱신보다 삭제
동시성 문제 방지
4
Hot data는 특별 관리
분산락, 워밍 적용
5
정확성이 중요하면 캐시하지 마세요
재고, 잔액 등
💡
이 시리즈가 캐시 전략을 결정하는 데 도움이 되길 바랍니다!
시리즈 목차
- 캐시 패턴 개요 및 비교
- Spring Boot + Redis 설정 및 Cache-Aside 구현
- Write-Through / Write-Behind 패턴 구현
- Cache Invalidation 전략
- Thundering Herd / Cache Stampede 해결
- 실전 시나리오별 캐시 전략 가이드 (현재 글)
예제 코드
ℹ️
전체 코드는 GitHub에서 확인할 수 있습니다.