TIL

9장 센티널

고가용성 기능의 필요성

• 레디스는 인메모리 DB이기 때문에 인스턴스가 재시작되면 레디스의 모든 데이터는 유실된다.
• 복제본을 구성한다 해도 클라이언트가 마스터에 직접 연결된 상태라면 아래 과정을 거쳐야 한다.
  1. 복제본 노드에 직접 접속 후 읽기 전용 상태 해제
  2. 애플리케이션 코드에서 레디스 엔드포인트를 복제본 IP로 변경
  3. 배포
• 따라서 별다른 고가용성 기능이 없다면 장애 처리가 지연돼 바로 장애로 이어지게 된다.

센티널이란?

• 센티널은 레디스 자체 고가용성 기능이다.
  • 기존 레디스 인스턴스와는 다른 역할을 하는 별도 프로그램
  • 자동 페일오버 기능을 통해 마스터에 장애가 발생해도 레디스를 계속 사용할 수 있도록 동작하여 다운타임을 최소화

센티널 기능

• 모니터링
  • 마스터, 복제본 인스턴스 기능을 실시간으로 확인
• 자동 페일오버
  • 마스터의 비정상 상태를 감지
  • 정상 상태 복제본 중 하나를 마스터로 승격
  • 기존 마스터에 연결된 복제본은 새롭게 승격된 마스터에 연결
• 인스턴스 구성 정보 안내
  • 클라이언트에게 현재 구성에서 마스터 정보를 알려준다.
  • 페일오버가 발생하면 변경된 마스터 정보를 재전달하기에 엔드포인트 정보를 변경할 필요가 없다.

분산 시스템으로 동작하는 센티널

• 센티널이 SPOF(Single Point Of Failure)라면 의미가 없다.
• 센티널은 그 자체로 SPOF가 되는 것을 방지하기 위해 최소 3대 이상일 때 정상적으로 동작하도록 설계되었다.
  • 하나의 센티널에 문제가 생겨도 다른 센티널에서 클라이언트에게 마스터 정보를 전달할 수 있다.
• 센티널은 오탐을 줄이기 위해 쿼럼(quorum) 개념을 사용한다.
  • 쿼럼 - 마스터가 비정상이라는 것에 동의해야 하는 센티널의 수
  • 쿼럼을 만족하면 페일오버를 시작
  • 일반적으로 센티널 인스턴스가 3개일 때 쿼럼은 2
• 센티널은 쿼럼을 통한 과반수 선출 개념을 사용하기에 3대 이상의 홀수로 구성하는 것이 좋다.

센티널 인스턴스 배치 방법

• 센티널은 마스터의 장애를 감지할 수 있어야하기에 서로 다른 가용 영역에 배치하는 것이 일반적이다.
  • 보통 하나의 서버에 레디스 프로세스와 센티널 프로세스를 동시에 실행시키고 각각 다른 물리 서버에 배치한다.

• 만약 서버 A에 문제가 생긴다면 B, C가 장애 상황에 동의한 후 페일오버를 진행시켜 아래 그림처럼 된다.

• 레디스로 새롭게 들어오는 커넥션은 모두 서버 B의 레디스 주소를 전달 받는다.
• 서버 A가 복구된다면 새로운 마스터인 B의 복제본이 되도록 연결시킨다.
  • 이 과정은 운영자의 개입 없이 센티널의 판단으로 동작한다.
• 센티널은 3개가 일반적이지만 복제본은 1개만 있어도 될 수도 있다.
  • 그런 경우에 3개 서버 중 한 서버는 센티널 프로세스만 동작시킬 수도 있다.

센티널 인스턴스 실행하기

• 위 배치가 되도록 센티널을 구성해보자.
  • 3대의 물리 서버
  • 한 서버는 센티널 프로세스만 실행
  • 레디스는 6379, 센티널은 26379 포트를 사용
  • 쿼럼 값은 2

