Sentinel(센티널)

레디스는 따로 백업 설정을 하지 않으면 모든 데이터가 사라지게 되고 서비스 전체 장애로 이어지게 되는데, 이를 방지하기 위해 레디스는 센티넬이라는 고가용성 솔루션을 제공한다.

  • 모니터링: 마스터 / 복제본 인스턴스 상태 실시간 확인

  • 자동 페일오버: 마스터의 비정상 상태를 감지해 복제본 중 하나를 새로운 마스터로 승격

  • 인스턴스 구성 정보 안내: 센티넬은 클라이언트에게 현재 구성의 마스터 인스턴스 정보를 제공하여, 클라이언트가 자동으로 마스터 인스턴스를 찾을 수 있도록 지원

분산 시스템에서의 센티널

센티널 네트워크를 통해 모니터링 결과와 장애 감지 정보를 공유하며, 특정 노드에 장애가 발생했다고 판단될 때 다수의 센티널이 이에 동의해야만 페일오버 절차를 시작한다.

쿼럼(Quorum)

쿼럼은 마스터 노드가 장애 상태임을 객관적으로 판단하기 위해 최소 몇 개의 센티널이 해당 마스터를 도달 불가능하다고 동의해야 하는지를 의미한다.

  • 일반적으로 쿼럼 수는 센티널 인스턴스의 과반수 이상으로 설정하는 것이 권장

  • 3대의 센티널이 운영 중이라면 쿼럼은 2 이상으로 설정해, 최소 2개의 센티널이 장애를 감지하면 실제 장애로 판단

  • 실제 페일오버를 수행은 리더 센티널이 담당 수행

    • 쿼럼은 장애 감지에만 사용되며, 실제 페일오버를 수행하기 위해서는 센티넬 프로세스의 과반수가 동의한 센티널 리더가 페일오버를 수행

Redis 센티널의 고가용성을 확보하기 위해서는 센티널 인스턴스를 다음과 같이 분산 배포하는 것이 중요하다.

  • 서버 및 가용 영역 분산: 각 인스턴스는 서로 다른 물리적 서버 또는 가용 영역에 배포

  • 최소 3대 이상의 센티널 인스턴스 운영: 쿼럼을 이용한 과반수 선출 개념을 사용하기 때문에 3대 이상의 홀수로 구성을 권장

센티널 인스턴스 배치 방법

안정적인 고가용성 환경을 구축하려면, 센티넬 인스턴스는 최소 3대 이상의 홀수로 구성하고, 각 인스턴스는 서로 다른 물리적 서버나 가용 영역(Availability Zone)에 분산하여 배포해야 한다.

  • 각 서버에는 하나의 Redis 인스턴스(마스터 또는 레플리카)와 하나의 센티널 인스턴스를 함께 배치

  • 센티널 인스턴스가 서로 다른 서버에 위치하게 되어, 서버 장애 시에도 센티널 다수결(쿼럼)을 통한 장애 감지 및 자동 페일오버 가능

  • 구성 예시(3 Servers)

    • Server A: Redis Master + Sentinel

    • Server B: Redis Replica (Slave) + Sentinel

    • Server C: Redis Replica (Slave) + Sentinel

자동 페일오버 과정

  1. 마스터 장애 상황 감지

    • 각 센티널은 주기적으로 PING 명령어를 사용하여 마스터 노드의 상태를 확인

    • down-after-milliseconds 기간 동안 응답이 없거나 비정상 응답이면 해당 센티널은 sdown 상태(subjectively down)로 판단

  2. sdown -> odown 실패 상태로 전환

    • sdown을 감지한 센티넬은 다른 센티널 노드들에게 장애 사실을 전파

    • 전파를 받은 센티널들은 해당 마스터에 대한 상태를 확인하고, 쿼럼 값 이상의 센티널이 동의하면 odown 상태(objectively down)로 전환

  3. 에포크(epoch) 증가

    • 장애가 확정되면 각 센티널은 페일오버를 위한 새로운 에포크(epoch) 값을 증가시켜 고유한 페일오버 시도를 구분

    • odown이 확정되면 각 센티널은 새로운 페일오버 라운드를 구분하기 위해 current-epoch를 증가(처음엔 1)

    • 각 센티널은 해당 에포크에서 한 후보에게만 투표할 수 있으며, 에포크 값은 서로 다른 페일오버 시도를 식별하는 버전 역할 수행

  4. 센티널 리더 선출

    • 센티널들은 동일 에포크에서 리더가 될 의사를 표명하고 상호 투표 수행

    • 과반수의 표를 얻은 센티널이 리더가 됨

  5. 복제본 선정 및 마스터 승격

    • 리더 센티널은 후보 복제본들 중 승격 대상을 선정

      • redis.conf 파일에 명시된 replica-priority 낮은 복제본

      • 마스터로부터 많은 데이터를 수신한 복제본

    • 선정한 복제본에 SLAVEOF NO ONE 명령어를 수행해, 기존 마스터로부터 복제를 중단

  6. 복제 연결 변경

    • 나머지 복제본들에 REPLICAOF <new-master-ip> <port>를 전송해 새 마스터를 따라가도록 재구성

