[Redis] 레디스 클러스터

레디스 클러스터

Redis Cluster는 여러 개의 Redis 노드로 이루어진 분산 구성(distributed setup)임.

자동 샤딩(Sharding)과 고가용성(High Availability)을 제공하는 기술임.

단일 인스턴스에서 처리할 수 있는 데이터나 트래픽 규모를 넘어서는 상황에서, 여러 노드로 부하를 분산하고 노드 장애 시 빠르게 복구할 수 있도록 설계됨.

즉, 확장성과 가용성이라는 Redis의 핵심 요구 사항을 충족하기 위한 솔루션이라고 할 수 있음.

 

레디스 클러스터의 주요 개념

1. 샤딩(Sharding)

Redis Cluster는 키(key) 기반으로 데이터를 여러 노드에 분산하여 저장함.

Hash Slot: Redis Cluster는 키를 0부터 16383까지의 해시 슬롯(Hash Slot)에 매핑함.

CRC16(key) % 16384를 통해 키가 어느 슬롯에 들어갈지를 정하고, 슬롯을 통해 특정 노드에 매핑됨.

각 노드는 특정 범위의 해시 슬롯들을 담당하며, 이 슬롯 분배 정보를 모든 클러스터 노드들이 공유함.

 

2. 마스터-슬레이브(Master-Slave) 구조

Redis Cluster 환경에서는 가용성을 확보하기 위해 마스터-슬레이브 구조를 사용함.

마스터 노드: 실제로 읽기/쓰기 연산을 처리하며, 특정 슬롯 범위를 책임짐.

슬레이브 노드: 마스터 노드의 데이터를 실시간으로 복제(Replication)받음.

마스터 노드에 장애가 발생하면 슬레이브 중 하나가 자동으로 마스터로 승격(Promote)되어 서비스를 지속함.

 

3. 고가용성(High Availability) & 오토 패일오버(Auto Failover)

클러스터 내에서 마스터 노드가 장애로 다운되면, 클러스터의 다른 노드들이 이를 감지하고 장애 조치(Failover)를 실행함.

슬레이브 노드 중 하나가 새 마스터로 선출되어(승격) 다운된 노드를 대체함.

이를 통해 자동 장애 조치가 가능하며, 외부에서 별도의 수동 개입 없이도 서비스가 유지됨.

Redis Cluster는 노드 간 Gossip 프로토콜을 통해 서로의 상태를 주기적으로 주고받으면서 장애를 탐지함.

 

4. 확장성(Scalability)

Redis Cluster는 노드를 추가하거나 제거할 때 자동으로 데이터를 재분배(Rebalance)할 수 있음.

노드를 추가하여 새로운 슬롯 범위를 할당받으면, 기존 노드에 분산되어 있던 슬롯 중 일부를 새로운 노드로 옮기는 과정을 거침.

즉, 규모가 커짐에 따라 노드를 유연하게 확장할 수 있으며, 이 때도 클러스터 내부에서 데이터를 재배치하여 부하를 분산하게 됨.

 

레디스 클러스터의 동작 원리

1. 해시 슬롯(Hash Slot) 기반 키 분배

Redis Cluster에서 키(key)를 어떤 노드에 저장할지 결정하는 핵심 원리는 16,384개의 해시 슬롯임.

키에 대해 CRC16 연산을 수행한 뒤, 16384로 나눈 나머지를 구함.

이 결과값이 0~16383 범위의 특정 슬롯 번호를 생성함.

슬롯 번호별로 담당하는 노드가 미리 정해져 있으므로, 해당 노드가 키-값 쌍을 저장하게 됨.

예를 들어, “user:1000”이라는 키에 대해 CRC16(“user:1000”) 결과가 12345라 가정하면, 12345 % 16384 = 12345번 슬롯이 됨.

이 슬롯을 담당하고 있는 노드가 해당 키의 값을 저장함.

 

2. 클러스터 노드 간 통신

2-1. Gossip 프로토콜

