Redis 는 단일 인스턴스로도 운영 가능하지만 물리 머신이 가진 메모리의 한계를 초과하는 데이터를 저장하고 싶거나, failover에 대한 처리를 통해 HA를 보장하려면 Sentinel이나 Cluster 등의 운영 방식을 선택해서 사용해야 한다.
가장 많이 사용되는 운영 방식인 Sentinel과 Cluster를 알아보자

Sentinel

기능

모니터링(Monitoring) : Master/Slave 제대로 동작하는지 지속적으로 감시
자동 장애 조치(Automatic Failover) : 하단 설명
알림(Notification) : failover 되었을 때 pub/sub으로 client에게 알리거나, shell script로 이메일이나 sms를 보낼 수 있다

Sentinal 인스턴스 과반 수 이상이 Master 장애를 감지하면 Slave 중 하나를 Master로 승격시키고 기존의 Master는 Slave로 강등시킨다
Slave가 여러개 있을 경우 Slave가 새로운 Master로부터 데이터를 받을 수 있도록 재구성된다
과반 수 이상으로 결정하는 이유는 만약 어느 sentinel이 단순히 네트워크 문제로 master와 연결되지 않을 수 있는데, 그때 실제로 Master는 다운되지 않았으나 연결이 끊긴 sentinel은 Master가 다운되었다고 판단할 수 있기 때문이다

SDOWN : Subjectively down(주관적 다운)
- Sentinal에서 주기적으로 Master에게 보내는 PING과 INFO 명령의 응답이 3초(down-after-milliseconds 에서 설정한 값) 동안 오지 않으면 주관적 다운으로 인지
- 센티널 한 대에서 판단한 것으로, 주관적 다운만으로는 장애조치를 진행하지 않는다

ODOWN : Objectively down(객관적 다운)
- 설정한 quorum 이상의 Sentinal에서 해당 Master가 다운되었다고 인지하면 객관적 다운으로 인정하고 장애 조치를 진행합니다.

get-master-addr-by-name
Master, Slave 모두 다운되었을 때 Sentinel에 접속해 Master 서버 정보를 요청하면 다운된 서버 정보를 리턴한다. 따라서 INFO sentinel 명령으로 마스터의 status를 확인해야 한다.
Slave -> Master 승격 안되는 경우
Slave다운 → Master다운 → 다운된 Slave 재시작되면 이 서버는 Master로 전환되지 않는다. Slave의 redis.conf에 자신이 복제로 되어 있고, sentinel도 복제라고 인식하고 있기 때문이다. 해결책은 Slave가 시작하기 전에 redis.conf에서 slaveof를 삭제하는 것이다.
Failover Timeout 만큼 write 연산 실패
데이터량에 따른 최적의 Failover Timeout값을 찾고 sentinel.conf에 적용해야 한다.

Quorum : Redis 장애 발생시 몇 개의 Sentinel이 특정 Redis의 장애 발생을 감지해야 장애라고 판별하는지를 결정하는 기준 값. 보통 redis의 과반 수 이상으로 설정한다
Sentinel은 1차 복제만 Master 후보에 오를 수 있다. ( 복제 서버의 복제 서버는 불가능 )
1차 복제 서버 중 replica-priority 값이 가장 작은 서버가 마스터에 선정된다. 0으로 설정하면 master로 승격 불가능하고 동일한 값이 있을 땐 엔진에서 선택한다
안정적 운영을 위해 3개 이상의 Sentinal을 만드는 것을 권장하는데, 서로 물리적으로 영향받지 않는 컴퓨터나 가상 머신에 설치되는 것이 좋다
sentienl은 내부적으로 redis 의 Pub/Sub 기능을 사용해서 서로 정보를 주고받는다
센티널 + 레디스 구조의 분산 시스템은 레디스가 비동기 복제를 사용하기 때문에 장애가 발생하는 동안 썼던 내용들이 유지됨을 보장할 수 없다.
Sentinel을 Redis와 동일한 Node에 구성해도 되고, 별도로 구성해도 된다
클라이언트는 주어진 서비스를 담당하는 현재 레디스 마스터의 주소를 요청하기 위해 센티널에 연결한다. 장애 조치가 발생하면 센티널은 새 주소를 알려준다

해시 슬롯을 이용해 데이터를 샤딩한다
- 샤딩 : 데이터를 분산 저장하는 방식
- 해시 슬롯 : CRC-16 해시 함수를 이용해 key를 정수로 변환하고 해당 정수 값을 16,385로 모듈 연산한 값
- cluster는 총 16384개의 해시 슬롯이 있으며 각 Master 노드에 자유롭게 할당 가능
- ex) Master 노드가 3개일 경우 1번 노드는 0~5460, 2번 노드는 5461~10922, 3번 노드는 10923~16383의 슬롯 할당
Master가 죽을 경우 Master의 Slave는 gossip Protocol을 통해 Master의 죽음을 파악하고, Slave 중 하나가 Master로 승격된다 → 중단 없는 서비스 제공
- gossip Protocol : 각 Redis는 다른 Redis들과 직접 연결하여 상태 정보를 통신
기존 Master가 다시 살아나면 새로운 Master의 Slave가 된다

sentinel보다 더 발전된 형태
Multi-master, Multi-slave 구조
1000대의 노드까지 확장 가능
모든 데이터는 Master 단위로 샤딩되고 Slave 단위로 복제된다.
Master 마다 최소 하나의 Slave를 두는 것을 추천한다. Slave가 하나도 없을 때 Master 노드가 작동이 안 되면 해당 데이터 유실 발생
노드를 추가/삭제할 때 운영 중단 없이 Hash slot을 재구성할 수 있다
failover가 발생한다면, 슬레이브가 마스터로 승격할 때까지, 문제가 발생한 마스터로 할당된 슬롯의 키는 사용할 수 없다.
키 이동 시에 해당 키에 잠시 락이 걸릴 수 있다
과반수 이상의 노드가 다운되면 cluster가 깨진다
Replication은 Async방식으로 이루어지기 문에 data 정합성이 깨질 수 있는데 이때 나중에 Master가 된 Data를 기준으로 정합성을 맞춘다
cluster redis는 2개의 포트가 필요하다 (클라이언트를 위한 포트, 노드 간 통신 버스 포트 )
gossip Protocol은 Redis Client가 이용하는 Port번호보다 10000 높은 port 번호를 이용
클라이언트가 redis에 데이터를 요청했을 때, 올바르지 않은 master node에 요청하면 해당 데이터가 저장된 위치를 알려주고 client에게 알려주고 client는 제대로 된 주소에 다시 요청한다

Cluster를 사용하자!!!
sentinel은 One Master 구조이기 때문에 데이터 사이즈가 커지면 스케일 업을 해야 하는데, cluster는 스케일 아웃이 가능하다.
추후 확장성을 위해 Cluster를 사용하는 것이 좋다