llm-wiki/raw/official-docs/redis-key-eviction-maxmemory-policy.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title	source_type	url	archive_url	related_branches	related_projects	tags	created
official-doc / Redis — Key Eviction & maxmemory-policy	official-doc	https://redis.io/docs/latest/develop/reference/eviction/		feature-redis-runtime-role-isolation-contract	ca-skeleton	official-doc ca-skeleton caching redis	2026-07-28

official-doc / Redis — Key Eviction & maxmemory-policy

Layer: raw/ — 외부 자료(공식 문서 / 대기업 기술 블로그)의 원문 발췌·출처 기록. 본 템플릿은 raw/official-docs/ 와 raw/company-tech-blogs/ 두 폴더가 공유. 검증된 요약은 /ingest 후 wiki/concepts/에 source-summary-template 형식으로 별도 작성. 원본은 raw에 영구 보관.

source_type 허용값

source_type: official-doc — Redis 공식 레퍼런스 문서 (redis.io/docs, vendor-neutral 공식 사양은 아니지만 Redis 프로젝트가 직접 운영하는 1차 문서).

Parent / 활용 branch

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-redis-runtime-role-isolation-contract	Redis role 을 cache(evictable) / coordination(noeviction) / session(noeviction) 으로 분리하고, maxmemory-policy 는 deployment(instance) 단위 설정이므로 애플리케이션이 아니라 배포 설정이 소유한다는 결정의 근거

출처

• 원본 URL: https://redis.io/docs/latest/develop/reference/eviction/
• 아카이브 URL: (미등록)
• 저자 / 조직: Redis (공식 문서, redis.io/docs)
• 발행일: (문서에 명시 없음 — 페이지 내 "Redis 8.6" 기준 최신 갱신 확인)
• 마지막 확인일: 2026-07-28

왜 저장했는지

maxmemory-policy 가 Redis 서버(인스턴스) 단위의 설정 directive라는 것과, eviction policy 종류별 의미(특히 noeviction이 write 명령을 에러로 거부한다는 것)를 원문으로 확인해, 3-role(cache/coordination/session) 분리와 policy 소유권을 배포 설정으로 두는 결정의 근거로 삼는다.

핵심 인용

[§Eviction policies] "Use the maxmemory-policy configuration directive to select the eviction policy you want to use when the limit set by maxmemory is reached." (source lines 80–81)

[§Eviction policies] "noeviction: Keys are not evicted but the server will return an error when you try to execute commands that cache new data. If your database uses replication then this condition only applies to the primary database. Note that commands that only read existing data still work as normal." (source lines 85–88)

[§Eviction policies] "volatile-lru: Evict the least recently used keys that have an associated expiration (TTL)." (source line 93)

[§LFU eviction] "LFU is approximated like LRU: it uses a probabilistic counter, called a Morris counter to estimate the object access frequency using just a few bits per object, combined with a decay period so that the counter is reduced over time." (source line 243)

[§Eviction policies] "Note also that if you make good use of key expiration, then you are less likely to run into the cache memory limit because keys will often expire before they need to be evicted." (source lines 120–122)

Claims Extracted

이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.

