2014년 10월 27일

센티널을 지원하는 레디스 클라이언트 구현의 가이드라인 (Guidelines for Redis clients with support for Redis Sentinel 번역)


본 내용은 http://redis.io/topics/sentinel-clients 문서를 번역한 것입니다.





WARNING: This document is a draft and the guidelines that it contains may change in the future as the Sentinel project evolves.


주의: 이 문서는 드래프트 버전이고, sentinel 프로젝트가 발전해감에 따라 미래에 변경될 수도 있는 정보를 포함하고 있습니다.






Redis Sentinel is a monitoring solution for Redis instances that handles automatic failover of Redis masters and service discovery (who is the current master for a given group of instances?). Since Sentinel is both responsible to reconfigure instances during failovers, and to provide configurations to clients connecting to Redis masters or slaves, clients require to have explicit support for Redis Sentinel.


This document is targeted at Redis clients developers that want to support Sentinel in their clients implementation with the following goals:

Automatic configuration of clients via Sentinel.
Improved safety of Redis Sentinel automatic failover.
For details about how Redis Sentinel works, please check the Redis Documentation, as this document only contains informations needed for Redis client developers, and it is expected that readers are familiar with the way Redis Sentinel works.

Redis Sentinel(이하 Sentinel)은 모니터링 솔루션이다. 이것은 redis 프로그램의 자동 failover와 그 이후의 서비스 사용가능에 대해서 다룬다(다른 redis instance들 중에서 어느 것이 현재의 마스터인가?). Sentinel은 두 가지 기능을 책임지고 있는데, 하나는 failover가 발생하는 동안에 redis 인스턴스(역자주: 여러 redis 서버를 의미함)들을 재설정하는 것이고, 다른 하나는 redis 마스터과 슬레이브에 연결하고 있는 클라이언트들에게 설정 사항을 제공합니다. 그러므로, 클라이언트들은 sentinel를 지원을 명확히 해줄 것을 요구합니다.

이 문서는 다음의 목적을 가지고 있는, Sentinel를 지원하는 redis 클라이언트 개발자들을 위한 것입니다.

-. Sentinel를 통해서 클라이언트들이 자동적으로 설정되기를 원함.

-. 더 안전한 자동 failover.

Sentinel를 어떻게 동작하는지에 대한 자세한 사항들은 Redis Documentation 문서를 참고하십시오. 이 문서는 단지 redis 클라이언트 개발자를 위한 정보만을 포함하고 있습니다. 또한, 개발자들이 Sentinel이 동작하는 방식에 대해서 잘 알고 있다고 가정합니다.







Redis service discovery via Sentinel


Redis Sentinel identify every master with a name like "stats" or "cache". Every name actually identifies a group of intances, composed of a master and a variable number of slaves.


The address of the Redis master that is used for a specific purpose inside a network may change after events like an automatic failover, a manually triggered failover (for instance in order to upgrade a Redis instance), and other reasons.


Normally Redis clients have some kind of hard-coded configuraiton that specifies the address of a Redis master instance within a network as IP address and port number. However if the master address changes, manual intervention in every client is needed.


A Redis client supporting Sentinel can automatically discover the address of a Redis master from the master name using Redis Sentinel. So instead of an hard coded IP address and port, a client supporting Sentinel should optionally be able to take as input:

A list of ip:port pairs pointing to known Sentinel instances.
The name of the service, like "cache" or "timelines".
This is the procedure a client should follow in order to obtain the master address starting from the list of Sentinels and the service name.



sentinel를 통한 redis 서비스 발견하기


Sentinel은 “통계(stats)” 또는 “캐쉬(cache)”와 같은 하나의 이름을 가지고 모든 마스터를 구분합니다. 실제로 이러한 이름은 인스턴스의 그룹을 구분하는 것인데, 인스턴스들은 하나의 마스터와 바뀔 수 있는 몇몇의 슬레이브들로 구성된 것입니다.


내부 네트워크에서 특정 목적을 가지는 redis 마스터의 주소는 자동 failover, 수동으로 failover를 동작시키는 것(예를 들면, redis 인스턴스를 업그레이드 하는 경우)을 포함하여 몇 가지 다른 이유로 인해서 redis 마스터의 주소는 바뀔 수 있습니다.

보통 redis 클라이언트는 redis 마스터의 IP 주소와 포트로 하드 코딩되어 있는 경우가 있습니다. 그래서, 이 마스터의 주소가 바뀌면 매번 수작업을 변경해 주어야 합니다.

Sentinel를 지원하는 redis 클라이언트는 Sentinel를 이용하는 마스터의 이름(역자주: 예를 들면, mymaster)으로부터 마스터의 주소를 자동으로 알게 됩니다. 그러므로, Sentinel를 지원하는 redis 클라이언트는 redis IP 주소와 포트를 하드코딩 하는 대신에 부가적으로 다음의 입력으로부터 그 redis 마스터의 IP 주소와 포트를 받을 수 있습니다:

