Redis Sentinel을 통한 Redis H/A 구성


Redis Sentinel은 Redis 서버군을 관리하기 위한 목적으로 개발된 도구이다.

이전에는 Sentinel이라는 이름으로 비공식 배포되었다가, Redis 2.6 버전부터 정식 패키지에 포함되어 배포되기 시작했다. 아직은 beta release이지만, 실서비스에 도입해본 결과 failover나 master server election 등의 기능은 모두 무리없이 동작함을 확인하였다.


http://redis.io/topics/sentinel

Monitoring: Sentinel constantly check if your master and slave instances are working as expected.

Notification: Sentinel can notify the system administrator, or another computer program, via an API, that something is wrong with one of the monitored Redis instances.

Automatic failover: If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.


기존에는 Redis가 공식적으로 failover를 지원하지 않던 터라, 다른 방법으로 failover 방식을 구성해야만 했다. 보통 ZooKeeper를 이용한 시나리오로 많이 구성하는데, 이는 몇가지 애로사항이 존재한다. 첫째로 장애 후처리(failover, failback)에 대한 부분들은 직접 구현해줘야 한다는 노가다(;;)가 발생한다. 둘째로는 Redis instance 단위의 모니터링이 어렵다는 점인데, ZooKeeper 입장에서는 클라이언트와의 네트워크 단절로 장애 판별을 하게 되기 때문이다. 그리고 마지막으로, 관리되는 서버군에 대한 정보 갱신을 수동으로 dynamic하게 발생시켜야 된다. 여러모로 Cluster의 서버 개수가 늘어날수록 짱난다..;;  LOL


Sentinel은 이미 동작하고 있는 Redis 서버군의 설정(Master/Slave 정보 등)을 기반으로 동작하기에, 좀 더 수월하게 관리할 수 있다. 이 말은, 'Redis==Sentinel'이기 때문이기도 하다. (실제로 Sentinel은 Redis의 다른 실행 모드이다. 컴파일된 바이너리의 사이즈를 비교해보면, redis-server와 redis-sentinel의 파일 사이즈가 정확하게 일치한다~)


다음은 간략한 센티널 구성의 예이다.



Redis Server와 Sentinel Server는 각 2대씩 구성되어 있다고 가정한다. 여기서 각 Sentinel 서버는 각각의 Redis instance를 모니터링하며, Redis master server 장애 감지시, 다른 Redis slave server 중, 우선순위가 높은 서버를 Master server로 승격시키고 failover를 수행한다.

(Master election에 대해 최소 몇 개의 Sentinel 서버가 동의해야 failover를 수행할지 결정할 수 있다.)


그럼 Client Connection Failover는???

현재 Redis client library로 Jedis를 사용하고 있는데, API 레벨에서 connection failover를 지원하지 않는다;;; (현재일자 기준 Jedis 최신버전 2.1.0)

덕분에 지저분한 코드가 만들어지긴 했지만, Sentinel도 결국 Redis이므로 Sentinel 서버의 subscribe를 통해 "+switch-master" 메세지를 수신하면, 동적으로 Redis master server address와 connection pool을 갱신하는 방법으로 Jedis를 확장하여 구현했다;;;


참고로 "+switch-master" 수신 메세지의 예.

mymaster 1.1.1.1 6379 1.1.1.2 6379


여기서 첫번째 address는 이전 Master address이며, 두번째 address가 실제 변경된 Master address이다. 클라이언트는 항상 Sentinel 방송 메세지를 watching하고, 해당 메세지가 수신되면 갱신된 Jedis instance를 반환해주는 Factory로 개발한다면 크게 복잡할건 없다..;



Sentinel 설정 및 테스트는 http://redis.io/topics/sentinel를 참고.


'TODO: blah blah~' 카테고리의 다른 글

Flash Scope in Spring MVC 3.1  (0) 2014.02.04
CQRS  (0) 2013.07.02
Redis Sentinel을 통한 Redis H/A 구성  (1) 2013.06.24
IBSheet Code Generator  (0) 2013.06.24
Functional Programming - 1급 함수와 고차 함수의 개념  (0) 2013.03.22
Apache ZooKeeper - 2. H/A 구성  (0) 2012.11.06