💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며

Redis는 인메모리 데이터 스토어로서 캐시, 세션 스토어, 메시지 브로커 등 다양한 용도로 사용된다. 단일 인스턴스로 시작하는 것은 쉽지만, 프로덕션 환경에서 고가용성(HA)과 수평 확장을 달성하려면 Sentinel 또는 Cluster 모드를 반드시 이해해야 한다. 메모리 기반 시스템인 만큼 메모리 관리, 축출 정책, 영속화 전략, 그리고 장애 시 복구 절차까지 운영 전반을 꿰뚫는 지식이 필요하다.

이 글에서는 Redis의 세 가지 배포 모드(Standalone, Sentinel, Cluster)를 비교하는 것부터 시작하여, Sentinel의 쿼럼 메커니즘, Cluster의 해시 슬롯 분산, 복제 프로토콜(PSYNC), 메모리 최적화 전략, 영속화(RDB/AOF), 슬로우 로그 분석, 그리고 대표적인 장애 시나리오(Split-brain, OOM)와 복구 절차까지 실전 예제와 함께 다룬다.

Redis 배포 모드 비교: Standalone vs Sentinel vs Cluster

배포 모드 비교표

| ----------------- | --------------------- | -------------------------------------- | ----------------------------- |

| 쓰기 확장 | 불가 | 불가 | 가능 (멀티 마스터) |

선택 기준 정리

의사결정 흐름

1. 데이터가 단일 노드 메모리에 들어가는가?

- YES → Sentinel (HA 필요 시) 또는 Standalone

- NO → Cluster 필수

2. 쓰기 성능 확장이 필요한가?

- YES → Cluster (멀티 마스터)

- NO → Sentinel로 충분

3. 운영 복잡도를 감당할 수 있는가?

- 소규모 팀 → Sentinel 우선 고려

- 전담 인프라팀 → Cluster 도입 가능

Sentinel 아키텍처와 쿼럼 메커니즘

Sentinel의 역할

Redis Sentinel은 Redis 인스턴스를 모니터링하고, 마스터 장애 시 자동으로 레플리카를 승격시키는 분산 감시 시스템이다. Sentinel 프로세스 자체도 분산되어 단일 장애 지점(SPOF)을 방지한다.

Sentinel 설정 파일 (sentinel.conf)

port 26379

sentinel monitor mymaster 192.168.1.10 6379 2

sentinel down-after-milliseconds mymaster 5000

sentinel failover-timeout mymaster 60000

sentinel parallel-syncs mymaster 1

sentinel monitor <master-name> <ip> <port> <quorum>

quorum = 장애 판정에 필요한 최소 Sentinel 동의 수

쿼럼(Quorum)과 과반수(Majority)

쿼럼과 과반수는 다른 개념이다. 쿼럼은 장애를 감지하는 데 필요한 최소 동의 수이고, 과반수는 실제 페일오버를 수행하기 위한 요건이다.

3대 Sentinel 구성 예시

quorum = 2 (2대가 동의하면 ODOWN 판정)

majority = 2 (3대 중 2대 = 과반수)

5대 Sentinel 구성 예시

quorum = 3 (3대가 동의하면 ODOWN 판정)

majority = 3 (5대 중 3대 = 과반수)

Sentinel 상태 확인

redis-cli -p 26379 SENTINEL masters

redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

redis-cli -p 26379 SENTINEL replicas mymaster

페일오버 순서

1. SDOWN (Subjective Down) - 개별 Sentinel이 마스터 응답 없음 감지

down-after-milliseconds 경과 후 발생

2. ODOWN (Objective Down) - quorum 수 이상의 Sentinel이 SDOWN 동의

이 시점에서 페일오버 프로세스 시작

3. Leader Election - Sentinel 중 하나가 리더로 선출

majority 이상의 투표 필요 (Raft 유사 알고리즘)

4. Replica 선택 - 리더 Sentinel이 최적의 레플리카 선택

우선순위: replica-priority → 복제 오프셋 → runid

5. Failover 실행