Claim ID	Claim	Evidence quote	Strength	Applies to	Does not prove
REDIS-EVICT-C1	maxmemory-policy 는 maxmemory 한도 도달 시 적용할 eviction policy 를 선택하는 configuration directive다 — redis.conf 또는 CONFIG SET 으로 설정하는 서버(인스턴스) 단위 값이며, 애플리케이션 코드 API 가 아니다	[§Eviction policies] "Use the maxmemory-policy configuration directive to select the eviction policy you want to use when the limit set by maxmemory is reached."	official-vendor-doc	임의 Redis 인스턴스(단일 노드/replica 포함)에서의 eviction policy 설정 경로	한 인스턴스 안에서 key 별/role 별로 다른 eviction policy 를 동시 적용할 수 있는지 여부 — 문서가 명시하지 않음 (다만 "하나의 directive" 라는 서술 자체가 인스턴스당 정책이 1개임을 시사)
REDIS-EVICT-C2	noeviction policy 에서는 key 가 evict 되지 않고, 대신 maxmemory 초과 시 새 데이터를 캐시하는 명령이 에러를 반환한다. read-only 명령은 정상 동작한다. replication 환경에서는 이 조건이 primary 에만 적용된다	[§Eviction policies] "noeviction: Keys are not evicted but the server will return an error when you try to execute commands that cache new data. ... Note that commands that only read existing data still work as normal."	official-vendor-doc	maxmemory-policy=noeviction 이고 maxmemory 한도에 도달한 모든 Redis 배포	어떤 명령이 정확히 "새 데이터를 캐시하는 명령"에 해당하는지 명령어 단위 목록은 제공하지 않음. maxmemory=0(무제한)일 때는 이 조건 자체가 발동하지 않음(이 문서의 다른 절에서 별도 서술)
REDIS-EVICT-C3	volatile-lru 는 TTL(만료 시각)이 설정된 key 들 중에서만 least-recently-used 기준으로 evict 한다 — volatile-* 계열 policy 는 TTL 이 있는 key 만 eviction 대상으로 삼는다	[§Eviction policies] "volatile-lru: Evict the least recently used keys that have an associated expiration (TTL)."	official-vendor-doc	TTL 을 명시적으로 설정한 key 들이 존재하는 상황에서 volatile-* 계열 policy 를 쓸 때의 동작	이 branch 의 session/coordination role 이 실제로 TTL 을 세팅하는지는 이 문서로 증명되지 않음(프로젝트 구현 사실)
REDIS-EVICT-C4	Redis 의 LFU eviction(및 이와 비교되는 LRU)은 근사(approximated) 알고리즘이다 — probabilistic counter(Morris counter)로 접근 빈도를 추정하고 decay 를 적용하는 방식이며, 정확한 전역 순서 계산이 아니다	[§LFU eviction] "LFU is approximated like LRU: it uses a probabilistic counter, called a Morris counter to estimate the object access frequency using just a few bits per object, combined with a decay period so that the counter is reduced over time."	official-vendor-doc	allkeys-lfu/volatile-lfu(및 대응 LRU policy) 를 사용하는 모든 Redis 배포의 eviction 정확도 특성	특정 워크로드에서 hit/miss ratio 에 미치는 정량적 영향은 제공하지 않음. ca-skeleton cache role 의 실측 hit ratio 는 이 문서로 증명되지 않음
REDIS-EVICT-C5	key expiration(TTL 기반 자동 삭제)을 잘 활용하면 key 가 evict 되기 전에 먼저 만료되므로 memory 한도 초과 상황 자체가 줄어든다 — 즉 "만료(expire)"와 "축출(evict)"은 서로 다른, 별개의 삭제 경로다	[§Eviction policies] "Note also that if you make good use of key expiration, then you are less likely to run into the cache memory limit because keys will often expire before they need to be evicted."	official-vendor-doc	TTL 기반 삭제(expiration)와 memory-pressure 기반 삭제(eviction)를 구분해야 하는 모든 Redis 사용 맥락	noeviction 처럼 애초에 evict 를 하지 않는 policy 에서 TTL 이 필수인지는 이 문장만으로 증명되지 않음(별도로 C2 가 noeviction 자체의 동작을 규정)

Strength 허용값

• official-standard — RFC, 표준 사양, 언어/프로토콜 표준
• official-vendor-doc — Spring, Keycloak, AWS, Google, Redis 등 공식 벤더 문서
• official-reference — 공식 reference/API 문서
• company-case-study — 대기업/실무 기술 블로그의 특정 사례
• engineering-blog — 개인/팀 블로그의 엔지니어링 해설
• tutorial — 튜토리얼/가이드. 일반화 금지
• needs-confirmation — 원문만으로는 적용 판단 불가

Usage Boundaries

