레디스 센티넬 (r1)

센티넬 인스턴스는 레디스 고가용성 솔루션의 핵심 구성 요소이다. 이는 독립적인 프로세스로 실행되며, 하나의 레디스 마스터-슬레이브 복제 그룹을 모니터링하고 관리하는 역할을 담당한다. 일반적으로 고가용성을 보장하기 위해 최소 3개 이상의 센티넬 인스턴스가 쿼럼을 형성할 수 있도록 구성하여 운영된다.

각 센티넬 인스턴스는 설정 파일을 통해 모니터링할 마스터 노드의 정보를 정의받는다. 이들은 지속적으로 마스터 노드와 연결된 슬레이브 노드들의 상태를 헬스 체크하며, 서로 간의 통신을 통해 시스템 상태에 대한 합의를 이루어간다. 이 통신은 자체적으로 구성된 센티넬 버스라는 Pub/Sub 채널을 통해 이루어진다.

센티넬 인스턴스들은 분산 시스템으로서 협력하여 작동한다. 개별 인스턴스의 장애에도 전체 모니터링 시스템이 무정지로 운영될 수 있도록 설계되었다. 이들은 장애 감지, 장애 조치 결정, 새로운 구성 정보의 전파 등 모든 핵심 의사결정을 합의 알고리즘과 투표 메커니즘을 통해 집단적으로 수행한다.

레디스 센티넬이 감시하고 관리하는 대상은 마스터-슬레이브 복제 구조로 구성된 레디스 서버 그룹이다. 이 구조에서 데이터 쓰기 작업은 오직 하나의 마스터 서버에서만 처리되며, 하나 이상의 슬레이브 서버가 마스터 서버의 데이터를 비동기적으로 복제하여 읽기 부하 분산과 데이터의 이중화를 담당한다.

센티넬의 핵심 임무는 이 마스터 서버의 상태를 지속적으로 모니터링하는 것이다. 마스터 서버에 장애가 발생하면, 센티넬은 자동으로 가장 적합한 슬레이브 서버를 새로운 마스터 서버로 승격시키는 장애 조치를 수행한다. 이 과정에서 나머지 슬레이브 서버들은 새로운 마스터 서버를 주인으로 재구성되고, 애플리케이션 클라이언트는 업데이트된 구성 정보를 센티넬로부터 받아 새로운 마스터 서버에 자동으로 재연결된다.

이러한 구조는 단일 레디스 서버의 단일 장애점 문제를 해결하며, 계획된 유지보수나 예기치 않은 하드웨어 장애 시에도 서비스 중단을 최소화할 수 있도록 돕는다. 따라서 센티넬은 고가용성이 요구되는 프로덕션 환경에서 레디스를 운영할 때 필수적인 구성 요소로 자리 잡았다.

레디스 센티넬 시스템에서 클라이언트는 장애 조치 과정을 인식하고 새로운 마스터 서버에 자동으로 연결하는 애플리케이션을 의미한다. 센티넬은 단순히 서버의 상태를 감시하고 장애를 복구하는 데 그치지 않으며, 이 변화된 구성 정보를 클라이언트에게 전파하여 서비스의 연속성을 보장하는 역할까지 수행한다. 따라서 클라이언트는 센티넬과의 상호작용을 통해 고가용성을 실현하게 된다.

클라이언트는 일반적으로 하나 이상의 센티넬 인스턴스에 연결하여 현재의 마스터 서버 주소를 질의한다. 센티넬은 쿼럼을 통해 합의된 최신 구성 정보를 클라이언트에게 제공한다. 대부분의 레디스 클라이언트 라이브러리에는 센티넬을 지원하는 전용 드라이버가 포함되어 있어, 개발자는 센티넬 서버의 주소 목록만 설정하면 된다. 이 드라이버는 내부적으로 센티넬로부터 마스터의 정보를 받아와 연결을 설정하며, 장애 조치 발생 시에도 이 과정을 자동으로 재수행한다.

클라이언트의 구현 방식은 크게 두 가지로 나눌 수 있다. 첫 번째는 센티넬을 직접 조회하는 방식이다. 클라이언트는 초기화 시 센티넬에 연결하여 현재 마스터의 정보를 얻고, 이후 주기적으로 또는 연결 실패 시 다시 센티넬에 문의하여 새로운 마스터를 찾는다. 두 번째는 퍼블리시-서브스크라이브 채널을 구독하는 방식이다. 센티넬은 장애 조치가 완료되면 특정 채널에 새 마스터의 주소를 발행한다. 이를 구독 중인 클라이언트는 메시지를 받아 즉시 새로운 마스터로 재연결할 수 있다. 이 방식은 클라이언트가 지속적으로 센티넬에 폴링할 필요가 없어 더 효율적이다.

센티넬을 사용하는 클라이언트 애플리케이션을 설계할 때는 모든 센티넬 인스턴스에 대한 연결 정보를 하드코딩하기보다는 설정 파일이나 외부 설정 관리 서비스를 활용하는 것이 바람직하다. 이렇게 하면 센티넬 인프라가 변경되더라도 애플리케이션의 재배포 없이 유연하게 대응할 수 있다. 또한, 클라이언트 측에서도 일시적인 연결 실패에 대한 재시도 로직을 구현하여 네트워크 불안정 상황에서의 견고성을 높일 수 있다.