선택된 레플리카에 SLAVEOF NO ONE 명령

다른 레플리카를 새 마스터로 재연결

페일오버 진행 상황 모니터링

redis-cli -p 26379 SENTINEL failover-status mymaster

Cluster 해시 슬롯과 리샤딩

해시 슬롯 분배

Redis Cluster는 전체 키스페이스를 16384개의 해시 슬롯으로 나누어 관리한다. 각 마스터 노드는 슬롯의 일부를 담당하며, 키의 CRC16 해시값을 16384로 나눈 나머지로 슬롯을 결정한다.

클러스터 생성 (최소 6노드: 3 Master + 3 Replica)

redis-cli --cluster create \

192.168.1.10:7000 192.168.1.11:7001 192.168.1.12:7002 \

192.168.1.10:7003 192.168.1.11:7004 192.168.1.12:7005 \

--cluster-replicas 1

슬롯 분배 확인

redis-cli -c -h 192.168.1.10 -p 7000 CLUSTER SLOTS

개별 키의 슬롯 확인

redis-cli -c CLUSTER KEYSLOT mykey

(integer) 14687

해시 태그를 사용한 같은 슬롯 배치

중괄호 안의 문자열만으로 슬롯 결정

redis-cli -c SET "user:1001:profile" "data1"

redis-cli -c SET "user:1001:session" "data2"

위 두 키는 다른 슬롯에 배치될 수 있음

해시 태그 사용 시 같은 슬롯에 배치 가능

CLUSTER KEYSLOT 명령으로 확인

redis-cli CLUSTER KEYSLOT "user:1001"

리샤딩(Resharding)

온라인 리샤딩 - 서비스 중단 없이 슬롯 이동

redis-cli --cluster reshard 192.168.1.10:7000 \

--cluster-from <source-node-id> \

--cluster-to <target-node-id> \

--cluster-slots 1000 \

--cluster-yes

리샤딩 진행 상황 확인

redis-cli -c -h 192.168.1.10 -p 7000 CLUSTER INFO

클러스터 상태 점검

redis-cli --cluster check 192.168.1.10:7000

슬롯 리밸런싱 (자동 균등 분배)

redis-cli --cluster rebalance 192.168.1.10:7000 \

--cluster-threshold 2

MOVED와 ASK 리다이렉션

Python redis-py-cluster 예제

ClusterMode 클라이언트는 MOVED/ASK를 자동 처리

rc = redis.RedisCluster(

host='192.168.1.10',

port=7000,

decode_responses=True,

skip_full_coverage_check=True

)

일반적인 사용 - 리다이렉션 자동 처리

rc.set('session:abc123', 'user_data')

value = rc.get('session:abc123')

파이프라인 사용 시 같은 슬롯의 키만 묶어야 함

해시 태그를 활용하면 같은 슬롯에 배치 가능

pipe = rc.pipeline()

pipe.set('order:1001:status', 'pending')

pipe.set('order:1001:total', '50000')

pipe.execute()

MOVED: 키가 다른 노드에 있을 때 (영구 이동)

ASK: 리샤딩 중 일시적으로 다른 노드에 있을 때

복제(Replication)와 PSYNC

복제 설정과 PSYNC 프로토콜

레플리카 설정

redis.conf (레플리카 노드)

replicaof 192.168.1.10 6379

masterauth your_password

PSYNC 프로토콜 동작:

1. Full Sync (전체 동기화)

- 레플리카가 처음 연결되거나 backlog가 부족할 때

- 마스터가 RDB 스냅샷 생성 후 전송

- 전송 중 변경분은 별도 버퍼에 저장 후 추가 전송

2. Partial Sync (부분 동기화) - PSYNC2

- 레플리카가 짧은 단절 후 재연결 시

- replication backlog에 저장된 변경분만 전송

- 훨씬 빠르고 효율적

backlog 크기 설정 (기본 1MB, 운영 환경에서는 증가 권장)

repl-backlog-size 256mb

repl-backlog-ttl 3600

복제 상태 확인

redis-cli INFO replication

