9장 센티널

고가용성 기능이 필요한 이유

만약 마스터가 장애나서 수동으로 failover해야하는 상황이라면

1. 복제본에서 REPLICA OF ON ONE 입력해 읽기 전용 상태 해제
2. 앺 코드에서 레디스 엔드포인트를 복제본 IP로 변경 후 앺 배포

과정을 거쳐야한다. 그럼 장애 처리가 지연돼 서비스 기능의 문제로 이어진다.

또한 캐시 look aside 구조라면 레디스 장애날 동안 MYSQL 같은 원본 DB로 요청이 집중돼 서버 부하 급증돼 서비스 영향 끼칠 수 있다.

센티널 (Sentinel)

• 레디스 자체 고가용성 기능
• 데이터 저장하는 레디스 인스턴스랑 다른 역할 하는 별도 프로그램
• 센티널의 자동 failover 사용하면 마스터 장애나도 다운타임 최소화할 수 있다.

센티널 기능

• 모니터링: 마스터, 복제본 인스턴스 상태 실시간 확인
• 자동 페일오버: 마스터의 비정상 상태 감지해 복제본 중 하나를 마스터로 승격. 기존 마스터에 연결됐었던 복제본도 새 마스터에 연결된다.
• 마스터 정보 전달: 클라에게 최신 버전의 마스터 정보를 알려준다. 그래서 페일오버 발생하면 새 마스터 정보를 재전달하기 때문에 앺에서 새 마스터 엔드포인트를 변경할 필요가 없다.

분산 시스템으로 동작

• 복제, 자동 failover로 고가용성 확보 이유: 레디스가 SPOF(Single Point Of Failure, 하나의 서비스 문제 됐을 때 전체 시스템이 영향을 받는 지점)가 되지 않기 위함
• 센티널 자체도 SPOF를 방지 하기 위해 최소 3대 이상일 때 정상 동작하도록 설계됐다.
• 쿼럼(quorum) 개념 사용
  • 마스터가 비정상적으로 동작함을 동의하는 센티널 수
  • 쿼럼을 만족해야 페일오버를 시작한다.
  • 오탐을 방지하려는 목적
  • 일반적으로 센티널 인스턴스 3개면 쿼럼은 2로 설정 (2대가 동의해야 페일오버 시작)
  • 과반수 선출 개념이라 센티널 인스턴스는 3대 이상 홀수가 좋다. (보통 3대, 좀 더 견고하게는 5대)

센티널 인스턴스 배치하기

• 센티널끼리는 서로 물리적으로 영향받지 않은 서버에서 실행되는 것이 좋기 때문에 서로 다른 가용 영역에 배치하는 것이 일반적.

• 

  • 보통 하나의 서버에 레디스와 센티널 프로세스를 동시에 실행시킨다
  • 만약 서버 A에 문제 생기면 서버 B, C의 센티널이 복제본 선출하고, 서버B의 복제본이 마스터로 선출됐다면 서버C의 복제본은 B바라보도록변경하고, 레디스로 새로 들어오는 커넥션은 B 레디스 주소를 전달받는다.
  • A가 복구되었을 때 B의 복제본으로 연결된다.
  • 이 과정을 센티널이 자동으로 해줘서 운영자의 개입이 필요하지 않음
• 
  • 레디스 인스턴스는 복제본 2개가 안정적이긴하나 1대만으로도 충분하면 센티널 인스턴스만 따로 다른 서버(최저 사양)에 배치할 수 있다.

센티널 인스턴스 실행하기

• 보통 레디스는 6379, 센티널은 26749 포트 사용

레디스 복제 연결 구성하기

복제본 노드에서 실행

REPLICAOF 192.168.0.11 6379

• 192.168.0.11 마스터노드

센티널 프로세스 띄우기

sentinel.conf 설정파일 구성

port 26379
sentinel monitor master-test 192.168.0.1 6379 2

• port 26739 센티널 포트
• sentinel monitor 모니터링할 마스터 지정 (이름은 이 커맨드에서 지정하는거임,마스터 쪽에서 지정하는게 아니라)
  • master-test: 마스터 이름 (특수문자, 공백 포함 X. 알파벳, 숫자, . - _ 만 사용)
  • 2: 쿼럼
• 센티널이 마스터, 모든 복제본까지 모니터링하지만 복제본 정보는 안 써도 됨. 자동으로 찾아내기 때문

센티널 띄우기 2가지 방법

