Redis Cluster

Redis 클러스터

Redis는 빠르고 간단해서 단일 서버로 시작하기 좋은 캐싱 시스템 중 하나입니다.

하지만 서비스 트래픽이 커지고, 데이터가 많아질수록 하나의 Redis로는 부족할 수 있습니다.

이번 글에서는 이를 해결하기 위한 Redis 클러스터(Cluster) 구조를 정리해보려 합니다.

---

1. 단일 Redis의 한계와 클러스터의 필요성

Redis는 기본적으로 싱글 스레드 구조이기 때문에,

아무리 서버 성능을 올려도 결국엔 Scale-up의 한계가 옵니다.

예를 들어,

• 트래픽이 커질수록 I/O 병목이 발생하고,
• Redis 서버가 죽으면 모든 캐시가 날아가며,
• 데이터가 많아지면 한 서버 메모리에 다 들어가지 않습니다.

그래서 등장한 개념이 바로 Redis Cluster입니다.

👉 여러 Redis 노드가 하나의 거대한 Redis처럼 동작하게 만들어,

데이터를 자동으로 분산 저장하고, 장애가 나도 일부 노드로 복구할 수 있게 합니다.

---

2. Redis 클러스터란?

Redis Cluster는 일종의 분산된 Redis 노드들의 집합입니다.

여러 개의 Master 노드가 데이터를 나눠 저장하고,

각 Master는 Replica(복제본) 노드를 하나 이상 가질 수 있습니다.

구조 예시

Redis Cluster
│
├── Shard 1
│   ├── Node A (Master)
│   └── Node B (Replica)
│
├── Shard 2
│   ├── Node C (Master)
│   └── Node D (Replica)
│
└── Shard 3
    ├── Node E (Master)
    └── Node F (Replica)

핵심 키워드

용어 설명

Master	데이터를 실제로 저장하는 주 노드
Replica	Master의 복제본으로, 장애 시 자동 승격 가능
Hash Slot	키를 분산시키는 단위 (0 ~ 16383)
Cluster Bus	노드 간 상태 정보 교환용 포트 (기본 포트 + 10000)

---

3. 데이터 분산 방식

Redis Cluster는 키를 16384개의 슬롯으로 나눕니다.

각 Master는 이 슬롯 중 일부를 담당합니다.

💡 예시

• Master1 → Slot 0~5460
• Master2 → Slot 5461~10922
• Master3 → Slot 10923~16383

이때 어떤 키가 어느 슬롯에 들어가는지는 아래 공식으로 결정합니다.

CRC16(key) % 16384

예를 들어 "user:123" 키가 5210번 슬롯에 해당한다면, 그 슬롯을 담당하는 Master에 데이터가 저장됩니다.

(UserId가 Key 값이라면 UserId의 수가 10만개건 100만개건 16384 슬롯 안에서 분산됩니다.)

---

4. Failover와 Replica 구조

클러스터의 강점은 장애 대응력입니다.

각 Master는 Replica를 하나 이상 두고, Master가 죽으면 Replica가 자동으로 Master로 승격됩니다.

이 과정은 내부적으로 Gossip 프로토콜을 통해 진행됩니다.

노드들이 서로 주기적으로 상태를 주고받으며 “누가 죽었는지”를 판단하는 구조입니다.

💬 Sentinel과의 차이점

• Sentinel은 장애 감지 + 재시작에 집중
• Cluster는 데이터 분산 + 자동 Failover 모두 처리

---

5. Docker로 클러스터 직접 구성해보기

아래는 6개의 노드(3 Master + 3 Replica)로 클러스터를 구성하는 예시입니다.

① Redis 컨테이너 실행

Redis 클러스터 구성을 위해 6개의 컨테이너를 실행합니다.

3개는 Master, 나머지 3개는 Replica로 사용됩니다.

모든 컨테이너는 클러스터 모드(--cluster-enabled yes)로 실행되며,

각 노드는 포트만 다르게 설정합니다.

docker run -d --name redis-7000 -p 7000:7000 redis --cluster-enabled yes --port 7000
docker run -d --name redis-7001 -p 7001:7001 redis --cluster-enabled yes --port 7001
docker run -d --name redis-7002 -p 7002:7002 redis --cluster-enabled yes --port 7002
docker run -d --name redis-7003 -p 7003:7003 redis --cluster-enabled yes --port 7003
docker run -d --name redis-7004 -p 7004:7004 redis --cluster-enabled yes --port 7004
docker run -d --name redis-7005 -p 7005:7005 redis --cluster-enabled yes --port 7005

Cluster는 최소 3개의 Master Node가 필요합니다.

그 이유는,

Redis Cluster는 내부적으로 위에서 설명한 것처럼 Gossip + 투표 기반 장애 감지(Quorum)를 사용합니다.

즉, 하나의 노드가 “나 죽었어”라고 하는 게 아니라,

다른 Master들이 그 노드가 죽었다고 일종의 합의를 해야 장애로 판단합니다.

최소 3개가 필요한 이유는 바로 이 합의를 판단하기 위한 지표인 “과반수(majority)” 때문입니다.

Master가 2개 이하이면 장애 감지와 Failover가 불가능합니다.

② 클러스터 생성

redis-cli --cluster create \\
127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \\
127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \\
--cluster-replicas 1

 

👉 --cluster-replicas 1

각 Master당 하나의 Replica를 자동으로 붙이겠다는 의미입니다.

---

6. 클러스터 사용 시 주의사항

Redis Cluster는 강력하고 편리하지만 제약도 명확합니다.

1) 트랜잭션 제약

MULTI/EXEC 명령은 동일 슬롯 키에서만 가능합니다.

다른 슬롯 키를 묶어서 트랜잭션 처리 불가합니다.

2) Lua 스크립트 제약

스크립트 내에서 여러 슬롯의 키를 동시에 다루면 오류 발생.

3) Pipeline 제약

파이프라인 처리 역시 cross-slot 불가.

4) Redirect 처리

클러스터에서는 키가 다른 노드에 있을 수 있으므로,

MOVED, ASK 리다이렉트 응답을 클라이언트가 처리해야 합니다.

(JedisCluster, Lettuce 같은 클라이언트는 자동 처리 지원)

---

7. 운영 및 확장 포인트

1) Slot 재배치

노드를 추가하면 새로운 Master에 슬롯을 재분배해야 합니다.

redis-cli --cluster reshard 127.0.0.1:7000\

여기서 7000은 명령을 받을 노드입니다.
새로운 노드(Master)를 추가하고 나서 위의 명령어를 실행 후 어느 정도 slot을 할당한거지 이 후에 설정하게 됩니다.

2) 모니터링 명령어

• cluster info → 클러스터 전체 상태 확인
• cluster nodes → 각 노드의 역할 및 슬롯 범위 확인

3) 확장 시 주의점

• 데이터 이동 중에는 일부 요청이 느려질 수 있음
• Replica를 충분히 두어 장애 대비 필수

---

9. 마무리

Redis Cluster는 자동 데이터 분산, 장애 복구, 읽기 부하 분산까지 한 번에 가능한 구조입니다.

하지만,

운영이 복잡하고 트랜잭션 제약이 있기 때문에 

“무조건 클러스터”보다는 서비스 규모에 맞게 선택하는 게 중요합니다.

참고로 AWS의 ElasticCache 서비스를 활용하면 보다 편리하게 Redis Cluster 구성이 가능합니다.