Redis Cluster

Redis Cluster

 

레디스는 단일 인스턴스만으로도 운영이 가능하지만 물리 머신이 가진 메모리의 한계를 초과하는 데이터를 저장하고 싶거나 failover에 대한 처리를 통해 HA를 보장하려면 센티널이나 클러스터 등의 운영 모드를 선택해서 사용해야 한다.

 

 

운영 모드 (Operation Modes)

단일 인스턴스 (Single Instance)

HA를 지원하지 않는다.

 

 

센티널 (Sentinel)

HA를 지원하며 Master/Slave Replication 구조를 가진다.

Sentinel Process는 Redis와 별도의 Process로 동작하며 여러개의 독립적인 Sentinel Process들이 협동하여 운영된다 (SPOF 아님)

안정적인 운영을 위해서는 최소 3개 이상의 Sentinel Instance가 필요하며 FailOver를 위해 과반수 이상의 Vote가 필요하다.

 

Redis Process가 실행되는 각 서버마다 각각 Sentinel Process를 띄어놓거나 Redis에 접근하는 Application Server에 Sentinel Process를 띄어놓고 사용한다. (여러가지 구성이 가능)

지속적으로 Master/Slave가 제대로 동작하는지 모니터링하다가 Master에 문제가 감지되면 자동으로 FailOver를 수행한다.

Application에서 Sentinel에서 Master가 어떤 Instance인지 확인하여 Master 접근하는 방식을 사용한다면 Master 장애로 FailOver시 Application에서도 자동으로 Master 변경이 가능하다.

즉, Application에서 Sentinel에 연결하여 현재 Master를 조회하는 방식이다.

 

 

클러스터 (Cluster)

HA와 Sharding을 지원한다. Sentinel과 동시에 사용하는거이 아니라 완전히 별도의 솔루션이다.

DataSet을 자동으로 여러 노드에 나눠서 저장해준다. Redis Cluster 기능을 지원하는 Client를 써야만 Data Access 시에 올바른 노드로 Redirect가 가능하다.

 

Cluser Node들은 기본설정인 6379 포트를 Data Port로 사용하며 Cluster는 Cluster Bus Port를 사용하여 자체적인 바이너리 프로토콜을 통해 Node to Node 통신을 한다. (보통 Cluster Bus Port는 6379에 10000을 더한 16379 Port를 사용한다.)

이 Cluster Bus Port를 통해 Node 간 Failure Detection, Configuration Update, FailOver Authorization 등을 수행한다.

 

Sharding은 최대 1000개의 Node로 Sharding해서 사용가능하며 그 이상은 권장하지 않는다. Consistent Hashing을 사용하지 않는 대신 Hash Slot이라는 개념을 도입하여 사용한다.

Hash Slot을 결정하는 방법으로는 CRC16(key) Mod 13684로 CRC16을 이용하면 16384개의 Slot에 균일하게 잘 분배된다.

노드별 자유롭게 Hash Slot을 할당 가능하다.

예를 들면 A Node에 0개부터 5500개, B Node에 5501개부터 11000개, C Node에 11001개부터 16383개를 할당할 수 있다. 

운영중단 없이 Hash Slot을 다른 노드로 이동시키는것이 가능하며 노드를 추가하거나 삭제하고 노드별 Hash Slot 할당량을 조절할 수 있다. (노드의 개수에 따라 Slot할당을 다르게 가져갈 수 있다.)

 

Multiple Key Operations를 수행하려면 모든 키값이 같은 Hash Slot에 들어와야 한다.

이를 보장하기 위해 Hash Tag라는 개념을 도입하여 사용한다. {} 안에 있는 값으로만 Hash 계산을 한다. ({foo}_mykey}, {foo}_your_key})

 

Fail Over를 위해 클러스터의 각 노드를 N대로 구성 가능하다. Master 1대 / Slave Replication (N대) 구성이다.

Async Replication (Master -> Slave Replication 과정에서 Ack를 받지 않는다.) 즉, 데이터를 보내지면 정확히 도착하였는지에 대한 응답을 받지않는 것이다.

