Redis Cluster 입문하기

Redis는 InMemory 데이터 저장소로 자주 사용되지만 안정적인 운영을 위해서는 고가용성을 확보하는것이 중요하기 때문에 Redis Cluster를 사용해야 합니다.

해당 글에서는 공식 문서를 기반으로 Redis Cluster의 개념을 설명하겠습니다.

• 고가용성이란? 시스템이 다운타임 없이 오랫동안 지속적으로 정상 운영 될 수 있는 능력을 의미합니다.

Redis Cluster란?

Redis Cluster는 데이터를 여러 노드(서버)에 분산 저장하는 시스템입니다.

• 확장성 : 노드를 추가해 용량과 처리량을 향상시킵니다.
• 고가용성 : 노드 장애 시 자동 복구가 가능합니다.
• 성능 : 작업을 분담 처리하기 때문에 성능적으로 향상시킵니다.

Redis 3.0 이상부터 지원하며 최대 1000개 노드까지 확장 가능합니다.

Redis Cluster 개념

1. Data Sharding

Redis Cluster는 키 스페이스를 16,384개의 해시 슬롯으로 나누게 됩니다.

1-1. 왜 16,384개 일까?

클러스터의 모든 노드는 어떤 노드가 16,384개의 슬롯 중 어떤 것을 담당하는지에 대한 전체 정보를 항상 알고 있어야 하며 이 정보는 비트맵(Bitmap) 형태로 교환됩니다.

• 16,384개의 슬롯 상태를 표현하려면 16,384 Bit가 필요합니다.
• 16,384 Bit / 8 = 2,048 Byte, 즉 2KB입니다.

노드들은 Gossip Protocol을 통해 서로의 상태를 주고받는데 이때 클러스터 전체의 슬롯 구성 정보가 담긴 이 2KB짜리 비트맵이 함께 전송하게 되며 이 데이터의 크기가 매우 작기 때문에 네트워크에 부담을 주지 않으면서도 클러스터의 구성 변경(노드 추가, 장애 복구 등)을 모든 노드에 빠르고 효율적으로 전파할 수 있는 것입니다.

 

그리고 슬롯 할당 방법으로 Redis Cluster는 CRC16 알고리즘을 사용해서 키를 해시한 후 그 결과값을 16,384로 나눈 나머지 값을 해당 키의 슬롯 번호로 사용하는데 만약 여러 키를 항상 같은 노드(같은 슬롯)에 저장하고 싶다면 해시태그{}를 사용할 수 있습니다.

예를 들어 user:{123}:food와 user:{123}:price는 {123} 때문에 항상 같은 슬롯에 저장됩니다.

2. Master와 Replica

• Master : 데이터를 읽기 / 쓰기를 합니다.
• Replica : Master의 복사본을 유지하고 Master 장애 시 자동 failover로 승격되는데 이는 Cluster Bus를 통해 노드간 합의하며 낮은 지연 시간을 보이지만 네트워크 지연이 있는 경우 긴 시간 지연될 수 있습니다.
  • Failover란? 장애가 발생했을 때 예비 시스템으로 자동으로 전환되는 기능을 의미합니다.

Redis Sentinel과 Redis Cluster의 차이는 Sentinel은 단일 Master-Replica 구조의 고가용성을 위한 모니터링 및 자동 복구 시스템이지만 데이터를 여러 노드에 자동으로 분산 저장하는 Sharding 기능은 없습니다.

3. Cluster Bus

노드들은 TCP 기반 Cluster Bus(default port : 16379)로 연결됩니다.

Gossip Protocol로 상태를 공유하며 장애 감지와 노트 추가를 처리하게 됩니다.

네트워크 지연이 발생하면 Cluster 전체 성능이 저하 될 수 있으므로 저지연 네트워크를 사용해야합니다.

• gossip 프로토콜이란? 노드들이 서로 소문을 퍼뜨리는 방식으로 동작하며 각 노드는 자기가 알고 있는 정보(자신의 상태, 다른 노드의 상태 등)를 주기적으로 몇몇 다른 노드에게 무작위로 알리게 되며 이 정보가 연쇄적으로 퍼져나가면서 결국 클러스터 전체에 정보가 동기화되는 방식입니다. 즉, 중앙 관리자 없이도 분산 환경에서 효율적으로 정보를 전파할 수 있는 방법입니다.

4. Redirection

클라이언트가 잘못된 노드에 요청하게 되면 오류가 반환됩니다.

• -MOVED : 요청한 키의 슬롯이 영구적으로 다른 노드로 이동했다는 뜻이며 이 응답을 받은 클라이언트는 자신의 슬롯 맵 정보를 최신화하고 새로운 노드로 요청을 다시 보내야 합니다.
• -ASK : 요청한 키의 슬롯이 임시적으로 다른 노드에 있다는 의미로 일시적인 상황이며 클라이언트는 해당 노드에 ASKING 명령을 먼저 보낸 후 원래 하려던 요청을 보내야 합니다. 단, -MOVED와 다르게 슬롯 맵 정보를 갱신하지는 않습니다.

Redis Cluster 운영 시 주요 고려 사항

1. 쓰기 안정성

Redis Cluster는 성능을 위해 기본적으로 비동기 방식으로 마스터 노드의 데이터를 레플리카에 복제하는데 이 방식은 쓰기 지연 시간을 최소화하지만 특정 상황에서 데이터 유실의 원인이 될 수 있습니다.

 

