본문 바로가기
Database/NoSQL

[Redis] Cluster vs Sentinel

by junseokoo 2025. 4. 11.

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 에서 설정한 값) 동안 오지 않으면 주관적으로 다운으로 인지
        • 센티넬 한 대에서 판단한 것으로, 주관적 다운만으로는 장애조치를 진행하지 않는다.
    • ODOWN
      • Objectively down (객관적 다운)
      • 설정한 quorum이상의 Sentinel 에서 해당 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에 구성해도 되고, 별도로 구성해도 된다
    • 클라이언트는 주어진 서비스를 담당하는 현재 레디스 마스터의 주소를 요청하기 위해 센티널에 연결한다. 장애 조치가 발생하면 센티널은 새 주소를 알려준다

Cluster

  • 기능
    • 자동 장애 조치 (Automatic Failover)
    • 샤딩 (Sharding)
      • 데이터를 분산 저장
  • 동작 방식
    • 해시 슬롯을 이용해 데이터를 샤딩한다
    • 샤딩
      • 데이터를 분산 저장하는 방식
    • 해시슬롯
      • CRC-16 해시 함수를 이용해 key를 정수로 변환하고 해당 정수값을 16,385로 모듈 연산한 값
      • cluster는 총 16384개의 해시 슬롯이 있으며 각 Master 노드에 자유롭게 할당 가능
      • Master 노드가 3개일 경우 1번 노드는 05460 , 2번 노드는 546110922,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는 제대로 된 주소에 다시 요청한다.

결론

  • 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