개발/대용량트래픽

Redis Sentinel의 이해: 고가용성을 위한 모니터링 및 장애 조치 전략

난중후니 2024. 1. 25. 20:55
728x90
반응형

Sentinel 구조

기능

  • 모니터링(Monitoring) : Redis의 Master / Slave 가 정상 작동하고 있는지 지속적으로 감시

  • 알림(Notification) : Redis 가 failover 되었을 때 pub / sub 로 클라이언트에게 알려주거나 shell script 로 이메일이나 SMS로 클라이언트에게 알려준다.

    • Sentinel은 '"__sentinel__:hello"` 채널을 통해 pub / sub 메시지를 전송합니다. 클라이언트는 이 채널을 구독하여 Sentinel의 이벤트를 수신할 수 있습니다.
    • 주의할 점은 '"__sentinel__:hello"` 채널은 Sentinel의 상태 및 구성 정보를 주기적으로 공유하기 위한 주요 채널이기 때문에 failover 외의 다양한 메시지도 전달될 수 있습니다.
      • '"__sentinel__:hello"`을 통해 Sentinel들이 정보를 주고받고 동기화를 유지합니다.
      • 1. Sentinel 간 정보 교환 : Sentinel 인스턴스들은 이 채널을 통해 다른 Sentinel 인스턴스들에게 자신의 존재와 상태를 알립니다. 이를 통해 Sentinel 클러스터는 네트워크 내의 다른 Sentinel 인스턴스들의 정보를 알아낼 수 있습니다.
      • 2. 새로운 Master 알림 : Master Redis 인스턴스에 장애가 발생하여 Failover가 일어난 경우, 새로 승격된 Master의 정보를 '"__sentinel__:hello"` 채널을 통해 다른 Sentinel 인스턴스들에게 알립니다.
      • 3. Sentinel 클러스터 동기화 : 새로 시작되는 Sentinel 인스턴스는 '"__sentinel__:hello"` 채널을 통해 다른 Sentinel 인스턴스들의 정보를 얻어옵니다. 이 정보는 Sentinel 인스턴스의 내부 데이터베이스에 저장되며, 다른 Sentinel 인스턴스들의 주소와 상태를 파악하는데 사용됩니다.
    • Shell Script를 사용한 알림
      • Sentinel의 구성 파일에서는 'notification-script'를 설정하여, 특정 이벤트가 발생했을 때, 원하는 스크립트를 실행하게 할 수 있습니다.
      • 예를 들어, 스크립트 내에서 Email을 보내는 로직이나 SMS API를 호출하는 로직을 추가할 수 있습니다.
sentinel notification-script mymaster /path/to/your/script.sh
      • '/path/to/your/script.sh'는 실제로 실행될 스크립트의 경로입니다.

  • 자동 장애 조치(Automatic Failoover)

동작 방식

  • Sentinel 인스턴스 과반 수 이상이 Master 장애를 감지하면 Slave 중 하나를 Master로 승격시키고 기존의 Master는 Slave로 강등시킵니다.
    • 이 때, 어떤 Slave 서버가 Master로 승격될지를 결정하는 요소 중 하나가 redis.conf의 'replica-priority' 입니다.
    • replica-priority 값이 가장 작은 서버가 마스터에 선정됩니다.
    • replica-priority는 숫자이며 0으로 설정시 해당 Slave는 Master로 승격이 불가합니다.
    • ex) replica-priority = 5인 Slave와 replica-priority = 7인 Slave가 있을 때 replica-priority = 5인 Slave가 Master로 승격됩니다.
    • 만약, replica-priority가 동일한 값을 가지고 있다면, Redis Sentinel 엔진이 어떤 replica를 master로 승격할지를 내부적인 알고리즘과 메커니즘에 따라 선택합니다.
  • Slave가 여러 개 있을 경우 Slave가 새로운 Master로부터 데이터를 받을 수 있도록 재구성됩니다.

* 과반 수 이상으로 결정하는 이유는 만약 어느 Sentinel이 단순히 네트워크 문제로 Master와 연결되지 않는 경우, 실제 Master는 정상적이나 Sentinel이 Master가 다운되었다고 판단할 수 있기 때문입니다.

