Redis 아키텍처 종류
Replication 구성 (master - slave)
- Redis의 Replication은 async Replication(비동기식 복제)로 Replication lag이 발생할 수 있다.
replicaof커맨드를 이용해 간단하게 복제 연결할 수 있다.- replicaof hostname port
- HA기능이 없어서 장애 상황 시 수동으로 복구해야 한다.
- replicaof no one
- DBMS로 보면 statement replication형태와 비슷하다.
replication 설정 과정
- secondary에 replicaof 명령 전달
- secondary는 Primary에 sync 명령 전달
- primary는 현재상태를 저장하기위해 fork 시행
- fork한 프로세서는 현재 메모리 정보를 disk에 dump시행
- 해당정보를 secondary에 전달하고 fork이후 데이터를 secondary에 계속 전달한다.
replication 주의점
- replication중 fork가 발생하므로 메모리 부족이 발생할 수 있다
redis-cli --rdb커맨드도 현재 상태의 메모리 스냅샷을 가져와 같은 문제가 있을 수 있다.- 클라우드에서 제공하는 Redis는 좀 더 안정적 일 수 있다.
replication lag
slave가 master에서 발생하는 업데이트를 따라잡을 수 없을 때 발생하는 현상
statement based replication
수정 작업에 사용되는 모든 SQL문이 바이너리 로그에 기록되고 동일한 명령문이 SQL스레드에 의해 슬레이브에서 실행되는 방식
row based replication
행을 수정하면 해당 행의 복사본이 바이너리 로그에 기록되고 이후에 슬레이브에 적용되는 방식
fork
프로세스를 복사하는 기능을 수행한다.
DB dump
데이터 베이스 dump는 데이터 손실시 내용을 복원할 수 있도록 데이터베이스를 백업하는데 사용됩니다.
Sentinel 구성
- sentinel 노드가 다른 노드를 감시한다.
- 마스터가 비정상 상태일때 자동으로 페일오버가 가능하다.
- sentinel 노드는 항상 3대 이상의 홀수로 존재해야 한다(과반수가 동의할때 failover 진행)
- 연결 정보가 필요없다
Cluster 구성
- scale out과 HA를 구성할 수 있다.
- 키를 여러 노드에 자동으로 분할해서 저장할 수 있다. (샤딩)
- 모든 노드가 서로를 감시하여 마스터 노드가 비정상 상태일 때 자동으로 페일오버한다
- 최소 3대의 마스터 노드가 필요하다
Redis 아키텍처 선택 기준
Redis의 데이터 분산
Consistent Hashing
- 어떤 key값이 들어오면 자신보다 크고 제일 가까운 해시값을 가진 서버에 할당하는 방식
(자신보다 큰 해시값을 가진 서버가 없다면 제일 해시값이 작은 서버에 할당) - 서버를 추가하고 삭제할때 reblance를 줄일 수 있습니다.
샤딩(Sharding)
거대한 데이터베이스나 네트워크 시스템을 여러 개 작은 조각으로 나누어 분산 저장하여 관리하는 방식
샤딩은 상황에 따라 전략이 달라질 수 있다.
- Range
- 특정 range를 정의하고 해당 range에 속하면 저장하는 방식
- 특정 range의 서버에만 부하가 몰릴 가능성이 높다.
- Modular
- N % K로 서버의 데이터를 결정한다.
- Range방식 보다는 균등하게 데이터를 분배한다.
- 서버 한대가 추가될 때 재분배 양이 많아진다.
- Indexed
- 해당 key가 어디로 저장되어야 하는지 관리하는 서버가 따로 존재한다. (index 서버)
- index서버에 의존적이다. 즉 index서버가 제대로 동작하지 않으면 다른 서버도 똑바로 동작하지 않는다.
Redis Cluster
- Hash기반 slot 16384로 구분한다.
- Hash알고리즘은 CRC16을 사용한다.
- 특정 Redis서버는 해당 slot range를 가져 데이터 migration시에 해당 slot 단위로 데이터를 다른 서버에 전달한다.(migrate 커맨드)
장단점
- 장점
- 자체적인 Primary, Secondary failover를 제공하고 Slot단위의 데이터 관리가 가능하다.
- 단점
- 메모리 사용량이 높고 migration 시점을 관리자가 결정해야 한다.
- library를 통한 구현이 필요하다.
Redis의 Failover 시스템
[Redis Failover Command Manual]
Redis는 6.2.0버전 이상부터 failover 명령어를 제공한다.
Syntax
failover [to host port [force] [abort] [timeout miliseconds]]
옵션 설명
- to host port : master로 승격시킬 replica를 지정할 수 있다.
- force : timeout을 초과하면 마스터가 롤백하지만 강제로 Failover를 수행한다.(replica가 완벽히 동기화 되지 않아도 실행)
- timeout : master 노드가 대기하는 최대 시간을 지정할 수 있다, 설정하지 않으면 무한대로 대기한다.
명령어 실행과정
- Master 노드가 client 연결로부터 오는 모든 쓰기를 중지하여 데이터의 축적을 막는다.
- Master 노드는 replica노드가 replication과정을 마칠때 까지 기다리고 여러 replica들이 있는 경우 첫 replica만 마칠때 까지 기다린다.
- Master 노드는 Replica 노드로 강등당하고 여러 Master가 생기는 것을 방지한다
- PSYNC FAILOVER을 타겟이 되는 replica에게 보내고 Master로 승격시킨다
- 이전 Master가 PSYNC FAILOVER를 받았다는 것을 인지하면 client들의 중지 상태를 풀고 PSYNC요청이 거절되면 기존 Master상태로 되돌아간다.
- failover abort명령어를 수행하면 failover 과정을 중단하고 기존 master를 되돌린다.(단 multiple master 문제가 발생할 수 있다.)
[우아한 Redis 강의 참고]
Failover는 장애가 발생했을때 미리 준비된 예비 시스템으로 자동전환되는 장애 극복 기능입니다.
Coordinator 기반 Failover
- zooker, etcd, consul등의 코디네이터를 사용합니다.
- 동작순서
- 사용되고 있는 Redis 서버(primary)가 죽게되면 health Checker는 미리 준비된 다른 서버를 primary로 승격
- Health Checker는 Coordinator에 current Redis를 죽은 서버가 아닌 다른 미리 준비된 다른 서버로 업데이트
- Coordinator가 API Server에 curren Redis가 변경됨을 알림
- Coordinator 기반으로 설정을 관리하면 동일한 방식으로 관리가 가능하다는 장점이 있지만 해당 기능을 이용하게 개발을 해야한다.
VIP/DNS기반 Failover
VIP기반
- 동작순서
- API서버가 특정 IP로만 접속하도록 제한을 두었을때 primary서버가 죽으면 Health Checkr는 미리 준비된 다른 서버에 VIP를 할당
- Health Checker는 미리 준비된 다른 서버를 승격하고 기존 primary서버의 연결을 모두 끊어줍니다.
(client의 재접속을 유도)
DNS기반
-
VIP를 DNS로 치환하면 동일하게 작동
-
특징
- 클라이언트에 추가적 구현이 필요없다.
- VIP방식은 클라우드 업체와 같이 외부로 서비스를 제공하는 서비스 업자가 사용에 유리하다
- DNS기반은 사용 언어별 DNS 캐싱 정책과 한번 가져온 DNS정보를 다시 호출하지 않는 경우들을 고려하여 DNS Cache TTL을 관리해야 한다.
참고자료
https://dbadiaries.com/mysql-replication-events-statement-versus-row-based-formats
http://wiki.hash.kr/index.php/%EC%83%A4%EB%94%A9
https://www.youtube.com/watch?v=92NizoBL4uA
https://meetup.nhncloud.com/posts/226
데이터를 탐구하는 개발자