복제 상태 모니터링

마스터에서 복제 상태 확인

redis-cli INFO replication

role:master

connected_slaves:2

slave0:ip=192.168.1.11,port=6379,state=online,offset=1234567,lag=0

slave1:ip=192.168.1.12,port=6379,state=online,offset=1234567,lag=1

master_replid:abc123def456...

master_repl_offset:1234567

repl_backlog_active:1

repl_backlog_size:268435456

복제 지연(lag) 모니터링 - lag이 지속적으로 높으면 조치 필요

lag > 10 : 네트워크 또는 레플리카 성능 확인

lag > 60 : 긴급 조치 필요 (풀싱크 발생 가능)

레플리카에서 읽기 전용 확인

redis-cli -h 192.168.1.11 CONFIG GET replica-read-only

메모리 관리와 축출 정책

maxmemory 설정

maxmemory 설정 (redis.conf)

maxmemory 8gb

런타임 변경

redis-cli CONFIG SET maxmemory 8589934592

현재 메모리 사용량 확인

redis-cli INFO memory

used_memory:4294967296

used_memory_human:4.00G

used_memory_rss:4831838208

used_memory_rss_human:4.50G

mem_fragmentation_ratio:1.12

maxmemory:8589934592

maxmemory_human:8.00G

maxmemory_policy:allkeys-lru

축출 정책 비교

| 정책 | 대상 키 | 알고리즘 | 적합한 시나리오 |

| --------------- | ---------------- | ---------------- | -------------------------- |

| allkeys-lru | 모든 키 | LRU | 일반 캐시 (가장 많이 사용) |

| allkeys-lfu | 모든 키 | LFU | 인기도 기반 캐시 |

| allkeys-random | 모든 키 | 랜덤 | 균등 접근 패턴 |

축출 정책 설정

redis-cli CONFIG SET maxmemory-policy allkeys-lfu

LFU 카운터 설정 (Redis 4.0+)

lfu-log-factor: 카운터 증가 속도 (기본 10, 높을수록 느리게 증가)

lfu-decay-time: 카운터 감소 주기 (분, 기본 1)

redis-cli CONFIG SET lfu-log-factor 10

redis-cli CONFIG SET lfu-decay-time 1

특정 키의 LFU 빈도 확인

redis-cli OBJECT FREQ mykey

축출 통계 확인

redis-cli INFO stats | grep evicted

evicted_keys:12345

메모리 최적화 기법

1. 데이터 구조 최적화 - ziplist/listpack 활용

소규모 해시에 ziplist 사용 (메모리 최대 10배 절약)

redis-cli CONFIG SET hash-max-ziplist-entries 128

redis-cli CONFIG SET hash-max-ziplist-value 64

소규모 리스트에 listpack 사용 (Redis 7.0+)

redis-cli CONFIG SET list-max-listpack-size -2

소규모 Sorted Set에 ziplist 사용

redis-cli CONFIG SET zset-max-ziplist-entries 128

redis-cli CONFIG SET zset-max-ziplist-value 64

2. 키 네이밍 최적화 - 짧은 키 이름 사용

Bad: user:session:authentication:token:1001

Good: u:s:t:1001

3. 메모리 사용량 분석

redis-cli MEMORY USAGE mykey

redis-cli MEMORY DOCTOR

4. 큰 키(Big Key) 탐지

redis-cli --bigkeys --memkeys

5. Lazy Free 설정 (백그라운드 삭제로 블로킹 방지)

redis-cli CONFIG SET lazyfree-lazy-eviction yes

redis-cli CONFIG SET lazyfree-lazy-expire yes

redis-cli CONFIG SET lazyfree-lazy-server-del yes

영속화: RDB와 AOF

RDB vs AOF 비교

| 항목 | RDB (Snapshot) | AOF (Append Only File) |

| ----------- | ---------------------------- | ---------------------------------- |

| 방식 | 특정 시점의 전체 스냅샷 | 모든 쓰기 명령을 순차적으로 기록 |