failover 감지 방법

  • SDOWN(Subjectively down) : 주관적 다운

    • Sentinel에서 주기적으로 Master에게 보내는 Ping과 info 명령의 응답이 3초(down-after-milliseconds 에서 설정한 값) 동안 오지 않는다면, 주관적 다운으로 인지
    • Sentinel 1대에서 판단한 것으로, 주관적 다운만으로는 장애조치를 진행하지 않습니다.

  • ODOWN(Objectively down) : 객관적 다운

    • 설정한 quorum 이상의 Sentinel 에서 해당 Master가 다운되었다고 인지하면 객관적 다운으로 인정하고 장애 조치를 진행합니다.

failover 시 알아두면 좋은 점

  1. get-master-addr-by-name
  • Master, Slave 모두 다운되었을 때, Sentinel에 접속하여 Master 서버 정보를 요청하면 다운된 서버 정보를 리턴합니다. 따라서 info sentinel 명령으로 Master status를 확인해야 합니다.
  • get-master-addr-by-name은 주어진 Master 이름에 대응하는 현재의 Master 서버의 IP 주소와 Port 번호를 반환합니다.
  • get-master-addr-by-name 사용 방법
# 여기서 <master-name>은 Sentinel 설정에서 정의한 Master의 이름입니다.
# 응답결과는 첫번째 줄이 Master의 IP, 두번째 줄이 Port 입니다.
sentinel get-master-addr-by-name <master-name>

2. Slave 다운 -> Master 다운 -> 다운된 Slave 재시작시 Master로 전환되지 않습니다.

  • Slave의 redis.conf에는 자신이 Slave라고 설정되어 있고, Sentinel도 복제라고 인식하고 있기 때문에 Master로 전환되지 않습니다.
  • Master로 전환하기 위해서는 Slave가 시작되기 전에 redis.conf에서 slaveof를 삭제하면 됩니다.

3. failover timeout 만큼 write 연산 실패할 때 Master가 다운되었다고 간주

  • Redis Sentinel 설정에서 'failover timeout'은 Sentinel이 Master 서버의 장애를 감지한 후 얼마나 오랜시간 대기할지 결정하는 시간 값입니다. 이 시간이 지나면 Master가 다운되었다고 간주하고 승격 프로세스(Slave -> Master)를 시작합니다.

Sentinel 에서 알아두면 좋은 점

1. Quorum

  • Redis 장애 발생시 몇 개의 Sentinel이 특정 Redis의 장애 발생을 감지해야 장애라고 판별하는지를 결정하는 기준 값입니다. 보통 과반 수 이상으로 설정합니다.

2. Sentinel은 1차 복제만 Master 후보에 오를 수 있습니다.

  • Slave 의 Slave는 Master 후보에 오를 수 없습니다.

3. 1차 복제 중 replica-priority 값이 가장 작은 서버가 마스터에 선정됩니다. 0으로 설정하면 Master로 승격이 불가능 하고 동일한 값이 있을 때는 내부 알고리즘과 엔진에 의해 선택됩니다.

4. 안정적인 운영을 위해 3개 이상의 Sentinel을 운영하는 것을 권장하며, 물리적으로 영향받지 않는 컴퓨터나 가상 머신에 설치되는 것이 좋습니다.

5. Sentinel은 내부적으로 Pub / Sub 기능을 사용해서 정보를 주고 받습니다.

6. Sentinel + Redis 구조의 분산 시스템은 레디스가 비동기 복제를 사용하기 때문에 장애가 발생하는 동안 썼던 내용들에 대한 보장성이 없습니다.

  • Redis의 비동기 복제
    • Redis는 기본적으로 비동기 방식으로 데이터를 Master에서 Slave(Replica)로 복제합니다.
    • Master에서 쓰기 연산이 일어나면, 그 연산은 즉시 Master의 데이터에 적용되고, 거의 동시에 Slave로 전송되기 시작합니다. 그러나 "즉시"라는 것이 항상 "동시"에 라는 것을 의미하는 것이 아니기 때문에 해당 데이터는 Slave에 도달하지 못할 수 있습니다.

7. 클라이언트는 주어진 서비스를 담당하는 현재 Redis Master의 주소를 요청하기 위해 Sentinel에 연결합니다. 장애 조치가 발생하면 Sentinel은 새 주소를 클라이언트에게 알려줍니다.

728x90
반응형
저작자표시