• Client가 Master Node에 데이터를 씁니다.
• Master는 즉시 Client에게 성공을 응답합니다.
• 해당 데이터를 Replica로 전파하기 전에 Master Node에 장애가 발생합니다.
• Redis Cluster는 Replica를 새로운 Master로 승격시키지만 이 Replica는 방금 전의 최신 데이터를 가지고 있지 않아 데이터가 유실됩니다.

데이터의 정합성이 매우 중요하다면 WAIT 명령어를 사용해 쓰기 안전성을 강화할 수 있습니다.

WAIT [복제본 수] [타임아웃] 형식으로 사용하며 지정된 수의 레플리카가 쓰기 작업을 복제했음을 확인할 때까지 클라이언트의 연결을 차단(block)하게 되어 쓰기 작업이 최소 N개의 노드에 안전하게 저장되었음을 보장할 수 있습니다.

하지만 복제를 기다리는 시간만큼 지연 시간이 발생하므로 성능 저하를 감수해야 합니다.

즉, 성능과 데이터 정합성 둘중 어느게 중요한지 파악한 후 사용해야합니다.

2. 안정적인 네트워크

Redis Cluster 운영 시 가장 중요하게 고려해야 할 것 중 하나는 네트워크 안정성인데 이는 네트워크 분할이라는 치명적인 문제를 방지하기 위함입니다.

2-1. 네트워크 분할이란?

Cluster Node 간의 통신 경로에 장애가 발생하여 Cluster가 논리적으로 둘 이상의 그룹으로 분리되는 현상이며 이는 고가용성 시스템의 안정성을 위협하는 주요 요인입니다.

Redis Cluster는 과반수(Quorum) 기반의 장애 감지 및 Failover 메커니즘을 사용합니다.

네트워크 분할이 발생하면 Cluster는 노드 수에 따라 다수 파티션(majority)과 소수 파티션(minority)으로 나뉩니다.

• 소수 파티션: 이 그룹의 노드들은 과반수를 확보하지 못했으므로 클러스터 전체의 데이터 불일치를 방지하기 위해 스스로를 비정상 상태로 간주하고 모든 쓰기(Write) 요청을 거부합니다.
• 다수 파티션: 과반수 이상의 노드를 확보했기 때문에 정상적으로 클라이언트의 요청을 계속 처리합니다.

2-2. 네트워크 분할과 데이터 유실의 관계

네트워크 분할이 위험한 이유는 위에서 설명한 쓰기 안정성 문제를 직접적으로 발생시키기 때문입니다.

 

• 네트워크 문제로 Master Node 하나가 다른 Node들과 분리됩니다.
• 다수 파티션의 노드들은 이 Master가 다운되었다고 판단하고 Failover를 시작하여 해당 Master의 Replica를 새로운 마스터로 승격시킵니다.
• 이때 원래 Master가 장애 직전 처리했던 쓰기 작업이 아직 Replica에게 비동기 방식으로 전파되지 않았다면 그 데이터는 영구적으로 유실됩니다.

결론은 안정적인 네트워크를 구성하는 것은 단순히 성능을 위한 것이 아니라 이처럼 Cluster 분리와 자동 Failover 과정에서 발생할 수 있는 데이터 유실 위험을 차단하기 위함입니다.

권장 사항 : 단일 데이터 센터나 클라우드의 단일 VPC 내에 클러스터를 배치

Redis Cluster 설정 방법

1. Redis 설치 및 설정

Redis 설치 후 redis.conf 수정

cluster-enabled yes # 단독 모드가 아닌 Cluster 모드로 실행
cluster-node-timeout 15000 # 장애 감지 타임아웃 ms 단위

2. Cluster 생성

모든 Redis 인스턴스가 Cluster 모드로 실행되었다면 하나의 클러스터로 묶어줄 차례입니다.

안정적인 운영을 위해 Redis는 최소 3개의 마스터 노드와 각 마스터에 연결된 3개의 레플리카 노드 구성을 권장합니다.

redis-cli --cluster create 192.168.1.101:7001 192.168.1.102:7002 192.168.1.103:7003 \
192.168.1.104:7004 192.168.1.105:7005 192.168.1.106:7006 --cluster-replicas 1

# 7001~7003: Master
# 7004~7006: Replica

• --cluster create: 클러스터 생성 도구를 실행합니다.
• --cluster-replicas 1: 입력된 노드 목록에서 각 Master에 대해 1개의 Replica를 자동으로 할당하라는 의미입니다
  • 이때 Master와 Replica는 작성 순서에 맞게 매핑됩니다.

3. 관리

• 노드 추가
  • redis-cli --cluster add-node [새 노드 IP:Port] [기존 노드 IP:Port]
• Resharding
  
  • 노드 간 해시 슬롯을 재분배하여 데이터 균형을 맞춥니다.
  • 클러스터에 부하를 주며 실패 시 데이터 불일치가 발생할 수 있어서 트래픽이 적은 시간에 사전 백업 후 진행해야합니다.
  • redis-cli --cluster reshard [기존 노드 IP:Port]
• 장애 복구
  • 자동 : 마스터 노드가 다운되면 레플리카가 자동으로 새로운 마스터로 승격됩니다.
  • 수동 : 관리자가 직접 Failover를 트리거할 수 있습니다.
  • redis-cli -c -p [Port] CLUSTER FAILOVER
• 모니터링
  • 클러스터의 전반적인 상태를 확인합니다.
  • redis-cli -c -p [Port] CLUSTER INFO