Redis(레디스; REmote DIctionary System)은 요즘 각광 받고 있는 In-memory Data(key-value) Store이다. 언제고 한 번 다뤄 봤으면 했는데, 마침 비슷한 기회가 주어져서 고가용성을 확보할 수 있는 중요한 설정 방법을 찾아보고 Redis 를 활용하는 아주 간단한 Python Client 예제를 정리하여 실전을 위해 기록해 두고자 한다.


"쓰다 보니 내용이 좀 많습니다. 2편 정도로 나누려 했으나, 다루려고 하는 내용을 한 편에 모아서 구성하는 편이 더 좋다고 생각했으니 스크롤 압박이 심하더라도 양해 바랍니다" - Barracuda -


"Redis 는 DBMS 인가?", "임시 데이터 저장용 캐시라고도 하던데..." 하는 잡다한 얘기는 여기서는 생략하자. 자주 쓰다 보면 아~ Redis 는 이래서 쓰는구나 하고 느끼면 되겠고, 기회가 된다면 왜 Naver Japan에서 LINE 서비스에 이를 적용했는지, Memcached와 왜 자주 비교 되는지, Twitter, Flickr, Github, Tumblr, Instagram 등의 구축 사례를 구글링 등으로 찾아 보면 어느 정도 감이 잡힐 것이라고 생각된다.


본 포스팅에서는 아래의 내용 위주로 정리해 두기로 한다.


* Redis 아키텍처 결정 및 설치/설정 방법

* Redis Sentinel 의 추가 설정과 HA 운영

* Redis Client example - python 버전

* Redis 를 서비스에 적용할 때의 주의사항


1. Redis 아키텍처 결정 및 설치/설정 방법


Redis 로 구성할 수 있는 아키텍처들은 그 용도, 규모에 따른 조합이 다양하게 있을 수 있으며, 응용/확장 형태로 Naver 등에서는 Zookeeper 와 함께 사용하기도 하고, 때로는 Haproxy/Keepalived 를 병행하여 실제 서비스에 사용되기도 한다. 여기서는 Redis 만을 사용한 구성 모델을 생각해 보자.


* Single(단일) 서버 구성 - 개발, 테스트 용도

* MS(Master_1-Slave_N) 구성 - 소규모 개발 및 테스트 용도

* Redis MS & Sentinel*2(Total 5) 구성 - 소규모 개발 및 서비스 용도

* Redis MS & Cluster & Sharding - 중규모 이상 서비스 용도



Redis 와 Sentinel 을 이해하기 위한 간단한 예


여기서는 비교적 단순하면서도 가용성(HA: High Availability)이 보장될 수 있는 3 번째 방법을 채택하고,실제로 구현해 보자. 우선 아래 첫 번째 그림을 보자. Redis 를 설명하는 웹페이지들이 예를 들어 자주 보여 주는 그림이다.


그림 1. Single Maser-Slave & Sentinel


그림1은 하나 씩의 Master-Slave 와, 이들을 감시하는 Sentinel이 Master down시 Slave를 Master 를 승격(Failover 과정을 통해)시켜 주게 되는 좋은 예라고 할 수 있다. 그러나 Redis와 Sentinel 의 작동 과정과 원리를 직관적으로 잘 보여 준다는 점 외에는 이 아키텍처로부터 얻을 수 있는 것은 거의 없다. 왜냐하면 "3대의 서버 중 Master 1대만 죽었을 때(quorom=1일때. quorom은 뒤에 설명)" 만 안정성이 보장된다는 한계를 지닌 아키텍처이기 때문이다.


부하를 분산하기 위해 Master 는 write-only, Slave 는 read-only 로 작동하게 된다고 가정하면, Redis에 접속하여 데이터를 처리하는 Client는 Sentinel로부터 Master와 Slave 의 주소를 알아내려 하기 때문에, Slave나 Sentinel이 죽거나 특정한 2대가 동시에 죽는 어떤 경우에라도 정상적인 서비스를 기대하지 못하게 된다는 사실을 잘 따져 보도록 하자(Sentinel이 왜 필요해 지는지는 아래 실제 구성에서 자연스럽게 정리 될 것이다).



서버 3대로 안정적인 Redis 서비스를 할 수 있는 방법은?


그렇다면, 위와 같은 3대의 서버로 어떻게 하면 비교적 안정적인 서비스 환경을 구성할 수 있을까? 아래 그림을 보자.


그림 2. Redis Master 1, Slave 2 & 3 Sentinels


그림 2는 2대의 서버가 동시에 죽더라도 최소한 Data의 읽기 또는 쓰기 중 한가지만은 가능한 구조이다. Master는 2대의 Slave 들에 각각 변경 데이터를 보내 주며, 3개의 Sentinel 들이 3대의 Redis 서버와 자신을 제외한 나머지 2대의 Sentinel 들을 감시하는 구조이다. Sentinel 을 3대 이상 홀수로 사용하는 이유는, Master 가 죽고 Failover 상황이 발생생했을 때, 홀수개의 Sentinel들이 각각 투표에 참여하여 과반수 이상이 선출되도록 하기 위함이다(redis.io 권고). 그러나 ...


* 이 아키텍처에는 결정적인 한계가 존재한다. 위 그림에서는 Master 서버 내의 Redis 서버(데몬, 서비스)가 Down 되었다면 3개의 Sentinel들이 투표에 참여하여 과반수인 2표(quorom >= 2) 이상을 얻은 Slave 가 Master 로 선출될 것이다. 그런데 뭐가 문제인가?


