Redis Cluster

Redis Cluster 란

• 여러 노드에 자동적인 데이터 분산을 하고, 일부 노드가 실패 혹은 통신 단절에도 계속 운영되는 가용성을 제공
• 또한 고성능을 보장하면서도 선형 확장성을 제공
• 일반적으로 샤딩을 할 때 아래와 같이 Hash-Based Sharding을 사용할 수 있다.
  • -> 문제: 샤드가 하나 늘어날 때마다 기존 데이터들을 전혀 다른 곳으로 이동시켜야 한다.
  • -> 해결: HashSlot 사용

HashSlot 동작 방식

• Redis Cluster는 16,384개의 hash slot을 사용
• 각 키는 CRC16 알고리즘으로 해시한 후 16384로 모듈로 연산하여 슬롯 할당
• 슬롯은 클러스터의 노드들에게 분배됨
• 노드 추가/제거 시 해당되는 슬롯만 재배치하면 되므로 효율적

특징

• full-mesh 구조로 통신 (모든 노드끼리 연결되어 있는 구조)
• cluster bus라는 추가 채널 사용하며 보통은 Redis 기본 포트인 6379에 10000을 더한 16379를 포트로 사용
• Gossip Protocol 사용
  • 사내 소문이 순식간에 퍼지는 것처럼 일부 노드에 정보를 전달하면 full-mesh 구조이기 때문에 결국에는 모든 정보가 해당 정보를 알게 된다는 논리
• 16,384개의 hash slot을 사용한 키 관리
• 데이터가 노드 간 분산되어 있기 때문에 multi key 명령어를 사용할 수 없음
• 클라이언트는 모든 노드에 접속

장애 감지

• 노드 간 heartbeat로 상태 모니터링
• 두 가지 실패 감지 메커니즘 사용
  • Gossip 기반 실패 감지: 노드 간 주기적인 ping/pong
  • FAIL 상태 전파: 노드가 다운되었다고 판단되면 클러스터에 전파

데이터 일관성

• 레디스 클러스터(Redis Cluster)는 고성능과 확장성을 제공하고, 적절한 수준의 데이터 안정성과 가용성을 유지하는 것을 목표로 설계되었다.
• 아래 그림과 같이 Redis Cluster는 Strong consistency를 제공하지 않는다.
• 
• 복제가 완료된 후 응답을 보내는 것이 아니라, 높은 성능을 제공하기 위해 응답과 동시에 비동기로 복제를 수행하기 때문에 복제가 완료되기 전에 master가 죽으면 데이터가 유실될 수 있다.

성능 최적화 팁

• 키 설계 시 hash tags 활용하여 관련 데이터를 같은 노드에 배치
• 클라이언트 사이드 캐싱 활용
• 적절한 connection pooling 설정

가용성

일부 Master 노드가 죽더라도 과반수 이상의 master가 남아있고, 사라진 master의 replace가 있다면 클러스터는 failover된다.

해당 Master 노드는 스스로 error 상태로 빠지고, 더이상 write 요청을 받지 않게 된다.

이후 해당 Slave 노드 중 1개가 Master 노드로 승격하게 된다.

Spring에서 Redis Cluster 환경을 구성했다면 해당과 같이 Fail over가 일어났을 때, yaml을 별도로 수정하지 않아도 Sentinel이나 Redis Client 라이브러리가 자동으로 새로운 Master 노드로 연결한다.

제약

1. Cluster에서는 DB0만 사용 가능하다. -> 클러스터 노드에는 DB 1개만 사용 가능하다는 의미
   • 싱글 Redis는 인스턴스에 여러 데이터베이스를 가질 수 있다.
   • 클러스터에서는 해당 기능을 사용할 수 없고 DB0으로 고정된다.
     2. Multi key operation 사용이 불가능하다.
   • Cluster 환경에서는 MSET과 같은 multi-key operation을 사용할 수 없다.
   • 같은 노드 안에 속한 key들에 대해서는 multi-key operation이 가능
   • hash tags를 사용해서 여러 key들이 같은 hash slot에 속하게 할 수 있음 (ex. MSET {user:a}age 20 {user:a}city seoul)