본문 바로가기
IT/Database

[Redis] Cluster Overview

by 물통꿀꿀이 2019. 1. 6.

Redis Cluster

Redis에서 사용하는 Cluster 즉, Clustering은 데이터를 분산시키는 방법이다. (분산 시스템처럼)

때문에 Redis에서는 한 곳의 Node 자원만 사용하는 것이 아닌 다른 Node 자원 또한 사용하여 전체 computing 자원을 최대한 사용하려 한다.


그림 1. Redis Cluster (+ Node 1과 통신 환경)


Redis Cluster를 간략하게 그린 그림 1을 보면 computing 자원을 최대한 사용한다는 의미를 알 수 있다.

예를 들어 각각의 Computer가 64GB의 메모리를 가진다면 총 10 대의 Computer라고 가정했을 때 우리는 최대 640GB의 메모리를 사용 할 수 있다.

그림 1로 따진다면 우리는 최대 256(64 * 4)GB를 사용 할 수 있다.


이를 바탕으로 Redis는 Clustering 기법을 적용하면서 아래와 같은 Clustering 설계 원칙을 가지고 있다.

- 고성능(High Performance), 확장성(Scalability) : 최대 1,000 개 노드

- 비동기 복제(Asynchronous replication)

- 안전한 쓰기*(Write safety)

* Redis는 대다수의 Master Node로 부터 들어오는 모든 쓰기를 최대한 유지하려고 한다.

- 가용성(Availability) : Master Node에는 적어도 하나의 Slave Node를 유지한다.


Redis Cluster Node

그림 1을 다시 확인해보면 크게 4개의 Node로 구성되어있다. 여기서 각 Node를 Cluster Node라고 한다. 즉, Redis 분산 환경을 구성하는 인스턴스를 의미한다. 

Cluster Node는 다른 Cluster Node와 통신하며 (그림 1에서는 전체 Node가 아닌 Node 1에게만 통신 할 수 있도록 그려짐) 그렇기 때문에 클라이언트 요청에 대해 적합한 Node로 전달해 줄 수 있다. 그러나 모든 Cluster Node가 연결되어 있기 때문에 Cluster 내의 하나의 Node라도 작동하지 않으면 전체가 동작하지 않는다*. 

*물론 전체가 동작하지 않는 문제를 해결하기 위해 Redis Cluster는 Node간 failover를 가능하게 해 놓았다.

이 외에도 Cluster Node의 다른 역할을 살펴보면, 데이터를 유지하고 다른 Nodes의 상태를 확인 하는 등 Cluster를 유지하는 다양한 역할을 수행한다.


Redis Cluster Protocol

아래의 그림 2에서 확인 할 수 있듯이 Cluster Node는 Client 뿐만 아니라 Node들 간에도 통신을 한다. 

즉, Cluster Node는 2개의 TCP Port를 가지고 Connection을 맺고 있다.

- Normal Port (Data Port)

Client와 통신하기 위해 사용되는 Port이다. (일반적으로 6379 Port 번호를 가지고 있다.)

- Cluster Bus Port

Cluster Node가 다른 Cluster Node와 통신하기 위한 Port이다. (Normal Port 번호에 10000을 더한 값)

Binary Protocol을 사용하며, 이 Port를 사용하여 Failure Detection, Configuration Update, Failover Authorization 등 을 수행한다.

(내부 작업을 수행하기 때문에 Client는 해당 Port를 사용할 수 없다.)


그림 2. Redis Cluster Communication


Redis Cluster Replication

위에서도 언급했듯이, Redis Cluster에서는 Cluster Node가 하나라도 작동하지 않으면 전체가 작동하지 않는다. 

그렇기 때문에 Replication 기법을 적용하여 Redis에서 장애 허용(fault tolerance)를 할 수 있도록 구성하였다. 즉, Cluster Node가 장애가 발생하더라도 Redis가 멈추지 않고 동작할 수 있도록 하였다.


그림 3. Redis Cluster Replication