레디스 센티넬의 핵심 기능은 마스터-슬레이브 복제 구조로 구성된 레디스 서버들을 지속적으로 모니터링하는 것이다. 각 센티넬 인스턴스는 설정된 마스터 노드와 그에 연결된 슬레이브 노드들에 대해 정기적인 헬스 체크를 수행한다.

이 모니터링은 주기적으로 PING 명령을 전송하여 각 레디스 서버의 가용성을 확인하는 방식으로 이루어진다. 센티넬은 마스터 노드로부터의 응답 상태, 응답 시간, 그리고 복제 정보를 포함한 INFO 명령의 출력을 분석한다. 이를 통해 마스터의 작동 상태뿐만 아니라 슬레이브들의 연결 상태와 데이터 동기화 지연(리플리케이션 랙) 여부도 함께 감시한다.

모니터링 정보는 센티넬 인스턴스들 간에 지속적으로 공유된다. 센티넬들은 서로 Pub/Sub 채널을 통해 하트비트 메시지를 교환하며, 각자가 관찰한 마스터 노드의 상태에 대한 판단을 주고받는다. 이 분산 합의 과정을 통해 단일 센티넬의 네트워크 문제나 오판으로 인한 오류를 방지하고, 시스템 전체의 상태에 대한 일관된 뷰를 유지한다.

센티넬 인스턴스는 구성된 마스터 노드와 그에 연결된 슬레이브 노드들을 지속적으로 모니터링한다. 이 모니터링은 정기적인 핑 명령과 인포 명령을 통해 이루어진다. 각 센티넬은 마스터 노드에 대해 정해진 간격으로 헬스 체크를 수행하며, 응답 시간과 상태를 확인한다.

장애 감지는 주관적 다운과 객관적 다운이라는 두 가지 개념을 기반으로 한다. 주관적 다운은 단일 센티넬 인스턴스가 마스터 노드에 대한 연결이 설정된 시간 동안 일정 횟수 이상의 핑 명령에 응답을 받지 못했을 때 판단하는 상태이다. 이는 네트워크 일시적 불안정이나 해당 센티넬의 문제로 인해 발생할 수 있다.

객관적 다운은 쿼럼 메커니즘을 통해 결정된다. 하나의 센티넬이 마스터에 주관적 다운을 선언하면, 이는 다른 센티넬 인스턴스들에게 전파된다. 이후 충분한 수의 센티넬(설정된 쿼럼 값 이상)이 짧은 시간 내에 동일하게 주관적 다운에 동의하면, 해당 마스터는 객관적 다운 상태로 최종 판단된다. 이 다수결 원칙은 단일 센티넬의 오판단으로 인한 불필요한 장애 조치를 방지하는 핵심 장치이다.

자동 장애 조치는 레디스 센티넬의 핵심 기능으로, 마스터 레디스 서버에 장애가 발생했을 때 자동으로 새로운 마스터를 선출하고, 슬레이브 서버를 새로운 마스터로 승격시키는 과정을 말한다. 이 과정은 쿼럼 메커니즘을 통해 수행되며, 다수의 센티넬 인스턴스가 합의에 도달해야만 장애 조치가 실행된다.

장애 조치 절차는 크게 세 단계로 나뉜다. 첫째, 다운된 마스터 서버를 장애 감지 알고리즘을 통해 확인하고, '주관적 다운' 상태에서 '객관적 다운' 상태로 전환한다. 둘째, 센티넬 리더 선출을 통해 장애 조치를 주도할 단일 센티넬을 결정한다. 마지막으로, 선출된 센티넬 리더가 가장 적합한 슬레이브를 새로운 마스터로 선택하고, 나머지 슬레이브와 클라이언트들에게 새로운 구성 정보를 전파한다.

이 과정에서 새로운 마스터로 선택되는 슬레이브는 복제 오프셋, 서버 ID, 다운 타임 등 여러 요소를 고려하여 결정된다. 장애 조치가 완료되면, 기존의 장애 난 마스터 서버가 복구되어 재가동되더라도 자동으로 새로운 마스터의 슬레이브로 재편성되어 고가용성을 유지한다.

구성 관리는 레디스 센티넬이 장애 조치 후 새로운 마스터 서버 정보를 다른 센티넬 인스턴스와 클라이언트에게 자동으로 전파하는 핵심 기능이다. 이 과정은 시스템의 구성 정보가 일관되게 유지되도록 보장하여, 애플리케이션이 수동 개입 없이도 새로운 마스터에 정상적으로 연결할 수 있게 한다.

