캐시 전략 완벽 이해
Cache Hit/Miss, TTL, Thundering Herd를 직접 체험하며 캐시 전략을 학습합니다.
왜 알아야 하나요?
상품 상세 페이지가 너무 느려요!
"같은 상품인데 왜 매번 2초나 걸려요? DB 쿼리가 너무 무거워요."
캐시를 적용했더니...
응답 시간: 2000ms → 2ms (1000배 개선!)
캐시는 성능 최적화의 첫 번째 무기!
하지만 잘못 쓰면 stale data, thundering herd 등 문제가 생겨요.
한눈에 보기: Cache-Aside 패턴
Hit: 캐시에서 바로 반환 (빠름!) / Miss: DB 조회 후 캐시에 저장
핵심 개념
Hit: 캐시에 데이터가 있음 → 빠른 응답
Miss: 캐시에 없음 → DB 조회 필요
목표: Hit Rate 90% 이상!
캐시 데이터의 유효 시간
만료되면 자동으로 삭제 → 다음 조회 시 갱신
주의: 너무 길면 stale data!
캐시 만료 순간, 동시 요청이 모두 DB를 때림
결과: DB 부하 폭증, 장애 가능
해결: 락으로 단일 갱신 보장
데이터 변경 시 캐시도 갱신/삭제 필요
"컴퓨터 과학에서 가장 어려운 문제 중 하나"
전략: 삭제 후 재조회 or 함께 갱신
캐시 전략 비교
| 전략 | 동작 | 장점 | 단점 |
|---|---|---|---|
| Cache-Aside | 앱이 캐시 관리 | 유연함, 장애 격리 | 코드 복잡 |
| Write-Through | 쓰기 시 캐시+DB 동시 | 일관성 보장 | 쓰기 느림 |
| Write-Behind | 캐시만 쓰고 나중에 DB | 쓰기 빠름 | 데이터 유실 위험 |
직접 체험하기
Cache Hit Rate를 높여보고, Thundering Herd 문제를 직접 발생시켜보세요.
같은 키를 반복 조회하면 Hit Rate가 올라가요. 유니크 키가 많으면 Miss가 많아지고 DB 부하가 증가해요.
Cache-Aside 패턴: 캐시 확인 → 없으면 DB → 캐시에 저장
Thundering Herd 방지: 락 또는 분산 락으로 단일 갱신 보장
TTL 주의: 너무 길면 stale data, 너무 짧으면 cache miss 증가
더 알아보기
실무 적용
- • 상품 정보: TTL 5분 + 변경 시 삭제
- • 세션: Redis에 저장, TTL = 세션 만료
- • 조회수: Write-Behind로 배치 저장
Redis 명령어
- • GET key / SET key value
- • SETEX key seconds value
- • TTL key / DEL key