.png&blockId=7628ec0c-1357-4c37-a1e9-32a282f6efaa)
.png&blockId=be06ed4d-0152-4f0f-b4b4-821bd1fb30d9)
.png&blockId=39a86e12-3cf4-40df-8d5e-9891c5adc274)
_%25E1%2584%2587%25E1%2585%25A9%25E1%2586%25A8%25E1%2584%2589%25E1%2585%25A1%25E1%2584%2587%25E1%2585%25A9%25E1%2586%25AB.png&blockId=891e6648-1148-4e7c-bfcd-0463dc71545c)
.png&blockId=5e737e69-4f36-437b-95e0-7db747173000)
.png&blockId=5294c22e-8cee-4109-963f-c8cfe8c852cf)
Sentinel
•
Sentinel의 기능 및 역할
•
모니터링 : Master / Slave 가 제대로 동작하고 있는지 지속적 감시
•
자동 장애조치
◦
SDOWN(Subjectively down - 주관적 다운)-> Sentinal에서 주기적으로 Master에게 보내는 PING과 INFO 명령의 응답이 3초(down-after-milliseconds 에서 설정한 값) 동안 오지 않으면 주관적 다운으로 인지-> 센티널 한 대에서 판단한 것으로, 주관적 다운만으로는 장애조치를 진행하지 않는다
◦
ODOWN(Objectively down - 객관적 다운)-> 설정한 quorum 이상의 Sentinal에서 해당 Master가 다운되었다고 인지하면 객관적 다운으로 인정하고 장애 조치를 진행합니다.
•
알림 : failover되었을 때 pub/sub으로 client에게 알리거나, shell script로 이메일이나 sms 알림
용어
quorum : Redis 장애 발생시 몇 개의 Sentinel이 특정 Redis의 장애 발생을 감지해야 장애라고 판별하는지를 결정하는 기준 값. 보통 redis의 과반 수 이상으로 설정
•
동작 방식
◦
Sentinal 인스턴스 과반 수 이상이 Master 장애를 감지하면 Slave 중 하나를 Master로 승격시키고 기존의 Master는 Slave로 강등
◦
Slave가 여러개 있을 경우 Slave가 새로운 Master로부터 데이터를 받을 수 있도록 재구성
failover시의 주의사항
•
get-master-addr-by-name : Master, Slave 모두 다운되었을 때 Sentinel에 접속해 Master 서버 정보를 요청하면 다운된 서버 정보를 리턴-> INFO sentinel 명령으로 마스터의 status를 확인
•
Slave -> Master 승격 안되는 경우 → 1차 복제만 Master 후보가 될 수 있기 때문
◦
Slave다운 → Master다운 → 다운된 Slave재시작되면 이 서버는 Master로 전환되지 않는다.
◦
Slave의 redis.conf에 자신이 복제로 되어 있고, sentinel도 복제라고 인식하고 있기 때문이다. 해결책은 Slave가 시작하기 전에 redis.conf에서 slaveof를 삭제
•
Failover Timeout 만큼 write 연산 실패
◦
데이터량에 따른 최적의 Failover Timeout값을 찾고 sentinel.conf에 적용해야 함
기타 동작 방식
•
Sentinel은 1차 복제만 Master 후보에 오를 수 있다. ( 복제 서버의 복제 서버는 불가능 )
-> 위 경고의 2번째 항목의 이유
•
1차 복제 서버 중 replica-priority 값이 가장 작은 서버가 마스터에 선정된다. 0으로 설정하면 master로 승격 불가능하고 동일한 값이 있을 땐 엔진에서 선택
•
안정적 운영을 위해 3개 이상의 Sentinal을 만드는 것을 권장
•
센티널 + 레디스 구조의 분산 시스템은 레디스가 비동기 복제를 사용하기 때문에 장애가 발생하는 동안 썼던 내용들이 유지됨을 보장할 수 없다. → Cluster도 마찬가지
•
클라이언트는 주어진 서비스를 담당하는 현재 레디스 마스터의 주소를 요청하기 위해 센티널에 연결한다. 장애 조치가 발생하면 센티널은 새 주소를 알려준다
Cluster
•
Cluster의 기능 및 역할
◦
샤딩 (sharding) : 데이터를 분산 저장
◦
자동 장애조치
▪
SDOWN(Subjectively down - 주관적 다운)-> Sentinal에서 주기적으로 Master에게 보내는 PING과 INFO 명령의 응답이 3초(down-after-milliseconds 에서 설정한 값) 동안 오지 않으면 주관적 다운으로 인지-> 센티널 한 대에서 판단한 것으로, 주관적 다운만으로는 장애조치를 진행하지 않는다
▪
ODOWN(Objectively down - 객관적 다운)-> 설정한 quorum 이상의 Sentinal에서 해당 Master가 다운되었다고 인지하면 객관적 다운으로 인정하고 장애 조치를 진행합니다.
•
동작 방식
◦
해시 슬롯을 이용해 데이터를 샤딩
▪
cluster는 총 16384개의 해시 슬롯이 있으며 각 Master 노드에 자유롭게 할당 가능-> ex) Master 노드가 3개일 경우 1번 노드는 05460, 2번 노드는 546110922, 3번 노드는 10923~16383 의 슬롯할당
▪
Master가 죽을 경우 Master의 Slave는 gossip Protocol을 통해 Master의 죽음을 파악하고, Slave중 하나가 Master로 승격된다 → 중단없는 서비스 제공
▪
기존 Master가 다시 살아나면 새로운 Master의 Slave가 된다
용어
•
샤딩 (sharding) : 데이터를 분산 저장하는 방식
•
해시 슬롯 : CRC-16 해시 함수를 이용해 key를 정수로 변환하고 해당 정수값을 16,385로 모듈 연산한 값
주의사항
•
failover가 발생한다면, 슬레이브가 마스터로 승격할 때까지, 문제가 발생한 마스터로 할당된 슬롯의 키는 사용할 수 없다.
•
키 이동 시에 해당 키에 잠시 락이 걸릴 수 있다
•
Replication은 Async방식으로 이루어지기 문에 data 정합성이 깨질 수 있는데 이때 나중에 Master가 된 Data를 기준으로 정합성을 맞춘다
기타 동작 방식
•
Cluster Bus Port
•
보통 Client와 Redis의 port는 6379, Cluster에서 Gossip Protocol을 위해 사용하는 Port가 16379
•
Multi-master, Multi-slave 구조, 1000대의 노드까지 확장 가능
•
모든 데이터는 Master 단위로 샤딩되고 Slave 단위로 복제
•
Slave가 하나도 없을 때 Master 노드가 작동이 안되면 해당 데이터 유실 발생
Gossip Protocol
•
node-to-node 통신
•
분산형 시스템간 서로의 통신을 위해 자주 사용
•
각 노드간 비동기 통신을 진행하기 때문에, 신뢰성은 보장되지 않음
•
클라이언트가 redis에 데이터를 요청했을 때, 올바르지 않은 master node에 요청하면 해당 데이터가 저장된 위치를 알려주고 client에게 알려주고 client는 제대로 된 주소에 다시 요청
결론
•
Cluster 사용
•
Sentinel 은 마스터를 하나 사용하며, 스케일 아웃이 불가능 (서버 성능을 향상시키는 Scale Up은 가능)
•
Cluster는 스케일 아웃이 가능
•
사용하는 redis 메모리가 굉장히 커질 수 있으며 데이터의 안정성 보장이 필수적으로 보장하기 위해 프로젝트에 맞게 사용하는 것을 권장