[입 개발] Redis Automatic failover Solution – Redis Sentinel 소개

해당 블로그는 KT UCloud의 지원을 받고 있습니다.

Redis Sentinel 은 Redis 개발자가 만든 자동 Automatic Failover Solution 입니다.  현재는 베타 Release 상태이나, 간단하게 테스트 한 결과로는 잘 동작하고 있습니다. 이 글을 작성하는 시점에 몇 가지 테스트를 더 해봐야 하는데, 일단은 간단하게 사용법 정도를 공유합니다.

특징

Sentinel은 다음과 같은 3가지 특성을 가집니다.

  • Monitoring : master나 slave 가 제대로 동작하는지 모니터링 합니다.
  • Notification : API를 제공해서 관리자가 장애 상황에 대해서 통보 받을 수 있도록 해줍니다.
  • Automatic FailOver: 마스터가 장애가 나면 Slave를 자동으로 새로운 마스터로 만들고 다른 Slave들이 해당 마스터를 사용하도록 설정합니다.

Sentinel은 분산 프로그램입니다. 그래서 장애 모니터링 자체의 장애를 받기 위해 여러 개의 서버를 동시에 실행할 수 있습니다. sentinel의 master 정보만 입력하면, 자체적으로 sentinel 과 redis 서버들의 정보를 확인할 수 있습니다. 재미난 것은 redis-sentinel 자체가 redis 소스를 그대로 이용한 거라, 거의 비슷한 구조로 동작합니다. 다만 기존 redis 명령이 먹지 않습니다.

코드

현재 sentinel 은 redis git trunk 에 이미 merge 되어 있습니다.


git clone https://github.com/antirez/redis.git

빌드

빌드도 간단합니다. mecached 가 libevent 의존이 있는 것과 다르게, redis는 외부 라이브러리 의존성이 없어서 그냥 make 만 하시면 빌드가 됩니다. 다만 unittest까지 전부 돌려보기 위해서는 TCL 을 설치하셔야 합니다.

실행

sentinel 은 두 가지 방법으로 실행할 수 있습니다. 빌드 결과물 중에 redis-sentinel을 사용하든지 기존 redis-server 에 –sentinel 옵션을 줘도 됩니다.


redis-sentinel sentinel.conf

redis-server sentinel.conf --sentinel

설정

기존 redis-server의 동작 자체는 바꿀 필요가 없고, 일단 sentinel 용 conf를 보도록 하겠습니다.


sentinel monitor resque 127.0.0.1 2001 1
sentinel down-after-milliseconds resque 3000
sentinel failover-timeout resque 900000
sentinel can-failover resque yes
sentinel parallel-syncs resque 1

기본적인 sentinel의 conf 구성은 다음과 같은 형태로 구성되어 있습니다.


sentinel <command> <command values>

일단 기본적으로 monitor 커맨드는 마스터 서버의 주소와 ip가 들어가게 됩니다. 그리고 down-after-miliseconds 는 해당 장비가 장애가 난 걸 인지하고 failover 를 결정할 때 걸리는 시간을 지정해주는 것입니다. can-failover 는 실제로 failover를 할 것인지에 대해서 결정합니다. yes일 때만 장애가 발생하면 failover가 시작됩니다. parallel-syncs는 최소 몇 대의 slave 가 새로운 마스터와 sync를 맞춰야 하는 가에 대한 내용인데, 아직 확실히 확인해보지는 못했습니다.

sentinel 를 추가하더라도 기존 시스템 자체에 변경이 필요하지 않고 sentinel 만 설정해주면 됩니다.  sentinel 은 기본적으로 26379 포트를 이용하는데, redis 의 설정 처럼 port 정보를 주면 원하는 포트로 실행이 됩니다.

여러 대의 sentinel 을 이용할 때 sentinel monitor resque 127.0.0.1 2001 1 에서 마지막 1의 값이 몇 대의 sentinel로 부터 마스터 장애를 통보 받아야 실제로 failover를 할 것인지에 대한 설정 값이다. 만약 해당 값을 실제 sentinel 서버 수 보다 늘리면, failover가 영원히 동작하지 않습니다.

시나리오

