REDIS SENTINEL

사내 인프라 방화벽 규정에 기본적으로 모든 포트는 닫아두고 사용하는 포트만 열어두는 정책이 있다.

Redis 에 접속해서 Pub/Sub을 사용해서 게임 서버와 의사소통을 하는 일이 필요해 방화벽 작업 요청 할 일이 있었는데 나는 공유받은 Sentinel ip/port만 신청 후 통신을 했는데 time out에러가 발생했다.

ConnectTimeoutException: connection timed out: /xxx.xxx.xxx.xxx:xxxx

나는 Sentinel 정보가 Redis 서버 정보와 동일하다고 생각했는데 잘못 알고 있었던 것이다.

Redis Sentinel 구성은 Redis 서버와 Sentinel서버를 연결하고 어플리케이션과 Sentinel을 연결해 Redis master 을 전달한다. Redis Sentinel과 Redis이 각각의 정보를 갖고있는 것을 알게 되었다.

Sentinel은 클라이언트 서비스 검색을 위한 구성 공급자 또는 권한 소스 역할을 합니다.

Sentinel 클라이언트 접속 과정

https://redis.io/docs/reference/sentinel-clients 문서에 SENTINEL이 접속하게 되는 클라이언트의 작업의 흐름이 잘 정리 되어 있다.

1. 클라이언트가 Sentinel 연결
2. 클라이언트가 Sentinel 에 redis master addres(ip:port쌍) 요청
3. Sentinel이 Redis master addres를 응답
   1. 클라이언트는 Redis master 연결 시도
   2. 대상 인스턴스 master 확인
      1. master O - 클라이언트는 Redis master 연결
      2.  master X - 1번부터 재시도
4. Sentinel이 null 응답
   1. 다음 Sentinel에 연결해 1번부터 재시도

클라이언트 입장에서 Sentinel 방화벽과 Redis 방화벽을 모두 처리해야 하는 것을 알게 되었다. Redis Sentinel은 보통 Redis3개 Sentinel3개씩 구성하게 되는데, 예를 들면 아래처럼

• Sentinel a - Redis a
• Sentinel b - Redis b
• Sentinel c - Redis c

6개의 물리 호스트에 대한 ip/port를 알아야하고, 방화벽 룰을 6개 열어야 한다는 말이 된다.

기본적으로 Sentinel은 tcp - 26379 포트를 사용하여 실행됩니다.(Redis는 6379 포트를 사용)

Redis Sentinel 실패 상태

Sentinel은 Redis matser에  n초마다 ping 을 날려서 응답을 받으면 인스턴스가 정상인 것으로 간주한다.

 

응답이 없으면

 

인스턴스가 문제가 있다고 생각하고 Sdown-Subjectively Down으로 인지 하며, 이 때 quorum 값도 +처리한다. Sdown은 센티널 한 대가 판단한 것이고, Sdown발생으로 장애조치를 하지 않는다. 

 

설정된 quorum값에 도달했을 때 인스턴스가 비정상이라고 판단하고 장애 조치를 한다. Odown-Objectively Down이라고 한다. 쉽게 말해 Sdown이 누적되면 Odown이 된다.

 

장애조치는 Redis master 연결을 해제 하고 Redis slave 중 복제본 우선순위가 높은 것을 master로 승격시킨다.

 

quorum은 master가 실패로 표시되고 장애 복구 절차를 시작하기 위해 master에 도달할 수 없다는 사실에 동의해야 하는 Sentinel의 수입니다.

예를 들어 Sentinel 5개로 구성된 master의 quorum이 2로 설정된 경우

• 두 센티넬이 동시에 마스터에 도달할 수 없다는 것에 동의하면 둘 중 하나가 장애 조치를 시작하려고 시도합니다.
• 도달 가능한 Sentinel이 총 3개 이상인 경우 장애 조치가 승인되고 실제로 시작됩니다.

 

Redis 와 Sentinel 같은 서버에 설치? 각각 다른서버 구성?

redis 공식 문서에는 다양한 구성이 있다 나는 두개만 정리를 해보았는데 상황에 맞는 구성을 선택해 사용하면 된다.

각각 서버 구성 : Sentinel 인스턴스가 Redis 인스턴스의 부하에 영향을 받지 않는다는 이점이 있다.

같은 서버 구성 : 비용에 이점이 있으나, 해당 서버가 죽게 되면 redis, sentinel 모두 사용할 수 없게 된다.

Redis Pub/Sub

Redis Pub/Sub를 통해 수신된 업데이트 메시지는 클라이언트가 모든 업데이트 메시지를 수신할 수 있다는 보장이 없습니다. 메시지 수신에 대한 보장을 받으려면 RabbitMQ를 사용해야한다.

 

참조 : https://redis.io/docs/management/sentinel/

#replica-selection-and-priority, #quorum

https://redis.io/docs/management/replication/#important-facts-about-redis-replication  - redis replication

https://medium.com/@amila922/redis-sentinel-high-availability-everything-you-need-to-know-from-dev-to-prod-complete-guide-deb198e70ea6

http://redisgate.jp/redis/sentinel/sentinel.php

https://stackoverflow.com/questions/28323936/redis-sentinels-in-same-servers-as-master-slave redis와 sentinel을 다른서버에 설치이유 설명