Redis 캐시 3대장: LRU·LFU·TTL, 언제 써야 진가를 발휘할까?

🔍 왜 Redis 캐시 정책이 중요한가?

트래픽이 몰릴수록 메모리는 금쪽같습니다. LRU(Least Recently Used), LFU(Least Frequently Used), TTL(Time-To-Live) 세 가지 정책을 제대로 이해하면 과금을 줄이고 응답 속도는 높이는 ‘캐싱 최적화 치트키’를 얻게 됩니다.

---

1. LRU ― 최근에 안 쓴 놈부터 아웃

• 어떻게 작동하나?
  마지막으로 조회된 시점을 기준으로 오래된 키를 제거합니다.
• 실전 포인트
  • 세션 스토어: 로그인 세션처럼 ‘최근 사용 여부’가 가치 판단의 전부일 때 적합.
  • 단점: 인기 급상승 키가 폭발적으로 생기면 단기 트래픽 폭주에 취약.
• 현장 사례
  국내 한 커머스사가 장바구니 데이터를 LRU로 캐싱하다가 ‘타임딜’ 시작과 동시에 인기 상품 정보가 밀려나 502 오류가 터진 사례가 있습니다. 이후 LFU로 전환하며 해결.

---

2. LFU ― 자주 쓰는 놈을 끝까지 품는다

• 어떻게 작동하나?
  Redis 4.0+의 allkeys-lfu / volatile-lfu 정책은 항목별 ‘접근 횟수’에 로그 스케일 가중치를 주어 빈도수 상위 키를 살아남게 합니다.
• 실전 포인트
  • 콘텐츠 추천·랭킹: ‘조회수 상위 N개’를 계속 빠르게 서빙해야 할 때 최적.
  • 단점: 새로 투입된 신작 콘텐츠가 낮은 빈도로 평가돼 ‘콜드 스타트’가 생길 수 있음.
• 현장 사례
  OTT 스타트업 A사는 “오늘 뜨는 콘텐츠” 목록을 LFU 캐시에 얹어 API 호출량을 70% 감소시켰습니다. 대신 콜드 스타트를 줄이려 신규 작품에 초기 가중치를 주는 스크립트를 배치로 돌립니다.

---

3. TTL ― 시간 다 되면 자동 소멸

• 어떻게 작동하나?
  키마다 EXPIRE 또는 SET key value EX seconds로 명시한 시간 뒤 삭제됩니다.
• 실전 포인트
  • 실시간 분석·IoT 로그: 1시간만 살아 있으면 되는 데이터라면 TTL이 메모리 누수를 막는 확실한 방법.
  • 단점: 수명이 남아 있어도 메모리가 꽉 차면 volatile-* 정책에 의해 예기치 않게 지워질 수 있음.
• 현장 사례
  국내 게임사가 TTL 10분으로 전투 로그를 넣어 DB 적재량을 하루 30억 건에서 5억 건으로 절감했습니다. “TTL 덕에 로그 비용이 반 토막 났다”는 내부 보고가 있었죠.

---

4. 성능 비교, 어떤 정책이 더 빠를까?

• 읽기 지연: LRU ≈ TTL < LFU (초기 콜드 스타트 고려)
• 메모리 효율: LFU < TTL < LRU (인기 편중이 큰 서비스일수록 LFU 우위)
• 설정 난이도: TTL < LRU < LFU

⚡ 실무 팁

1. 혼합 전략이 정답일 때가 많다 — 예: 세션은 LRU, 인기 랭킹은 LFU, 로그는 TTL.
2. 프로덕션 투입 전 redis-bench 같은 도구로 서비스 패턴을 흉내 내 벤치마크하라.
3. 메모리 한계 근처라면 redis-cli INFO memory로 RSS 변동폭을 모니터링하고 maxmemory-policy를 주기적으로 재검토하라.

---

5. 선택 가이드 한눈에 🧭

• 사용 패턴이 예측 가능 + 최근성 중시 → LRU
• 핫·콜드 트래픽 편차가 심함 → LFU
• 데이터 자체에 유효기간이 명확 → TTL