그렇기 때문에 데이터 손실 가능성이 존재한다. (Master가 Client 요청을 받아서 Ack를 완료한 후 받은 Client의 요청을 Slave Replication으로 보내기전에 Master가 죽는 경우가 존재한다.)

 

Redis Client는 Cluster 내의 어떤 노드든 쿼리를 날려도 된다. (Slave에 쿼리를 날리는 것도 가능하다. 예를 들어 GET my_key 와 같은 쿼리)

그렇게 되면 쿼리를 받은 노드가 해당 쿼리를 분석하고 해당 키를 자신이 갖고 있다면 바로 찾아서 리턴하고 그렇지 않은 경우 해당 키를 저장하고 있는 노드의 정보를 리턴한다.

Client는 전달받은 노드의 정보로 다시 쿼리를 보내 요청한 쿼리에 대한 정보를 전달받는다. (리턴은 MOVED 3999 127.0.0.1:6381 형식으로 응답받는데 이 내용으로 다시 쿼리를 보낸다.)

 

 

 

메모리 동작 방식

Key가 만료되거나 삭제되어 Redis가 메모리를 해제하더라도 OS에서 해제된 분량만큼 바로 메모리가 확보되지는 않는다. (꼭 Redis만 해당되는 얘기는 아님)

예를 들어 5GB는 3GB의 데이터를 메모리에서 해제하더라도 여전히 OS 메모리 사용량은 5GB로 잡혀있다.

하지만 다시 Data를 추가하면 Logically Freed된 영역, 즉 해제되었지만 OS에 반환되지 않은 영역에 할당되므로 물리적인 5GB를 넘지는 않는다.

 

따라서 Peak Memory Usage를 기준으로 Memory를 잡아야한다. 예를 들어 5GB 사용하고 가끔 10GB가 필요한 경우가 있다면 10GB 이상을 가진 머신이 필요한것이다.

MaxMemory 설정을 해두는 것이 좋은데 설정을 하지 않으면 Memory를 무한히 사용하다가 OOM이나 머신에 장애가 발생할 가능성이 높아진다.

 

MaxMemory 설정시의 Eviction Policy (Memory 해제 정책) 는 아래와 같다.

• No-Eviction : 추가 Memory를 사용하는 Write Command에 대해 Error를 리턴

• Allkeys-LRU : 전체 아이템 중에서 LRU (페이지 교체 알고리즘으로 가장 마지막에 사용된 페이지를 새로운 페이지로 교체하는 방식)

• Volatile-LRU : Expire 되는 아이템 중에서 LRU

• Volatile-TTL : Expire 되는 아이템 중 TTL이 얼마 안남은 순으로 교체

 

RDB Persistence를 사용한다면 MaxMemory를 실제 가용 Memory의 45% 수준으로 설정하는 것을 권장한다. Snapshot을 찍을때 현재 사용중인 Memory 양만큼 필요하기 때문이다. (5%는 오버헤드에 대비하기 위해 여유분)

만약 RDB Persistence를 사용중이지 않다면 95%정도로 사용하여도 된다.

 

동일 Key-Value Data를 저장한다고 가정했을 때 Cluster Mode를 사용할 경우 Single Instance 보다 1.5 ~ 2배 정도 Memory를 더 사용하는 것에 주의해야 한다.

Redis Cluster의 경우 내부적으로 Cluster안에 저장된 Key를 Hash Slot으로 Mapping하기 위한 Table을 가지고 있기 때문에 추가적인 Memory OverHead가 발생한다.

이 때문에 Key의 숫자가 많아질수록 Memory OverHead가 더 빈번히 발생한다. 4버전 부터는 이전 버전보다 Memory 최적화 기능이 포함되어 Memory를 더 적게 사용하지만 여전히 Single Instance보다 많은 Memory를 필요로 한다.

 

 

 

주요 특수 기능

다양한 데이터 구조 지원

단순히 Key - Value 문자열만 저장하는 것이 아니라 고수준의 데이터 구조를 사용가능 하다. 

