
Sentinel
- 기능
- 모니터링
- Master/Slave 제대로 동작하는지 지속적 감시
- 자동 장애 조치
- 하단 설명
- 알림
- failover 되었을 때 pub/sub 으로 Client에 알리거나, shell script로 이메일이나 sms를 보낼 수 있다.
- Sentinel을 홀수 대로 구성해야 한다.
- Redis가 Master를 승격하는 과정에서 투표를 하게되는데, 다수결로 Master 승격 여부를 결정할 수 있기 때문에 홀수로 구성해야한다. 짝수로 구성하게되면 auto failover를 하지 못하게 될 수 있다.
- 모니터링
- 동작 방식
- Sentinel 인스턴스 과반 수 이상이 Master 장애를 감지하면 Slave 중 하나를 Master로 승격시키고 기존의 Master는 Slave로 강등시킨다.
- Slave가 여러개 있을 경우 Slave가 새로운 Maste로부터 데이터를 받을 수 있도록 재구성된다.
- 과반 수 이상으로 결정하는 이유는 만약 어느 sentinel이 단순이 네트워크 문제로 master와 연결되지 않는 경우일 수도 있는데, 그 때 실제로 Master는 다운되지 않았으나 연결이 끊긴 sentinel은 Master가 다운되었다고 판단할 수 있기 때문이다.
- failover 감지 방법
- SDOWN
- Subjectively down (주관적 다운)
- Sentinel 에서 주기적으로 Master에게 보내는 PING 과 INFO 명령의 응답이 3초(down-after-milliseconds 에서 설정한 값) 동안 오지 않으면 주관적으로 다운으로 인지
- 센티넬 한 대에서 판단한 것으로, 주관적 다운만으로는 장애조치를 진행하지 않는다.
- Subjectively down (주관적 다운)
- ODOWN
- Objectively down (객관적 다운)
- 설정한 quorum이상의 Sentinel 에서 해당 Master가 다운되었다고 인지하면 객관적으로 다운으로 인정하고 장애 조치를 진행
- SDOWN
- 주의사항
- 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 에 적용해야 한다.
- get-master-addr-by-name
- 기타
- Quorum
- Redis장애 발생시 몇 개의 Sentinel 이 특정 Redis의 장애 발생을 감지해야 장애라고 판별하는지를 결정하는 기준 값. 보통 redis의 과반 수 이상으로 설정
- Sentinel은 1차 복제만 Master 후보에 오를 수 있다. ( 복제 서버의 복제 서버는 불가능 )
- 1차 복제 서버 중 replica-priority 값이 가장 작은 서버가 마스터에 선정된다. 0으로 설정하면 master로 승격 불가능하고 동일한 값이 있을 땐 엔진에서 선택한다
- 안정적 운영을 위해 3개 이상의 Sentinal을 만드는 것을 권장하는데, 서로 물리적으로 영향받지 않는 컴퓨터나 가상 머신에 설치되는 것이 좋다
- sentienl은 내부적으로 redis 의 Pub/Sub 기능을 사용해서 서로 정보를 주고 받는다
- 센티널 + 레디스 구조의 분산 시스템은 레디스가 비동기 복제를 사용하기 때문에 장애가 발생하는 동안 썼던 내용들이 유지됨을 보장할 수 없다.
- Sentinel을 Redis와 동일한 Node에 구성해도 되고, 별도로 구성해도 된다
- 클라이언트는 주어진 서비스를 담당하는 현재 레디스 마스터의 주소를 요청하기 위해 센티널에 연결한다. 장애 조치가 발생하면 센티널은 새 주소를 알려준다
- Quorum
Cluster
- 기능
- 자동 장애 조치 (Automatic Failover)
- 샤딩 (Sharding)
- 데이터를 분산 저장
- 동작 방식
- 해시 슬롯을 이용해 데이터를 샤딩한다
- 샤딩
- 데이터를 분산 저장하는 방식
- 해시슬롯
- CRC-16 해시 함수를 이용해 key를 정수로 변환하고 해당 정수값을 16,385로 모듈 연산한 값
- cluster는 총 16384개의 해시 슬롯이 있으며 각 Master 노드에 자유롭게 할당 가능
- Master 노드가 3개일 경우 1번 노드는 0
5460 , 2번 노드는 546110922,3번 노드는 10923~16383 의 슬롯 할당
- Master 가 죽을 경우 Master의 Slave는 gossip Protocol을 통해 Master의 죽음을 파악하고, Slave 중 하나가 Master로 승격된다 → 중단없는 서비스 제공
- gossip Protocol
- 각 Redis는 다른 Redis들과 직접 연결하여 상태 정보를 통신
- gossip Protocol
- 기존 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는 제대로 된 주소에 다시 요청한다.
결론
- sentinel은 One Master 구조이기 때문에 데이터 사이즈가 커지면 스케일 업을 해야하는데, cluster는 스케일 아웃이 가능하다. 추후 확장성을 위해 Cluster를 사용하는 것이 좋다.
- 클러스터 방식은 간단하게 말해 여러개의 Master 노드 구성된 구조이다. 즉 , Read/Write 를 모두 사허용하는 Master를 여러대 두고 데이터 자체를 분산해서 저장/관리 하는 방식이다. 샤딩 기법이 사용되기 때문에 각 노드를 샤드라고 명명하기도 한다.
- 센티넬 구조는 HA는 보장되지만 하나의 Master 노드에 모든 데이터가 저장되어야 하기 때문에 물리 장비의 스펙에 영향을 받을 수 밖에 없고 Replication 되는 Slave노드도 상황은 마찬가지이다. 즉, 데이터가 많아질 경우 Scale Up밖에 도리가 없다.
- 반면 클러스터는 데이터 자체를 샤딩해서 저장하기 때문에 상황에 따라 Scale UP, Scale Out 모두 적용할 수 있고 트래픽 분산효과도 덤으로 가지고 갈 수 있다.
- 다만 각 Master 에서 서로다른 데이터를 관리하는 만큼 HA도 각각 구성되어야 한다. 일반적으로 Master 별로 1~2대의 Slave를 두어 Replication 되도록 하고 Master가 죽으면 연결된 Slave 노드가 Master 노드로 전환된다ㅏ. 이는 Sentinel 과 비슷한것 같지만 별도의 솔루션이다.
'Database > NoSQL' 카테고리의 다른 글
| [Redis] Intro (0) | 2024.11.28 |
|---|