Redis Eviction Policy 가이드
Dev
마지막 업데이트

Redis Eviction Policy 가이드

Redis key가 랜덤하게 사라지는 것처럼 보일 때 원인은 생각보다 자주 corruption이 아니라 eviction입니다. 다만 애플리케이션 입장에서는 eviction, expiration, overwrite, delete, write failure가 비슷하게 보이기 때문에 원인을 잘못 짚기 쉽습니다.

핵심은 간단합니다. 먼저 Redis가 실제로 maxmemory 압박 아래 있는지 확인하고, 어떤 eviction policy가 켜져 있는지 확인한 다음, 사라진 key가 eviction인지 expiration인지 애플리케이션 동작인지를 구분해야 합니다.

Redis에서 eviction이 뜻하는 것

Redis는 메모리 압박과 maxmemory 설정이 함께 있을 때만 eviction을 수행합니다.

즉 압박 상황에서 key가 사라진다면 이상 현상이라기보다 설정된 동작일 수 있습니다. 먼저 아래를 확인하세요.

  • maxmemory가 설정되어 있는가
  • maxmemory-policy가 무엇인가
  • 지금 실제로 memory pressure가 있는가

마지막 질문의 답이 아니라면, 사라진 key는 expiration, overwrite, delete, 애플리케이션 로직으로 설명될 가능성이 더 큽니다.

정책에 따라 key가 사라지는 방식이 다른 이유

Redis는 아래 같은 policy를 제공합니다.

  • noeviction
  • allkeys-lru
  • allkeys-lfu
  • allkeys-random
  • volatile-lru
  • volatile-lfu
  • volatile-random
  • volatile-ttl

핵심 차이는 Redis가 모든 key에서 evict할 수 있는지, TTL이 있는 key만 대상으로 삼는지입니다.

팀은 “cache key만 사라져야 한다”고 기대했는데 policy가 allkeys-*라면 Redis는 정상 동작 중이어도 incident는 이상하게 느껴질 수 있습니다.

eviction, expiration, overwrite는 서로 다릅니다

현장에서는 셋을 한 덩어리로 보는 경우가 많지만, 실제 점검 경로는 다릅니다.

  • eviction: memory pressure와 policy 때문에 Redis가 key를 제거
  • expiration: TTL이 0이 되어 key가 사라짐
  • overwrite 또는 delete: 애플리케이션이 값을 바꾸거나 지움

key가 만료되어야 하는데 안 된다면 Redis Keys Not Expiring가 더 직접적인 다음 글입니다.

반대로 key가 사라지는 것이 아니라 write가 실패한다면 Redis OOM Command Not Allowed가 더 맞는 분기입니다.

실제 문제는 TTL 누락일 수도 있습니다

eviction 문제와 TTL 문제는 자주 같이 나타납니다.

대표적인 패턴은 이렇습니다.

  1. 앱은 cache key가 만료될 것이라고 기대한다
  2. 일부 key가 overwrite 과정에서 TTL을 잃는다
  3. memory가 오른다
  4. eviction이 시작되면서 예상과 다른 key가 사라진다

이 경우 policy는 이야기의 끝부분이고, 더 이른 원인은 TTL 동작입니다.

흔한 policy 오해

1. volatile-*가 모든 key에 적용된다고 생각하는 경우

아닙니다. TTL이 있는 key만 후보가 됩니다.

2. noeviction이면 아무 문제도 없다고 생각하는 경우

아닙니다. eviction을 안 하는 대신 추가 memory가 필요한 write가 실패할 수 있습니다.

3. 사라진 key는 무조건 eviction 때문이라고 생각하는 경우

애플리케이션 overwrite, delete, expiration 때문일 수도 있습니다.

4. workload shape가 결과를 바꾼다는 점을 놓치는 경우

같은 policy라도 burst write, 큰 value, 엉성한 TTL 운영 아래에서는 체감이 크게 달라집니다.

실전 점검 순서

  1. 현재 memory 사용량을 확인한다
  2. maxmemory를 확인한다
  3. maxmemory-policy를 확인한다
  4. 사라진 key에 TTL이 있었는지 확인한다
  5. write failure가 같이 있었는지 본다
  6. 현재 policy가 데이터 중요도 모델과 맞는지 판단한다

incident 중에는 policy를 곧바로 바꾸기보다 이 순서가 훨씬 안전합니다.

바로 확인할 명령

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
redis-cli INFO memory
redis-cli INFO stats

이 명령으로 Redis가 eviction 가능한 상태인지, memory pressure가 실제인지, incident 동안 evicted_keys 카운터가 오르는지 확인할 수 있습니다.

빠르게 분기하는 법

key가 사라질 때 아래처럼 먼저 갈라보면 좋습니다.

  • memory pressure가 높고 evicted_keys가 오른다: eviction 먼저 의심
  • TTL이 정상적으로 줄어든다: expiration 먼저 의심
  • memory pressure가 낮고 TTL도 없다: overwrite나 delete 먼저 의심
  • write가 OOM으로 실패한다: noeviction 또는 메모리 고갈 먼저 의심

이 분기만으로도 첫 30분 동안 엉뚱한 subsystem을 탓하는 일을 많이 줄일 수 있습니다.

증상별 진입 힌트

  • memory pressure 아래서 key가 예상보다 빨리 사라지면 여기서 시작하면 됩니다.
  • key가 아예 만료되지 않는 쪽이 더 의심되면 TTL 가이드가 더 직접적입니다.
  • key가 사라지는 것이 아니라 OOM write failure가 보이면 OOM 가이드가 더 맞습니다.

FAQ

Q. 왜 일부 key만 사라지나요?

활성 policy가 TTL이 있는 key만 대상으로 삼거나, LRU/LFU 같은 접근 패턴 기준을 사용하기 때문입니다.

Q. noeviction이면 write도 안전한가요?

아닙니다. eviction은 막지만 추가 memory가 필요한 write는 실패할 수 있습니다.

Q. 가장 먼저 무엇을 봐야 하나요?

maxmemory, maxmemory-policy, 그리고 사라진 key에 TTL이 있었는지입니다.

Q. policy가 핵심이 아닐 때는 언제인가요?

memory pressure가 약하거나 없고, 실제 원인이 expiration이나 overwrite인 경우입니다.

Sources:

계속 읽어볼 글

심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.

계속 읽어볼 글

심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.

관련 글

이 카테고리의 다른 글