* 실제 상황에서는 서버(머신) 내의 특정 프로세스 또는 데몬이 죽어 버리는 경우도 있지만, 머신 자체의 하드웨어(전원, 네트워크) 고장/오동작 또는 네트워크 장비/포트 단절 등에 의해 서버 자체의 연결이 끊어지는 경우가 더 많을 수 있다. 그림 1에서와 같은 문제점과 유사하게, Master 서버 머신이 Down 되어 버리거나(왜 문제일까? 아래에서 Quiz 로 제시한다), 2대의 서버가 동시에 Down 되어 버린다면 마찬가지의 참담한 결과를 맞게 된다.


해결 방법은 무엇일까? 단순히 Redis-Sentinel 서버를 1대 더 추가하여 4대를 만들어서 사용하는 방법도 있고, 3대의 Sentinel을 모두 외부의 다른 서버에 설치하거나, Redis 에 접속하는 Client 머신 내에 설치를 권장하기도 한다. 또는 시스템 내의 그리 바쁘지 않은 서버 2대를 따로 선정해서 Sentinel 만 설치/설정해 두면 상대적으로 그림은 간단해지고 위의 문제도 어느 정도 해결 가능하다.



그림 3. Redis Master 1, Slave 2 & 5 Sentinels


그림 3에서는 2대의 서버 머신이 동시에 죽는 어떠한 상황이라도 Redis 서비스 자체는 훌륭하게 동작하게 될 수 있다. 특별히 2대의 Redis 서버가 동시에 다운되었더라도, Redis Client 측에서 Master 를 Write & Read 용으로 사용하도록 약간의 코딩을 해 둔다면 말이다.


* 투입되는 서버의 댓수가 많다면 충분히 안정적인 서비스가 가능하겠지만, 하드웨어나 VM이 무한정 사용될 수는 없는 것이고 보면, 외부 Sentinel 머신을 한 개 정도만 더 추가해서 Redis 3, Sentinel 5 구성이 비교적 합리적인 선택이 아닐까 생각된다(물론 운영의 부담이 되는 관리포인트가 늘어남은 감수해야 한다)


* 결국은 여건을 충분히 고려한 취사 선택이 어느 정도로 필요하다는 말이 되겠고, 본 포스팅에서는 마지막의 그림 3을 목표 아키텍처로 하여 시스템을 준비하고, 실제로 구현하고 검증까지 진행해 보도록 하자.



Redis 서버용 머신을 이용해 Master(1)-Slave(2) 를 구성한다


* 5대의 서버를 준비한다(본 테스트 환경에서 사용한 머신은 모두 ubuntu14.4 vm이며 10.0.0.0/16 네트워크에 연결)

 - ubuntu14-pv1: 10.0.10.1 (Redis Master, Sentinel)

 - ubuntu14-pv2: 10.0.10.2 (Redis Slave1, Sentinel)

 ubuntu14-pv3: 10.0.10.3 (Redis Slave2, Sentinel)

 - ubuntu14-pvha1: 10.0.0.1 (Sentinel)

 - ubuntu14-pvha2: 10.0.0.2 (Sentinel)


그림 4. Redis Master 1, Slave 2


* 1단계 작업으로 그림 4에서와 같이 3대의 서버로 Redis Master-Slave 구성부터 진행

ubuntu14-pv1~3, ubuntu14-pvha1,2 모든 5대의 서버에서 동일하게 작업

root@ubuntu14-pv1:~# apt-get install redis-server redis-tools

root@ubuntu14-pv1:~# apt-get install python-pip

root@ubuntu14-pv1:~# pip install redis

root@ubuntu14-pv1:~# vi /etc/sysctl.conf -> 아래 내용을 추가

# Redis M-S sync

vm.overcommit_memory=1


# Increase max open file limit

fs.file-max = 1048576

root@ubuntu14-pv1:~# sysctl -p

root@ubuntu14-pv1:~# ulimit -n 65535

root@ubuntu14-pv1:~# vi ~/.bashrc -> 스크립트 최 상단에 아래 내용을 삽입

ulimit -n 65535


* ubuntu14-pv1 서버를 Redis master 로 설정하기 위한 작업이다

* 설치 자체는 어렵지 않지만, config 설정시에 주의해야할 것들이 있으니, 붉은 글씨의 라인에 쓰인 설명을 잘 참고한다

* requirepass 는 자신이 Master 가 되었을 때 요구할 접속 암호, masterauth 는 자신이 Slave 일 때 Master 로 접속하기 위한 암호이다. 본 설정에서는 뒤에 Sentinel 에 의해서 Master <-> Slave 전환이 자유로워야 하므로 동일하게 맞추어야 한다.

root@ubuntu14-pv1:~# vi /etc/redis/redis.conf

daemonize yes

pidfile /var/run/redis/redis-server.pid

port 6379

timeout 0

tcp-keepalive 0


bind 10.0.10.1 # 서버 머신 자체의 IP 주소


# slaveof 10.0.10.3 6379 # Master 는 slaveof 설정이 없어야 한다

masterauth 1234

requirepass 1234


repl-ping-slave-period 10

repl-timeout 60


loglevel notice


logfile /var/log/redis/redis-server.log


databases 16


save 900 1

save 300 10

save 60 10000


stop-writes-on-bgsave-error yes


rdbcompression yes

rdbchecksum yes

dbfilename dump.rdb


dir /var/lib/redis


slave-read-only yes


# Yes for high bandwidth, No for high latency or high traffic

repl-disable-tcp-nodelay yes


slave-priority 100


# Mitigation for replication lag, only for Master

#min-slaves-to-write 1

#min-slaves-max-lag 10


appendonly no

appendfilename "appendonly.aof"

appendfsync everysec

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb


lua-time-limit 5000


slowlog-log-slower-than 10000

slowlog-max-len 128


notify-keyspace-events ""


hash-max-ziplist-entries 512

hash-max-ziplist-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

zset-max-ziplist-entries 128

zset-max-ziplist-value 64


activerehashing yes


client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60


hz 10


aof-rewrite-incremental-fsync yes


