Redis 성능/특성 정리: eviction/persistence/big key가 latency spike를 만드는 이유

Redis 성능/특성 정리: eviction/persistence/big key가 latency spike를 만드는 이유

이 글은 Redis를 성능/운영 관점에서 길게 정리한 개인 노트입니다. 목표는 "지금 느린 이유"를 증거로 좁히고, 재발을 줄이는 체크리스트를 갖추는 것입니다.

전제: 성능은 DB만으로 결정되지 않습니다. 쿼리 패턴, 데이터 분포, 인덱스/스키마, 애플리케이션 트랜잭션 경계, 인프라(IO/네트워크)가 함께 결정합니다. 그래서 이 글은 '성능 모델(어디서 시간이 쓰이나) -> 설계/쿼리 -> 설정 -> 운영' 순서로 정리합니다.

Redis는 '메모리 + 이벤트 루프' 모델 덕분에 빠르지만, big key/eviction/persistence가 겹치면 지연이 급격히 튈 수 있습니다. 운영은 메모리 모델 이해가 1순위입니다.

이 DB를 언제 선택하나

정답은 항상 케이스 바이 케이스지만, 선택을 빠르게 만들기 위해 기준을 먼저 둡니다. 아래에 해당이 많을수록 이 DB를 고려할 만합니다.

- 캐시/세션/레이트리밋처럼 밀리초 단위 지연이 중요한 컴포넌트
- 간단한 자료구조 기반의 큐/카운터/집계가 필요할 때
- DB 부하를 줄이기 위한 read-heavy 최전선 캐시

성능 모델: 어디서 시간이 쓰이나

Redis는 메모리에 데이터를 두고 명령을 이벤트 루프로 처리합니다. 정상 상태에서는 매우 빠르지만, 특정 명령(큰 정렬/대용량 값 조작), 백그라운드 작업(RDB/AOF rewrite), eviction이 겹치면 지연이 튑니다.

즉 성능은 명령당 작업량과 메모리 압박으로 설명됩니다. Redis에서 가장 흔한 사고는 big key와, eviction 정책을 모르고 메모리를 꽉 채우는 것입니다.

핵심 용어 빠른 사전

성능/장애 분석에서 자주 쓰는 단어는 팀마다 다르게 이해되기 쉽습니다. 용어를 짧게 정의하고, 어떤 지표/증상과 연결되는지 같이 적어둡니다.

용어	설명	실무에서 연결되는 것
big key	값/컬렉션 크기가 큰 키	단일 명령이 비싸져 latency spike 유발
eviction	메모리 부족 시 키를 퇴출	미스 폭증/캐시 붕괴, 지연 증가
AOF rewrite	AOF를 재작성해 파일을 압축	백그라운드 IO/CPU로 지연 스파이크 가능
RDB snapshot	스냅샷 저장	저장 시점에 IO/CPU 영향 가능
pipelining	여러 명령을 묶어 왕복을 줄임	네트워크 왕복이 큰 환경에서 throughput 개선
TTL	키 만료 시간	만료/정리 주기 작업과 메모리 사용에 영향

옵션/핵심 요소(3~6)

자주 부딪히는 핵심 요소를 표로 먼저 고정해 두면, 장애/튜닝 때 팀 커뮤니케이션이 빨라집니다.

항목	의미	언제 쓰는지(실무 상황)
maxmemory	메모리 상한	OOM/eviction을 예측 가능하게 만들 때
maxmemory-policy	eviction 정책	캐시 패턴에 맞는 퇴출 규칙을 정할 때
LATENCY DOCTOR	지연 원인 힌트	지연 스파이크 원인을 빠르게 좁힐 때
SLOWLOG	느린 명령 로그	big key/비싼 명령을 찾을 때
AOF/RDB	영속화 방식	내구성 요구와 지연을 균형 잡을 때

실무 튜닝 포인트(설정/옵션별)

설정에는 정답이 없습니다. 워크로드(읽기/쓰기/동시성/데이터 크기) 기준으로 관측하고 조정합니다. 아래는 실무에서 가장 자주 만지는 레버를 '항목별'로 정리한 것입니다.

maxmemory
의미: 메모리 상한
언제 만지나: 메모리 사용을 통제하고 eviction을 계획적으로 쓰고 싶을 때
주의/트레이드오프: 너무 낮으면 미스 폭증, 너무 높으면 OOM/스왑 위험

maxmemory-policy
의미: eviction 정책
언제 만지나: LRU/LFU 등 캐시 패턴에 맞출 때
주의/트레이드오프: 잘못 고르면 핫 키가 계속 날아가 캐시 미스 폭증

activedefrag
의미: 활성 메모리 조각 모음
언제 만지나: 단편화가 커져 RSS가 비정상적으로 클 때
주의/트레이드오프: CPU 오버헤드가 있어 관측 기반으로 켜야 함

appendonly
의미: AOF 사용
언제 만지나: 재시작 후 데이터 복구가 필요할 때
주의/트레이드오프: rewrite 시 지연 스파이크 가능

