Redis 캐시 정합성과 실패 패턴

Overview

캐시는 정상 상태의 평균 응답을 줄이지만 Miss가 동시에 발생하면 부하를 원본으로 증폭한다. 그래서 Hit Ratio보다 “Cache가 없거나 오래됐을 때 시스템이 어떻게 실패하는가”가 더 중요하다.

핵심 용어

왜 필요한가

캐시가 DB를 보호한다는 가정은 Hit일 때만 맞는다. 장애나 재시작 후 Cold Cache에서 모든 요청이 DB로 향하면 Redis 장애가 DB 장애로 번진다. 최신성 요구와 원본 보호를 함께 설계해야 한다.

핵심 원리와 내부 동작

Single Flight는 같은 Key의 첫 요청만 Load하고 나머지는 결과를 기다린다. TTL Jitter는 만료 시간을 분산한다. Negative Cache는 “없음”을 짧게 저장한다. Logical TTL은 만료된 값을 잠시 제공하면서 한 Worker가 갱신해 Tail Latency와 원본 폭주를 줄인다.

Example

freshUntil > now  → cached value
staleUntil > now  → stale value 반환 + 한 요청만 refresh
그 이후             → 제한된 동기 load, timeout 시 fallback

DB Commit 후 Evict가 실패한 경우 TTL까지 Stale이 남는다. 중요 데이터는 Payload Version을 비교하거나 Event 기반 재삭제를 두고, 권한·잔액처럼 Stale 허용이 거의 없는 데이터는 Cache 적용 자체를 제한한다.

실무에서 발생하는 문제와 Trade-off

Lock TTL보다 Load가 길면 중복 Load가 다시 생긴다. Null Cache TTL이 길면 새 데이터가 생겨도 안 보인다. Local Cache를 추가하면 빠르지만 Instance별 Stale Window가 생긴다. Hot Key 복제는 쓰기 동기화 비용을 늘린다.

흔한 오해

• TTL Jitter만으로 Redis 전체 장애를 해결할 수 없다.
• 분산 Lock은 모든 요청을 직렬화해 오히려 Tail Latency를 키울 수 있다.
• 높은 Hit Ratio가 최신성이나 사용자 성공률을 보장하지 않는다.

Production Considerations

Key 분포, Hit/Miss, Load 동시성, Stale 제공 수, Redis/DB Timeout을 함께 본다. Redis 차단, Empty Cache, 대량 만료, Hot Key를 부하 테스트한다. DB 보호를 위해 Concurrency Limit, Circuit Breaker와 Fallback을 단계별로 둔다.

다른 사람에게 설명한다면

30초: “캐시 장애의 핵심은 Miss가 원본 부하로 바뀐다는 점입니다. 인기 Key 동시 만료는 Stampede, 없는 Key 반복은 Penetration, 대량 만료는 Avalanche입니다. Single Flight, Negative Cache, TTL Jitter와 원본 Rate Limit을 조합합니다.”

2분: 각 실패 모드가 요청 흐름에서 어디서 발생하는지 그리고 대응이 만드는 Stale·대기 Trade-off, Cold Cache 복구 순서를 설명한다.

Interview Questions

1. Stampede와 Avalanche의 차이는?
2. Logical TTL은 왜 Stale을 허용하는가?
3. Negative Cache TTL은 어떻게 정하는가?
4. Redis 장애가 DB 장애로 번지지 않게 하려면?

Related Topics

Cache-aside, 부하 테스트 설계와 연결한다.