Redis 장애 원인 분석 — 운영 중 발생하는 장애 패턴 7가지

장애 패턴 1: OOM (Out Of Memory)

MISCONF Redis is configured to save RDB snapshots,
but it is currently not able to persist on disk.

또는 단순히 maxmemory에 도달해 쓰기 거부.

# 현재 메모리 상태
redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

# 큰 키 찾기
redis-cli --bigkeys

# 메모리 사용 상위 키 분석
redis-cli memory usage <key>

원인:

• maxmemory 설정 없음 (무제한 성장)
• maxmemory-policy: noeviction + 쓰기 폭증
• 메모리 단편화 (fragmentation_ratio > 1.5)

해결:

maxmemory 4gb
maxmemory-policy allkeys-lru  # 캐시 용도

# 단편화 복구 (Redis 4.0+)
activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10

장애 패턴 2: Connection 고갈

ERR max number of clients reached

# 현재 연결 수
redis-cli info clients | grep connected_clients

# 연결 상세 (어디서 붙었는지)
redis-cli client list | awk -F' ' '{print $3}' | sort | uniq -c | sort -rn

원인:

• 애플리케이션에서 커넥션 반환 안 함 (커넥션 풀 미사용)
• maxclients 기본값(10000)이지만 실제 파일 디스크립터 한계

해결:

maxclients 20000

# OS 파일 디스크립터 한계 확인
ulimit -n
# Redis systemd 서비스에 설정
LimitNOFILE=65535

장애 패턴 3: Slow Commands (Blocked)

# Slow log 확인 (기본 10ms 이상)
redis-cli slowlog get 20
redis-cli slowlog len

# 현재 실행 중인 명령어
redis-cli monitor  # 주의: 프로덕션에서 성능 영향 있음

위험한 명령어:

• KEYS * → SCAN 으로 대체
• SMEMBERS (대용량 Set) → SSCAN으로 청크 처리
• LRANGE 0 -1 (전체) → 범위 제한

# KEYS * 대신 SCAN
redis-cli scan 0 match "user:*" count 100

장애 패턴 4: Replication Lag

Replica가 Master를 따라가지 못하는 상태.

redis-cli info replication | grep -E "master_link_status|master_repl_offset|slave_repl_offset"

# repl_backlog_size 확인
redis-cli info replication | grep repl_backlog

원인:

• 네트워크 대역폭 부족
• Replica 서버 CPU/IO 병목
• repl-backlog-size 너무 작음 (재연결 시 Full Resync 발생)

해결:

repl-backlog-size 256mb  # 기본 1mb → 늘리기
repl-diskless-sync yes   # 디스크 없이 소켓으로 직접 전송

장애 패턴 5: RDB Save 실패

Background save failed

redis-cli info persistence | grep rdb_last_bgsave_status
# rdb_last_bgsave_status:err

원인:

• 디스크 공간 부족
• fork() 실패 (메모리 부족, vm.overcommit_memory 설정)

해결:

# Linux 메모리 오버커밋 허용
echo 1 > /proc/sys/vm/overcommit_memory
# /etc/sysctl.conf에 영구 설정
vm.overcommit_memory = 1

장애 패턴 6: Sentinel Failover 미작동

Sentinel이 설치되어 있지만 Master 장애 시 자동 전환이 안 되는 경우.

# Sentinel 상태 확인
redis-cli -p 26379 sentinel masters
redis-cli -p 26379 sentinel slaves mymaster

# Quorum 확인 (최소 과반수 Sentinel 필요)
redis-cli -p 26379 sentinel ckquorum mymaster

원인:

• Sentinel 수가 짝수 (2대) → 과반수 결정 불가
• 방화벽으로 Sentinel 간 통신 막힘
• down-after-milliseconds 너무 길게 설정

장애 패턴 7: Key Expiry 폭발

특정 시각에 대량의 키가 동시에 만료되며 CPU 스파이크 발생.

# 초당 만료된 키 수
redis-cli info stats | grep expired_keys

원인: 같은 시각에 생성된 키에 동일 TTL 설정.

해결: TTL에 랜덤 지터 추가.

import random

BASE_TTL = 3600  # 1시간
jitter = random.randint(-300, 300)  # ±5분
redis.setex(key, BASE_TTL + jitter, value)

운영 모니터링 대시보드 필수 지표

지표	정상 범위	알림 기준
connected_clients	설정값 80% 이하	90% 이상
used_memory	maxmemory 70% 이하	85% 이상
keyspace_hits / (hits + misses)	85% 이상	70% 미만
instantaneous_ops_per_sec	피크 기준	비정상 급등
rdb_last_bgsave_status	ok	err
master_link_status	up	down