Backend Master | 2.1.4 Cache - Redis Clustering part.1

Index
• 클러스터링?
• Redis 클러스터링

클러스터링
• 여러 대의 컴퓨터를 서로 연결해 하나의 컴퓨터처럼 사용하는 것
• 특정 장비나 실행중인 애플리케이션에 문제가 발생하더라고 전체 서비스에 영향을 미치
지 않도록 제어가 가능. Virtual IP를 기반으로 구현.
• 목적에 따라
• 베어울프 : 다수의 컴퓨터가 하나의 프로그램을 협동해 수행, 고성능의 계산능력
• 부하분산 : 서비스 요청을 받으면 클러스터내 다른 컴퓨터에게 제공, 대규모 서비스 제공
• 고가용성 : 서로가 수시로 체크하고 고장난 노드를 동적으로 제거하고 대신 수행, fail 극복
• 가격대 성능비, 확장성 (Scale-out)
• 클러스터 성능에 영향을 미치는 것은 프로세서의 성능과 함께 통신속도
• 네트워크 병목현상(bottleneck)

클러스터링
• 특징
• Load-Balancing : 계산 부하량을 여러 노드에서 분담해 병렬 처리
• High-availability : 연결된 다른 노드의 컴퓨터가 서비스를 이어받아(Failover) 계속해서 서비스
• 구성 요소
• 클러스터 노드 : 프로세싱 자원을 제공하는 시스템
• 클러스터 관리자 : 노드를 서로 연결하여 단일 시스템처럼 보이게 만드는 로직을 제공
• 관리
• 작업 스케줄링 : 애플리케이션의 환경이 복잡한 이기종 CPU-코프로세서 클러스터의 경우 각 job의 성능은
클러스터의 특성에 의존적
• 노드 장애 관리 : 한 노드에서 장애 발생시 나머지의 모든 시스템이 계속 동작하도록 하는 방법 “Fencing”
-> 노드가 오동작할 때 공유된 자원을 보호하고 그 노드를 격리

Redis Cluster
• Version 3.0 이상부터 지원, 최신 Stable Version은 4.0 (July 2017)
• Redis Cluster 101
• 데이터가 자동으로 sharding되어 다수의 Redis 노드로 분산되어 들어가도록 해준다.
• 노드의 fail이나 통신 불능 상태 등에 대해 지속적으로 동작할 수 있도록 파티션 간의 가용성 제공
=> 여러 노드들에 데이터들을 분리해서 넣을 수 있다.
=> 부분적인 노드들에서 실패 혹은 통신 불능 상태에서 지속적인 동작 제공
• 간단한 Redis Cluster 구조

Redis Cluster
• Redis Cluster Architecture
• 단일 장애점(Single point of failure)이 없는 토폴로지: Mesh
=> Clone 노드를 포함한 모든 노드가 서로를 확인하고 정보를 주고 받는다.
=> 별도의 마스터 노드를 두지 않는 구조
=> 모든 노드가 클러스터 구성 정보(슬롯 할당 정보를 가지고 있다)
=> 클라이언트는 어느 노드든지 접속해서 클러스터 구성 정보를 가져온 후 보유,
입력되는 Key에 따라 해당 노드에 접속해서 처리
Fully Connected Mesh Topology Redis Cluster Architecture

Redis Cluster
• Redis Cluster는 별도의 Cluster Master가 필요하지 않다.
=> Sentinel의 Master/Slave X , Cluster에 대한 별도의 Master가 필요하지 않음.
• Cluster에는 별도의 Sentinel이 필요하지 않다
=> 각 Redis가 Sentinel 역할도 수행하기 때문이다.
=> 각 Redis 노드들은 Master or Slave 역할 수행
ex) 여러 Master 중 한 대가 다운되어 Slave->Master 작업,
각 Redis 노드들이 Sentinel과 같은 역할을 수행해 장애복구(Failover)를 수행.
• Cluster는 각 Redis 노드에 데이터를 가능한 균등하게 분산해 저장하는 기능
=> 분산 방식은 CRC16 function 수행.
=> Redis는 담당하는 Slot에 해당하는 key는 받고, 다른 key는 담당 Redis IP:Port 리턴

Redis Cluster
• 모든 Redis Cluster 노드는 두 개의 TCP connection을 필요로 한다. (방화벽 설정 필수)
• Redis TCP Port (default 6397)
=> Cluster에 접근하고자 하는 모든 client와 다른 cluster 노드들(Key 이동을 위한)에 의해 사용
• Cluster bus Port (default +10000) : 노드 간의 바이너리 커뮤니케이션 채널
=> 노드의 실패 detection이나 설정 업데이트, failover authorization 등에 사용됨
• NAT 환경 및 IP 주소나 TCP Port가 다시 mapping되는 환경 지원하지 않음.