appendfsync
의미: AOF fsync 정책
언제 만지나: 내구성과 지연을 조정할 때
주의/트레이드오프: always는 느릴 수 있고 everysec는 유실 가능성

save
의미: RDB 스냅샷
언제 만지나: 간단한 백업/복구가 필요할 때
주의/트레이드오프: 스냅샷 생성이 IO/CPU를 유발할 수 있음

lazyfree-lazy-eviction
의미: eviction 비동기 처리
언제 만지나: 큰 키 eviction 지연 스파이크를 줄일 때
주의/트레이드오프: 메모리 회수 타이밍이 달라져 관측 필요

timeout
의미: 클라이언트 유휴 타임아웃
언제 만지나: 유휴 커넥션이 과도할 때
주의/트레이드오프: 풀링과 충돌하면 재연결 폭증

쿼리/스키마 설계에서 성능이 갈리는 지점

Redis에서는 스키마 대신 키 설계가 성능입니다. 키 네이밍, TTL, 값 크기, 자료구조 선택(list/set/zset/hash)이 모두 지연과 메모리를 결정합니다.

특히 big key는 단일 명령을 비싸게 만들고 이벤트 루프 지연으로 연결됩니다. 운영에서는 big key를 발견하면 쪼개거나 자료구조를 바꾸는 게 기본 대응입니다.

# 지연/병목 확인
redis-cli LATENCY DOCTOR
redis-cli SLOWLOG GET 20

# big key 찾기(운영 부하 주의, 샘플링 권장)
redis-cli --bigkeys

진단 명령/쿼리 모음(바로 실행용)

장애 때는 문서 찾을 시간이 없습니다. 아래는 현장에서 자주 쓰는 '첫 5분' 진단 명령/쿼리만 모은 것입니다. 환경/권한에 따라 일부는 제한될 수 있습니다.

redis-cli INFO
redis-cli LATENCY DOCTOR
redis-cli SLOWLOG GET 20
redis-cli MEMORY STATS
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

자주 하는 실수(운영/튜닝)

실수 체크리스트:
- maxmemory/maxmemory-policy 없이 메모리를 끝까지 채운다
- big key를 방치해 단일 명령 지연이 전체 지연으로 전파된다
- SLOWLOG/LATENCY 모니터링 없이 체감으로만 운영한다
- AOF/RDB 정책을 내구성 요구 없이 관성으로 설정한다
- TTL 설계를 하지 않아 만료 폭주/eviction 폭주를 만든다
- 캐시 미스가 늘어났는데도 DB를 보호할 백프레셔/레이트리밋이 없다

운영/모니터링 체크리스트

운영에서는 used_memory/RSS, eviction 횟수, hits/misses, slowlog, latency(p99)를 중심으로 봅니다. eviction이 늘면 캐시가 캐시 역할을 못 한다는 신호일 수 있어 TTL/키 설계부터 점검합니다.

공통 체크리스트:
- 느린 쿼리 top N을 지속 수집(시간/호출수/총시간)
- 지연(p95/p99)과 오류율을 애플리케이션 지표와 함께 본다
- 캐시/메모리/디스크 IO 중 무엇이 병목인지 먼저 분리한다
- 복제/HA를 쓰면 일관성 요구가 높은 기능을 분리한다
- 튜닝/변경 후에는 동일 조건으로 재측정해 회귀를 막는다

트러블슈팅 루틴(순서 고정)

장애 때는 선택지가 너무 많아서 흔히 길을 잃습니다. 아래 순서를 팀 표준으로 정해두면, 원인 추적이 빨라지고 '감으로 설정만 만지는' 일을 줄일 수 있습니다.

1) latency(p99) 스파이크가 있는지 확인
2) SLOWLOG로 비싼 명령을 찾는다
3) used_memory/RSS/fragmentation을 확인한다
4) eviction 정책과 TTL 설계를 점검한다
5) big key를 쪼개거나 자료구조를 바꾼다
6) AOF/RDB rewrite 타이밍과 지연 상관을 확인한다

문제 상황(정확히 1개)

상황 -> Redis가 평소에는 빠른데, 하루에 몇 번씩 1~2초 지연 스파이크가 생긴다.
원인 -> AOF rewrite 또는 RDB 스냅샷, 혹은 big key eviction이 이벤트 루프 지연을 만들었다.
해결 -> SLOWLOG/LATENCY DOCTOR로 원인을 특정하고 big key를 분할하며, 영속화 정책(AOF/RDB)을 조정한다.
예방 팁 -> 키 크기/TTL/eviction을 설계 단계에서 정하고, 지연/eviction/slowlog를 상시 지표로 둔다.

참고/출처

정확한 동작/버전별 차이는 공식 문서를 기준으로 확인합니다. 실무에서는 버전 차이가 곧 성능/장애 차이입니다.

• Redis Documentation
• Redis: Memory Optimization