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

---
title: official-doc / Redis — Key Eviction & maxmemory-policy
source_type: official-doc
url: https://redis.io/docs/latest/develop/reference/eviction/
archive_url:
related_branches: [feature-redis-runtime-role-isolation-contract]
related_projects: [ca-skeleton]
tags: [official-doc, ca-skeleton, caching, redis]
created: 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/...]]` (생성 시)