Redis Cluster
• Heartbeat 체크 방법 (Cont.)
http://www.redisgate.com/redis/cluster/cluster_heartbeat.php
1. 1초마다 한 개 노드에 Ping을 보내 확인
-> 임의로 5개 노드 추출해 Pong을 받은 시간이 가장 오래된 노드에 Ping 보냄.
-> 노드 수는 적은데 cluster_node_timeout 지나치게 길게 설정되어 확인 시간 늦어지는 것을 방지
ex) 6개의 노드, cluster_node_timeout = 60s,
-> 30초가 지나서 다른 노드 확인하므로 fail에 대한 대응이 너무 늦음
2. cluster_node_timeout
-> Pong 받은 시간이 cluster_node_timeout/2 보다 큰 노드들에 대해 Ping을 보냄.
Cluster-nodes(size)
Cluster_node_timeout
(second)
timeout / 2 Ping count per node
50 15 7.5 6.7
50 30 15 3.3
100 15 7.5 13.3
100 30 15 6.7
100 60 30 3.3
1000 60 30 33.3
1000 120 60 16.7
1000 180 90 11.1

Redis Cluster
• Heartbeat 체크 방법 (Cont.)
• 대량 입력이 지속적으로 발생하면 작업들에 대한 부하가 발생할 수 있음.

Redis Cluster
• Consistency hashing을 사용하지 않고 모든 key가 개념적으로 hash slot의 일부인 다른
sharding을 사용한다.
• 키-노트 할당 방법
• 입력된 키에 Hash function (CRC16)을 적용한다.
• Redis Cluster는 16,384개의 슬롯을 사용(0~16,383)
• HASH_SLOT = CRC16(key) mod 16384
• 모든 노드는 hash slot의 subset이다.
• 예를 들어 노드가 3개일 경우, 노드는 각각
0~5460(A), 5461~10922(B), 10923~16383(C) 슬롯을 가진다.
=> Slot을 노드에 할당하는 것은 클러스터 관리자 역할
• 노드 추가 및 제거를 쉽게 한다.
• D라는 노드가 추가되면 A,B,C 어느 정도 Slot을 D에게 할당
• A를 제거한다면 A의 Slot을 B나 C로 옮긴다.
• Hash slot을 이동하는 것은 Cluster를 정지할 필요가 없기 때문에 언제든 변경 가능

Redis Cluster
• 클러스터 구성 방법
1. redis-trib.rb (ruby 설치 필요)
redis-trib.rb create --replicas 1 127.0.0.1:5001 127.0.0.1:5002 127.0.0.1:5003 127.0.0.1:5004
127.0.0.1:5005 127.0.0.1:5006
=> replicas는 마스터 노드 당 복제를 몇 개 할 것인지, 2이면 1:2
이를 통해 클러스터를 생성할 경우에는 마스터가 최소 3 노드 이상 요구된다.
=> 고가용성을 위해서는 manual하게 구성 필요
=> 노드 & 박스 다운 후에는 구성 변경됨
cf) Ruby version == redis-trib.rb version
Cluster bus port <...>
=> DB에 데이터 있으면 클러스터 생성 X
-> AOF(appendonly.aof), RDB(dump.rdb)로부터 데이터 읽으면 안된다.
2. 클러스터 명령을 통해 직접 구성 (http://www.redisgate.com/redis/cluster/cluster_design.php)
=> redis.conf 를 통한 서버 실행 (not standalone)
=> case 1, master 1대면 cluster addslots
2, + slave or 여러 대일 경우에는 cluster meet, replica, addslots

Redis Cluster
• Redis Server는 Master or Slave(Clone)
• 부분적인 노드가 실패나 통신 불능에도 가용성 확보
• A, B, C에서 B가 실패한다면 할당된 slot을 서비스할 수 없다.
• A, B, C / A1, B1, C1으로 구성을 하면, B1은 B를 replication한다.
=> B의 장애 발생시 B1이 election을 통해 새로운 master로 선출
• 만일, B와 B1이 모두 fail이 될 경우에는, 지속적으로 서비스를 할 수 없다.
• 이에 대한 방법으로는 nodes.conf 파일을 사용하거나, cluster forget, cluster meet, redis-trib reshard 명령
어 사용해야 한다.
• nodes.conf: 클러스터 모드일 때 각 노드의 정보를 보관하는 파일, Redis server가 기록
해당 파일을 사용할 수 있으면, 가용 머신에서 파일 복사 실행하면 바로 클러스터에 붙음

Redis Cluster
• Redis Server Failover (Cont.)
• 마스터 노드 다운의 경우
1. 다운된 노드를 클러스터에서 제거
=> 살아 있는 모든 노드에서 수행
ex) src/redis-cli -p 5001 cluster forget <nodeID>
2. 없어진 노드의 slot 할당 cluster addslot
3. 신규 노드 할당 후 cluster-meet
4. 슬롯 재할당 redis-trib.rb reshard
• 슬레이브가 있으면?
=> 이전에 다운된 마스터 노드 재부팅시에는 마스터로 시작하지만
구성 변경을 감지하고 자동적으로 슬레이브로 전환
<redis.conf>
port 5001
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 3000
cluster-require-full-coverage
yes
appendonly yes
dir /path/to/5001/
38809:S # Connection with master lost.
38809:S # Cluster state changed: fail 4초 후에 Cluster fail
38809:S # Failover election won: I'm the new master. 슬레이브가 마스터로 승격
38809:M # Cluster state changed: ok Cluster ok
38797:M # Cluster state changed: fail
38797:M # Failover auth granted to
f55ff1ca79ed8261370e172782759f81a0e48040 for epoch 7 Failover 완료
38797:M # Cluster state changed: ok Cluster 상태 변경