• 이 자료가 직접 증명하는 것:
  • REDIS-EVICT-C1: maxmemory-policy 는 Redis 인스턴스(서버) 단위 설정이다 — redis.conf 또는 CONFIG SET 으로 지정되는 configuration directive 이며 애플리케이션 코드 API 가 아니다. 하나의 directive 라는 서술은 한 인스턴스에 정책이 1개만 존재함을 시사한다.
  • REDIS-EVICT-C2: noeviction 은 write 를 에러로 거부하고 read 는 계속 허용하는 "fail loud" 동작이다 — 데이터 유실보다 명시적 실패를 선호하는 role(coordination/session)에 적합한 근거가 된다.
  • REDIS-EVICT-C3 / REDIS-EVICT-C5: eviction(memory-pressure 기반)과 expiration(TTL 기반)은 서로 다른 삭제 메커니즘이며, volatile-* policy 는 TTL 있는 key 만 대상으로 삼는다.
  • REDIS-EVICT-C4: LRU/LFU eviction 은 근사 알고리즘이라 완벽한 전역 순서를 보장하지 않는다 — cache role 설계 시 "정확한 LRU"를 전제하면 안 된다는 근거.
• 이 자료가 증명하지 않는 것:
  • Redis 의 기본(default) maxmemory-policy 값이 무엇인지 이 페이지는 명시하지 않는다(다른 절이 maxmemory 기본값 0 만 언급).
  • "cache = evictable, coordination/session = noeviction" 이라는 3-role 매핑 자체는 이 문서의 용어가 아니다 — Redis 문서는 "cache" 사용 사례를 일반적으로 언급할 뿐, ca-skeleton 의 role 분류 체계(cache/coordination/session)를 알지 못한다. 이 매핑은 branch 의 결정이며, 본 자료는 그 결정을 뒷받침하는 일반 eviction 시맨틱만 제공한다.
  • 한 Redis 인스턴스 안에서 key/role 별로 다른 maxmemory-policy 를 동시 적용할 수 없다는 것을 명시적으로 금지한다고 말하지는 않는다 — maxmemory-policy 가 단일 directive 라는 서술에서 유추할 뿐이며, 이는 오히려 "다른 정책이 필요한 role 은 별도 Redis 배포로 분리해야 한다"는 branch 결정과 정합적이다.
  • maxmemory/persistence(RDB·AOF) 소유 경계에 대한 심층 규정은 없다 — replication/persistence buffer 가 maxmemory 계산에서 제외된다는 부수적 언급만 있고, 이 문서는 eviction 에 집중한다.
  • ca-skeleton 의 실제 Redis 배포(단일 인스턴스 vs 복수 인스턴스, docker-compose/Helm 설정 파일 소유권)가 어떻게 구성되어야 하는지는 이 문서로 확인되지 않는다 — /branch-spec 단계에서 구현 결정으로 별도 확정 필요.

메모

• 원문에 명시된 evict/expire 구분과 "maxmemory-policy = 인스턴스 단위 directive" 서술은, coordination/session role 이 cache role 과 같은 Redis 인스턴스에 co-locate 될 수 없다는 branch 결정(incompatible co-location 거부)의 방향성과 일치한다 — 단, 이 연결 자체는 branch 의 해석이며 본 문서가 직접 말하는 것은 아니다.
• allkeys-lru / allkeys-lfu / allkeys-random / volatile-ttl 등 나머지 policy 종류의 정확한 정의도 같은 페이지 §Eviction policies 목록에 있음 — 필요 시 추가 인용 가능(현재는 5개로 제한).
• Redis 8.6 부터 추가된 LRM(Least Recently Modified) policy 도 같은 페이지에 있으나, 이 branch 결정과 직접 관련 없어 인용에서 제외.

관련

• 같은 주제 다른 official-doc: (아직 없음 — Spring Data Redis / Lettuce 커넥션 설정 관련 공식 문서는 /branch-spec 단계에서 추가 수집 예정)
• 이 자료를 인용한 wiki 요약: [[wiki/concepts/...]] (생성 시)