Redis Operate

 

이번 글을 통해 Redis를 운영할 수 있는 방법들을 정리하겠다.

 

Redis 운영 방식

 

Standalone

가장 간단한 형태로, 하나의 서버에 Redis를 설치하고 실행하는 방식이다.

 

standalone

 

위 방법은 간단하지만, SPOF(Single Point of Failure)이기 때문에 실제 서비스에서는 사용할 수 없다.

 

 

Sentinel

Sentinel : a soldier or guard whose job is to stand and keep watch.

 

Sentinel로 운영한다는 의미는 Redis Master와 Replication를 두고, Sentinel Process를 이용해 Master와 Replication의 상태를 계속 모니터링 하고, 문제가 발생하면 자동으로 대응해주도록 구성한다는 의미다.

 

가장 기본적인 Sentinel 구성

 

 

Sentinel 구성의 특징

• Monitoring : Sentinel Process가 주기적으로 Master와 Replication 서버가 잘 동작하는지 모니터링 한다.
• Notification : Redis 서버에 이벤트가 발생하면, Sentinal은 API 형태로 이벤트 발생을 전파할 수 있다.
• Automatic Failover : Master 서버에 문제가 생겼을 때, 자동으로 Replication 중 하나를 마스터로 승격시킨다.
• Configuration provider : 클라이언트에게 현재 활성화된 Master 서버의 주소를 알려준다.

 

위 특징들 덕분에 Sentinel 구성은 HA(High Availablity)를 보장한다.

 

Master 서버 장애 발생시 Flow

Sentinel로 구성된 상태에서 Redis Master 서버가 불능 상태가 되면 아래와 같은 플로우로 복구된다.

 

1. Sentinel에서 Master 서버 장애 상황 감지.

Sentinel간 통신을 통해 Quorum 수 이상의 Sentinel들이 Master 노드가 다운되었다고 동의하면, Master 노드를 다운된 상태로 인지한다.

 

2. Automatic Failover 동작

여러 Sentinel 중 Leader를 선출한 후, Leader여러 Replcation 중 새로운 마스터가될 서버를 선택한 후, Master로 승격시킨다.

 

ref

- https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/

 

Redis Cluster

Redis Cluster는 여러 Node에 데이터를 분산해서 저장하는 방식이다. 덕분에 여러대의 Redis Node가 모여 하나의 큰 Redis 역할을 수행한다.

 

 

기본 구성

 

 

특징

• Node Communication : Cluster bus를 통해 node간 커뮤니티케이션을 한다. binary protocol을 사용하기 때문에 network bandwidth가 적고, processing time도 짧다. (Gossip Protocol 이라고한다.)
• Data Sharing : 데이터들이 여러 노드에 분산되어 저장된다. 데이터를 16384개의 Hash Slot으로 나눈다. 그리고 Key의 해시값을 계산해 Hash Slot 중 하나에 맵핑한다.  

CRC16(key) % 16384 = Hash Slot Index

 

Master Noder가 3개라고 가정하면 보통 데이터는 아래와 같이 분산된다.

Node 1 : hash slots 0 - 5500

Node 2 : hash slots 5501 - 11000

Node 3 : hash slots 11001 - 16383

• master-replica model : master replica 모델을 사용하기 때문에 master 노드에 장애가 발생해도, auto failover를 통해 서비스 다운 타임 없이 운영 할 수 있다.

 

Redis Cluster는 Data Sharing으로 수평 확장(Horizontal Scalability)를 보장한다. 다시 말하자면, 데이터 양이 많거나, 트래픽이 증가하면 노드를 추가하여 시스템의 성능을 확장할 수 있다.

Master-Replica 모델 덕분에 고가용성(High Availablity)와 내결함성(Fault Tolerance)를 보장할 수 있다. Master Node가 서비스 불가능한 상황이 생겨도, 자동으로 Replica를 승격시켜, 서비스 다운타임 없이 운영할 수 있다.

 

하지만 몇 가지 주의할 점이 있다.

 

주의사항

• Data Consistency : Redis Cluster를 사용하면 데이터 일관성을 100% 보장하기 힘들다.

그 이유는 master-replica 모델에서 데이터 복제가 비동기로 발생하기 때문이다.

 