센티널 프로세스 실행

• 센티널을 실행하기 전 마스터와 복제본을 연결해야 한다.

REPLICAOF 192.168.0.11 6379

• 센티널을 띄우기 위해 sentinel.confg 구성 파일이 필요하다.
  • 포트 지정
  • 모니터링할 마스터의 이름을 지정
  • 구성 파일에는 복제본 정보를 입력하지 않아도 된다. (자동으로 복제본을 찾음)
  • 쿼럼 설정

port 26379
sentinel monitor master-test 192.168.0.11 6379 2

• sentinel.conf 파일을 통해 센티널 인스턴스를 시작하려면 두 가지 방법이 있다.

# redis-sentinel을 이용하는 방법
redis-sentinel /path/to/sentinel.conf

# redis-server를 이용하는 방법
redis-server /path/to/sentinel.conf --sentinel

• 레디스 프로세스에 접근할 때처럼 redis-cli로 센티널 프로세스에 접근 가능하다.

redis-cli -p 26379

• 센티널 프로세스 안에서 다른 센티널 프로세스, 그리고 마스터와 복제본 노드의 정보를 확인할 수 있다.
  • 마스터의 IP, 포트
  • 연결된 복제본 개수 등
  • num-other-sentinels - 모니터링 중인 다른 센티널 정보
  • flags - 마스터의 상태
    • 정상적이지 않다면 s_down, o_down 등 값으로 변경된다.
  • num-slaves - 마스터에 연결된 복제본 개수

SENTINEL master <master-name>

• 아래 커맨드들을 통해 더 자세한 정보를 알 수 있다.
  • SENTINEL replicas - 연결된 복제본의 자세한 정보
  • SENTINEL sentinels <master-name> - 연결된 복제본의 자세한 정보
  • SENTINEL ckquorum <master-name> - 마스터를 보는 센티널 인스턴스가 설정한 쿼럼 값보다 큰지 확인 가능

페일오버 테스트

• 복제본과 센티널이 정상적으로 구성되었다면 운영 투입 전 페일오버 테스트를 진행해보는 것이 좋다.
• 페일 오버 테스트에는 두 가지 방법이 있다.
  • 커맨드를 이용 - SENTINEL FAILOVER <master name>
    • 다른 센티널의 동의를 구하지 않고도 페일오버를 바로 발생시킬 수 있다.
  • 직접 마스터 노드에 장애 발생
    • redis-cli -h <master-host> -p <masterport> shutdown

센티널 운영하기

패스워드 인증

• 마스터와 복제본 노드에 패스워드를 설정한 경우 센티널 설정 파일에도 패스워드를 지정해야 한다.
  • requirepass/masterauth 옵션을 이용한 패스워드 설정
• requirespass와 masterauth 값은 모든 노드에서 동일해야 한다.
  • 복제 구성 내 모든 노드는 마스터 노드가 될 가능성이 있기 때문
• 패스워드가 있는 레디스를 모니터링할 경우 sentinel.conf에 패스워드를 지정해야 한다.
  • sentinel auth-pass <master-name> <password>

복제본 우선순위

• 모든 레디스 인스턴스는 replica-priority 파라미터를 가진다.
  • 해당 값이 가장 적은 노드를 마스터로 선출한다.
  • 기본값은 100
  • 값이 0이면 절대 마스터로 선출되지 않는다.

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

• 센티널은 실행 도중 모니터링할 마스터를 추가, 제거, 변경 가능하다.
• 설정을 변경했다고 그 정보가 다른 센티널로 전파되진 않는다.
  • 각 센티널에 모두 설정을 적용해야 한다.
• SENTINEL MONITOR
  • 새로운 마스터를 모니터링
  • SENTINEL MONITOR <master-name> <ip> <port> <quorum>
• SENTINEL REMOVE
  • 지정하는 마스터를 더 이상 모니터링 하지 않음
