Redis 메모리 압박 장애 대응 플레이북 - eviction 전에 봐야 할 신호와 복구 순서

Redis 메모리 장애는 조용히 시작된다

Redis 장애는 보통 디스크처럼 갑자기 꽉 찬다는 느낌보다,
성능 저하와 지연 증가가 먼저 오고 그 뒤에 장애로 이어집니다.

대표 신호는 아래와 같습니다.

응답 시간 증가
hit ratio 급락
eviction 증가
특정 키 패턴 급증
앱 쪽 timeout 증가

운영팀이 흔히 하는 실수는 “메모리만 더 올리자”로 바로 가는 것입니다.
메모리 증설이 임시 완화는 될 수 있지만 원인 분석 없이 끝내면 같은 문제가 반복됩니다.

가장 먼저 확인할 지표 5개

1. used_memory 와 maxmemory 관계

현재 얼마나 찼는지 보는 기본 지표입니다.

하지만 이것만 보면 부족합니다.
used_memory_peak, mem_fragmentation_ratio까지 같이 봐야 합니다.

2. eviction 발생 여부

eviction이 이미 일어나고 있다면 캐시 정책이 서비스 응답에 영향을 주기 시작한 상태입니다.

이때는 아래를 함께 봐야 합니다.

어떤 키 공간이 밀려나는가
비즈니스적으로 다시 로드 비용이 큰가
eviction 증가와 앱 latency가 함께 움직이는가

3. hit ratio 변화

메모리 부족은 단순 용량 문제가 아니라 캐시 효율 문제로 이어집니다.

hit ratio가 떨어지면:

DB 부하 증가
upstream API 호출 증가
전체 응답 시간 증가

즉, Redis 문제는 Redis 안에서 끝나지 않습니다.

4. 큰 키와 키 분포

메모리 압박 원인은 종종 “키가 너무 많다”보다 “몇 개 키가 너무 크다”인 경우가 있습니다.

확인 포인트:

hash, zset, list 크기
예상보다 큰 세션 데이터
만료되지 않는 집계 결과
잘못된 직렬화 구조

5. TTL 없는 키 비율

캐시 계층인데 TTL 없는 키가 많다면 사실상 영구 저장소처럼 쓰고 있을 가능성이 큽니다.

이 경우 메모리 증가는 구조적 문제입니다.

eviction 정책은 만능이 아니다

Redis 메모리 압박이 오면 eviction policy를 바꾸자는 의견이 자주 나옵니다.

하지만 정책 변경은 구조를 고치는 것이 아니라 버티는 방식일 뿐입니다.

예를 들어:

allkeys-lru: 전반적으로 캐시 용도에 적합
volatile-lru: TTL 있는 키만 제거
noeviction: 쓰기 실패를 명시적으로 드러냄

문제는 정책 선택이 데이터 성격과 맞지 않으면 더 큰 혼란을 만든다는 점입니다.

예:

세션 데이터와 일반 캐시가 섞여 있음
중요한 키와 재생성 쉬운 키가 같은 DB에 있음
TTL 정책이 제각각임

이 상태에서 eviction 정책만 바꾸면 장애의 모양만 바뀔 뿐입니다.

복구 단계는 짧고 분명해야 한다

장애 중에는 근본 원인 해결보다 서비스 안정화가 우선입니다.

추천 순서는 아래와 같습니다.

1. 급격히 증가한 키 공간 파악

최근 배포 여부
특정 기능 릴리스 여부
비정상 트래픽 여부

2. 재생성 가능한 큰 키부터 정리

무턱대고 flush를 하면 더 큰 사고가 납니다.
비즈니스 영향이 낮고 다시 만들 수 있는 키를 선별해야 합니다.

3. 애플리케이션 fallback 경로 확인

Redis miss가 늘어날 때 DB나 원본 시스템이 버틸 수 있는지 함께 봐야 합니다.

4. 필요 시 일시 증설

임시 증설은 가능하지만, 이 단계에서 원인 가설을 동시에 잡아야 합니다.

재발 방지 체크리스트

복구 후에는 아래를 꼭 정리해야 합니다.

TTL 없는 캐시 키 제거
큰 키 탐지 자동화
키 네이밍 규칙과 소유팀 명시
캐시와 세션/영속성 데이터 분리
메모리 임계치 알림 조기화
기능 릴리스 전 캐시 부하 검토

Redis는 빠르지만, 구조가 흐려지면 금방 “빠른 임시 저장소”에서 “불안정한 단일 장애점”으로 바뀝니다.

마무리

Redis 메모리 압박 장애는 단순 용량 이슈처럼 보이지만, 실제로는 캐시 정책, 키 설계, 서비스 fallback 구조가 한꺼번에 드러나는 사건입니다.

핵심은 아래 세 가지입니다.

used memory만 보지 말고 eviction, hit ratio, 큰 키 분포를 함께 볼 것
eviction 정책 변경만으로 문제를 해결하려 하지 말 것
복구와 재발 방지를 분리해 각각 짧고 명확한 절차로 가져갈 것

Redis 장애 대응이 잘 되는 팀은 캐시를 단순 성능 도구가 아니라
운영 설계의 일부로 다룹니다.
그래서 장애가 나도 당황하지 않고, 어떤 키를 살리고 어떤 구조를 고쳐야 하는지 빠르게 결정할 수 있습니다.