데이터 입력이 들어오면 아래와 같이 동작한다.

1. master node에 데이터 쓰고 ok 응답 보내기

2. 비동기로 replica에게 데이터 변경 전파

 

만약, 1번 과정을 수행하고 master node가 불능상태가 된다면, 1번에서 요청된 데이터에 손실이 발생한다.

replica로의 데이터 전파 과정을 동기적으로 수행할 수 있지만, 그렇게 되면 Redis의 write 성능이 크게 저하된다.

즉, 성능과 데이터 일관성은 trade-off 관계이다.

 

• Multi 연산의 복잡성

Redis Cluster는 모든 키가 동일한 Hash Slot에 있을 경우에 한해 멀티키 연산을 지원한다. 왜냐하면 데이터가 여러 노드에 분산되어 있기 때문이다.

 

이를 위한 한 가지 묘수가 존재한다.

Hash Tag 기능을 사용하면 이 문제를 해결할 수 있다. Key를 만들때 키에 {}로 묶인 문자열이 있다면 Redis는 해당 문자만을 이용해 Hash Slot을 결정한다. 그러면 Key가 같은 Hash Slot에 있기 때문에 여러 키를 사용하는 명령어를 사용할 수 있다.

1. user:{123}:profile
2. user:{123}:account

1, 2번 키 모두 123 이라는 Hash Tag를 공유하기 때문에 같은 Hash Slot 즉, 같은 노드에 저장된다.

 

ref

- https://redis.io/docs/latest/operate/oss_and_stack/management/scaling/

 

 

Standalone vs Sentinel vs Cluster

그럼 셋 중 어떤 상황에 어떤 구성을 쓰면 좋을까?

 

만약, 테스트 용도의 Redis가 필요하다면, Standalone을 추천한다.

그런데 테스트가 아니라 실 서비스를 위해서라면 Standalone은 적합하지 않다. 왜냐하면 서비스의 SPOF가 되기 때문이다.

 

실제 서비스에 사용하려면 Sentinel로 구성하는게 좋다. 그러면 Master Redis가 불능 상태가 되어도 automatic failover 덕분에 서비스가 다운되지 않는다. 

하지만 처리해야하는 트래픽과 데이터 양이 많다면, Sentinel은 적합하지 않다. 왜냐하면 수평 확장이 불가능하기 때문이다.

 

그럴때는 Redis Cluster를 사용해야 한다. Redis Cluster는 트래픽과 데이터 양이 늘어나면 Redis Node 수를 늘려 수평 확장이 가능하다. 추가로 Master-Replica 모델 덕분에 고가용성과 내결함성도 보장한다.

 

 

번외..

Redis Cluster vs nbase-arc

Naver 에서 세션 저장소 용도로 사용하기 위해 개발된 솔루션이 있다.

이름은 nbase-arc로 In-memory 기반의 클러스터 DB 이다. 내부 저장소로 Redis를 사용하고 있다.

 

위 솔루션이 나온 시점에는 Redis Cluster가 정식 출시하지 않아, 솔루션을 만든 것 같다.

Redis Cluster와 nbase-arc의 주요 차이점은 아래와 같다.

 

	Redis Cluster	nbase-arc
키 분산	동일
데이터 복제 방식	Asynchronous	Consensus
Node 복구	RDB / AOF / RDB + AOF	RDB + LOG
클라이언트 연결	REDIS	Gateway
Migration	Key 단위	Key 영역 단위
Fault detection	Node 간의 gossip	모니터링 모듈 존재

 

위 차이점을 정리해보면, nbase-arc는 redis-cluster와 비교해볼때 아래와 같은 이점이 있다.

 

nbase-arc는 데이터 복제 방식을, 선 복제 후 처리식으로 변경해 데이터 일관성을 보장한다.

클라이언트가 Redis에 직접 붙지 않고, Gateway에 붙기 때문에 Redis 형상관리가 용이하다. 추가로 Migration이 Key 영역 단위로 진행되기 때문에 더 빠르다.

 

하지만 위 작업들 때문에 어쩔 수 없는 성능상의 trade-off는 존재한다.

 

ref

- https://deview.kr/2014/session?seq=37

- https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

- https://d2.naver.com/helloworld/614607