개발자를위한레디스 9장 - 센티넬
센티넬
센티넬이란?
기존 레디스 인스턴스와 다른 역할을 하는 별도의 프로그램이며, 센ㅣ넬의 자동 페일 오버 기능을 사용하면 마스터 인스턴스에 장애가 발생하더라도 레스를 계속 사용할 수 있도록 동작해 레디스의 다운타임을 최화할 수 있습니다.
센티넬 기능
- 모니터링 : 마스터, 복ㅔ본 인스턴스의 상태를 실시간으로 확인
- 자동 페일오버 : 마스터의 비정상 상태를 감지해 정상 상태의 복제본 중 하나를 마스터로 승격시킴
- 인스턴스 구성 정보 안내 : 현재 구성에서 마스터 정보를 알려줌
분산 시스템으로 동작하는 센티널
센티널은 SPOF가 되는 것을 방지하기 위해 최소 3대 이상일 때 정상적으로 동작할 수 있도록 설계되어있습니다.
센티넬은 오탐을 줄이기 위해 쿼럼이라는 개념을 사용합니다.
쿼럼: 마스터가 비정상 동작을 한다는 것에 동의해야 하는 센티널의 수
일반적으로 센티널 인스턴스가 3개일 때 쿼럼은 2로 설정합니다. 과반수 선출 개념을 사용하기 때문에 3대 이상의 홀수로 구성하는 것이 좋습니다.
센티널 인스턴스 배치 방법
서로 다른 가용 영역에 배치하는 것이 일반적입니다.
- 2개의 복제본이 있는 구성의 센티넬 배치 방법
보통 하나의 서버에 레디스 프로세스와 센티널 프로세스를 동시에 실행
- server A : redis master, sentinel
- server B : redis replica, sentinel
- server C : redis replica, sentinel
여기서 A가 죽으면 새롭게 마스터가 될 복제본을 선출한 뒤, 해당 복제본 인스턴스를 마스터로 승격시킵니다.
아래와 같이 기존 마스터를 바라보고 있던 클라이언트는 모두 서버 B에서 새롭게 선출된 마스터로 연결됩니다.
- server A :
redis master, sentinel - server B : redis master, sentinel
- server C : redis replica, sentinel
여기서 서버 A가 복구되면 센티널 인스턴스의 판단으로 자동으로 구성됩니다. 서버 리소스에 여유가 있다면 2개의 복제본을 가질 수 있도록 구성하는 것이 안정적입니다.
- server A : redis master, sentinel
- server B : redis master, sentinel
- server C : redis replica, sentinel
- 1개의 복제본이 있는 구성의 센티넬 배치 방법
server C에는 센티넬 프로세스만 실행
- server A : redis master, sentinel
- server B : redis replica, sentinel
- server C : sentinel
여기서 서버 A에 문제가 생기면 페일오버를 진행시킵니다. 서버 C를 최저 사양으로 구성해 리소스 비용을 아끼면서도 마스터의 장애를 감지해 자동 페일오버를 수행할 수 있는 안정적인 구조입니다.
- server A :
redis master, sentinel - server B : redis master, sentinel
- server C : sentinel
센티널 운영하기
패스워드 인증
마스터와 복제본 노드에 패스워드를 설정한 경우 센티널의 설정 파일에서도 패스워드를 지정해야 합니다. 하나의 복제 그룹에서 requirepass와 masterauth 값은 모든 노드에서 동일하게 설정해야 합니다.
패스워드가 걸려 있는 레디스를 모니터링할 경우에는 sentinel.conf에 패스워드를 지정해야 합니다.
1
sentinel auth-pass <master-name> <password>
복제본 우선순위
센티널은 페일오버를 진행할 때 각 복제본 노드의 replica-priority라는 우선순위 노드를 확인하며, 해당 값이 가장 작은 노드를 마스터로 선출합니다. 기본값은 100이며, 0인 복제본은 마스터로 선출되지 않습니다.
운영 중 센티널 구성 정보 변경
아래의 명령어로 센티널이 새로운 마스터를 모니터링할 수 있도록 합니다.
1
SENTINEL MONITOR <master name> <ip> <port> <quorum>
더 이상 지정하는 마스터를 모니터링하지 않도록 지시도 가능합니다.
1
SENTINEL REMOVE <master name>
특정 마스터에 대해 지정한 파라미터를 변경할 수 있습니다.
- down-after-milliseconds: 마스터가 다운됐다는 것을 판단하는 시간
- quorum: 쿼럼 값
1
SENTINEL SET <name> [<option> <value> ...]
센티널 초기화
서버를 더 이상 사용할 수 없어 해당 인스턴스에 대한 모니터링을 중단하려면 SENTINEL REST 커맨드를 사용해 센티널 인스턴스의 상태 정보를 초기화해야 합니다.
1
SENTINEL RESET <master name>
센티널 인스턴스의 상태 정보를 초기화하고 센티널이 모니터링하고 있는 마스터, 복제본, 다른 센티널 인스턴스의 정보를 초기화해야합니다.
센티널 노드의 추가/제거
- 추가 : 마스터를 모니터링하도록 설정한 센티널 인스턴스를 실행
- 제거 : SENTINEL RESET * 커맨드를 이용해 센티널이 모니터링하고 있는 정보를 리셋
센티널의 자동 페일오버 과정
1. 마스터의 장애 상황 감지
센티넬은 down-after-milliseconds 파라미터에 지정된 값 이상 동안 마스터에 보낸 PING에 대해 유효한 응답을 받지 못하면 마스터가 다운됐다고 판단합니다.
ping에 대한 유효항 응답은 +PONG, -LOADING, -MASTERDOWN이며, 다른 응답이나 응답을 아예 받지 못할 경우에는 유효하지 않다고 판단합니다.
2. sdown, odown 실패 상태로 전환
3. 마스터 노드 상태를 sdown으로 변경
하나의 센티널 노드에서 마스터 인스턴스에 대한 응답을 늦게 받으면 마스터 상태를 우선 sdown으로 플래깅합니다.
sdown: subjectly down, 주관적인 다운 상태
4. 마스터 노드 상태를 odown으로 변경
이후 다른 센티널 노드들에게 SENTINEL is-master-down-by-addr
쿼럼 값 이상의 센티널 노드에서 마스터의 장애를 인지한다면 센티널 노드는 마스터의 상태를 odown으로 변경합니다.
odown: objectly down, 객관적인 다운 상태
5. 에포크 증가
처음으로 마스터 노드를 odown으로 인지한 센티널 노드가 페일오버 과정을 시작합니다.
센티널은 에포크라는 개념을 이용해 각 마스터에서 발생한 페일오버의 버전을 관리합니다. 처음으로 페일오버가 일어날 때의 에포크 값은 1이며 새로운 페일오버가 발생할 때마다 에포크 값은 하나씩 증가합니다. 동일한 에포크 값을 이용해 페일오버 과정이 진행되는 동안 모든 센티널 노드가 같은 작업을 시도하고 있다는 것을 보장할 수 있습니다.
6. 센티널 리더 선출
에포크를 증가시킨 센티널은 리더를 선출하기 위해 투표하라는 메시지를 보냅니다. 이때 증가시킨 에포크를 함께 전달하는데, 해당 메시지를 받은 다른 센티널 노드가 현재 자신의 에포크보다 전달받은 에포크가 클 경우 자신의 에포크를 증가시킨 뒤, 센티널 리더에게 투표하겠다는 응답을 보냅니다.
과반수와 쿼럼
선티널이 마스터 노드를 sdonw -> odown으로 변경하기 위해서는 쿼럼 값 이상의 센티널의 동의가 필요합니다.
하지만 페일오버를 실제로 시도하기 위해 센티널 리더를 선출할 때에는 쿼럼값이 아니라 실제 센티널 개수 중 과반수 이상의 센티널의 동의를 얻어야만 센티널 리더가 선출됩니다. 쿼럼 값보다 큰 센티널이 동의를 했을 경우에도 그 수가 과반수보다 작다면 페일오버는 발생하지 않습니다.
예를 들어 센티널이 5개이고 쿼럼이 2일때 마스터의 상태는 sdown -> odown으로 변경돼 페일오버가 트리거 될 수는 있으나, 2개의 센티널만 동의한 경우에는 센티널 리더를 선출할 수 없어, 페일오버가 발생하지 않습니다.
7. 복제본 선정 후 마스터로 승격
과반수 이상의 센티널이 페일오버에 동의했다면 리더 센티널은 페일오버를 시도하기 위해 마스터가 될 수 있는 적당한 복제본을 선정합니다.
- redis.conf 파일에 명시된 replica-priority가 낮은 복제본
- 마스터로부터 더 많은 데이터를 수신한 복제본
- 2번 조건까지 동일하다면, runID가 사전 순으로 작은 복제본
선정한 복제본에는 slaveof no one 커맨드를 수행해, 기존 마스터로부터 복제를 끊습니다.
8. 본제 연결 변경
복제본마다 replicaof new-ip new-port 커맨드를 수행해 복제 연결을 변경합니다.
9. 장애조치 완료
모든 과정 완료 후 센티널은 새로운 마스터를 모니터링합니다.
스플릿 브레인 현상
스플릿 브레인이란 네트워크 파티션 이슈로 인해 분산 환경의 데이터 저장소가 끊어지고, 끊긴 두 부분이 각각을 정상적인 서비스라고 인식하는 현상입니다.
p.274 참조