redis-sentinel /path/to/sentinel.confg
혹은
redis-server /path/to/sentinel.confg --sentinel

두 개 커맨드는 동일하게 동작함

로그

redis-sentinel sentinel.conf
53472:X 22 Feb 2026 12:14:48.913 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
53472:X 22 Feb 2026 12:14:48.913 # Redis version=7.0.11, bits=64, commit=00000000, modified=0, pid=53472, just started
53472:X 22 Feb 2026 12:14:48.913 # Configuration loaded
53472:X 22 Feb 2026 12:14:48.913 * Increased maximum number of open files to 10032 (it was originally set to 2560).
53472:X 22 Feb 2026 12:14:48.913 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 7.0.11 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 53472
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

53472:X 22 Feb 2026 12:14:48.913 # WARNING: The TCP backlog setting of 511 cannot be enforced because kern.ipc.somaxconn is set to the lower value of 128.
53472:X 22 Feb 2026 12:14:48.913 # Sentinel ID is cc8015b96d2c0d6b1816d1a00362982ca358b66a
53472:X 22 Feb 2026 12:14:48.913 # +monitor master master-test 192.168.0.1 6379 quorum 1
53472:X 22 Feb 2026 12:15:18.967 # +sdown master master-test 192.168.0.1 6379
53472:X 22 Feb 2026 12:15:18.967 # +odown master master-test 192.168.0.1 6379 #quorum 1/1
53472:X 22 Feb 2026 12:15:18.967 # +new-epoch 3
53472:X 22 Feb 2026 12:15:18.967 # +try-failover master master-test 192.168.0.1 6379
53472:X 22 Feb 2026 12:15:18.995 * Sentinel new configuration saved on disk
53472:X 22 Feb 2026 12:15:18.995 # +vote-for-leader cc8015b96d2c0d6b1816d1a00362982ca358b66a 3
53472:X 22 Feb 2026 12:15:18.995 # +elected-leader master master-test 192.168.0.1 6379
53472:X 22 Feb 2026 12:15:18.995 # +failover-state-select-slave master master-test 192.168.0.1 6379
53472:X 22 Feb 2026 12:15:19.051 # -failover-abort-no-good-slave master master-test 192.168.0.1 6379
53472:X 22 Feb 2026 12:15:19.153 # Next failover delay: I will not start a failover before Sun Feb 22 12:21:19 2026

센티널 접근하기

redis-cli -p 26379

• 마스터, 복제본, 다른 센티널 인스턴스 정보 확인 가능
• 레디스 데이터는 확인 불가

*SENTINEL master master-test
*

127.0.0.1:26379>  SENTINEL master master-test
 1) "name"
 2) "master-test"
 3) "ip"
 4) "192.168.0.1"
 5) "port"
 6) "6379"
 7) "runid"
 8) ""
 9) "flags"
10) "master"
11) "link-pending-commands"
12) "100"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "11661"
17) "last-ok-ping-reply"
18) "11661"
19) "last-ping-reply"
20) "11661"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "0"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "11661"
29) "config-epoch"
30) "0"
31) "num-slaves"
32) "0"
33) "num-other-sentinels"
34) "0"
35) "quorum"
36) "1"
37) "failover-timeout"
38) "180000"
39) "parallel-syncs"
40) "1"

• num-other-sentinels 마스터 모니터링하는 다른 센티널 수
• flags 마스터 상태 (기본: master). 비정상적이면 s_down, o_down로 변경됨
• num-slaves 마스터에 연결된 복제본 수

SENTINEL replicas master-test

127.0.0.1:26379> SENTINEL replicas master-test
(empty array)

복제본 정보 확인

SENTINEL sentinels master-test

127.0.0.1:26379> SENTINEL sentinels master-test
(empty array)

다른 센티널 정보 확인

SENTINEL ckquorum master-test

127.0.0.1:26379> SENTINEL ckquorum master-test
OK 1 usable Sentinels. Quorum and failover authorization can be reached -> 센티널 1, 쿼럼 1

127.0.0.1:26379> SENTINEL ckquorum master-test
(error) NOQUORUM 1 usable Sentinels. Not enough available Sentinels to reach the specified quorum for this master -> 센티널 1, 쿼럼 3

센티널 인스턴스 수가 쿼럼 이상인지 확인

페일오버 테스트

커맨드로 수동 페일오버

SENTINEL FAILOVER master-test(마스터이름)

다른 센티널 동의 안 구하고도, 마스터 정상이어도 바로 페일오버 발생돼 마스터/복제본 롤 체인지 됨

