본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 강의에서는 Redis의 운영 관점에서 중요한 메모리 관리와 모니터링에 대해 다루었다. Redis Monitor 명령어를 통한 간단한 실시간 모니터링 방법을 알아보았으나, 운영 환경에서는 프로메테우스와 그라파나를 통합한 메트릭 수집 및 시각화 방식이 더 적합하다는 점을 확인했다. 메모리 제거 정책인 maxmemory-policy에 대해 추가적으로 정리해보았다.
Redis Maxmemory 정책의 필요성
Redis는 모든 데이터를 메모리에 저장하는 구조로 설계되어 있다. 디스크 기반 데이터베이스와 달리 RAM에 의존하기 때문에 공간이 한정적이며, 메모리 한도 초과 시 명확한 제거 전략이 없다면 시스템 불안정을 초래할 수 있다.
maxmemory 설정을 통해 Redis가 사용할 수 있는 최대 메모리를 명시적으로 지정하고, maxmemory-policy를 통해 한도 도달 시 어떤 키를 제거할지 결정하는 방식으로 메모리를 관리한다. 이러한 정책은 다음과 같은 이유로 필수적이다.
- 메모리 기반 구조: 디스크가 아닌 RAM에 저장하므로 공간 유한
- 쓰기 요청 처리 조건: 메모리 한도 초과 시 eviction 정책 없으면 쓰기 거부
- 정책 필요성: 어떤 키를 우선 제거할지 기준 없으면 서비스 불안정
Eviction 정책의 구성 요소
Redis의 제거 정책은 크게 두 가지 기준의 조합으로 동작한다.
제거 대상 범위
정책 이름의 접두사는 어떤 키 범위에서 제거 대상을 선택할지 결정한다.
- allkeys-* : 모든 키를 제거 후보로 포함 (TTL 여부 무관)
- 캐시 전체를 관리할 때 사용
- 예: allkeys-lru, allkeys-lfu
- volatile-* : TTL이 설정된 키만 제거 대상
- 임시 데이터, 만료 데이터만 선별 정리할 때 사용
- 예: volatile-lru, volatile-random
제거 알고리즘
정책 이름의 접미사는 제거 대상을 선택하는 알고리즘을 나타낸다.
- LRU (Least Recently Used) : 가장 오랫동안 사용되지 않은 키 제거
- Redis는 정확한 LRU 대신 샘플 기반 근사 사용
- 전체 키 중 가장 오래 사용되지 않은 키 제거
- LFU (Least Frequently Used) : 가장 적게 사용된 키 제거
- 내부 카운터 + decay 기반, Redis 4.0 이상
- 접근 빈도가 낮은 키를 우선 제거
- Random : 제거 대상 중 무작위 선택
- 계산 비용 낮지만 예측 불가능
- noeviction : 제거하지 않고 쓰기 실패
- 저장소처럼 사용할 때 적용 가능
- TTL : 만료 시간 우선
- volatile-ttl 정책에서만 사용 가능
사용 가능한 Eviction 정책 목록
| 정책 이름 | 제거 대상 | 제거 알고리즘 | 설명 |
| noeviction | 없음 | 없음 (쓰기 거부) | 메모리 초과 시 쓰기 명령 실패, 영속성 중요할 때 사용 |
| allkeys-lru | 모든 키 | LRU (최소 최근 사용) | 전체 키 중 가장 오래 사용되지 않은 키 제거 |
| volatile-lru | TTL 설정 키 | LRU | TTL 있는 키 중 가장 오래 사용되지 않은 키 제거 |
| allkeys-lfu | 모든 키 | LFU (최소 사용 빈도) | 전체 키 중 가장 적게 사용된 키 제거 |
| volatile-lfu | TTL 설정 키 | LFU | TTL 있는 키 중 가장 적게 사용된 키 제거 |
| allkeys-random | 모든 키 | 무작위 | 전체 키 중 임의 선택 제거 |
| volatile-random | TTL 설정 키 | 무작위 | TTL 있는 키 중 임의 선택 제거 |
| volatile-ttl | TTL 설정 키 | 만료 시간 우선 | TTL이 가장 임박한 키부터 제거 (LRU/LFU 아님) |
정책 선택 기준
Eviction 정책은 애플리케이션의 데이터 접근 패턴에 따라 적합한 선택지가 달라진다. 일반적으로 다음과 같은 기준으로 판단할 수 있다.
allkeys-lru를 선택하기 좋은 경우
파레토 법칙이 적용되는 전형적인 캐시 시나리오에 적합하다. 전체 데이터 중 일부가 훨씬 자주 접근된다면, 최근에 사용된 데이터를 유지하는 것이 효율적이다.
- 예: 웹 페이지 캐싱, API 응답 캐싱
- 최근 데이터가 곧 다시 필요할 가능성이 높은 시나리오
allkeys-lfu를 선택하기 좋은 경우
특정 데이터가 지속적으로 높은 빈도로 접근되는 패턴에서 유리하다. LRU와 달리 일시적 대량 접근에도 기존 핫 데이터를 보호할 수 있다.
- 예: 데이터베이스 쿼리 결과 캐싱, 인기 콘텐츠 저장
- 배치 작업 등 일시적 접근 패턴이 있는 경우
volatile-lru / volatile-lfu를 선택하기 좋은 경우
하나의 Redis 인스턴스에서 캐시와 영속 데이터를 함께 사용하는 경우 유용하다. TTL이 설정된 임시 데이터만 제거하고 영속 데이터는 보존한다.
- 예: 세션 저장소 + 설정 데이터
- 다만 가능하면 인스턴스를 분리하는 것이 권장됨
volatile-ttl을 선택하기 좋은 경우
애플리케이션에서 키의 중요도를 TTL로 표현할 수 있는 경우에 적합하다. 짧은 TTL을 가진 데이터를 우선 제거한다.
- 예: Rate limiting, 임시 토큰 관리
- 키 만료를 적극 활용하면 메모리 한도 도달 가능성도 낮아짐
allkeys-random을 선택하기 좋은 경우
접근 패턴이 완전히 무작위이거나 예측 불가능한 경우 사용한다. 계산 비용이 낮아 제거 속도가 빠르다.
- 예: 테스트 환경, 사이클 형태로 반복되는 접근 패턴
- 명확한 선호 없이 단순하게 동작 원할 때
noeviction을 선택하기 좋은 경우
데이터 손실이 절대 허용되지 않는 시스템에서 사용한다. 메모리 한도 도달 시 쓰기를 거부하고 오류를 반환한다.
- 예: 영속 저장소로 사용, 중요 설정 데이터
- 메모리 부족 시 알림을 받고 용량 확장이 필요
정책 적용 시 고려사항
정책 설정 후에도 운영 조건과 모니터링 방법을 함께 고려해야 한다.
- Redis 기본 정책은 noeviction이므로, 명시적으로 정책을 지정하지 않으면 메모리 한도 도달 시 쓰기가 차단된다. 프로덕션 환경에서는 반드시 적절한 정책을 설정해야 한다.
- maxmemory의 기본값은 0이며, 제한이 없는 설정이다.
- 따라서 해당 값을 바꾸지 않으면 eviction 자체가 미작동한다.
- volatile-* 정책은 TTL이 설정된 키가 없으면 noeviction처럼 동작한다. 따라서 TTL 없는 키만 있다면 쓰기가 거부될 수 있다.
참고 출처
- https://redis.io/docs/latest/develop/reference/eviction/
- https://shayne007.github.io/2025/06/18/Redis-Cache-Eviction-Policies-Complete-Guide/
