High Availability Redis Archtecturest

Redis HA 고려사항 고 가용성

- 일관성 보장 작성 복제 클러스터링 및 샤딩 로드 밸런스

- 결함 허용

- 장애 조치 백업 및 복원

- 관찰성

- 모니터링 - 성능 및 가동 시간

- 경영 문제

- 마이그레이션 업그레이드 및 다운 그레이드

- 인프라 계획

- 네트워크 파티셔닝 장애 도메인에서의 서비스 배포

High Availability

Data Inconsistency 

데이터 일관성을 위해 레디스는 클러스터 승인 매커니즘을 이용 

Write load 

- 당연한 예기지만 write가 read보다 소모되는 비용이 크다. 요청 속도가 훨씬 느릴 때 오류가 발생. 이러한 상황에서는 write load 분산하는 메커니즘이 필요 

Data loss and Data Corruption  

- 노드 오류, 프로세스 충돌 및 디스크 오류로 인해 데이터가 손실 될 수 있다 이를 방지할 매커니즘이 필요

Redis Cluster

redis 를 ha 구성하기 위해서는 sentinel을 이용하여 (master-slave repliocation)을 하는 구조가 있고 cluster로 샤딩하는 구조가 있다.

여기서는 클러스터 로 ha구성에 대해 알아본다.

redis cluster 는 말그대로 노드들을 샤딩하는 기본 매커니즘이다 최대 16384개(만약 마스터가 3개면) hash slot으로 이루어져있으며 샤딩으로  노드간 쓰기가 분산되어 한노드가 실패한다고해서 전체 시스템이 다운되는 일을 방지한다.

redis cluster에서 master의 역활은 write, slave의 역활은 read 역활 및 stand by 역활이다.

slave는 master에 연결하여 데이터를 non-blocking 방식으로 동기화한다

하지만 cluster - replication 구조라고 데이터 손실 현상이 발생하지 않는것은 아니다.

slave에 데이터가 복제되기전에 마스터에 오류가 발생한다면 데이터가 손실된다.

이런점을 방지하기 위해 multipath writes, disk level replication등이 필요하다.

또한 cluster구성시 master가 down시 해당 master에 slave가 master가 되고 그이후 다운된 node(master)를 올리면 자동으로 slave로 올라온다.

cluster

9f89b455f0ddcfc9e0f1289b2a62e48f61d0e840 127.0.0.1:7002@17002 master - 0 1545380898859 3 connected 10923-16383 
12e6b5b8d23875012e3f5bcba0afdc0a69e26e26 127.0.0.1:7001@17001 slave ce29f33d54d7c4aae5eeda85471de74a5ef1c42e 0 1545380897858 7 connected 
973563dd9201eed8e4599c8c1c74b7f242df4e89 127.0.0.1:7004@17004 slave 198dee9a4726603d37572b164070d95642cafcbc 0 1545380898000 5 connected 
198dee9a4726603d37572b164070d95642cafcbc 127.0.0.1:7000@17000 myself,master - 0 1545380897000 1 connected 0-5460 
ce29f33d54d7c4aae5eeda85471de74a5ef1c42e 127.0.0.1:7005@17005 master - 0 1545380898359 7 connected 5461-10922 
ed6387c90d54524c79e205e39df434ac82a34aa5 127.0.0.1:7003@17003 slave 9f89b455f0ddcfc9e0f1289b2a62e48f61d0e840 0 1545380897557 3 connecte

master node 7002 down

9f89b455f0ddcfc9e0f1289b2a62e48f61d0e840 127.0.0.1:7002@17002 master,fail 1545381194439 1545381193000 3 disconnected 
12e6b5b8d23875012e3f5bcba0afdc0a69e26e26 127.0.0.1:7001@17001 slave ce29f33d54d7c4aae5eeda85471de74a5ef1c42e 0 1545381202556 7 connected 
973563dd9201eed8e4599c8c1c74b7f242df4e89 127.0.0.1:7004@17004 slave 198dee9a4726603d37572b164070d95642cafcbc 0 1545381201000 5 connected 
198dee9a4726603d37572b164070d95642cafcbc 127.0.0.1:7000@17000 myself,master - 0 1545381200000 1 connected 0-5460 
ce29f33d54d7c4aae5eeda85471de74a5ef1c42e 127.0.0.1:7005@17005 master - 0 1545381202856 7 connected 5461-10922 
ed6387c90d54524c79e205e39df434ac82a34aa5 127.0.0.1:7003@17003 master - 0 1545381201000 8 connected 10923-16383

7002 node up

9f89b455f0ddcfc9e0f1289b2a62e48f61d0e840 127.0.0.1:7002@17002 slave ed6387c90d54524c79e205e39df434ac82a34aa5 0 1545381238531 8 connected 
12e6b5b8d23875012e3f5bcba0afdc0a69e26e26 127.0.0.1:7001@17001 slave ce29f33d54d7c4aae5eeda85471de74a5ef1c42e 0 1545381238932 7 connected 
973563dd9201eed8e4599c8c1c74b7f242df4e89 127.0.0.1:7004@17004 slave 198dee9a4726603d37572b164070d95642cafcbc 0 1545381236528 5 connected
 198dee9a4726603d37572b164070d95642cafcbc 127.0.0.1:7000@17000 myself,master - 0 1545381235000 1 connected 0-5460 
ce29f33d54d7c4aae5eeda85471de74a5ef1c42e 127.0.0.1:7005@17005 master - 0 1545381238000 7 connected 5461-10922 
ed6387c90d54524c79e205e39df434ac82a34aa5 127.0.0.1:7003@17003 master - 0 1545381238000 8 connected 10923-16383

Conclusion

해당 내용에서는 cluster에 내용만 담았지만 sentinel구조도 나름의 장점을 가진 이상적인 구조이다.(redis는 cluster에 sentinel을 넣을 수 있는 구조는 아니다.)

redis-cluster를 위해서는 해당 cluster를 맺을때 external접근을 위해서는 모든 node들이 external에 접근할수 있는 상태여야만 외부에서 접속이 가능하다.

즉 operator를 따로 둬서 분배하거나 포트 포워딩을 하지않으면 외부에서는 쓰기 힘들다. 특히 k8s안에서는 더 그렇다.(node마다 서비스 디플로이먼트를 지정해줘야됨)

하지만 고가용성을 위해 master를 여러개 두고 write를 분산처리 하는것은 필수가 아닐까 하는 생각이 든다.