그림 3을 보면 Redis Cluster에서 Replication이 어떻게 구성되는지 확인 할 수 있다. 

사실 Master/Slave의 Replication은 널리 알려진 기법이기 때문에 색다른 것은 아니지만, Redis Cluster에서는 가용성을 높이기 위한 좋은 방법이다.

그래서 다시 그림 3을 보면 Master/Slave Node로 Master의 데이터를 복제한다.


Redis Cluster Persistence

Replication은 Fault Tolerance를 구성하기 위한 기법으로 사용된다. 그런데 Primary Node(Master Node)의 데이터가 여러 문제로 유지되지 못 할 수 있는 상황을 대비하여 Redis는 AOF/RDB 방식을 차용한다.

- AOF(Append Only Files) : 모든 쓰기 작업을 로그로 남김

- RDB : 데이터를 복사하여 secondary(또는 permanent) 저장소에 저장


Redis Cluster Data Sharding

Redis Cluster는 일관성 해싱(Consistent Hashing) 기법을 사용하지 않고 16,384의 Hash Slot을 사용한다.

그래서 아래와 같이 Node가 많아져도(물론 최대 개수는 존재한다.) 16,384의 슬롯 개수 한에서 분배된다.


Ex) 노드가 3개일 경우(A, B, C)

Node A 

 0 ~ 5500

Node B

5501 ~ 11000 

Node C

11001 ~ 16383 

 

Slot을 사용하기 때문에 Node를 추가/삭제하기가 쉽다. 그 이유는 특정 Slot만 재분배하면 되고, 모든 Node를 중단할 필요가 없기 때문이다.

추가적으로 Hash Slot의 키값을 얻기 위한 알고리즘은 아래와 같다.


HASH_SLOT = CRC16(key) mod 16384

uint16_t crc16(const char *buf, int len) {

    int counter;

    uint16_t crc = 0;

    for (counter = 0; counter < len; counter++)

            crc = (crc<<8) ^ crc16tab[((crc>>8) ^ *buf++)&0x00FF];

    return crc;



위의 알고리즘*을 사용하면 균등하게 키가 분배된다. (테스트에 따르면)

*간단한듯 보이지만 복잡하다. CRC16에 대한 자세한 부분은 참조 페이지를 확인하면 된다.


그림 4. Redis Cluster Hash Slot


그림 4를 확인해보면 Redis Cluster 환경에서 각 Node 안에서 Slot이 어떻게 포함되는지 확인 할 수 있다.

(Node 0에는 Slot 0 ~ 2, Node 1에서는 Slot 3 ~ 5)


그림 5. Master-Slave (Slave의 Slave를 구성)


그림 5의 Master-Slave를 포함하여 Hash Slot, Failover에 대해 생각해보면 다음과 같다. 

Redis Cluster를 구성할 때, 일반적으로 가용성을 위해 Master Node에 적어도 하나의 Slave Node를 추가한다. 그래서 Master Node A, B, C가 만들어지면 자동적으로 Slave Node A1, B1, C1가 만들어진다. 때문에 Node B(Slot 5501~11000)가 장애가 발생하면 Slave Node B1로 Failover 된다.


Reference

https://redis.io/topics/cluster-tutorial

https://redis.io/topics/cluster-spec

- https://redislabs.com/ebook/part-2-core-concepts/chapter-4-keeping-data-safe-and-ensuring-performance/4-2-replication/4-2-3-masterslave-chains/

- https://brandur.org/redis-cluster

https://www.slideshare.net/NoSQLmatters/no-sql-matters-bcn-2014

http://qnimate.com/overview-of-redis-architecture/


'IT > Database' 카테고리의 다른 글

MCC (Multiversion Concurrency Control)  (0) 2019.02.19
[Redis] Cluster Redirection  (0) 2019.01.06
[Redis] Partitioning  (0) 2018.12.10
Redis 성능에 영향을 끼치는 것  (0) 2018.07.16

댓글