Redis - Persistence, Availability & Security

By Mir

Transcript

1. Redis Persistence, Availability & Security
2. • Persistence ◦ RDB ▪ Data dump to disk (snapshot) ▪ 스냅샷을 주기적으로 백업하여 장애/재해 복구 시 주요 백업 전략으로 활용가능 (백업 주기 만큼의 데이터 손실은 감수해야한다) ▪ 데이터 크기에 따라 다르지만 기본적으로 AOF보다 빠르게 재시작 가능 ▪ 스냅샷 시점 • SAVE command (main process, no cow) • SAVE configure (child process, cow) • BGSAVE (child process, cow) • Replication (child process, cow) ▪ 실 메모리 사용량 고려 • copy-on-write ◦ 이론적으로 레디스 서버 인스턴스의 총 memory 사용량의 2배 정도의 메모리가 필요 (server log에 cow시 추가적으로 사용한 메모리의 기록이 남는다. 잘 관찰 후 넉넉하게 메모리 사용량을 결정해야한다) • vm.overcommit_memory=1 ◦ memory page size를 넘어가는 memory commit 시 process kill을 방지!
3. • Persistence ◦ AOF ▪ logging all write commands ▪ RDB 대비 안정적, append only! (우리는 fsync 기본값 사용중) ▪ readable log (ex. flushall -> aof 파일에서 해당 부분만 삭제 -> 서버 재시작) • AOF rewrite 시점이 지나가면 무용지물 ▪ 파일용량이 RDB보다 크다 (rewrite시의 latency, 재시작 속도가 RDB보다 느림) ▪ 스냅샷 시점 • AOF rewrite (ex. auto-aof-rewrite-percentage 100, AOF 파일이 100% 커지면 rewrite) • BGREWRITEAOF command (둘다 cow, AOF만 사용하더라도 메모리 사용량 고려 필요) ▪ 현재 우리는 안정성을 위해 master는 AOF만, 백업을 위해 slave는 RDB만을 사용하고 RDB 파일을 주기적으로 백업중(??) (slave SAVE 900 1, 900초동안 1개의 키가 변경되면 RDB 파일 생성. 백업을 하더라도 900초 정도의 데이터 유실 발생)
4. • Availability ◦ Sentinel ▪ Monitoring + Automatic Failover ▪ 장애 발생 시 자동으로 슬레이브 마스터 교체작업 진행 (사실 이게 전부...) ▪ Sentinel이 각 노드를 감시 ▪ Master Down 시 Slave Master로 승격 Sentinel Master Slave 구성 1
5. • Availability ◦ Sentinel ▪ BUT!, Master, Slave 동시 장애 발생시에는? ▪ Slave나 Sentinel이 죽는경우? ▪ 실서버에서는 구성 2와 같은 아키텍처가 필요 ▪ 2대의 redis instance가 동시에 종료되면? ▪ 변경된 1대의 Master로 서비스 가능 ▪ sentinel이 죽으면? ▪ 다른 sentinel로 failover 처리가능 ▪ instance가 많을수록 좋을듯? (돈이 문제) 구성 2 Master/ Sentinel Slave 1/ Sentinel Slave 2/ Sentinel Sentinel Sentinel
6. • Availability ◦ Failover Process ▪ Master Down!! • down 감지 (quorum 값에 따라 down 감지 횟수 설정 가능) • failover 발동 • 투표 종료 후 새로운 master가 될 slave node 선정 • 새로 선정된 master를 slave에서 제외 • master로 승격 요청 • 남아있는 slave의 master 주소를 변경 • failover 종료 알림 • down된 master는 slave로 내려감 ▪ new Master Down!! • down 감지 • 첫번째 failover의 timeout이 경과 • 마지막 남은 slave를 새로운 master로 선정 • master로 승격
7. • Availability ◦ Failover Process ▪ client가 바라보는 sentinel이 모두 unavailable ㅜㅜ • 마지막 버전의 데이터를 저장하고 있다고 판단되는 redis 머신을 master로 결정 • 현재까지 작업에 투입된 모든 sentinel를 셧다운, redis 서비스도 종료 • master로 결정한 머신의 slaveof를 comment 처리 및 종료 처리한 나머지 머신의의 slaveof를 master로 결정한 머신의 주소로 설정 • 만약을 위해 각 redis의 RDB 백업 • sentinel의 config 값을 다음과 같이 수정 • redis master - slave 순으로 재시작, sentinel을 모두 재시작 후 정상 작동 및 데이터 점검 sentinel monitor stn-master {master-address} sentinel down-after-milliseconds stn-master 2000 sentinel failover-timeout stn-master 90000 (data 량에 따라 적당한 값) sentinel config-epoch stn-master 1 (failover 수)
8. • Availability ◦ 주의사항 ▪ instance 부팅시 sentinel을 자동으로 실행하지 않도록 주의 (실행 순서에 따라 master - slave sync가 꼬여 데이터가 날라갈 수 있음) ▪ 데이터량에 따른 적절한 failover timeout값을 설정해야한다. (테스트 필요) ▪ sentinel은 아직 불완전 (RDB, AOF file 백업를 꾸준히 해서 중요한 장애 복구 시에는 수동으로 복구작업을 해야함) ▪ redis.log, sentinel.log를 수시로 모니터링 해야함 (쉽게 모니터링할 방법을 연구해야함)
9. • Security ◦ RDB ▪ keys, flushall, Flushdb 등의 명령어를 실행한경우… -> 답이없음 ▪ 경험에서 우러나오는 command security의 중요성… ▪ rename-command를 잘 활용하자…. ▪ 새로 띄운 redis 서버의 설정 ▪ redis-client의 api로 실험 결과 rename으로 변경한 command의 api는 실행불가 (ex. redis.flushall() -> raise exception) rename-command FLUSHDB sonjBBhgpz8F0WLM4iCiLnaFtQ4zWwJm rename-command FLUSHALL hRsnbEvTteIptvuY5ZzGQNZSR8f18vAk rename-command KEYS f9he3YuvGdJYjgSj4J5GpD303q0LfDe8 rename-command DEBUG 3pBYbauPItXOP8WTE55B39tYKuqSD1Hz
10. • TODO ◦ Redis data monitoring (budget data) ◦ Redis Sentinel 테스트 해보기 (redis 날리기 전에 해보다가 잠시 멈춰있음…) ◦ 백업 재개 및 복구 프로세스 정립 (필요하다면 script로 자동화…) ◦ Redis High Availability 아키텍처 설계 ◦ Sentinel 적용 및 redis monitoring 시스템 구축하기 ◦ data sharding 방법 고민해보기