• SENTINEL SET
  • 특정 마스터에 지정한 파라미터를 변경할 수 있다.
  • SENTINEL SET mymaster down-after-milliseconds 1000

센티널 초기화

• 센치널은 비정상적 복제본 노드에 대해서도 계속 모니터링을 시도한다.
  • 주기적으로 PING을 호출
• SENTINEL RESET <master name>
  • 모니터링을 중단하기 위한 커맨드
  • 센티널 인스턴스의 상태 정보를 초기화
  • 마스터 이름이 아닌 *을 입력해 전체 마스터 정보를 초기화할 수도 있다.

센티널 노드의 추가/제거

• 그냥 마스터를 모니터링하도록 설정한 센티널 인스턴스를 실행시키면 된다.
  • 자동 검색 메커니즘으로 기존 다른 센티널의 known-list에 추가된다.
• 한 번에 여러 센티널을 추가해야 한다면 10초 이상 간격을 두며 추가하는 것이 오류 가능성을 줄인다.

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

1. 마스터의 장애 상황 감지
   1. down-after-milliseconds 값 이상 동안 PING에 대해 유효 응답을 받지 못하면 다운됐다고 판단
2. sdown, odown 실패 상태로 전환
   1. 우선 sdown 상태로 플래깅 (subjectly down, 주관적 다운 상태)
   2. 다른 센티널에게 장애 사실 전파
   3. 쿼럼 값 이상의 센티널 노드에서 장애를 인지하면 odown 상태로 변경 (objectly down, 객관적 다운 상태)
   4. 장애 전파는 마스터 노드에 대해서만 이뤄지기에 복제본은 sdown 상태만을 가진다.
3. 에포크 증가
   1. 처음 odown으로 인지한 센티널 노드가 페일오버를 시작
   2. 페일오버를 시작하기 전 에포크 값을 증가시킨다. (첫 페일오버라면 1)
   3. 에포크 값을 이용해 여러 센티널 노드가 같은 작업을 시도하고 있다는 것을 보장할 수 있다.
4. 센티널 리더 선출
   1. 에포크를 증가시킨 센티널은 다른 센티널 노드에게 리더 선출 투표 메시지를 에포크와 함께 보낸다.
   2. 메시지를 받은 노드는 받은 에포크 값이 자신의 값보다 큰 경우 에포크를 증가시킨 뒤 투표 응답을 보낸다.
   3. 만약 받은 에포크 값이 자신과 동일하다면 이미 투표한 센티널 id를 응답한다.
5. 복제본 선정 후 마스터로 승격
   1. replica-priority가 낮고 마스터로부터 더 많은 데이터를 수신한 복제본을 마스터로 선출
   2. 위 두 값이 동일하다면 runID가 작은 복제본을 선택
   3. 선정한 복제본에서 slaveof no one 커맨드로 기존 마스터로부터의 복제를 끊난다.
6. 복제 연결 변경
   1. 다른 복제본이 새로 승격된 마스터의 복제본이 될 수 있도록 북제 연결을 변경한다.
   2. 복제 그룹의 모든 센티널 노드에서도 레디스 구성 정보를 변경한다.
7. 장애 조치 완료
   1. 모든 과정 완료 후 센티널은 새로운 마스터를 모니터링한다.

스플릿 브레인 현상

• 스플릿 브레인
  • 네트워크 파티션 이슈로 인해 분산 환경의 데이터 저장소가 끊기고 끊긴 두 부분이 각각 정상적인 서비스라고 인식하는 현상
• 아래 상황이라면 센티널 구성에서 스플릿 브레인 현상이 발생할 수 있다.

• 네트워크 단절이 복구된다면 기존 마스터는 새로 승격된 마스터의 복제본으로 연결된다.
  • 복제본으로 연결되면서 노드의 데이터는 모두 삭제된다.
  • 기존 마스터가 네트워크 단절 동안 처리했던 데이터는 유실된다.