Sentinel 클라이언트 스펙
Sentinel 클라이언트 스펙 (Sentinel client spec)
Redis Sentinel용 클라이언트를 만드는 방법.
출처: 공식문서
Redis Sentinel은 Redis 인스턴스를 위한 모니터링 솔루션으로, Redis 마스터의 자동 장애 조치(failover)와 서비스 디스커버리(주어진 인스턴스 그룹의 현재 마스터는 누구인가?)를 처리합니다. Sentinel은 장애 조치 중 인스턴스를 재구성하고, Redis 마스터·레플리카에 연결하는 클라이언트에 설정을 제공하는 일을 모두 담당하므로, 클라이언트가 Sentinel을 명시적으로 지원해야 합니다.
이 문서는 클라이언트 구현에서 Sentinel을 지원하려는 Redis 클라이언트 개발자를 위한 것입니다. 목표는:
- Sentinel을 통한 클라이언트 자동 구성
- Redis Sentinel 자동 장애 조치의 안전성 향상
Redis Sentinel이 어떻게 동작하는지에 대한 자세한 내용은 Redis 문서를 참조하세요. 이 문서는 Redis 클라이언트 개발자에게 필요한 정보만 담고 있으며, 독자가 Redis Sentinel의 동작 방식을 잘 알고 있다고 전제합니다.
Sentinel을 통한 Redis 서비스 디스커버리
Redis Sentinel은 각 마스터를 "stats"나 "cache" 같은 이름으로 식별합니다. 각 이름은 실제로 마스터와 가변 개수의 레플리카로 구성된 인스턴스 그룹을 식별합니다.
네트워크 안에서 특정 목적으로 쓰이는 Redis 마스터의 주소는 자동 장애 조치, 수동 트리거 장애 조치(예: Redis 인스턴스 업그레이드), 그 외 이유로 바뀔 수 있습니다.
보통 Redis 클라이언트는 네트워크 내 Redis 마스터 인스턴스 주소를 IP와 포트 번호로 지정하는 하드코딩된 설정을 가집니다. 그런데 마스터 주소가 바뀌면 모든 클라이언트에 수동 개입이 필요합니다.
Sentinel을 지원하는 Redis 클라이언트는 마스터 이름에서 Redis Sentinel을 통해 Redis 마스터 주소를 자동 디스커버리할 수 있습니다. 하드코딩된 IP·포트 대신, Sentinel 지원 클라이언트는 선택적으로 입력으로 받아야 합니다:
- 알려진 Sentinel 인스턴스를 가리키는
ip:port쌍 목록 - 서비스 이름, 예: "cache" 또는 "timelines"
클라이언트가 Sentinel 목록과 서비스 이름에서 마스터 주소를 얻기 위해 따라야 하는 절차입니다.
1단계: 첫 번째 Sentinel에 연결
클라이언트는 Sentinel 주소 목록을 순회해야 합니다. 각 주소마다 짧은 타임아웃(수백 밀리초 정도)으로 Sentinel 연결을 시도합니다. 오류나 타임아웃 시 다음 Sentinel 주소를 시도합니다.
모든 Sentinel 주소가 실패하면 클라이언트에 오류를 반환해야 합니다.
클라이언트 요청에 처음 응답한 Sentinel을 목록 맨 앞에 두어, 다음 재연결 때 이전 연결 시도에서 도달 가능했던 Sentinel을 먼저 시도해 지연을 최소화합니다.
2단계: 마스터 주소 요청
Sentinel과 연결이 맺어지면 클라이언트는 Sentinel에서 다음 명령 실행을 재시도해야 합니다:
SENTINEL get-master-addr-by-name master-name
여기서 master-name은 사용자가 지정한 실제 서비스 이름으로 바꿔야 합니다.
이 호출의 결과는 다음 두 응답 중 하나입니다:
ip:port쌍- null 응답 — Sentinel이 이 마스터를 모른다는 뜻
ip:port 쌍을 받으면 이 주소로 Redis 마스터에 연결합니다. null 응답이면 목록의 다음 Sentinel을 시도합니다.
3단계: 대상 인스턴스에서 ROLE 명령 호출
클라이언트가 마스터 인스턴스 주소를 디스커버리한 후 마스터와 연결을 시도하고, 인스턴스의 역할이 실제로 마스터인지 확인하기 위해 ROLE 명령을 호출해야 합니다.
ROLE 명령을 쓸 수 없으면(Redis 2.8.12에서 도입됨) INFO replication 명령을 호출해 출력의 role: 필드를 파싱할 수 있습니다.
인스턴스가 예상대로 마스터가 아니면 잠시(수백 밀리초) 기다렸다가 1단계부터 다시 시도해야 합니다.
재연결 처리
서비스 이름이 마스터 주소로 검증되고 Redis 마스터 인스턴스와 연결이 맺어지면, 재연결이 필요할 때마다 1단계부터 Sentinel을 사용해 주소를 다시 검증해야 합니다. 예를 들어 Sentinel에 다시 연락해야 하는 경우:
- 타임아웃이나 소켓 오류 후 클라이언트가 재연결하는 경우
- 사용자가 명시적으로 닫거나 재연결해 클라이언트가 재연결하는 경우
위 경우와 클라이언트가 Redis 서버와의 연결을 잃은 모든 경우, 클라이언트는 마스터 주소를 다시 검증해야 합니다.
Sentinel 장애 조치 연결 해제
Redis 2.8.12부터, Redis Sentinel이 인스턴스 설정을 변경할 때(예: 레플리카를 마스터로 승격, 장애 조치 후 마스터를 새 마스터의 레플리카로 강등, 오래된 레플리카 인스턴스의 마스터 주소 변경) CLIENT KILL type normal 명령을 인스턴스에 보내 재구성된 인스턴스에서 모든 클라이언트가 연결 해제되도록 합니다. 이는 클라이언트가 마스터 주소를 다시 검증하도록 강제합니다.
클라이언트가 아직 갱신되지 않은 정보를 가진 Sentinel에 연락하면, ROLE 명령을 통한 인스턴스 역할 검증이 실패해, 클라이언트는 접촉한 Sentinel이 오래된 정보를 제공했음을 감지하고 다시 시도합니다.
참고: 오래된 마스터가 클라이언트가 오래된 Sentinel 인스턴스에 연락하는 것과 동시에 온라인으로 돌아올 수 있어, 클라이언트가 오래된 마스터에 연결해도 ROLE 출력이 일치할 수 있습니다. 그러나 마스터가 돌아오면 Sentinel이 이를 레플리카로 강등시키려 해 새로운 연결 해제가 유발됩니다. 다른 마스터와 복제하도록 재구성될 오래된 레플리카에 연결하는 경우에도 같은 논리가 적용됩니다.
레플리카에 연결
때로 클라이언트는 읽기 요청 확장을 위해 레플리카에 연결하길 원합니다. 이 프로토콜은 2단계를 약간 수정해 레플리카 연결을 지원합니다. 다음 명령을 호출하는 대신:
SENTINEL get-master-addr-by-name master-name
클라이언트는 대신 다음을 호출해 레플리카 인스턴스 목록을 가져와야 합니다:
SENTINEL replicas master-name
대칭적으로 클라이언트는 ROLE 명령으로 인스턴스가 실제로 레플리카임을 검증해, 마스터로 읽기 쿼리 스케일링을 하지 않아야 합니다.
커넥션 풀
커넥션 풀을 구현하는 클라이언트는 단일 연결의 재연결 시 Sentinel에 다시 연락해야 하고, 마스터 주소가 바뀐 경우 모든 기존 연결을 닫고 새 주소에 연결해야 합니다.
오류 보고
클라이언트는 오류 시 사용자에게 정보를 올바르게 반환해야 합니다. 구체적으로:
- 어떤 Sentinel에도 연락할 수 없으면(즉 클라이언트가
SENTINEL get-master-addr-by-name응답을 결코 못 받으면) Redis Sentinel에 연결할 수 없다는 오류를 명확히 반환해야 합니다 - 풀의 모든 Sentinel이 null 응답을 반환했으면, Sentinel이 이 마스터 이름을 모른다는 오류로 사용자에게 알려야 합니다
Sentinel 목록 자동 갱신
선택적으로 get-master-addr-by-name 성공 응답을 받으면 클라이언트는 다음 절차로 Sentinel 노드 내부 목록을 갱신할 수 있습니다:
SENTINEL sentinels <master-name>명령으로 이 마스터의 다른 Sentinel 목록을 얻음- 이미 목록에 없는 각
ip:port쌍을 목록 끝에 추가
클라이언트가 목록을 영속화해 자체 설정을 갱신할 필요는 없습니다. 메모리 내 Sentinel 목록 표현을 업그레이드하는 능력만으로도 신뢰성을 높이는 데 유용합니다.
Sentinel 이벤트 구독으로 응답성 향상
Sentinel 문서는 클라이언트가 Pub/Sub으로 Sentinel 인스턴스에 연결해 Redis 인스턴스 설정 변경을 구독하는 방법을 보여줍니다.
이 메커니즘은 클라이언트 재구성을 가속화하는 데 쓸 수 있습니다. 즉 클라이언트는 Pub/Sub을 들어 설정 변경이 발생했을 때 알기 위해 사용하고, 이 문서에서 설명한 3단계 프로토콜을 실행해 새 Redis 마스터(또는 레플리카) 주소를 검증할 수 있습니다.
그러나 Pub/Sub을 통해 받은 갱신 메시지가 위 절차를 대체해서는 안 됩니다. 클라이언트가 모든 갱신 메시지를 받으리란 보장이 없기 때문입니다.
추가 정보
추가 정보나 이 지침의 특정 측면에 대한 논의는 Redis Google Group에 문의하세요.
더 알아보기 (Learn more)
- Redis 고가용성: Sentinel 문서
- Redis 복제 (Replication)
- Redis 클라이언트 라이브러리로 연결하기