캐시 항목의 생존 시간(Time To Live). 지정한 시간이 지나면 자동으로 사라진다.
왜 필요한가 — 무효화의 안전망
앞서 봤듯 완벽한 캐시 무효화는 어렵다. 지워야 할 키를 놓칠 수 있다. TTL은 "최악의 경우에도 이 시간이 지나면 최신이 된다" 는 상한을 보장한다.
무효화가 실패해도 데이터가 영원히 틀리지는 않는다는 것 — 이게 TTL의 진짜 값어치다.
얼마로 잡나
세 가지를 본다.
| 기준 | 질문 |
|---|---|
| 허용 가능한 낡음 | 이 값이 5분 낡아도 되나? 상품 가격은 초 단위, 공지는 분 단위 |
| 재계산 비용 | 만드는 데 비싸면 TTL을 늘려 이득을 키운다 |
| 변경 빈도 | 자주 바뀌면 짧게. 안 바뀌면 길게 |
Redis에서
- SET key value EX 300 — # 300초 후 만료
- TTL key — # 남은 시간(초). -1은 만료 없음, -2는 키 없음
- PERSIST key — # 만료 제거
주의 — SET key value 로 값을 다시 쓰면 TTL이 사라진다(만료 없음이 된다).
갱신할 때마다 EX를 다시 지정해야 한다. 이걸 놓쳐 메모리가 계속 차는 사고가 흔하다.
Redis는 어떻게 만료를 처리하나 — 자주 묻는다
만료 시각이 됐다고 즉시 지우지 않는다. 그러면 CPU를 너무 쓴다.
- Lazy expiration — 그 키에 접근할 때 만료됐으면 그때 지운다
- Active expiration — 100ms마다 만료 키 후보를 무작위 표본으로 뽑아 지운다
그래서 만료됐지만 아직 메모리에 남아 있는 키가 존재할 수 있다.
used_memory가 예상보다 큰 이유가 이것일 때가 있다.
지터를 왜 섞나
같은 시각에 채워진 키들은 TTL도 같아 동시에 만료된다.
ttl = base + random(0, base * 0.2) 20% 정도 흔들어 주면 캐시 스탬피드를 값싸게 예방할 수 있다.
TTL과 eviction의 차이
| TTL 만료 | eviction(축출) | |
|---|---|---|
| 원인 | 시간 | 메모리 부족 |
| 대상 | 만료된 키 | 정책이 고른 키(LRU 등) |
메모리가 부족하면 TTL이 남아 있어도 축출될 수 있다.