모든 노드는 다른 노드들과 주기적으로(PING/PONG) 통신하여 노드 상태 정보를 업데이트함.

장애 노드가 감지되면, 과반수 이상의 노드가 그 노드가 다운되었음을 확인해야 최종적으로 “fail” 상태로 선언됨.

 

2-2. 슬롯 매핑 정보

각 노드는 “어떤 슬롯 범위를 담당하는지”, “어떤 노드가 마스터이고 어떤 노드가 슬레이브인지” 등의 메타데이터를 저장 및 동기화함.

 

3. 요청 라우팅(Routing)

클라이언트가 Redis Cluster에 연결할 때, 일반적으로 클러스터 모드를 지원하는 클라이언트 라이브러리를 사용함.

클라이언트는 연결된 노드(어떤 노드든)로 키에 대한 연산을 요청함.

만약 해당 노드가 요청된 키의 슬롯 범위를 담당하지 않는다면, “MOVED” 혹은 “ASK” 에러를 통해 올바른 노드의 위치를 알려줌(리다이렉션).

클라이언트는 그 정보를 이용해 해당 마스터 노드로 재시도하여 최종적으로 연산을 수행함.

 

4. 장애 감지와 자동 복구

마스터 노드가 장애를 일으켜 다운되었을 때, 다른 노드들은 Gossip을 통해 해당 노드가 응답이 없음을 파악함.

과반수 이상의 노드가 “이 노드는 fail 상태”라고 합의하면, 해당 노드의 상태가 fail로 확정됨.

장애가 발생한 마스터 노드의 슬레이브 중 하나가 새로운 마스터로 승격됨.

이 때 클러스터 메타데이터가 변경되며, 해당 슬롯 범위를 이제 새로운 마스터가 관리함.

 

레디스 클러스터 구성 방법

1. 노드 배포

Redis Cluster를 구성하기 위해서는 최소 3개의 마스터 노드가 필요함.

각 마스터 노드에는 1개 이상의 슬레이브 노드를 두어야 장애 상황에서 자동 복구가 가능함.

일반적으로 “3 마스터 + 3 슬레이브(각 마스터마다 슬레이브 1개)” 최소 구성(총 6노드)을 권장함.

더 높은 가용성이 필요하면 슬레이브 노드를 늘려서 특정 마스터에 대한 슬레이브 수를 2개 이상 두는 식으로 확장 가능함.

 

2. 클러스터 초기화

Redis 설정 파일(redis.conf)에서 cluster-enabled yes, cluster-config-file nodes.conf 등 클러스터 관련 옵션을 활성화함.

노드들이 서로 통신할 cluster-port(일반적으로 Redis 포트+10000, 예: 6379→16379)도 열어둬야 함.

노드를 여러 개 띄운 뒤 redis-cli --cluster create ... 커맨드를 통해 초기 클러스터 링(Ring)을 형성함.

이 과정에서 각 노드가 어떤 슬롯 범위를 담당할지 결정하고, 마스터-슬레이브 구성을 설정함.

 

3. 노드 추가/제거 및 슬롯 재분배(Rebalance)

클러스터에 노드를 추가하면, redis-cli --cluster add-node 명령을 통해 새로운 노드를 이미 구성된 클러스터에 연결할 수 있음.

추가된 노드를 마스터나 슬레이브로 지정할 수 있으며, 노드를 마스터로 사용할 경우 필요에 따라 슬롯 재분배가 필요함.

노드를 제거할 때(redis-cli --cluster del-node), 해당 노드가 담당하던 슬롯들을 다른 노드로 이전해야 하므로, 삭제 전에 재분배 과정을 거쳐야 함.

 

운영 시 고려 사항

1. 데이터 파편화와 키 배포

Redis Cluster는 기본적으로 16,384개 해시 슬롯으로 모든 키를 자동 분산함.

파편화(Shard) 균형도를 높이려면 가능한 한 고르게 키를 배포할 수 있도록 키 설계를 할 필요가 있음.