Ex) Hash, Set, List, SortedSet, ETC

 

Hash에는 HSET(key, fileds, value), HGET(key,filed)가 있다.

Web Application에서 특정 유저 ID를 Key로 두고 해당 유저의 세부 정보 (Name, Email 등)를 filed로 둔다.

이렇게 하면 특정 유저와 관련된 정보들을 한번에 삭제하는 등 하나의 Namespace처럼 사용할 수있다.

Hash Key당 1000개 정도의 field까지는 Redis가 zipmap을 이용해 압축해서 저장한다. 즉, 1000개의 Key에 저장될 내용이 하나의 Key에 1000개의 field로 저장되는 것이다.

하지만 CPU 사용량이 증가하므로 Application 특성에 맞게 적정 갯수를 잘 선택해야 한다.

(Link :  https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c /  https://redis.io/topics/memory-optimization)

 

 

Expireation 지정

Key 별로 TTL(Time-To-Live)을 설정해두면 Redis가 알아서 해당시점이 지날때 Key를 삭제한다. 설정된 Max Memory에 도달하면 Expire되지 않은 Key들도 Eviction Policy에 따라 삭제될 수 있다.

 

 

Pipelining

여러 Command들을 한번에 모아서 보낸후 실행 결과도 한번에 모아서 받을 수 있다. Latency가 큰 네트워크 환경이라면 Command 하나당 한번의 Request/Response를 할 때보다 Throughput(처리량)을 올릴 수 있다.

 

 

Pub/Sub (출판/구독 모델)

하나의 Client가 같은 채널에 연결된 다른 Client들에게 메시지를 보내는 것이 가능하다. 이를 이용하여 속도가 빠른 메시지 브로드캐스터 혹은 메시지 큐처럼 사용하는 것이 가능하다.

 

 

Lua Scripting

여러 명령어들이 사용되는 복잡한 작업을 할 때 (특히 트랜잭션이 사용되는 경우) 이를 하나의 Lua Script로 만들어서 사용할 수 있다.

Script는 Automic하게 실행되기 때문에 Optimistic Locking Transactions를 사용할 필요가 없다.

 

 

 

지표 모니터링 (Monitoring Metrics)

Total Commands Processed

이 지표와 Request/Response를 Latency Logging해두면 Command 처리량 대비 Latency를 알 수 있다.

# redis-cli -h {host} -p {port} --latency

 

 

Slow Commands

SlowLog Get 명령으로 Slow Command를 확인 가능하다.

 

 

Client Connections

info clients 명령으로 확인 가능하다.

대략 5000개 이상의 Connection들이 존재한다면 응답시간이 느려지고 있을 가능성이 있으니 모니터링 해야한다.

Maxclients 값을 대략 예상되는 Connection 숫자의 1.1 ~ 1.5배 정도로 설정해 두면 안전하다.

 

 

Mem Fragmentation Ratio

정의 = 실제 물리 메모리 사용량 / 레디스의 메모리 사용량 (나누기)

실제 물리 메모리 사용량에서 레디스의 메모리 사용량으로 나누었을 때로 예를 들어 물리 메모리가 10GB이고 레디스 메모리 사용량이 10GB인 경우는 10/10이므로 값이 1이 된다.

물리 메모리가 10GB이고 레디스 메모리 사용량이 8GB인 경우 값은 1.25가 되는 것이다.

 

1이면 이상적인 상태이나 이 값보다 커진다면 파편화가 심화된다.

1.5가 넘는다면 서버 재시작을 권장한다.

1보다 작은 경우 레디스의 메모리 사용량이 실제 물리 메모리 사용량보다 큰 경우여서 OS에 의해 메모리의 일부가 Swap되어 디스크로 이동되었을때 나타난다. (디스크 사용으로 성능저하가 발생하므로 물리 메모리 증설 권장)

 

 

 

Redis Cluster Install

Environment

 

OS : Ubuntu 18.04

Redis Version : 5.0.8

Machine : 3EA (192.168.50.14 ~ 16)

 

 

Redis Port : 6379, 6380, 6381

Redis Cluster Port : 16379 

 

 

Redis Install

Ubuntu 20.04에서는 기본적으로 Redis 5버전이 설치되지만 Ubuntu 18.04에서 Redis 4버전이 설치되므로 Redis 5버전을 설치하려면 별도의 Repository가 필요하다.

 

1. Add Repository

# add-apt-repository ppa:chris-lea/redis-server

# apt update

 

2. Redis 5 Install

# apt install -y redis-server

 

 

Create Redis Cluster

1. Default redis conf setting 

# vim /etc/redis/redis.conf

bind 0.0.0.0

cluster-enabled yes

cluster-config-file nodes-6379.conf

cluster-node-timeout 15000

appendonly yes

 

# cp /etc/redis/redis.conf /etc/redis/redis-6380.conf

#  vim /etc/redis/redis-6380.conf

port 6379 => port 6380

pidfile /var/run/redis/redis-server.pid => pidfile /var/run/redis/redis-6380.pid

cluster-config-file nodes-6379.conf => cluster-config-file nodes-6380.conf

 

# cp /etc/redis/redis.conf /etc/redis/redis-6381.conf

# vim /etc/redis/redis-6381.conf

port 6379 => port 6381

pidfile /var/run/redis/redis-server.pid => pidfile /var/run/redis/redis-6381.pid

cluster-config-file nodes-6379.conf => cluster-config-file nodes-6381.conf

 

# systemctl restart redis-server

# redis-server /etc/redis/redis-6380.conf

# redis-server /etc/redis/redis-6381.conf

 

# redis-cli -p 6379 ping

PONG

# redis-cli -p 6380 ping

PONG

# redis-cli -p 6381 ping

PONG

3대의 머신에 동일하게 설정하여 준다.

 

2. Create Cluster

6379는 Master Port, 6380은 Slave 1 Port, 6381은 Slave 2 Port 이다.

각 Cluster의 Repilcas를 2로 하여 Master 3대, Slave 6대로 구성하였다.

 

# redis-cli --cluster create \

192.168.50.14:6379 \

192.168.50.15:6379 \

192.168.50.16:6379 \

192.168.50.14:6380 \

192.168.50.15:6380 \

192.168.50.16:6380 \

192.168.50.14:6381 \

192.168.50.15:6381 \

192.168.50.16:6381 \

--cluster-replicas 2

 

 

3. Cluster Node Check

# redis-cli -p 6379 cluster nodes

d8aacf656c4a9c67708ab89d3038736cbe1cc364 192.168.50.14:6380@16380 slave b1e905ca7d3fb5f743930565994aef6eb48cfe95 0 1590331467684 4 connected

4d51c878f3ff425d5423e32e6c16c1076b27200d 192.168.50.16:6381@16381 slave 29c5855872ff38f9f2a4203094fc4928fec7744f 0 1590331464397 9 connected

186deee637ea73f136d671f674320b424c3dddf4 192.168.50.14:6379@16379 myself,master - 0 1590331466000 1 connected 0-5460

d5d6f86145f27daabd587601e0daf452900699fc 192.168.50.15:6381@16381 slave b1e905ca7d3fb5f743930565994aef6eb48cfe95 0 1590331468000 8 connected

29c5855872ff38f9f2a4203094fc4928fec7744f 192.168.50.15:6379@16379 master - 0 1590331470302 2 connected 5461-10922

cb508abdf02d27281b1f73019ce4b2529a6391ef 192.168.50.14:6381@16381 slave 29c5855872ff38f9f2a4203094fc4928fec7744f 0 1590331466275 7 connected

9465e7a7d8420a6abae8c01e37ad50575d06141a 192.168.50.15:6380@16380 slave 186deee637ea73f136d671f674320b424c3dddf4 0 1590331466577 5 connected

bb77d55e06f3e99b4ada111085f678b791d36dc7 192.168.50.16:6380@16380 slave 186deee637ea73f136d671f674320b424c3dddf4 0 1590331469295 6 connected

b1e905ca7d3fb5f743930565994aef6eb48cfe95 192.168.50.16:6379@16379 master - 0 1590331467281 3 connected 10923-16383

 

각 노드별 slot이 분배된 것을 확인할 수 있다.

 

# redis-cli -p 6379 cluster info

cluster_state:ok

cluster_slots_assigned:16384

cluster_slots_ok:16384

cluster_slots_pfail:0

cluster_slots_fail:0

cluster_known_nodes:9

cluster_size:3

cluster_current_epoch:9

cluster_my_epoch:1

cluster_stats_messages_ping_sent:109

cluster_stats_messages_pong_sent:102

cluster_stats_messages_sent:211

cluster_stats_messages_ping_received:94

cluster_stats_messages_pong_received:109

cluster_stats_messages_meet_received:8

cluster_stats_messages_received:211

 

클러스터의 상태 정보를 볼 수 있다.

 

# redis-cli -c -p 6379

127.0.0.1:6379> cluster keyslot test:1

(integer) 10491

127.0.0.1:6379> cluster keyslot test:2

(integer) 6296

127.0.0.1:6379> cluster keyslot test:3

(integer) 2233

127.0.0.1:6379> cluster keyslot test:4

(integer) 14430

127.0.0.1:6379> cluster keyslot test:5

(integer) 10367

127.0.0.1:6379>

 

cluster keyslot 명령어를 실행해보면 해당 키가 어떤 슬롯에 저장되는지 확인할 수 있다.

 

4. Inster Data

# redis-cli -c -p 6379

set hello world

-> Redirected to slot [866] located at 192.168.50.14:6379

OK

 

hello라는 key에 world라는 value를 넣고 redis에 set하였다. hello라는 key는 866 slot에 저장되며 노드는 1번인 192.168.50.14 서버의 redis에 저장된다.

 

# redis-cli -c -p 6379

127.0.0.1:6379> get hello

-> Redirected to slot [866] located at 192.168.50.14:6379

"world"

 

다른 서버에서 질의시 해당 서버는 자신이 가지고 있는 slot이 아니면 client에게 slot을 가진 서버를 리다이렉트하도록 전달한다.

 

5. Fail Over

hello (key slot 866) 라는 key를 가진 1번 (192.168.50.14) Master의 머신을 종료하여 다른 머신에 있는 Slave가 Master로 승격되는지 테스트를 진행한다.

 

# poweroff 

 

노드의 상태를 확인한다.

 

# redis-cli -p 6379 cluster nodes

d8aacf656c4a9c67708ab89d3038736cbe1cc364 192.168.50.14:6380@16380 slave,fail? b1e905ca7d3fb5f743930565994aef6eb48cfe95 1590332380344 1590332379219 3 connected

cb508abdf02d27281b1f73019ce4b2529a6391ef 192.168.50.14:6381@16381 slave,fail? 29c5855872ff38f9f2a4203094fc4928fec7744f 1590332380344 1590332377000 2 connected

29c5855872ff38f9f2a4203094fc4928fec7744f 192.168.50.15:6379@16379 master - 0 1590332393000 2 connected 5461-10922

d5d6f86145f27daabd587601e0daf452900699fc 192.168.50.15:6381@16381 slave b1e905ca7d3fb5f743930565994aef6eb48cfe95 0 1590332392703 8 connected

b1e905ca7d3fb5f743930565994aef6eb48cfe95 192.168.50.16:6379@16379 myself,master - 0 1590332395000 3 connected 10923-16383

bb77d55e06f3e99b4ada111085f678b791d36dc7 192.168.50.16:6380@16380 slave 186deee637ea73f136d671f674320b424c3dddf4 0 1590332393750 1 connected

9465e7a7d8420a6abae8c01e37ad50575d06141a 192.168.50.15:6380@16380 slave 186deee637ea73f136d671f674320b424c3dddf4 0 1590332394813 5 connected

186deee637ea73f136d671f674320b424c3dddf4 192.168.50.14:6379@16379 master,fail? - 1590332379521 1590332377000 1 connected 0-5460

4d51c878f3ff425d5423e32e6c16c1076b27200d 192.168.50.16:6381@16381 slave 29c5855872ff38f9f2a4203094fc4928fec7744f 0 1590332395846 2 connected

 

머신 1(192.168.50.14)번에 있던 master와 slave가 fail 상태인 것을 확인할 수 있다.

 

#  redis-cli -p 6379 cluster info

cluster_state:ok

cluster_slots_assigned:16384

cluster_slots_ok:16384

cluster_slots_pfail:0

cluster_slots_fail:0

cluster_known_nodes:9

cluster_size:3

cluster_current_epoch:11

cluster_my_epoch:3

cluster_stats_messages_ping_sent:1101

cluster_stats_messages_pong_sent:1115

cluster_stats_messages_meet_sent:4

cluster_stats_messages_fail_sent:24

cluster_stats_messages_auth-ack_sent:1

cluster_stats_messages_sent:2245

cluster_stats_messages_ping_received:1111

cluster_stats_messages_pong_received:1089

cluster_stats_messages_meet_received:4

cluster_stats_messages_fail_received:3

cluster_stats_messages_auth-req_received:2

cluster_stats_messages_received:2209

 

1번(192.168.50.14) 머신이 종료되어 Cluster에서 빠졌음에도 cluster_state:ok 상태이다.

 

# redis-cli -p 6379 cluster nodes

d8aacf656c4a9c67708ab89d3038736cbe1cc364 192.168.50.14:6380@16380 slave,fail b1e905ca7d3fb5f743930565994aef6eb48cfe95 1590332380344 1590332379219 3 connected

cb508abdf02d27281b1f73019ce4b2529a6391ef 192.168.50.14:6381@16381 slave,fail 29c5855872ff38f9f2a4203094fc4928fec7744f 1590332380344 1590332377000 2 connected

29c5855872ff38f9f2a4203094fc4928fec7744f 192.168.50.15:6379@16379 master - 0 1590332546021 2 connected 5461-10922

d5d6f86145f27daabd587601e0daf452900699fc 192.168.50.15:6381@16381 slave b1e905ca7d3fb5f743930565994aef6eb48cfe95 0 1590332550073 8 connected

b1e905ca7d3fb5f743930565994aef6eb48cfe95 192.168.50.16:6379@16379 myself,master - 0 1590332546000 3 connected 10923-16383

bb77d55e06f3e99b4ada111085f678b791d36dc7 192.168.50.16:6380@16380 master - 0 1590332547039 11 connected 0-5460

9465e7a7d8420a6abae8c01e37ad50575d06141a 192.168.50.15:6380@16380 slave bb77d55e06f3e99b4ada111085f678b791d36dc7 0 1590332548046 11 connected

186deee637ea73f136d671f674320b424c3dddf4 192.168.50.14:6379@16379 master,fail - 1590332379521 1590332377000 1 connected

4d51c878f3ff425d5423e32e6c16c1076b27200d 192.168.50.16:6381@16381 slave 29c5855872ff38f9f2a4203094fc4928fec7744f 0 1590332549054 2 connected

 

1번이 종료됨에 따라 3번 머신(192.168.50.16)에 있던 Slave가 Master로 승격된 것을 확인할 수 있다.

 

# redis-cli -c -p 6379 get hello

"world"

 

 

 

 

참조 URL

• https://medium.com/garimoo/redis-documentation-2-%EB%A0%88%EB%94%94%EC%8A%A4-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-%ED%8A%9C%ED%86%A0%EB%A6%AC%EC%96%BC-911ba145e63

• http://blog.haandol.com/2018/09/07/redis-cluster-predixy.html

• https://brunch.co.kr/@springboot/218

• https://freesunny.tistory.com/56

• https://www.letmecompile.com/redis-cluster-sentinel-overview/

• http://redisgate.kr/redis/cluster/cluster.php

• http://kimyongjin.com/post/1909

• https://blog.naver.com/PostView.nhn?blogId=theswice&logNo=221413242954&parentCategoryNo=&categoryNo=15&viewDate=&isShowPopularPosts=true&from=search