-. Sentinel 인스턴스로 알려진 IP:Port 리스트

-. “Cache” 또는 “timelines” 같은 서비스의 이름

다음은 Sentinel의 리스트와 서비스 이름으로 시작하는 마스터 주소를 얻기 위해서 클라이어트가 따라야하는 과정을 보여줍니다.






Step 1: connecting to the first Sentinel


The client should iterate the list of Sentinel addresses. For every address it should try to connect to the Sentinel, using a short timeout (in the order of a few hundreds of milliseconds). On errors or timeouts the next Sentinel address should be tried.


If all the Sentinel addresses were tried without success, an error should be returned to the client.


The first Sentinel replying to the client request should be put at the start of the list, so that at the next reconnection, we'll try first the Sentinel that was reachable in the previous connection attempt, minimizing latency.


과정 1: 첫번째 sentinel에 연결하기
클라이언트는 Sentinel 주소 리스트는 순환해야합니다. 클라이언트가 연결해야하는 모든 sentinel 주소에 대해서 짧은 간격의 시간 주기(수백 밀리 세컨드 주기)로 연결을 시도해야합니다. 에러 또는 타임아웃이 발생하면 다음 sentinel 주소로 연결해야합니다.


모든 sentinel 서버로의 연결이 성공없이 끝나게 되면, 그 에러가 클라이언트에게 리턴되어야 합니다.


클라이언트 요청에 응답하는 첫번째 sentinel은 그 리스트의 시작에 있어야합니다. 그러므로 다음의 재연결에서도, 우리는 지금 연결에 성공한 sentinel 서버에 맨처음 연결을 시도할 것입니다. 이는 전체적인 지연을 최소화하기 위함입니다.







Step 2: ask for master address


Once a connection with a Sentinel is established, the client should retry to execute the following command on the Sentinel:


SENTINEL get-master-addr-by-name master-name


Where master-name should be replaced with the actual service name specified by the user.


The result from this call can be one of the following two replies:

An ip:port pair.
A null reply. This means Sentinel does not know this master.
If an ip:port pair is received, this address should be used to connect to the Redis master. Otherwise if a null reply is received, the client should try the next Sentinel in the list.

과정 2: 마스터 주소 물어보기
sentinel로 연결에 성공하면 클라이언트는 다음의 명령을 시도해야합니다.

SENTINEL get-master-addr-by-name master-name

master-name 자리에는 서비스에서 지정한 이름으로 대체되어야 합니다.

이 명령으로 인한 결과는 다음 두 개의 응답 중에 하나입니다:
-. ip:port 쌍으로 된 정보
-. null 응답: 이 응답의 의미는 sentinel이 마스터의 주소를 모른다는 것입니다.

ip:port 정보를 수신하면, 이 주소는 redis 마스터 주소로 이용하면 됩니다. 만약, null 응답을 받았다면 클라이언트는 다음 sentinel 주소로 연결을 시도해야합니다.







Step 3: call the ROLE command in the target instance


Once the client discovered the address of the master instance, it should attempt a connection with the master, and call the ROLE command in order to verify the role of the instance is actually a master.


If the ROLE commands is not available (it was introduced in Redis 2.8.12), a client may resort to the INFO replication command parsing therole: field of the output.


If the instance is not a master as expected, the client should wait a short amount of time (a few hundreds of milliseconds) and should try again starting from Step 1.


과정 3: 타켓 인스턴스에 ROLE 명령어 호출하기
클라이언트가 마스터 인스턴스의 주소를 알게되면, 그 서버에 연결하여 “ROLE” 이라는 명령을 호출해야합니다. 이는 그 인스턴스가 실제로 마스터 역할을 하고 있는지 확인하기 위한 것입니다. 
ROLE 명령어를 이용할 없다면(이 명령어는 redis 2.8.12부터 가능함), INFO 명령의 결과에서 “replication” 항목으로 확인할 수 있습니다. 출력 데이터에서 “role”이라는 항목을 보면 됩니다.
(역자주: INFO 명령의 출력에서 다음 항목입니다.
# Replication
role:master
connected_slaves:0)







Handling reconnections


Once the service name is resolved into the master address and a connection is established with the Redis master instance, every time a reconnection is needed, the client should resolve again the address using Sentinels restarting from Step 1. For instance Sentinel should contacted again the following cases:

If the client reconnects after a timeout or socket error.
If the client reconnects because it was explicitly closed or reconnected by the user.
In the above cases and any other case where the client lost the connection with the Redis server, the client should resolve the master address again.