해시 태그(Hash Tag)를 사용해 다중 키 연산(Pipeline, Lua 스크립트에서 여러 키 접근 등)을 같은 슬롯에 위치시키는 방법도 고려함.

예를 들어, {user1000}:data1, {user1000}:data2 같이 중괄호를 활용.

 

2. 장애 및 복구 시나리오 테스트

마스터 장애 시 자동으로 슬레이브가 승격되어도, 승격 과정에서 잠시 써빙이 지연될 수 있음.

장애 상황 테스트(마스터 강제 다운, 네트워크 분할 등)를 사전에 시뮬레이션하여 최적의 슬레이브 설정, 타임아웃, 복제 지연 등을 조정해야 함.

 

3. Redis 버전 호환성

Redis Cluster 기능은 Redis 3.0부터 공식 지원이 시작됨.

이후 버전에서 안정성, 성능, 복제 및 클러스터 관리 개선사항이 계속 적용되고 있으므로, 프로덕션 환경에서는 되도록 최신 LTS(Long Term Support)에 가까운 버전을 사용하는 것이 좋음.

 

4. 성능 모니터링

노드별 CPU 사용량, 메모리 사용량, 키 수, 네트워크 트래픽, 레플리카(슬레이브) 동기화 지연 등을 모니터링해야 함.

Redis 자체의 INFO 커맨드 및 Slow Log, 혹은 redis_exporter 등을 통해 모니터링/메트릭을 수집할 수 있음.

Redis Cluster 특성상 노드 수가 많아지고 데이터 분량이 클수록, 슬롯 재분배나 장애 복구 시 부하가 커질 수 있으므로 지속적인 모니터링이 필수임.

 

5. Config Epoch과 Split-Brain(네트워크 분할)

Redis Cluster에서 클러스터 구성 정보(누가 마스터이고 누가 어떤 슬롯을 담당하는지)를 버전 관리하는 config epoch이라는 개념이 있음.

만약 네트워크 분할로 인해 클러스터가 반으로 갈라지면, 두 파티션이 각자 다른 config epoch을 증가시키며 마스터 승격을 일으킬 수 있음.

이로 인해 “Split-Brain” 상황이 발생할 수 있으므로, 배포 환경에서 네트워크 안정성, 다중 AZ 구성 시 고려 사항 등을 꼼꼼히 체크해야 함.

 

정리

Redis Cluster는 대규모 데이터 처리 및 고가용성 보장을 위해 설계된 솔루션임.

 

자동 샤딩을 통해 클러스터의 각 노드에 부하를 고르게 분산하고,

마스터-슬레이브 복제로 노드 장애 발생 시 자동으로 슬레이브가 마스터로 승격되어 서비스 연속성을 보장하며,

Gossip 프로토콜로 노드 상태 정보를 공유, 장애 감지 및 복구를 빠르게 수행함.

 

운영 환경에서 Redis Cluster를 효율적으로 사용하려면 다음과 같은 사항들을 주의깊게 살펴야 함.

 

노드 배포 구성: 마스터/슬레이브 개수 및 노드 물리적 위치(AZ, 지역)

모니터링 및 장애 대응: CPU, 메모리, 네트워크, 슬롯 분배, 레플리카 동기화 상태

데이터 모델링: 키 설계, 해시 태그 사용으로 파이프라인 및 Lua 스크립트 활용

노드 확장/축소: 슬롯 재분배와 다운타임 최소화 전략

버전 관리: Redis 버전 호환성 및 꾸준한 업그레이드, 클러스터 설정

 

이러한 요소들을 종합적으로 고려하여 Redis Cluster를 구성하면, 높은 성능, 확장성, 가용성을 모두 만족하는 인메모리 데이터베이스 환경을 구축할 수 있음.

Redis Cluster는 특히 세션 저장소, 캐싱 레이어, 실시간 분석, 순위/랭킹 처리와 같은 고속 읽기/쓰기가 필요한 서비스에 적합함.