마스터 중지 시켜 자동 페일오버

redis-cli -h <master host> -p <master port> shutdown

센티널이 마스터한테 주기적으로 PING 보내는데 sentinel.conf의 down-after-milliseconds 동안(기본 30초) 응답 안 오면 페일오버 트리거한다.

센티널 운영하기

패스워드 인증

• 마스터/복제본에서 requirepass/masterauth로 패스워드 설정했으면 센티널에서도 해줘야함
• 모든 복제본이 마스터가 될 가능성이 있기 때문에 requirepass/masterauth 값은 모든 노드에서 동일하게 설정한다.

sentinel.conf

sentinel auth-pass <master name> <password>

복제본 우선순위

• 센티널이 페일오버 진행할 때 레디스 인스턴스의 replica-priority 값이 가장 작은 노드를 마스터로 선출한다.
• 기본값은 100이고, 0인 복제본은 절대 마스터로 선출되지 않는다.

운영중 센티널 구성 정보 변경

센티널 실행 도중 모니터링할 마스터 변경 가능. 근데 센티널끼리 동기화는 안돼서 각각 센티널에 설정 변경해줘야함

# 모니터링할 새 마스터 추가
SENTINEL MONITOR <master name> <ip> <port> <quorum>

# 마스터 완전히 제거. SENTINEL masters 같은 커맨드에서도 보이지 않음
SENTINEL REMOVE <master name>

# 특정 마스터 파라미터 변경
SENTINEL SET master-test down-after-milliseconds 1000
SENTINEL SET master-test quorum 1

# 레디스 6.2이상 부터 마스터 종속 없은 센티널 고유한 설정값도 런타임 중에 변경 가능
SENTINEL CONFIG GET <config name>
SENTINEL CONFIG SET <config name> <vlaue>

센티널 초기화

• 센티널은 비정상적이라 판단한 복제본 노드도 모니터링(PING)을 임의로 멈추지 않는다.
  • 페일오버 된 접근 불가한 노드도 계속 모니터링 시도함
• 더 이상 접근 불가 인스턴스 모니터링 중단하고 싶으면 센티널 초기화해야함

SENTINEL RESET

SENTINEL RESET <master name>

• 센티널이 모니터링하는 마스터, 복제본, 다른 센티널 정보 새로 고침
• SENTINEL RESET * 센티널이 모니터링 중인 전체 마스터 정보 초기화

센티널 노드 추가⁠⁠/제거

추가

• 마스터 모니터링하게 설정하고 센티널 실행시키면 자동으로 다른 센티널의 known-list에 추가된다.
• 여러 대 센티널 추가해야하면 10초 이상 간격 두어 1개씩 목록에 들어가게 하는게 오류 줄일 수 있다.
• SENTINEL MASTER <master name> 의 num-other-sentinels 값으로 센티널 잘 추가됐는지 확인한다.

제거

• 센티널 프로세스 종료 후 다른 센티널에서 SENTINEL RESET * 로 초기화해줘야함
• 센티널 노드끼리는 응답 없어도 known-list에서 지우지 않기 때문
• 최소 30초 대기시간 가지는게 좋다
• SENTINEL MASTER <master name> 의 num-other-sentinels 값으로 센티널 잘 제거됐는지 확인한다.

센티널의 자동 페일오버 과정

여러 센티널 노드가 마스터 장애 감지하고 페일오버 시키는 과정 좀 더 자세히 알아보자

1) 마스터의 장애 상황 감지

• 센티널이 마스터에게 PING 보냈는데 down-after-milliseconds 가 유효하지 않은 응답이 오거나 응답이 안 옴
  • 유효한 응답: +PONG, -LOADING, -MASTERDOWN

2) sdown, odown 실패 상태로 전환

• 하나의 센티널 노드에서 마스터 응답 못 받으면 마스터를 sdown(subjectly, 주관적)으로 플래깅한다.
• 다른 센티널들한테 아래 커맨드 보내 장애 사실 전파한다.

  • SENTINEL is-master-down-by-addr <master ip> <master port> <current epoch> <*>  

• 커맨드 받은 센티널들이 장애 맞다고 응답함

  • 

• 자신을 포함해 쿼럼 값 이상의 센티널이 장애 인지하면 마스터를 odown(objectly, 객관적)으로 플래깅함
• odown은 마스터만 가지는 값이다. 복제본 노드는 장애 인지하면 sdown까지만 플래깅하고 다른 센티널에 전파하진 않는다. sdown 상태 복제본은 마스터로 승격되지 않음