센티넬은 쿼럼과 과반수 원칙에 따라 새로운 마스터를 선출한 직후, 해당 결정을 자신의 내부 구성 에포크에 기록한다. 이 구성 에포크는 버전 관리 번호와 유사한 역할을 하여, 가장 최신의 구성 정보가 무엇인지를 판단하는 기준이 된다. 모든 센티넬 인스턴스는 지속적으로 서로 통신하며 자신의 구성을 브로드캐스트하고, 더 높은 구성 에포크를 가진 정보를 발견하면 자신의 구성을 그 정보로 갱신한다. 이를 통해 분산 시스템 전체에 걸쳐 구성 정보의 일관성이 유지된다.

클라이언트 측 구성 관리는 Pub/Sub 메커니즘을 통해 이루어진다. 센티넬은 특정 채널에 새로운 마스터의 IP 주소와 포트 정보를 메시지로 발행한다. 센티넬을 인지 모드로 연결한 클라이언트 애플리케이션은 이 채널을 구독하고 있으며, 메시지를 수신하면 자동으로 새로운 마스터 서버로의 연결을 재설정한다. 또한, 클라이언트는 센티넬에게 직접 질의를 보내 현재 마스터의 주소를 얻어올 수도 있다. 이러한 자동화된 구성 전파는 시스템 장애 복구 시간을 크게 단축시키고 운영 부담을 줄여준다.

센티넬의 설정은 주로 sentinel.conf 파일을 통해 이루어진다. 이 파일은 각 센티넬 인스턴스가 모니터링할 마스터 레디스 서버, 장애 감지 임계값, 장애 조치 조건, 실행 옵션 등을 정의한다.

설정 파일의 주요 지시어(directive)는 다음과 같다. sentinel monitor <마스터-이름> <마스터-IP> <마스터-포트> <쿼럼>은 모니터링할 마스터 서버를 지정하는 핵심 설정이다. 여기서 <쿼럼>은 장애 감지를 위해 필요한 최소 동의 센티넬 인스턴스 수를 의미한다. sentinel down-after-milliseconds <마스터-이름> <밀리초>는 서버가 응답하지 않을 때 '주관적 다운' 상태로 판단하기까지의 대기 시간을 설정한다. sentinel failover-timeout <마스터-이름> <밀리초>는 장애 조치에 관련된 다양한 타임아웃을 정의하는 다목적 옵션이다. 또한 sentinel auth-pass <마스터-이름> <비밀번호>를 통해 패스워드가 설정된 레디스 서버의 인증 정보를 제공할 수 있다.

설정 파일은 실행 중에도 SENTINEL SET 명령어를 사용하여 동적으로 일부 파라미터를 변경할 수 있다. 그러나 sentinel monitor와 같이 핵심적인 설정은 재시작을 통해서만 적용된다. 모든 센티넬 인스턴스는 마스터의 구성 변경 사항을 지속적으로 감시하고, 장애 조치가 발생하면 새로운 구성 관리 정보를 자동으로 다른 센티넬과 클라이언트에 전파하여 일관성을 유지한다.

레디스 센티넬 시스템을 기동하고 운영하는 방법은 비교적 단순하다. 일반적으로 각 레디스 서버와 함께 또는 별도의 서버에 센티넬 인스턴스를 배포하여 실행한다. 기동은 redis-sentinel 실행 파일에 설정 파일 경로를 인자로 주어 수행한다. 예를 들어, sentinel.conf라는 설정 파일을 사용할 경우 redis-sentinel /path/to/sentinel.conf 명령어로 실행한다. 운영 중에는 로그를 통해 모니터링 상태, 쿼럼 달성 여부, 장애 감지 및 장애 조치 이벤트를 확인할 수 있다.

센티넬의 운영은 주로 설정 파일을 통해 관리된다. 이 파일에는 모니터링할 마스터 레디스의 정보, 쿼럼 수, 장애 조치 타임아웃 등 핵심 파라미터가 정의된다. 운영 중 실시간 상태 확인은 redis-cli를 통해 센티넬 포트에 연결하여 SENTINEL masters, SENTINEL slaves <master-name>, SENTINEL get-master-addr-by-name <master-name> 등의 명령어를 사용한다. 이를 통해 현재 마스터의 주소, 슬레이브 목록, 센티넬들의 상태를 조회할 수 있다.

장애 조치가 발생한 후 시스템은 새로운 토폴로지 정보를 모든 센티넬 인스턴스와 클라이언트 라이브러리에 자동으로 전파한다. 운영자는 새로 선출된 마스터와 그 슬레이브들의 상태가 정상인지, 애플리케이션 연결이 원활히 재설정되는지 모니터링해야 한다. 또한, 다운된 이전 마스터 서버가 복구되면 센티넬에 의해 자동으로 새로운 마스터의 슬레이브로 재편성되어 데이터 동기화를 시작한다.

고가용성을 위해 센티넬 인스턴스 자체도 홀수 개(보통 3개 또는 5개)로 분산 배치하는 것이 권장된다. 모든 센티넬 인스턴스는 동일한 설정 파일을 공유하거나, 최소한 모니터링 대상 마스터에 대한 설정은 일치시켜야 한다. 운영 중 설정의 일부 항목은 SENTINEL SET 명령어를 사용하여 동적으로 변경할 수도 있다.