재연결 다루기(역자주: 클라이언트가 서버로 재연결 시도)
마스터 주소에 해당하는 서비스 이름을 알게되면 그 서버에 연결을 합니다. 매번 재연결 해야합니다. 과정 1로부터 sentinel의 재시작을 알게 될 수도 있습니다. 같은 sentinel 주소를 다시 접속해야한다면 매번 재연결을 시도해야한다는 의미입니다. sentinel의 다음의 상황에 놓여있다면 클라이언트는 sentinel에 다시 연결해야합니다.
-. sentinel로부터 타임아웃 또는 소켓에러를 받은 경우
-. sentinel이 명시적으로 소켓 종요를 수행했거나, 사용자에 의해서 재연결이 이루어진 경우







Sentinel failover disconnection


Starting with Redis 2.8.12, when Redis Sentinel changes the configuration of an instance, for example promoting a slave to a master, demoting a master to replicate to the new master after a failover, or simply changing the master address of a stale slave instance, it sends a CLIENT KILL type normal command to the instance in order to make sure all the clients are disconnected from the reconfigured instance. This will force clients to resolve the master address again.


If the client will contact a Sentinel with yet not updated information, the verification of the Redis instance role via the ROLE command will fail, allowing the client to detect that the contacted Sentinel provided stale information, and will try again.


Note: it is possible that a stale master returns online at the same time a client contacts a stale Sentinel instance, so the client may connect with a stale master, and yet the ROLE output will match. However when the master is back again Sentinel will try to demote it to slave, triggering a new disconnection. The same reasoning applies to connecting to stale slaves that will get reconfigured to replicate with a differnt master.


sentinel failover 끊어짐
redis 2.8.12부터는 sentinel이 인스턴스의 설정을 변경하게 되는 경우, 예를 들면 슬레이브가 새로운 마스터가 된 경우이거나 failover 이후에 예전 마스터가 새로운 마스터로부터 복제를 수행하는 경우, 그리고,  간단하게는 마스터가 슬레이브로 변경되는 경우에 대해서, sentinel은 “CLIENT KILL” 명령을 그 인스턴에서 보냅니다. 이것은 모든 클라이언트들의 연결을 끊게 만들기 위해서 입니다. 이렇게 되면 클라이언트들은 새로운 마스터 주소를 찾기 위한 과정을 시도하도록 하기 위함입니다.

클라이언트가 갱신되지 않은 정보로 연결을 시도하게 되면, ROLE 명령에 의해서 redis 인스턴스의 증명(역자주: role 명령에 의해서 master가 아님을 알게됨)은 실패할 것입니다. 클라이언트는 접근했던(역자주: 예전에 접근하여 얻은 redis master 정보) sentinel은 최신 정보를 주는 것이 아니라는 것을 알게 되면 sentinel에 새롭게 시도를 할 것입니다.

참고: 클라이언트가 오래된 sentinel에 접근한 시각과 동시에 예전 마스터가 다시 살아나는 것도 가능합니다. 그렇게되면 클라이언트는 오래된 마스터에 연결을 할 것이고, ROLE 명령에 대한 응답도 master로 일치하게 됩니다. 그러나, 그 마스터가 다시 살아났을 때에는 sentinel이 그 마스터를 슬레이브로 만들게 됩니다. 그러면 클라이언트는 현재 마스터로 알고 있는 인스턴스로부터 연결 종료를 받게 됩니다. 같은 방식의 추론으로 오래된 슬레이브는 다른 마스터를 통하여 복제되도록 설정이 이루어지게 됩니다.







Connecting to slaves


Sometimes clients are interested to connect to slaves, for example in order to scale read requests. This protocol supports connecting to slaves by modifying step 2 slightly. Instead of calling the following command:


SENTINEL get-master-addr-by-name master-name


The clients should call instead:


SENTINEL slaves master-name


In order to retrieve a list of slave instances.


Symmetrically the client should verify with the ROLE command that the instance is actually a slave, in order to avoid scaling read queries with the master.


슬레이브에 연결하기
가끔 클라이언트는 슬레이브에 연결하기도 합니다. 예를 들면, 대량의 읽기만 발생시키는 요청의 경우입니다. 이러한 방식은 과정 2를 조금 수정하여 슬레이브에 연결하는 것을 지원할 수 있습니다. 즉, 다음의 명령을 사용하는 대신에:

SENTINEL get-master-addr-by-name master-name

클라이언트는 다음 명령을 사용합니다:

SENTINEL slaves master-name

그 결과로 슬레이브들의 리스트를 받을 수 있습니다.

클라이언트는 ROLE 명령을 사용해서 그 인스턴스가 실제로 슬레이브인지 확인하게 됩니다. 이것은 대량의 읽기 요청을 마스터에 보내는 것을 피하기 위함입니다.








Connection pools


For clients implementing connection pools, on reconnection of a single connection, the Sentinel should be contacted again, and in case of a master address change all the existing connections should be closed and connected to the new address.