| 데이터 유실 | 마지막 스냅샷 이후 유실 가능 | fsync 설정에 따라 최소화 |

| 파일 크기 | 작음 (바이너리 압축) | 큼 (명령어 텍스트, rewrite로 축소) |

| 복구 속도 | 빠름 | 느림 (명령 재실행) |

| 성능 영향 | fork() 시 순간 지연 | fsync 빈도에 따라 지속적 영향 |

| 권장 설정 | 백업용 | 데이터 안정성용 |

RDB 설정 (redis.conf)

save 900 1 # 900초(15분) 내 1개 이상 변경 시 스냅샷

save 300 10 # 300초(5분) 내 10개 이상 변경 시 스냅샷

save 60 10000 # 60초(1분) 내 10000개 이상 변경 시 스냅샷

rdbcompression yes

rdbchecksum yes

dbfilename dump.rdb

dir /var/lib/redis

AOF 설정

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec # 권장: 1초마다 fsync (성능과 안정성 균형)

appendfsync always # 매 명령마다 fsync (가장 안전, 성능 저하)

appendfsync no # OS에 위임 (가장 빠르나 데이터 유실 위험)

AOF Rewrite 설정

auto-aof-rewrite-percentage 100 # AOF가 마지막 rewrite 대비 100% 커지면

auto-aof-rewrite-min-size 64mb # 최소 64MB 이상일 때 rewrite 실행

프로덕션 권장: RDB + AOF 동시 사용

RDB: 빠른 복구 + 백업

AOF: 데이터 유실 최소화

AOF 재작성과 관리

수동 AOF Rewrite 실행

redis-cli BGREWRITEAOF

AOF 상태 확인

redis-cli INFO persistence

aof_enabled:1

aof_rewrite_in_progress:0

aof_last_rewrite_time_sec:2

aof_current_size:134217728

aof_base_size:67108864

AOF 무결성 검사

redis-check-aof --fix appendonly.aof

RDB 무결성 검사

redis-check-rdb dump.rdb

수동 백업 (BGSAVE 사용)

redis-cli BGSAVE

백그라운드에서 RDB 스냅샷 생성

dump.rdb 파일을 안전한 스토리지로 복사

슬로우 로그 분석

슬로우 로그 설정

redis-cli CONFIG SET slowlog-log-slower-than 10000 # 10ms 이상 기록

redis-cli CONFIG SET slowlog-max-len 128 # 최대 128개 항목 유지

슬로우 로그 조회

redis-cli SLOWLOG GET 10

1) 1) (integer) 14 # 로그 ID

2) (integer) 1710230400 # 타임스탬프

3) (integer) 15230 # 실행 시간 (마이크로초)

4) 1) "KEYS" # 명령어

2) "session"

5) "192.168.1.50:54321" # 클라이언트 주소

6) ""

슬로우 로그 통계

redis-cli SLOWLOG LEN

redis-cli SLOWLOG RESET

프로덕션에서 반드시 피해야 할 O(N) 명령어:

KEYS * → SCAN으로 대체

SMEMBERS → SSCAN으로 대체

HGETALL → HSCAN으로 대체

LRANGE 0 -1 → 페이지네이션 적용

SCAN 기반 안전한 키 탐색

KEYS 대신 SCAN 사용 (비차단)

redis-cli SCAN 0 MATCH "session:*" COUNT 100

1) "17920" # 다음 커서

2) 1) "session:abc123"

2) "session:def456"

...

반복 스캔 (커서가 0이 될 때까지)

redis-cli SCAN 17920 MATCH "session:*" COUNT 100

메모리 단편화 대응

단편화 비율 확인

redis-cli INFO memory | grep frag

mem_fragmentation_ratio:1.45

mem_fragmentation_bytes:536870912

mem_fragmentation_ratio 해석:

1.0 ~ 1.5 : 정상 범위

1.5 이상 : 단편화 심각, 조치 필요

1.0 미만 : 스왑 사용 중 (매우 위험)

Active Defragmentation 활성화 (Redis 4.0+)

redis-cli CONFIG SET activedefrag yes