* ubuntu14-pv2, 3 서버를 Redis slave 로 설정하기 위한 작업이다

* 붉은 글씨의 라인에 쓰인 설명을 잘 참고한다. 나머지 부분 내용은 Master와 동일하다

root@ubuntu14-pv2:~# vi /etc/redis/redis.conf

daemonize yes

pidfile /var/run/redis/redis-server.pid

port 6379

timeout 0

tcp-keepalive 0


bind 10.0.10.2 # 서버 머신 자체의 IP주소


slaveof 10.0.10.1 6379 # 초기에 Master 로 사용할 1번 서버의 IP주소

masterauth 1234

requirepass 1234


repl-ping-slave-period 10

repl-timeout 60


loglevel debug


logfile /var/log/redis/redis-server.log


databases 16


save 900 1

save 300 10

save 60 10000


stop-writes-on-bgsave-error yes


rdbcompression yes

rdbchecksum yes

dbfilename dump.rdb


dir /var/lib/redis


slave-read-only yes


# Yes for high bandwidth, No for high latency or high traffic

repl-disable-tcp-nodelay yes


slave-priority 100


# Mitigation for replication lag, Comment out for slaves

#min-slaves-to-write 1

#min-slaves-max-lag 10


appendonly no

appendfilename "appendonly.aof"

appendfsync everysec

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb


lua-time-limit 5000


slowlog-log-slower-than 10000

slowlog-max-len 128


notify-keyspace-events ""


hash-max-ziplist-entries 512

hash-max-ziplist-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

zset-max-ziplist-entries 128

zset-max-ziplist-value 64


activerehashing yes


client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60


hz 10


aof-rewrite-incremental-fsync yes


* Master부터 두 번째 Slave 까지, 모두 위와 같이 작업을 했다면, Master 부터 순차적으로 Redis 를 재시작한다.

* 진행 과정을 관찰하기 위해 redis-server 기동 후 log에 tail 을 걸어 둔다

root@ubuntu14-pv1:~# service redis-server restart