스플릿 브레인(Split Brain)

스플릿 브레인은 네트워크 단절(Network Partition)로 인해 분산 시스템이 두 개 이상의 독립적인 그룹으로 나뉘고, 각 그룹이 자신이 유일한 정상 그룹이라고 착각하여 발생하는 문제다.

  • 센티널 환경에서 스플릿 브레인이 발생하면, 네트워크가 분리된 각 파티션 내의 센티널들이 서로 통신하지 못하게 됨

  • 각 파티션이 독립적으로 장애를 감지하고 페일오버를 수행할 수 있음

  • 결과적으로 두 개 이상의 마스터가 동시에 존재하는 상황 발생

  • 최종적으로 두 마스터 간 데이터 불일치 및 데이터 유실로 이어질 수 있음

네트워크 파티션으로 인해 Partition A(마스터 + Sentinel A)와 Partition B(레플리카 2대 + Sentinel B, Sentinel C)로 나뉘는 상황의 예시는 다음과 같다.

+---------------------------+             +---------------------------+
|        Partition A        |             |        Partition B        |
|                           |             |                           |
|  +---------------------+  |             |  +---------------------+  |
|  | Sentinel A          |  |             |  | Sentinel B          |  |
|  +---------------------+  |             |  +---------------------+  |
|  +---------------------+  |             |  +---------------------+  |
|  | Redis Master        |  |             |  | Redis Replica       |  |
|  +---------------------+  |             |  +---------------------+  |
|                           |             |  +---------------------+  |
|                           |             |  | Sentinel C          |  |
|                           |             |  +---------------------+  |
|                           |             |  +---------------------+  |
|                           |             |  | Redis Replica       |  |
|                           |             |  +---------------------+  |
+---------------------------+             +---------------------------+
  • 네트워크 단절 상황

    • 마스터 노드와 Sentinel A가 포함된 네트워크 영역 A, 복제본 노드 2대와 Sentinel B, Sentinel C가 포함된 네트워와 영역 B) 간 네트워크 단절 발생

    • 두 네트워크 영역은 서로를 인식하지 못함

  • 센티널 동작 과정

    • Sentinel B와 Sentinel C는 마스터 노드에 접근하지 못해 마스터를 비정상으로 판단하고 Failover를 시작

    • 과반수(3대 중 2대)인 Sentinel B와 C가 같은 파티션에 있어 복제본 중 하나를 새로운 마스터로 승격

  • 스플릿 브레인 발생

    • 네트워크 단절이 지속되는 동안 기존 마스터(Partition A)와 새로 승격된 마스터(Partition B)가 동시에 마스터 역할 수행

    • 두 개의 독립 마스터가 존재하면서 데이터 불일치 발생

+------------------------------------------------------------+
|                          클라이언트 연결                       |
+------------------------------------------------------------+
|                                                            |
|       기존 클라이언트                   새로운 클라이언트          |
|                                                            |
|  +-------------------+          +-------------------+      |
|  |                   |          |                   |      |
|  | 기존 마스터 (A)      |          | 새로운 마스터 (B)    |      |
|  |                   |          |                   |      |
|  +---------+---------+          +---------+---------+      |
|            |                              |                |
|            |                              |                |
|  +---------v---------+          +---------v---------+      |
|  | Sentinel A        |          | Sentinel B, C     |      |
|  +-------------------+          +-------------------+      |
|                                                            |
+------------------------------------------------------------+
  • 기존 연결된 클라이언트의 동작

    • 기존 마스터에 연결된 클라이언트는 네트워크 단절의 영향을 받지 않으면 계속 기존 마스터에 쓰기를 수행

    • 기존 마스터의 데이터는 승격된 새로운 마스터와 동기화되지 않음

  • 새로운 클라이언트의 동작

    • 새로운 클라이언트는 Sentinel에 현재 마스터 주소를 요청

    • 단절 상황에서 Sentinel B/C는 승격된 새 마스터의 주소를 반환하므로, 새로운 클라이언트는 새 마스터에 쓰기를 수행

  • 네트워크 복구 후

    • 네트워크가 복구되면 기존 마스터는 Sentinel B/C의 결정에 따라 새 마스터의 복제본으로 재구성

    • 이 과정에서 기존 마스터(이제 복제본)의 데이터가 초기화되며, 단절 기간 동안 기존 마스터에 기록된 데이터는 유실될 수 있음

방지 대책

레디스는 스플릿 브레인으로 인한 데이터 유실을 최소화하기 위한 설정을 제공한다.

  • min-replicas-to-write <count>: 마스터가 쓰기 작업을 처리하기 위해 최소한 연결되어 있어야 하는 복제본의 수

  • min-replicas-max-lag <seconds>: 복제본의 복제 지연(lag)이 이 설정 시간을 초과하면 마스터는 쓰기 작업을 거부

이 설정들을 통해 마스터는 자신에게 연결된 복제본이 일정 수 미만이거나 복제가 너무 지연되면, 스스로를 읽기 전용(read-only) 상태로 전환하여 데이터 불일치가 심화되는 것을 막는다.

참고자료

Last updated

Was this helpful?