redis-cli CONFIG SET active-defrag-enabled yes

단편화 임계값 설정

redis-cli CONFIG SET active-defrag-ignore-bytes 100mb

redis-cli CONFIG SET active-defrag-threshold-lower 10 # 10% 이상이면 시작

redis-cli CONFIG SET active-defrag-threshold-upper 100 # 100% 이상이면 최대 노력

redis-cli CONFIG SET active-defrag-cycle-min 1 # CPU 최소 1% 사용

redis-cli CONFIG SET active-defrag-cycle-max 25 # CPU 최대 25% 사용

jemalloc 통계 확인

redis-cli MEMORY MALLOC-STATS

장애 시나리오와 복구 절차

시나리오 1: Split-brain (스플릿 브레인)

네트워크 파티션이 발생하면 Sentinel 클러스터가 분리되어 두 개의 마스터가 동시에 존재할 수 있다. 이는 데이터 불일치를 유발하는 가장 위험한 장애다.

Split-brain 예방 설정

마스터가 최소 N개의 레플리카와 연결되지 않으면 쓰기 거부

redis-cli CONFIG SET min-replicas-to-write 1

redis-cli CONFIG SET min-replicas-max-lag 10

발생 시 복구 절차:

1. 모든 Redis 인스턴스 상태 확인

redis-cli -h 192.168.1.10 -p 6379 INFO replication

redis-cli -h 192.168.1.11 -p 6379 INFO replication

2. 어떤 마스터가 최신 데이터를 가지고 있는지 확인

redis-cli -h 192.168.1.10 -p 6379 INFO replication | grep master_repl_offset

redis-cli -h 192.168.1.11 -p 6379 INFO replication | grep master_repl_offset

3. 오래된 마스터를 레플리카로 강등

redis-cli -h 192.168.1.11 -p 6379 REPLICAOF 192.168.1.10 6379

4. Sentinel 상태 리셋

redis-cli -p 26379 SENTINEL RESET mymaster

5. 데이터 정합성 검증

redis-cli -h 192.168.1.10 DBSIZE

redis-cli -h 192.168.1.11 DBSIZE

시나리오 2: OOM (Out of Memory)

OOM 예방 모니터링

redis-cli INFO memory

used_memory_peak:8589934592

used_memory_peak_human:8.00G

OOM Killer에 의해 종료된 경우 확인

시스템 로그 확인

dmesg 또는 /var/log/syslog에서 OOM 관련 로그 확인

긴급 복구 절차:

1. maxmemory 확인 및 조정

redis-cli CONFIG SET maxmemory 12gb

2. 축출 정책이 noeviction이면 변경

redis-cli CONFIG GET maxmemory-policy

redis-cli CONFIG SET maxmemory-policy allkeys-lru

3. 큰 키 식별 및 정리

redis-cli --bigkeys

redis-cli --memkeys --memkeys-samples 100

4. 불필요한 키 만료 설정

redis-cli SCAN 0 MATCH "temp:*" COUNT 1000

필요한 키에 TTL 설정

redis-cli EXPIRE "temp:old-data" 3600

5. 향후 예방을 위한 알림 설정 (maxmemory의 80%에서 경고)

시나리오 3: Cluster 노드 장애

클러스터 상태 확인

redis-cli -c CLUSTER INFO

cluster_state:ok

cluster_slots_assigned:16384

cluster_slots_ok:16384

cluster_slots_pfail:0

cluster_slots_fail:0

장애 노드 확인

redis-cli -c CLUSTER NODES

장애 노드에 "fail" 플래그가 표시됨

노드 교체 절차:

1. 새 Redis 인스턴스 시작

redis-server /etc/redis/7006.conf

2. 클러스터에 새 노드 추가

redis-cli --cluster add-node 192.168.1.13:7006 192.168.1.10:7000

3. 새 노드를 특정 마스터의 레플리카로 지정

redis-cli --cluster add-node 192.168.1.13:7006 192.168.1.10:7000 \

--cluster-slave --cluster-master-id <master-node-id>