Redis Cluster
• Redis Server consistency guarantee
• Strong consistency를 보장하기 않음. (consistency와 성능 간의 trade-off)
-> 특정 조건에서 Cluster가 Client의 데이터를 잃어버릴 수 있다.
1. Asynchronous replication
Client가 Master B에게 데이터를 쓴다.
Master B가 Client에게 OK 대답
Master B는 B1, B2, B3의 replica에 쓰기를 전달 (prohibitive latency penalty for Redis)
=> B가 쓰기를 확인하고 slave에 전달하는 과정에서 fail이 발생하면 데이터 손실 가능.
=> 대다수 데이터베이스에서 매 초마다 disk로 데이터를 flush하는 것과 매우 유사
Redis Cluster는 synchronous 쓰기를 지원함(WAIT 명령어를 통해)
-> https://stackoverflow.com/questions/33629339/can-the-wait-command-provide-strong-consistency-
in-redis
2. 클라이언트가 하나의 마스터를 포함한 소수의 인스턴스로 격리된 네트워크 파티션
ex) A, B, C, A1, B2, C3의 Master-Slave / Z1 이라는 Client
파티션 발생 후에는 B와 Z1 / 나머지 노드
파티션이 B1이 마스터로 승격될 정도로 오래 발생시에는 B로 전송되는 데이터는 유실
=> Maximum Window; 다수의 파티션 측에서 슬레이브->마스터될 정도의 충분한 시간이 지나면 소수
측의 모든 마스터 노드에 데이터 전송 불가능 (node timeout과 관계)

Redis Cluster
• 제한 사항
1. 기본적으로 멀티 키 명령(operation)을 수행할 수 없다.
MSET key1 value1 key2 value2, SUNION key1 key2, SORT와 같은 명령
=> hash tag (키의 일부를 {}로 감싸는 것, {user001}.following)을 사용하면 사용 가능.
2. Data Merge를 허용하지 않음.
=> 노드간 데이터(key, value)를 전송하는 것은 bottleneck 가능
=> key에 hash tag를 사용
3. 클러스터 모드는 DB 0번만 사용할 수 있다.
4. 3.0 이상부터

Redis Cluster Reference
• http://www.redisgate.com/redis/cluster/cluster.php
• https://redis.io/topics/cluster-spec
• https://redis.io/topics/cluster-tutorial
• https://redis.io/
• tech.cloudz-labs.io/posts/redis-overview/

Redis Cluster
• Version 3.0 이상에서 사용 가능
• 다음의 목표를 가진 Redis의 분산 구현
1. 1000대의 노드까지 확장할 수 있도록 설계
=> 프록시가 없고, 비동기 복제 사용되며 값에 병합 작업 수행하지 않음
2. 노드 추가, 삭제 시 클러스터 전체를 중지할 필요 없이, 키 이동 시에만 해당 키에 대해 잠시 중단될 수 있다.
3. 시스템은 마스터 노드의 대다수와 연결된 클라이언트에서 발생하는 모든 쓰기를 유지하려고 시도함
4. 가용성
• Redis의 비 분산 버전에서 사용 가능한 모든 단일 키 명령을 구현
• 특정 키가 동일한 노드에 저장되도록 하기 위한 Hash Tag 개념을 구현

Backend Master | 2.1.4 Cache - Redis Clustering part.1

More Related Content

What's hot (20)

Similar to Backend Master | 2.1.4 Cache - Redis Clustering part.1 (20)

More from Kyunghun Jeon (10)

Backend Master | 2.1.4 Cache - Redis Clustering part.1

Editor's Notes