1. 개요

2. 레디스 고가용성

2.1. failover

기본적인 Auto failover는 센티넬이 처리할 수 있다. (레디스 노드 수준의 restart는 쿠버네티스로 가능)

2.2. 클러스터

레디스 클러스터를 반드시 사용해야 하는가? 물론 성능 때문에 꼭 사용하지 않는 경우도 있다. 

2.3. 레디스 클러스터의 키-슬롯-노드 할당

레디스 클러스터는 10~16383까지, 총 16384개의 슬롯을 사용한다. 이 슬롯들은 클러스터 초기에 각 노드에 적절히 할당된다.

• Redis#1 : 0 ~ 5460
• Redis#2 : 5461 ~ 10922
• Redis#3 : 10923 ~ 16383

데이터가 어떤 슬롯에 저장되어야 하는지는 HASH_SLOT = CRC16(key) mod 16384 라는 정해진 식에 의해 결정되며, 각 노드는 다른 노드에서 어떤 슬롯을 할당 중인지 안다. 따라서 내가(노드가) 관리하고 있는 데이터가 아니라면 해당 데이터 주인이 되는 노드로 리다이렉션한다. 

HASH_SLOT = CRC16(key) mod 16384 은 CRC16 펑션을 통해 나온 해시 코드를 전체 슬롯 크기인 16384로 나눈다. 그럼 0부터 16383 사이의 나머지가 나오는데 그 값이 키에 해당하는 슬롯 번호이다. aaa라는 키를 저장한다면 CRC16("aaa") mod 16384 를 수행하고, 그 값이 1000이라고 할 때, 1000은 0 ~ 5460 범위에 속하므로 Redis#1에 저장된다.

만약 노드가 추가/삭제된다면 슬롯과 데이터를 재분배하는 상황이 발생하는데, 이때 Reshard/Rebalance 기능이 사용된다.

2.4. 노드 추가

키 값이 변하지 않으면 해시 코드 값도 변하지 않기 때문에 3으로 나눈 나머지도 항상 같은 결과가 나올 것이다. 

그런데 3개 노드에서 4개 노드로 증가한다고 가정하면 이전에는 해시 코드를 3으로 나누었지만, 노드 증가 후에는 해시 코드를 4로 나누어야 하고, 최종적으로는 저장되는 노드가 변하게 된다. 그리고 캐시 재구축을 위한 데이터의 대이동이 발생한다. 이미 운영시스템에서 캐시가 활발히 사용 중이라면 시스템에 문제가 발생할 것이다.

3. Consistent Hashing

1997년 개발된 알고리즘이다. 처음에는 웹 캐시를 구현하기 위해 개발되었으며 캐시 노드의 추가/삭제와 무관하게 높은 웹 히트율을 보장한다.

이는 앞서 레디스 노드의 추가로 인한 이슈를 해결하기 위한 방법으로도 사용된다. Consistent Hashing을 적용하면 노드 추가 시 데이터 재할당이 최소화된다. 

Consistent Hashing을 적용하지 않으면 모든 키가 재매핑되어야 하지만, 적용 시에는 이론적으로 해시 테이블의  크기가 변할 때 (노드가 추가/삭제되면) 평균적으로 K/n의 키만 재매핑된다. (K는 아이템 수, n은 노드 수)