GitHubAboutDocsTech-Log

Cluster(클러스터)

Redis Cluster는 데이터를 여러 노드에 분산 저장하여 수평적 확장을 지원하여, 큰 아키텍처 변경 없이 데이터 샤딩(Sharding)과 고가용성(High Availability)을 확보할 수 있다.

  • 데이터 샤딩

    • 데이터를 여러 노드에 분산하여 데이터 저장소의 수평 확장 지원

    • 최대 1,000개의 노드까지 지원

  • 고가용성

    • Master-Slave 복제를 통해 데이터의 가용성 보장

    • 클러스터 내 노드들이 서로를 감시하며, 마스터 장애 시 복제본 노드로 자동 페일오버(Failover)를 수행

    • 안정적인 운영을 위해 최소 3개의 마스터와 각 마스터에 대한 복제본으로 구성하는 것이 일반적

해시 슬롯(Hash Slot)을 이용한 데이터 샤딩

Redis Cluster는 키를 CRC16(키) % 16384 값으로 슬롯이 결정되며, 슬롯을 소유한 마스터 노드가 해당 키를 책임진다.

  • 슬롯 범위: 0 ~ 16383 (총 16,384개)

  • 키 -> 슬롯 매핑: CRC16(key) % 16384

  • 확장/축소 시 슬롯 재분배 가능

    • 노드 추가 시: 일부 슬롯을 새 마스터로 이관(resharding)이 가능

    • 노드 제거/축소 시: 해당 마스터의 슬롯을 다른 마스터로 재분배

Slots 0..16383
[ 0 ───────── 5460 ]   -> Master #1
[ 5461 ───── 10922 ]   -> Master #2
[ 10923 ──── 16383 ]   -> Master #3

실제 운영에서는 트래픽 특성에 따라 슬롯을 비대칭으로 재분배(resharding)할 수 있다.

해시태그(Hash Tag)

MGET, MSET, SUNION 등 다중 키 커맨드 같은 다른 슬롯의 키를 동시에 처리할 수 없지만, 함께 사용되는 키들을 같은 슬롯에 저장할 수 있도록 해시태그를 사용하는 방법으로 해결할 수 있다.

  • 키 이름에 {와 }가 있으면 첫 번째 {와 그 뒤 첫 } 사이 문자열만 해시 대상으로 사용

  • 중괄호 안의 값을 기준으로 해시 슬롯이 결정되므로, 같은 태그를 가진 키들은 항상 같은 슬롯에 저장

케이스
키 예시
다중키 커맨드(MGET)

태그 없음 (슬롯이 다를 수 있음)

cart:user123:items, cart:user123:total

서로 다른 슬롯이면 CROSSSLOT 오류

태그 사용 (같은 슬롯 보장)

cart:{user123}:items, cart:{user123}:total

같은 슬롯이므로 MGET 가능

슬롯은 클러스터 규모를 확장하거나 축소할 때, 슬롯을 다른 노드로 재분배(Resharding)할 수 있다.

  • 노드 추가: 기존 노드가 담당하던 슬롯의 일부를 새로운 마스터 노드로 이전

  • 노드 제거: 제거할 노드가 담당하던 슬롯들을 다른 마스터 노드들로 이전시킨 후 노드를 클러스터에서 제외

자동 재구성을 통한 고가용성 확보

센티널과 마찬가지로 클러스터 구조에서도 복제와 자동 페일오버를 이용해 고가용성을 확보할 수 있다.

  • 센티넬: 별도의 센티넬 프로세스들이 레디스 마스터-복제본 구성을 감시하고 장애 조치를 수행하는 중앙 감시 방식

  • 클러스터: 클러스터에 속한 모든 노드가 서로를 감시하는 분산된 감시 방식

장애 발생 시 서비스 연속성을 보장하기 위한 주요 메커니즘은 다음과 같다.

항목
자동 페일오버 (Automatic Failover)
복제본 마이그레이션 (Replica Migration)

목적

마스터 노드 장애 시 서비스 중단을 최소화하고 복제본을 새 마스터로 승격

마스터가 된 복제본으로 인해 복제본이 없어진 다른 마스터에 새로운 복제본을 할당

트리거

과반수 이상의 마스터 노드가 특정 마스터의 장애(FAIL) 상태에 동의

어떤 마스터의 복제본이 0개가 되고, 다른 마스터는 여분의 복제본을 가지고 있을 때

효과

즉각적인 서비스 복구 경로 확보

클러스터 전체의 장애 내성(Fault Tolerance)을 원래 수준으로 복원하여 이중화 유지

클러스터 동작 원리

클러스터 동작 매커니즘은 다음과 같다.

  • 노드 간 통신

    • 클러스터의 모든 노드는 TCP 버스로 연결되어 주기적으로 PING/PONG 패킷 교환

    • 해당 패킷에는 자신의 상태와 자신이 알고 있는 다른 노드들의 상태 정보, 해시 슬롯 구성 등이 포함

    • 모든 노드는 중앙 관리자 없이도 클러스터 전체의 토폴로지를 인지하고 장애 감지 가능

  • 노드 핸드셰이크

    • 새 노드를 클러스터에 등록해 가십에 참여시키는 초기 절차

    • 새 노드는 기존 노드에 CLUSTER MEET 커맨드를 보내고, 수신한 노드는 다른 노드에 새 노드의 정보를 전파

  • 클러스터 라이브 재구성

    • 클러스터가 운영되는 동안 노드를 추가하거나 제거하는 과정

    • 새로운 노드 추가: 빈 노드를 클러스터에 추가한 뒤, 기존 노드에서 일부 슬롯을 새 노드로 이동시키는 방식으로 진행

    • 노드 제거: 기존 노드에서 슬롯을 다른 노드로 이동시키고, 해당 노드를 클러스터에서 제거

  • 리디렉션

    • 클라이언트가 특정 키에 대한 요청을 잘못된 노드에 보냈을 때, 클러스터는 올바른 노드로 요청을 다시 보내도록 안내하는 메커니즘

    • MOVED: 요청하는 해시 슬롯이 다른 노드에 있을 때, 해당 노드의 주소를 포함해 클라이언트에게 전달

    • ASK: 해시 슬롯이 다른 노드로 이동 중의 임시 리디렉션, 해시 슬롯은 변경되었지만 실제 데이터는 아직 이전 노드에 존재할 때 사용

  • 장애 감지와 페일오버

    • PFAIL(Possible Fail): 한 노드가 다른 노드로부터 일정 시간 이상 응답을 받지 못하면, 주관적으로 해당 노드를 장애 의심 상태로 인지

    • FAIL: PFAIL 상태를 감지한 노드가 다른 마스터들에게 해당 노드의 상태 질의 후 과반수 이상이 동의하면, 해당 노드의 상태는 FAIL로 확정

  • 복제본 선출

    • 마스터가 FAIL 상태가 되면, 해당 마스터의 복제본 노드들은 마스터 승격 절차 시작

    • 선출 우선순위는 복제 오프셋이 가장 높은(마스터와 데이터 동기화가 가장 최신 상태) 복제본으로 결정

    • 후보가 된 복제본은 다른 모든 마스터에게 투표를 요청하고, 과반수의 동의를 얻으면 새로운 마스터로 승격되어 장애가 발생한 마스터의 슬롯들을 담당

참고자료

Last updated

Was this helpful?