root@ubuntu14-pv1:~# tail -f /var/log/redis/redis-server.log

                _._                                                  

           _.-``__ ''-._                                             

      _.-``    `.  `_.  ''-._           Redis 2.8.4 (00000000/0) 64 bit

  .-`` .-```.  ```\/    _.,_ ''-._                                   

 (    '      ,       .-`  | `,    )     Running in stand alone mode

 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379

 |    `-._   `._    /     _.-'    |     PID: 1140

  `-._    `-._  `-./  _.-'    _.-'                                   

 |`-._`-._    `-.__.-'    _.-'_.-'|                                  

 |    `-._`-._        _.-'_.-'    |           http://redis.io        

  `-._    `-._`-.__.-'_.-'    _.-'                                   

 |`-._`-._    `-.__.-'    _.-'_.-'|                                  

 |    `-._`-._        _.-'_.-'    |                                  

  `-._    `-._`-.__.-'_.-'    _.-'                                   

      `-._    `-.__.-'    _.-'                                       

          `-._        _.-'                                           

              `-.__.-'                                               


[1140] 09 Jul 01:13:08.762 # Server started, Redis version 2.8.4

[1140] 09 Jul 01:13:08.763 * DB loaded from disk: 0.001 seconds

[1140] 09 Jul 01:13:08.763 * The server is now ready to accept connections on port 6379

[1140] 09 Jul 01:13:08.763 - DB 0: 633 keys (0 volatile) in 1536 slots HT.

[1140] 09 Jul 01:13:08.763 - 0 clients connected (0 slaves), 834680 bytes in use

[1140] 09 Jul 01:13:09.189 * Starting BGSAVE for SYNC

[1140] 09 Jul 01:13:09.191 * Background saving started by pid 1143

[1143] 09 Jul 01:13:09.218 * DB saved on disk

[1143] 09 Jul 01:13:09.219 * RDB: 0 MB of memory used by copy-on-write



Redis Master에 데이터를 입력하고 Slave 로 복제 되는지 확인하자


* Sentinel 전용 머신(ubuntu14-pvha1,2)에서는 Sentinel만 작동하여야 하므로, redis-server 데몬을 내리고 자동실행을 해제한다(source build 가 아닌  apt-get 같은 방법으로 redis-server 를 설치하면 부팅후 자동실행까지 설정되므로)

root@ubuntu14-pvha2:~# service redis-server stop

root@ubuntu14-pvha2:~# rm /etc/init.d/redis-server

root@ubuntu14-pvha2:~# update-rc.d redis-server remove


* Sentinel 전용 머신(또는 redis-tools 가 설치된 외부 머신)의 redis client 를 이용해서 확인을 수행한다

* Master 에 접속하여 "testkey01":"data1234" Key-Value 를 저장하고 Slave 에서 get 으로 확인

root@ubuntu14-pvha2:~# redis-cli -a 1234 -h 10.0.10.1 -p 6379

10.0.10.1:6379> info replication

# Replication

role:master

connected_slaves:2

slave0:ip=10.0.10.2,port=6379,state=online,offset=1386,lag=0

slave1:ip=10.0.10.3,port=6379,state=online,offset=1386,lag=0

master_repl_offset:1386

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:2

repl_backlog_histlen:1385

10.0.10.1:6379> set testkey01 'data1234'

OK

10.0.10.1:6379> 

root@ubuntu14-pvha1:~# redis-cli -a 1234 -h 10.0.10.2 -p 6379

10.0.10.2:6379> get testkey01

"data1234"

10.0.10.2:6379> 

root@ubuntu14-pvha1:~# redis-cli -a 1234 -h 10.0.10.3 -p 6379

10.0.10.3:6379> get testkey01

"data1234"


전체적인 동작이 정상적인 것을 확인했다. 자 이 상황에서 Quiz 하나 !(검토하신 아이디어를 공유하거나 질문 하실 분은 댓글로 기재해 주세요)


* <Quiz 1> Master 서버 머신이 Down(redis.io 문서에서는 partition 이라고 표현한다. 즉 shutdown, power down, network 단절 등) 된다면 어떤 일이 일어 나는지 생각해 보자. Master 는 선출될 수 있을까? Read 동작은 가능한가? 원래의 Master 가 다시 연결되면 전체 시스템이 정상 동작 할까?(전제조건: Master 1, Slave 2(read-only), Sentinel 3, quorom=2 일 경우)

[답은 아래로 drag 하세요. 중요한 것은 왜 그럴까를 따져 보는 것입니다]

 - Master 는 선출되지 않는다. 즉, 쓰기 작업은 불가능

 - Read 는 가능하다(Sentinel을 통하여 Slave 를 알아 낸다면)

 - Master 가 살아나면 원 상태로 정상 동작 한다


여기까지 3대의 머신으로 Redis Master-Slave 를 구성하는 기본 작업을 진행했다. Master 를 Write 전용으로, Slave 를 Read 전용으로 하여 부하는 분산하고 데이터를 복제 보존하는 효과까지는 기대할 수 있지만, 자동으로 Failover를 수행하지는 못하는 구성이다.


2. Redis Sentinel 의 추가 설정과 고가용(HA)적 운영


이제 목표 아키텍처인 그림 3 과 같은 구성을 만드는 것이 다음 작업이다.


5대의 머신에 Sentinel을 설정, 기동하고 log 파일을 보면서 진행 과정 관찰


* Sentinel 수행 머신인 ubuntu14-pv1~3, ubuntu14-pvha1,2 에서 각각 다음의 작업을 동일하게 수행한다.

* 모든 Sentinel의 설정 파일은 동일하여야 한다

* 현재의 Redis Master 인 10.0.10.1:6379 를 모니터 대상으로 설정하며, quorom=2, 서비스 이름은 stn-master

root@ubuntu14-pv1:~# vi /etc/redis/sentinel.conf

daemonize yes

pidfile "/var/run/redis/sentinel.pid"

logfile "/var/log/redis/sentinel.log"


# port <sentinel-port>

port 26379


sentinel monitor stn-master 10.0.10.1 6379 2 # <== Failover시 Sentinel 이 자동으로 값들을 수정

sentinel down-after-milliseconds stn-master 2000

sentinel failover-timeout stn-master 90000 <== Failover 완료되어야 하는 시간. 데이터 량에 따라 값을 증가

sentinel auth-pass stn-master 1234

sentinel config-epoch stn-master 1 # <== Failover시 Sentinel 이 자동으로 수정(1씩 증가)


# <=== 여기부터 Sentinel 이 자동으로 설정 내용을 추가, 관리


root@ubuntu14-pv1:~# /usr/bin/redis-sentinel /etc/redis/sentinel.conf

root@ubuntu14-pv1:~# tail -f /var/log/redis/sentinel.log

                _._                                                  

           _.-``__ ''-._                                             

      _.-``    `.  `_.  ''-._           Redis 2.8.4 (00000000/0) 64 bit

  .-`` .-```.  ```\/    _.,_ ''-._                                   

 (    '      ,       .-`  | `,    )     Running in sentinel mode

 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379

 |    `-._   `._    /     _.-'    |     PID: 1155

  `-._    `-._  `-./  _.-'    _.-'                                   

 |`-._`-._    `-.__.-'    _.-'_.-'|                                  

 |    `-._`-._        _.-'_.-'    |           http://redis.io        

  `-._    `-._`-.__.-'_.-'    _.-'                                   

 |`-._`-._    `-.__.-'    _.-'_.-'|                                  

 |    `-._`-._        _.-'_.-'    |                                  

  `-._    `-._`-.__.-'_.-'    _.-'                                   

      `-._    `-.__.-'    _.-'                                       

          `-._        _.-'                                           

              `-.__.-'                                               


[1094] 09 Jul 15:58:49.321 # Sentinel runid is 0f83482ecc6a3724d40f4469ac8368a1742be8fd

[1094] 09 Jul 15:58:50.324 * +slave slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.1 6379

[1094] 09 Jul 15:58:50.324 * +slave slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.1 6379

[1094] 09 Jul 15:58:54.013 * +sentinel sentinel 10.0.10.2:26379 10.0.10.2 26379 @ stn-master 10.0.10.1 6379

[1094] 09 Jul 15:58:55.429 * +sentinel sentinel 10.0.10.3:26379 10.0.10.3 26379 @ stn-master 10.0.10.1 6379

[1094] 09 Jul 15:58:56.708 * +sentinel sentinel 10.0.0.1:26379 10.0.0.1 26379 @ stn-master 10.0.10.1 6379

[1094] 09 Jul 15:58:57.791 * +sentinel sentinel 10.0.0.2:26379 10.0.0.2 26379 @ stn-master 10.0.10.1 6379


<...>


root@ubuntu14-pvha2:~# vi /etc/redis/sentinel.conf

root@ubuntu14-pvha2:~# /usr/bin/redis-sentinel /etc/redis/sentinel.conf

                _._                                                  

           _.-``__ ''-._                                             

      _.-``    `.  `_.  ''-._           Redis 2.8.4 (00000000/0) 64 bit

  .-`` .-```.  ```\/    _.,_ ''-._                                   

 (    '      ,       .-`  | `,    )     Running in sentinel mode

 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379

 |    `-._   `._    /     _.-'    |     PID: 26166

  `-._    `-._  `-./  _.-'    _.-'                                   

 |`-._`-._    `-.__.-'    _.-'_.-'|                                  

 |    `-._`-._        _.-'_.-'    |           http://redis.io        

  `-._    `-._`-.__.-'_.-'    _.-'                                   

 |`-._`-._    `-.__.-'    _.-'_.-'|                                  

 |    `-._`-._        _.-'_.-'    |                                  

  `-._    `-._`-.__.-'_.-'    _.-'                                   

      `-._    `-.__.-'    _.-'                                       

          `-._        _.-'                                           

              `-.__.-'                                               


[4204] 09 Jul 15:58:55.946 # Sentinel runid is 82a6faa318223af0362f59095f8c138be9f9e76d

[4204] 09 Jul 15:58:56.949 * +slave slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.1 6379

[4204] 09 Jul 15:58:56.949 * +slave slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.1 6379

[4204] 09 Jul 15:58:57.617 * +sentinel sentinel 10.0.10.3:26379 10.0.10.3 26379 @ stn-master 10.0.10.1 6379

[4204] 09 Jul 15:58:57.731 * +sentinel sentinel 10.0.10.1:26379 10.0.10.1 26379 @ stn-master 10.0.10.1 6379

[4204] 09 Jul 15:58:57.935 * +sentinel sentinel 10.0.0.1:26379 10.0.0.1 26379 @ stn-master 10.0.10.1 6379

[4204] 09 Jul 15:58:58.182 * +sentinel sentinel 10.0.10.2:26379 10.0.10.2 26379 @ stn-master 10.0.10.1 6379


* 서비스에 투입된 Sentinel 의 정보를 확인해 보자(모든 Sentinel 에서의 조회 값이 동일함)

root@ubuntu14-pvha2:~# redis-cli -a 1234 -h 10.0.10.1 -p 26379

10.0.10.1:26379> info

# Server

redis_version:2.8.4

redis_git_sha1:00000000

redis_git_dirty:0

redis_build_id:a44a05d76f06a5d9

redis_mode:sentinel

os:Linux 3.13.0-55-generic x86_64

arch_bits:64

multiplexing_api:epoll

gcc_version:4.8.2

process_id:1094

run_id:0f83482ecc6a3724d40f4469ac8368a1742be8fd

tcp_port:26379

uptime_in_seconds:177

uptime_in_days:0

hz:11

lru_clock:1036194

config_file:/etc/redis/sentinel.conf


# Sentinel

sentinel_masters:1

sentinel_tilt:0

sentinel_running_scripts:0

sentinel_scripts_queue_length:0

master0:name=stn-master,status=ok,address=10.0.10.1:6379,slaves=2,sentinels=5


이제 설정 과정은 끝이 났다. 테스트 시나리오를 정하고 검증을 수행해 보자. 본 포스팅의 하이라이트라고 할 수도 있는 중요한 부분이다.


Test Case 1: Master 셧다운


* Master에 ssh 로 접속하여 셧다운을 수행하고 Slave 2 의 로그를 살펴 보자

root@ubuntu14-pv1:~# shutdown -h now


* Slave 2(10.0.10.2)의 로그 모니터링, 해설

[1063] 09 Jul 16:03:13.245 # +sdown master stn-master 10.0.10.1 6379 <== Down 감지(주관적)

[1063] 09 Jul 16:03:13.323 # +odown master stn-master 10.0.10.1 6379 #quorum 2/2 <== Down 감지(객관적)

[1063] 09 Jul 16:03:13.323 # +new-epoch 10 <== 후속 조치 발동

[1063] 09 Jul 16:03:13.323 # +try-failover master stn-master 10.0.10.1 6379 <== Failover 발동

[1063] 09 Jul 16:03:13.324 # +vote-for-leader 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 10

[1063] 09 Jul 16:03:13.327 # 10.0.0.1:26379 voted for 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 10

[1063] 09 Jul 16:03:13.327 # 10.0.0.2:26379 voted for 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 10

[1063] 09 Jul 16:03:13.328 # 10.0.10.2:26379 voted for 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 10

[1063] 09 Jul 16:03:13.390 # +elected-leader master stn-master 10.0.10.1 6379 <== 투표 종료

[1063] 09 Jul 16:03:13.391 # +failover-state-select-slave master stn-master 10.0.10.1 6379

[1063] 09 Jul 16:03:13.458 # +selected-slave slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.1 6379 <== Slave2(10.0.10.3:6379) 이 최종 선정

[1063] 09 Jul 16:03:13.458 * +failover-state-send-slaveof-noone slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.1 6379 <== Slave2 를 10.0.10.1 의 slave 에서 제외

[1063] 09 Jul 16:03:13.513 * +failover-state-wait-promotion slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.1 6379

[1063] 09 Jul 16:03:14.392 # +promoted-slave slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.1 6379 <== Slave2 를 Master 로 승격 요청

[1063] 09 Jul 16:03:14.393 # +failover-state-reconf-slaves master stn-master 10.0.10.1 6379

[1063] 09 Jul 16:03:14.443 * +slave-reconf-sent slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.1 6379

[1063] 09 Jul 16:03:14.635 # +sdown sentinel 10.0.10.1:26379 10.0.10.1 26379 @ stn-master 10.0.10.1 6379

[1063] 09 Jul 16:03:15.410 * +slave-reconf-inprog slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.1 6379

[1063] 09 Jul 16:03:15.485 # -odown master stn-master 10.0.10.1 6379

[1063] 09 Jul 16:03:16.423 * +slave-reconf-done slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.1 6379 <== 기존 Slave2의 config 를 변경(10.0.10.2 의 slave로)

[1063] 09 Jul 16:03:16.524 # +failover-end master stn-master 10.0.10.1 6379 <== Failover 종료 알림

[1063] 09 Jul 16:03:16.524 # +switch-master stn-master 10.0.10.1 6379 10.0.10.2 6379

[1063] 09 Jul 16:03:16.525 * +slave slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.2 6379

[1063] 09 Jul 16:03:16.560 * +slave slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.2 6379 <== Down된 10.0.10.1 은 Slave 로 내려감

[1063] 09 Jul 16:03:18.611 # +sdown slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.2 6379


* 이제 1번 과정에서 redis-cli 로 Master에 데이터를 입력(Set)하고 Slave에서 Get 으로 확인하는 과정을 수행해 보자

root@ubuntu14-pvha1:~# redis-cli -a 1234 -h 10.0.10.3 -p 6379

10.0.10.2:6379> keys *

1) "testkey01"

10.0.10.2:6379> set key_into_master2 'data5678'

OK

10.0.10.2:6379> 

root@ubuntu14-pvha1:~# redis-cli -a 1234 -h 10.0.10.2 -p 6379

10.0.10.3:6379> keys *

1) "key_into_master2"

2) "testkey01"

10.0.10.3:6379> 



Test Case 2: 새로운 Master 셧다운


* Case 1 에 이어서 Master(10.0.10.2)에 ssh 로 접속하여 셧다운을 수행하고 Master, Sentinel 머신측 의 로그를 살펴 보자

root@ubuntu14-pv2:~# shutdown -h now


* Slave(10.0.10.2)의 로그 모니터링

[1063] 09 Jul 16:13:22.809 # +sdown master stn-master 10.0.10.2 6379

[1063] 09 Jul 16:13:22.902 # +new-epoch 11

[1063] 09 Jul 16:13:22.902 # +vote-for-leader f7ca052de1d504d263511d5fb9d032c56a0fa351 11

[1063] 09 Jul 16:13:23.910 # +odown master stn-master 10.0.10.2 6379 #quorum 3/2 <== 셧다운 감지

[1063] 09 Jul 16:13:24.666 # +sdown sentinel 10.0.10.2:26379 10.0.10.2 26379 @ stn-master 10.0.10.2 6379

<== Master 완료 후 Failover 완료시까지 시간(sentinel.conf 에 90초 설정) 경과, 결국 Failover 실패로 끝남

[1063] 09 Jul 16:16:22.920 # +new-epoch 12

[1063] 09 Jul 16:16:22.921 # +try-failover master stn-master 10.0.10.2 6379

[1063] 09 Jul 16:16:22.921 # +vote-for-leader 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 12

[1063] 09 Jul 16:16:22.923 # 10.0.0.2:26379 voted for 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 12

[1063] 09 Jul 16:16:22.923 # 10.0.0.1:26379 voted for 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 12

[1063] 09 Jul 16:16:22.984 # +elected-leader master stn-master 10.0.10.2 6379 <== 투표 종료

[1063] 09 Jul 16:16:22.985 # +failover-state-select-slave master stn-master 10.0.10.2 6379

[1063] 09 Jul 16:16:23.085 # +selected-slave slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.2 6379 <== 유일한 Redis(10.0.10.3:6379) 가 최종 선정

[1063] 09 Jul 16:16:23.086 * +failover-state-send-slaveof-noone slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.2 6379 <== 10.0.10.2 의 slave 에서 제외

[1063] 09 Jul 16:16:23.157 * +failover-state-wait-promotion slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.2 6379

[1063] 09 Jul 16:16:24.071 # +promoted-slave slave 10.0.10.3:6379 10.0.10.3 6379 @ stn-master 10.0.10.2 6379 <== Master 로 승격 요청

[1063] 09 Jul 16:16:24.072 # +failover-state-reconf-slaves master stn-master 10.0.10.2 6379

[1063] 09 Jul 16:16:24.117 * +slave-reconf-sent slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.2 6379

[1063] 09 Jul 16:16:24.118 # +failover-end master stn-master 10.0.10.2 6379

[1063] 09 Jul 16:16:24.118 # +switch-master stn-master 10.0.10.2 6379 10.0.10.3 6379

[1063] 09 Jul 16:16:24.119 * +slave slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.3 6379

[1063] 09 Jul 16:16:24.146 * +slave slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.3 6379

<== Down 된 10.0.10.1, 10.0.10.2 는 Slave 로...

[1063] 09 Jul 16:16:26.121 # +sdown slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.3 6379

[1063] 09 Jul 16:16:26.212 # +sdown slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.3 6379


* Sentinel 전용머신(10.0.0.2)의 로그 모니터링

[4204] 09 Jul 16:13:23.058 # +new-epoch 11

[4204] 09 Jul 16:13:23.058 # +vote-for-leader f7ca052de1d504d263511d5fb9d032c56a0fa351 11

[4204] 09 Jul 16:13:23.700 # +sdown master stn-master 10.0.10.2 6379

[4204] 09 Jul 16:13:23.801 # +odown master stn-master 10.0.10.2 6379 #quorum 3/2

[4204] 09 Jul 16:13:24.841 # +sdown sentinel 10.0.10.2:26379 10.0.10.2 26379 @ stn-master 10.0.10.2 6379

[4204] 09 Jul 16:16:23.079 # +new-epoch 12

[4204] 09 Jul 16:16:23.079 # +vote-for-leader 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3 12

[4204] 09 Jul 16:16:24.496 # +switch-master stn-master 10.0.10.2 6379 10.0.10.3 6379

[4204] 09 Jul 16:16:24.497 * +slave slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.3 6379

[4204] 09 Jul 16:16:24.533 * +slave slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.3 6379

[4204] 09 Jul 16:16:26.528 # +sdown slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.3 6379

[4204] 09 Jul 16:16:26.583 # +sdown slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.3 6379



2대의 Redis 서버가 남은 상황에서 Master 머신 마저 셧다운 되었을 때의 결과가 흥미롭다. 첫 번째 Failover 는 후보 머신이 더 이상 없어서 Failover timeout(90초)까지 경과하고, 이후의 후속 조치로 마지막 남은 Redis가 Master로 승격되어 처리됨을 확인하였다. 다시 말하면, Redis 시스템 내의 모든 Slave 는 Read-only 이므로, 설정된 Failover timeout 만큼의 시간 동안은 데이터의 쓰기가 실패하게 됨을 잘 알고 상황에 적절히 대처할 수 있어야 한다.



장애 후 복구 과정에서의 처리 절차


위의 Test Case 2까지 진행된 상황에서 redis-cli 로 접속하여 다음과 같이 데이터를 기록해 두자.

root@ubuntu14-pvha1:~# redis-cli -a 1234 -h 10.0.10.3 -p 6379

10.0.10.3:6379> set testkey02 'data7890'

OK


이제 현재의 Master 인 10.0.10.3 의 Redis 에는 최종 버전의 데이터가 저장되어 있다. 여기서 두 번째 Quiz!

셧다운되어 있는 10.0.10.2 머신이 다시 기동되었을 경우 어떤 일이 일어 나는가?10.0.10.2 에 Sentinel 이 기동되었다면 어떤 일이 일어날까? 과연 마지막에 저장한 testkey02 데이터는 보존 될 것인가?


[답은 아래로 drag 하세요] 전제 조건: 기존에 작동하던 3개의 Sentinel 이 작동 상황을 잘 유지하고 있을 경우

10.0.10.2 가 부팅되고  Redis 서비스가 작동 되면, 약간의 시간이 지난 후, 셧다운 되기 전 Master 였던 10.0.10.2는 얌전히 Slave 로 떨어지고, 마지막에 저장된 testkey02 데이터는 이상 없이  보존된다.


* 최종 Master 머신(10.0.0.3)의 로그 모니터링

[1063] 09 Jul 16:16:26.121 # +sdown slave 10.0.10.1:6379 10.0.10.1 6379 @ stn-master 10.0.10.3 6379

[1063] 09 Jul 16:16:26.212 # +sdown slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.3 6379

[1063] 09 Jul 16:49:19.799 # -sdown slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.3 6379

[1063] 09 Jul 16:50:50.019 * +fix-slave-config slave 10.0.10.2:6379 10.0.10.2 6379 @ stn-master 10.0.10.3 6379 <== Sentinel 에 의해, 셧다운 전에 Master였던 10.0.10.2 Redis는 Slave 로 전환된다



본 포스팅의 실험 결과에서 가장 중요하게 생각해야 할 점은, Sentinel 을 통해 가용성을 유지하기 위한 본 아키텍처에서, Sentinel 을 확인 없이 셧다운한 상태에서 Redis 를 기동하게 되면, 원래 Master 였던 Redis 의 과거 버전 데이터로 인하여 최근 버전에 데이터를 잃어버릴 가능성이 다분하다는 것이다.


그렇다면, 만약 어쩔 수 없는 사정으로 Sentinel 이 작동하지 않게 되어 있고, 수작업으로 최신 데이터를 유지하고 싶다면 어떻게 하면 될까?아래의 순서를 잘 이해하고 차분히 작업을 진행하면 된다.


첫째. 마지막 버전의 데이터를 저장하고 있다고 판단되는 Redis 머신을 Master로 결정한다

둘째, 현재까지 작업에 투입된 모든 Sentinel 을 셧다운하고(# killall redis-sentinel), Redis 서비스도 종료한다(service redis-server stop)

셋째, Redis M-S 구축 첫 단계의 설정에서, Master로 결정한 머신의 redis.conf 에서 slaveof 라인을 comment 처리하고,나머지 머신의 redis.conf 에서 slaveof 라인의 주소를 Master 주소로 변경한다

넷째, 만약을 위해, 각 Redis 머신들의 데이터 파일(/var/lib/redis/dump.rdb)를 백업해 둔다

다섯째, 모든 Sentinel 들의 config 를 아래와 같이 동일하게 수정한다

root@ubuntu14-pvha2:~# vi /etc/redis/sentinel.conf 

...

port 26379


sentinel monitor stn-master 10.0.10.3 6379 2 <== Master로 결정한 머신의 주소로 변경

sentinel down-after-milliseconds stn-master 2000

sentinel failover-timeout stn-master 90000

sentinel auth-pass stn-master 1234

sentinel config-epoch stn-master 1 <== 최종 값을 1로 변경


#

# Generated by CONFIG REWRITE <== 여기부터 마지막 라인까지 삭제

dir "/root"

sentinel known-slave stn-master 10.0.10.1 6379

sentinel known-slave stn-master 10.0.10.2 6379

sentinel known-sentinel stn-master 10.0.10.2 26379 f7ca052de1d504d263511d5fb9d032c56a0fa351

sentinel known-sentinel stn-master 10.0.10.1 26379 0f83482ecc6a3724d40f4469ac8368a1742be8fd

sentinel known-sentinel stn-master 10.0.0.1 26379 9e177cbda8d73c7fc11ac17a6a6d0eef02b3b762


sentinel known-sentinel stn-master 10.0.10.3 26379 1a80939f2d06e6c1d5073ea0dca121c2c02ac5f3

여섯째, 여기 까지의 모든 작업 내용을 다시 점검

일곱째, Redis Master - Slave 순으로 시작, Sentinel 을 모두 시작 후 정상 작동 및 데이터 점검



3. Redis Client example - python 버전


다음은 Redis 와 Sentinel 이 적용된 데이터스토어에 접근하고 각종 Key-Value 데이터를 처리하는 Python Client 의 예제이다. 거의 프로그램 개발 초기의 원형이라고 보면 되겠다. 개발을 위한 라이브러리는 redis-py 를 pip 로 설치하는 정도면 충분하다.


* Redis Master 에 접속하여 쇼핑 데이터를 기록, Slave 에서 데이터를 조회, 출력하는 Python application 이다

( 참고: 1000 명의 고객 쇼핑 카트 정보 기록에 0.18 sec, 읽기에 0.1 sec 소요 - 1cpu, 1GB ram, xen vm)

root@ubuntu14-pvha2:~# apt-get install pip

root@ubuntu14-pvha2:~# pip install redis

root@ubuntu14-pvha2:~/pysrc# vi sentinel_test3.py 

# -*- coding:utf-8 -*-
  
import sys, random, time
from redis import Redis, exceptions, RedisError
from redis.sentinel import (Sentinel, SentinelConnectionPool,ConnectionError,
                            MasterNotFoundError, SlaveNotFoundError)
  
# Redis 접속 기본 설정값
listSentinel = [('10.0.10.1', 26379), ('10.0.10.2', 26379), ('10.0.10.3', 26379), ('10.0.0.2', 26379)]
strServiceName = 'stn-master'
strRedisPass = '1234'
nDB = 0
  
nMaxUser = 1000
  
sentinel = Sentinel(listSentinel, socket_timeout=0.1)
try:
    #sentinel.discover_master(strServiceName) # No need for this
    #sentinel.discover_slaves(strServiceName)
    master = sentinel.master_for(strServiceName, password=strRedisPass, db=nDB, socket_timeout=0.1)
    slave = sentinel.slave_for(strServiceName, password=strRedisPass, db=nDB, socket_timeout=0.1)
  
except MasterNotFoundError:
    print 'Master not found or Sentinel instances not runnung'
    sys.exit()
except SlaveNotFoundError:
    print 'Slave not found or Sentinel instances not runnung'
    sys.exit()
except ConnectionError:
    print 'Connection Error. Check if Sentinel instances are running'
    sys.exit()
  
start_time = time.time()
  
for n in range(1, nMaxUser):
    for m in range(1, random.randint(0, 5)):
        master.hset( "cart.user:"+str(n), random.randint(1, 300), random.randint(1, 5) )
  
time_elapsed_1 = time.time() - start_time
  
start_time = time.time()
  
for n in range(1, nMaxUser):
    slave.hgetall("cart.user:"+str(n))
  
time_elapsed_2 = time.time() - start_time
  
count = 0
  
for n in range(1, nMaxUser):
    data = slave.hgetall("cart.user:"+str(n))
    if len(data) > 0:
        count = count + 1
        print count, " [Cart.user:"+str(n)+"] ", data
  
print "---------------------------------------------------"
print "[Time for writing]: ", time_elapsed_1, " sec., [Time for reading]: ", time_elapsed_2, " sec."



주의 사항: Redis 를 서비스에 적용했을 때의 '대재앙' 을 막아라


운영상 설정 사항 관련 주의 사항

- Sentinel(즉 redis-sentinel) 을 부팅시 자동 실행하도록 두지 마라: 최종 변경 데이터를 날리거나 전체 데이터가 날아갈 수 있다. 귀차니즘은 당신의 몸값을 깎을 수도 있다.

- 데이터를 Disk에 저장하는 save 설정 주기를 짧게 하지 마라: Disk IO 때문에 속도 저하가 발생할 수 있다. 다양한 관찰과 실험을 통해 최적의 save 설정 주기를 찾고 사용하라.

- 데이터 량에 따른 최적의 Failover timeout 값을 찾고 sentinel.conf에 적용하라: 이유는 위에서 설명하였다.

- 메모리 사용 량을 초과하도록 방치하면 안된다: 자칫 메인 메모리를 다 쓰면 가상메모리까지 사용하게 되어 디스크 스와핑이 다량 발생하고, 시스템은 거의 먹통 수준에 빠질 수도 있다.

- Sentinel은 아직은 불완전하다. 결코 과신하지 마라: 덜 Busy한 시간에 주기적으로 dump.db를 백업하고 중요한 장애 복구시는 수동으로 M-S를 지정해서 작업한다.

- Redis.log, Sentinel.log 를 수시로 모니터링하라: Redis 머신의 디스크가 고장나는 등의 하드웨어 장애는 Sentinel이 감지할 수 없다. Master 가 이런 장애를 만나면 Read-only 상태로 바뀔 수도 있다(config 설정에 따라 다르긴 하다)



데이터 관리 방법/설계 관련 주의 사항

- 운영 중에 keys, flushall, flushdb 명령어를 쓰지 마라: 메모리 DB라고 과신하다가 큰 코 다친다. Single thread 방식이며, 데이터 구조와 처리 방식이 상대적으로 Memcached보다 복잡해서 데이터 건수가 많아지면 Memcached 보다는 훨씬 느려진다(널리 알려진 사실이다. 100만건 처리에 멤캐시는 1~2ms, 레디스는 1000ms). 운영 중에 이런 전체 데이터를 긁는 명령을 쓴다면 Redis 를 사용하는 시스템이 일시 먹통이 될 테고, 한 동안 뒤통수가 따가울 수도 있다. 운영지침이나 데이터 관리 등급을 따로 지정해서 체계적으로 데이터를 운영/관리하는 방식을 써야 할지도 모른다

- 개발자는 Redis Master 는 Write-only로, Slave는 Read-only 로 잘 구분해서 잘 써야한다. 코드리뷰시 주요 검토사항이 될 수도 있다.

- 콜렉션(Collection: List, Set, Hash 등) 에는 한 번에 최대 수 천 건 정도의 데이터만 Insert한다.

- 최대 데이터 량을 예측하고, 필요시 클러스터링과 샤딩을 검토하여 아키텍처 설계에 반영하고 개선하라. 때때로 Zookeeper 나 Haproxy 와 같은 다른 솔루션을 검토해야 할 경우도 있을 수 있다.



- Barracuda -


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들