4. 장애 노드 제거

redis-cli --cluster del-node 192.168.1.10:7000 <failed-node-id>

5. 슬롯 재할당 (마스터 장애 시)

redis-cli --cluster fix 192.168.1.10:7000

운영 모니터링과 핵심 메트릭

종합 상태 확인 스크립트

핵심 모니터링 메트릭:

1. 메모리: used_memory / maxmemory 비율

2. 단편화: mem_fragmentation_ratio

3. 캐시 히트율: keyspace_hits / (keyspace_hits + keyspace_misses)

4. 연결 수: connected_clients

5. 초당 처리량: instantaneous_ops_per_sec

6. 축출 수: evicted_keys (급증 시 경고)

7. 복제 지연: master_repl_offset vs slave_repl_offset

Latency 모니터링

redis-cli --latency

redis-cli --latency-history

Latency 이벤트 모니터링 (Redis 2.8.13+)

redis-cli CONFIG SET latency-monitor-threshold 100

redis-cli LATENCY LATEST

redis-cli LATENCY HISTORY event-name

운영 시 주의사항

1. **메모리 오버커밋**: Linux에서 `vm.overcommit_memory=1` 설정이 필요하다. fork() 기반 RDB/AOF rewrite 시 메모리 부족으로 실패할 수 있다.

2. **Transparent Huge Pages(THP) 비활성화**: THP는 Redis의 fork 성능에 악영향을 미치므로 반드시 비활성화한다.

3. **maxmemory 마진**: 물리 메모리의 70-80%로 설정하여 복제 버퍼, AOF rewrite, OS 캐시 등에 여유를 둔다.

4. **Cluster 모드에서 MULTI/EXEC**: 트랜잭션 내 모든 키가 같은 슬롯에 있어야 한다. 해시 태그를 활용하라.

5. **Sentinel 배포 위치**: Sentinel 인스턴스를 Redis 노드와 다른 물리 서버 또는 가용 영역에 배치하여 동시 장애를 방지한다.

6. **KEYS 명령 금지**: 프로덕션에서 KEYS 명령은 O(N) 블로킹을 유발한다. SCAN으로 대체하고, rename-command로 비활성화하라.

운영 환경 커널 튜닝

/etc/sysctl.conf

vm.overcommit_memory = 1

net.core.somaxconn = 65535

net.ipv4.tcp_max_syn_backlog = 65535

THP 비활성화

echo never > /sys/kernel/mm/transparent_hugepage/enabled

위험 명령어 비활성화 (redis.conf)

rename-command KEYS ""

rename-command FLUSHDB ""

rename-command FLUSHALL ""

rename-command DEBUG ""

마치며

Redis의 고가용성 운영은 단순히 Sentinel이나 Cluster를 설정하는 것을 넘어선다. 메모리 관리, 축출 정책, 영속화 전략, 복제 모니터링, 그리고 장애 시나리오에 대한 사전 준비가 모두 갖추어져야 안정적인 프로덕션 운영이 가능하다.

핵심은 세 가지다. 첫째, 워크로드에 맞는 배포 모드를 선택하라. 둘째, 메모리 한계와 축출 정책을 반드시 설정하라. 셋째, 장애 시나리오별 복구 절차를 문서화하고 주기적으로 훈련하라. 이 세 가지가 갖추어지면 Redis는 초고속 인메모리 스토어의 장점을 안정적으로 발휘할 수 있다.

참고자료

- [Redis Cluster Tutorial - Official Documentation](https://redis.io/docs/latest/operate/oss_and_stack/management/scaling/)

- [Redis Sentinel - High Availability](https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/)

- [Redis Memory Optimization](https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/memory-optimization/)

- [Redis Key Eviction Policies](https://redis.io/docs/latest/develop/reference/eviction/)

- [Redis Cluster Specification](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/)

- [Google Cloud - Redis Memory Management Best Practices](https://docs.cloud.google.com/memorystore/docs/redis/memory-management-best-practices)

- [Azure Cache for Redis - Best Practices for Memory Management](https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-memory-management)