3) 에포크 증가

• 처음으로 마스터를 odown으로 인지한 센티널 노드가 페일오버 시작한다.
• 페일오버 시작 전 epoch 값 하나 증가한다
  • 에포크: 각 마스터에서 발생한 페일오버 버전. 처음 페일오버 일어나면 에포크는 1이된다. 동일한 에포크 값을 이용해 모든 센티널 노드가 같은 페일오버 작업 시도한다는걸 보장할 수 있다.

4) 센티널 리더 선출

• 에포크 증가시킨 센티널이 다른 센티널들한테 센티널 리더 선출하기 위해 투표하라는 메시지를 보낸다. 이 때 증가시킨 에포크 값 함께 전달.
• 메시지 받은 다른 센티널들이 받은 에포크 값으로 맞추고 투표한다고 응답 보낸다.
  • 이미 전달받은 에포크 값이 자신의 에포크와 동일할 땐 이미 리더로 선출한 센티널 id를 응답한다. 한 번 투표하면 동일 에포크 내에선 못 바꾸기 때문.

❓SENTINEL is-master-down-by-addr 보낸 애가 리더하면 되지 않나? 왜 리더를 따로 선출?

• 그 커맨드를 여러 센티널이 동시에 보낼 수 있기 때문에 split brain 발생할 수 있음
• 장애 판단, 리더 선출에 사용하는 정족수 값도 다름
  • Quorum (장애 판독 기준): 보통 2정도로 낮게 설정
  • Majority (리더 선출 기준): 반드시 전체 센티널 수의 과반수여야 함
    • 만약 과반 수 못 넘으면 각 센티널에서 각각의 랜덤 시간 후에 에포크 다시 늘리고 투표 요청

5) 복제본 선정 후 마스터로 승격

• 리더 센티널 뽑히면 마스터가 될 복제본 선정한다.
  • redis.conf의 replica-priority가 낮은 복제본
  • 마스터로부터 더 많은 데이터를 수신한 복제본 (master_repl_오프셋)
  • 위 두 조건 동일하면 runId 사전순으로 작은 복제본 (의미는 없음. 임의로 하나 노드 선택하려는 목적)
• 복제 연결 변경
  • 선정된 복제본에서 slaveof no one 커맨드 실행해 기존 마스터로부터의 복제 끊는다.

6) 복제 연결 변경

기존 마스터에 연결돼있던 복제본들도 새 마스터의 복제본이 될 수 있도록 복제본마다 replicaof new-ip new-port 커맨드 수행한다.

7) 장애 조치 완료

장애 조치 후 센티널은 새 마스터를 모니터링 한다.

스플릿 브레인 현상

: 네트워크 파티션 이슈로 네트워크가 끊긴 분산환경의 데이터 저장소 두 부분이 각각 정상적인 서비스라고 인식하는 현상

• 센티널 A / B,C가 네트워크 단절됨
• 센티널 B,C 쪽은 마스터 접근이 비정상적임을 감지해 복제본을 마스터로 승격시킴
• 만약 마스터가 장애가 아니라 단지 노드 간 네트워크 단절이었다면 하나의 복제본 그룹에 마스터가 2개가 되버린다.
• 마스터 2개에 각자 데이터가 입력됨
  • 기존 마스터 주소에 연결돼있던 클라이언트는 계속 기존 마스터에 데이터 입력한다.
  • 새 클라이언트가 센티널C한테 연결 요청하면 새 마스터 주소를 알려주고 여기에 데이터 입력한다.
• 네트워크 복구됐을 때, 기존 마스터는 새 마스터의 복제본으로 연결된다.
  • 그럼 기존 마스터의 데이터는 모두 삭제돼 기존 클라이언트의 데이터는 모두 유실된다.

❓해결 방안?

• min-replicas-to-write 값 설정해 마스터가 최소 N개 이상 복제본 갖고 있어야 쓰기 가능하게 만듦
• 일부 고급 설정에선 기존 마스터가 자격 잃었음 감지하면 스스로 연결 끊거나 클라 차단하는 기능도 있다함 (fencing 메커니즘, 레디스 순정기능엔 없지만)
• 레디스 클러스터가 노드 많은 쪽을 선택
• 클라 쪽에서 주기적으로 마스터가 누군지 물어봄
• 클라 쪽에서 최소 2대 이상 센티널한테 마스터 누군지 물어봄