커넥셜 풀(connection pools)
클라이언트의 커넥션풀 구현과 하나의 커넥선을 재연결하기 위한 구현을 위해서, 클라이언트는 sentinel에 재연결을 시도해야합니다. 클라이언트는 현재 갖고 있는 모든 연결을 가진 마스터의 주소가 바뀐 경우라면 모든 연결을 종료하고 새로운 마스터로 연결을 시로해야합니다.








Error reporting


The client should correctly return the information to the user in case of errors. Specifically:

If no Sentinel can be contacted (so that the client was never able to get the reply to SENTINEL get-master-addr-by-name), an error that clearly states that Redis Sentinel is unreachable should be returned.
If all the Sentinels in the pool replied with a null reply, the user should be informed with an error that Sentinels don't know this master name.

에러 보고
클라이언트는 사용자에게 에러 상황이 발생한 경우에 그 정보를 올바르게 보고해야합니다. 특히 다음의 경우는 더 그러합니다:
-. 접근할 수 있는 sentinel이 없는 경우(그래서, 클라이언트는 SENTINEL get-master-addr-by-name 라는 명령의 응답을 받을 수 없는 경우)에는 sentinel에 도달하지 못했다(Sentinel is unreachable)라는 에러를 리턴해야합니다.
-. 모든 sentinel이 null 응답을 보낼 경우에는 sentinel은 마스터 이름을 모른다(Sentinels don't know this master name.)라는 에러를 사용자에게 통보해야합니다.







Sentinels list automatic refresh


Optionally once a successful reply to get-master-addr-by-name is received, a client may update its internal list of Sentinel nodes following this procedure:

Obtain a list of other Sentinels for this master using the command SENTINEL sentinels .
Add every ip:port pair not already existing in our list at the end of the list.
It is not needed for a client to be able to make the list persistent updating its own configuration. The ability to upgrade the in-memory representation of the list of Sentinels can be already useful to improve reliability.

sentinel 서버 목록의 자동 갱신
부가적으로, 마스터 정보를 알 수 있는 명령에 대한 성공 응답을 받았을 때, 클라이언트는 다음의 과정을 통해서 내부의 sentinel 서버 리스트를 갱신할 수도 있습니다.
-. SENTINEL sentinels 명령을 이용하여 다른 sentinel 서버 리스트를 획득할 수 있습니다.
-. 지금 가진 sentinel 서버 리스트(ip:port 쌍으로 된)의 끝에 새로운 ip:port 정보를 추가할 수 있습니다.

클라이언트가 자신이 갖고 있는 설정를 지속적으로 업데이트하여 그 리스트를 계속유지하는 것은 필요하지 않습니다. 메모리상에 존재하는 sentinel 서버 리스트 이용하여 업그레이드하는 것은 신뢰성을 높이는데 유용하게 사용될 수 있습니다.








Subscribe to Sentinel events to improve responsiveness


The Sentinel documentation shows how clients can connect to Sentinel instances using Pub/Sub in order to subscribe to changes in the Redis instances configurations.


This mechanism can be used in order to speedup the reconfiguration of clients, that is, clients may listent to Pub/Sub in order to know when a configuration change happened in order to run the three steps protocol explained in this document in order to resolve the new Redis master (or slave) address.


However update messages received via Pub/Sub should not substitute the above procedure, since there is no guarantee that a client is able to receive all the update messages.


sentinel 이벤트에 더 잘 대응하기 위한 구독자 되기

Sentinel documentation 이라는 문서는 클라이언트가 pub/sub를 이용하여 sentinel 인스턴스에 어떻게 연결해야하는지를 설명하고 있습니다. 이것은 클라이언트가 redis 인스턴스의 설정상의 변경을 알기 위한 구독자 역할로 동작하기 위함입니다. 

이 매커니즘은 클라이언트의 재설정 속도를 높이기 위해서 사용될 수 있습니다. 즉, 클라이언트는 redis 마스터 또는 슬레이브 정보의 변경을 알기 위해서, 위에서 설명한 과정 1,2,3 실행해야만 하는데요, pub/sub은 설정 변경이 발생했을 때, 이 변경을 항상 listen 할 수 있도록 해줍니다.

그러나, pub/sub를 통하여 수신한 매시지는 위 과정의 대체과정이 되어서는 안됩니다. 왜냐하면, 클라이언트가 항상 갱신 매시지를 받을 수 있다는 보장이 없기때문입니다.








Additional information


For additional information or to discuss specific aspects of this guidelines, please drop a message to the Redis Google Group.


추가 정보
이 가이드라인의 관점에서 특별한 상황을 논의하고자 한다면  Redis Google Group에 매시지를 남겨주세요.

댓글 없음:

댓글 쓰기