sentinel의 시나리오는 다음과 같습니다. Sentinel의 monitor에 master의 정보를 주면 자동으로 slave 는 감지하게 됩니다.

그리고 Master가 장애가 나면 Sentinel 이 감지하게 됩니다.

그리고 Sentinel 이 하나의 slave를 정해서 slave를 master로 변경합니다. 그리고 타 슬레이브 노드의 마스터를 신규 마스터로 설정합니다.

SDown(Subjectively down) 과 ODown(Objectively down)

Sentinel 은 서버의 상태를 SDown 과 ODown 이라는 형태로 구분합니다. SDown은 한 대의 sentinel 이 해당 장비가 장애가 났다라고 판단하는 것인데, 이것으로만은 Failover를 하지 않습니다. ODown 상태가 되어야만 Failover를 하게 되는데, 최초에 장애가 났다는 것이 SDown 그리고 다른 sentinel 에서 과반 수 이상이 해당 장비가 장애난게 맞다라고 답변을 주면 ODown이 되어서 실제로 Failover가 시작됩니다.( 보통 이런 경우는 Brain Split, 네트웍으로 인해서 특정 sentinel이 해당 서버가 장애났다고 인식해서 갑자기 failover 하는 것을 막기 위한 방법입니다. ) SDown은 정기적으로 PING 명령을 사용해서 체크하게 됩니다.

무엇보다 알아야 할 부분은?

사실 가장 중요한 부분이 여기 있습니다. 여기까지 보셨으면 질문이 하나 생길 것입니다. 그리고 그 질문에 대한 대답이 나오지 않으면 쓸 수 없을지도 모릅니다. Sentinel 은 “마스터” 가 장애가 나면 슬레이브 중에 한대를 골라서 “새로운 마스터”로 승격시켜주고, 다른 슬레이브들은 해당 마스터를 바라 보도록 합니다. 그렇다면, 어떤 슬레이브가 선택이 되고, 클라이언트 입장에서 해당 FailOver의 발생과 새로운 마스터 서버의 정보를 얻을 수 있을까요?

  •  새로운 마스터 정보의 획득: 해당 정보는 redis-sentinel 역시 redis와 마찬가지라 command를 통해서 얻을 수 있습니다. SENTINEL get-master-addr-by-name <master name>을 이용하면 됩니다. 해당 master name은 montior 로 설정했던 그 이름입니다.
</pre>
redis 127.0.0.1:2003> SENTINEL get-master-addr-by-name resque
1) "127.0.0.1"
2) "2002"
<pre>
  • 그리고 이런 변경에 대한 이벤트는 sentinel 에 대해서 psubscribe 를 통해서 통보 받을 수 있습니다.
</pre>
charsyam@ubuntu:~/projects/redis$ src/redis-cli -p 2003
redis 127.0.0.1:2003> psubscribe *
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "*"
3) (integer) 1
1) "pmessage"
2) "*"
3) "+sdown"
4) "master resque 127.0.0.1 1999"
1) "pmessage"
2) "*"
3) "+odown"
4) "master resque 127.0.0.1 1999 #quorum 1/1"
1) "pmessage"
2) "*"
3) "failover-detected"
4) "master resque 127.0.0.1 1999"
1) "pmessage"
2) "*"
3) "+failover-end"
4) "master resque 127.0.0.1 1999"
1) "pmessage"
2) "*"
3) "+switch-master"
4) "resque 127.0.0.1 1999 127.0.0.1 2002"
1) "pmessage"
2) "*"
3) "+sentinel"
4) "sentinel 127.0.0.1:2004 127.0.0.1 2004 @ resque 127.0.0.1 2002"

주의할 점

아직 sentinel의 경우 beta release 입니다만, 꽤 안정적으로 보이지만, 주의해야 할 부분이 있습니다. 예를 들어서 현재까지는 기존 redis-server 들이 모두 재시작하게 되면 sentinel 서버들의 정보를 reset 해 주거나 재시작해야만, 다시 모니터링이 시작됩니다. 이걸 모르시고 적용하게 되면, 한번 모니터링 된 이후에는 안될 수도 있으니 주의해야 합니다.

[추가] 해당 이슈에 대해서는 베타라 아직 구현되지 않았다고 합니다.