Redis-Cluster 특징
- Redis Cluster 는 여러 노드에 자동적인 데이터 분산을 하고, 일부 노드가 실패 혹은 통신 단절에도 계속 운영되는 가용성을 제공한다. 또한 고성능을 보장하면서도 선형 확장성을 제공한다.
- full-mesh 구조로 통신하며 cluster bus 라는 추가 채널(port)을 사용한다. hash slot을 사용한 키를 관리하고, multi key 명령어는 제한됐다.
또한 클라이언트는 모든 노드에 접속이 가능하며, DB0만 사용이 가능하다. (?) - 희한하게 gossip 프로토콜을 사용하는데, gossip 프로토콜은 마치 소문이 퍼지는 것처럼 통신의 개수를 줄이는 프로토콜이다.
-
master 를 여러개 두어 데이터를 분산 저장이 가능하다. (샤딩)
Scale Out이 가능하다.
서버를 늘릴수록 저장 공간이 무한대로 커진다. -
master 하나에 여러개의 slave 를 둘 수 있다.
-
master 1,2,3이 있다면 데이터는 3개중에 하나에 저장되며,
client 가 읽기 요청 시 저장된 곳이 아닌 다른 마스터에 요청했다면,
데이터가 저장된 마스터 정보를 알려주어 전달받은 마스터 정보로 다시 요청하여 데이터를 받아온다. (이 부분은 redis-cluster 를 지원하는 라이브러리에서 다 해준다) -
slave 가 죽어서 복제 노드가 없는 master가 생기면 다른 master 노드에 여유분이 있다면 해당 노드로 빈자리를 채울 수 있다.
(이 부분도 사용자가 개입하지 않고 클러스터가 알아서 해준다) -
master가 죽으면 slave 가 master로 자동 faliover 된다.
-
최소 3개의 마스터 노드가 있어야 구성이 가능하다.
-
센티널이 노드를 감시했지만, 클러스터에서는 모든 노드가 서로를 감시한다.
Sentinel 과의 차이점
- Cluster는 Sentinel 이랑 비슷하지만, 결국 싱글 마스터로 작동한다는 차이점이 있다. Sentinel은 단순하고 소규모 시스템의 HA (고가용성)이 필요할 때 선택한다.
- Cluster는 데이터 분산에 샤딩을 사용하고, 자동 장애조치를 위해 모니터링 노드(Sentinel)를 추가 배치할 필요가 없다. 또한 multi key 사용이 제한된다.
데이터 분산과 Key 관리
- 데이터를 분산하려면 기준이 필요하다. 특정 key 값이 어느 노드(shard) 에 속할 지 결정하는 메커니즘이 있어야 한다. 보통 분산 시스템에서 해싱이 사용된다.
- 단순 해싱으로는 노드 개수가 변할 때 모든 매핑이 새로 계산해야 하는 문제가 있다. 이를 해결하기 위해 Hash Slot 이 있다.
- Redis는 16384개의 hash Slot으로 key 공간을 나누어 관리한다. 각 키는 CRC16 해싱 후에 16384로 modulo 연산을 하여 hash slot에 매핑시킨다.
hash slot은 각 노드들에 나누어 분배된다.
클라이언트의 데이터 접근
- 한 번 매핑을 만들면 보통 바뀌는 일이 없다. 클러스터 노드는 요청 key에 해당 노드로 자동 redirect를 해주지 않는다.
- MOVED 에러를 받으면 해당 노드로 다시 요청해야 한다. 담당 slot이 아니면 클라이언트는 알맞은 노드로 재시도 할 수 있다.
성능과 가용성
클라이언트가 MOVED 에러에 재요청을 해야할 때, 클라이언트는 key-node 맵을 캐싱해서 대부분의 경우 발생하지 않는다. 클라이언트는 단일 redis 인스턴스를 이용할때와 같은 성능으로 이용이 가능하다. 대신 분산 시스템에서 성능은 데이터 일관성과 trade-off 가 있다. Redis Cluster는 고성능의 확장성을 제공하면서도 일정 수준의 안전성과 가용성을 유지하는 것을 목표로 설계됐다.
가용성
1. 데이터 일관성
- 강한 일관성을 제공하지 않는다. 높은 성능을 위해 비동기 복제를 하기 때문이다.
- Ack 와 복제는 순서가 정해져있지 않아서 복제 전에 master가 죽는 경우라면, 데이터가 유실된다.
2. auto failover
- 일부 노드가 실패해도 다수의 master가 남아있고, 사라진 master의 replica가 있다면 클러스터는 failover 되어 가용한 상태가 된다.
- 노드의 timeout동안 다수의 master와 통신하지 못한 master는 스스로 error가 돼서 write 요청을 받지 않는다.
3. replica migration
- replica가 다른 master로 migrate 해서 가용성을 높인다.
클러스터 제약 사항
- DB0만 사용 가능
- Redis는 한 인스턴스에 여러DB를 가질 수 있으며 default 는 16이다.
- Multi DB는 용도별로 분리해서 관리를 쉽게 하는 목적이다. 그런데 클러스터에서는 Multi DB를 사용할 수 없고 DB0으로 고정된다.
- Multi key operation 사용 제약
- MSET 같은 Multi key 오퍼레이션은 기본적으로 사용할 수 없다.
- 클라이언트 구현 강제
- 클라이언트는 클러스터의 모든 노드에 접속해야 한다.
- MOVED 에러에 대응하기 위해 클라이언트의 redirect 기능을 구현해야 한다.
- 클라이언트 라이브러리가 없는 환경이 있을 수 있기에, 이 경우는 대처가 어렵다.
Fail Fast, Fail Often