Redis 아키텍처 정리 (Replication / Sentinel / Cluster / Sharding)

지금까지 Redis의 개념, 자료구조, 캐싱 전략까지 정리했습니다.

이제 진짜 중요한 단계입니다.

 

트래픽이 커졌을 때 Redis를 어떻게 운영할 것인가?

 

실무에서는 단일 Redis 서버로는 성능 / 안정성 / 확장성 모두 한계가 옵니다.

그래서 Redis는 다양한 아키텍처 기능을 제공합니다.

이번 글에서는

• Replication
• Sentinel
• Cluster
• Sharding

처럼 대규모 트래픽 대응 핵심 구조를 정리해 보겠습니다

---

Redis 아키텍처 종류 

 

Redis의 아키텍처는 간단히 말하면 3가지의 종류를 가지고 있습니다

이제 각각의 아키텍처를 알아보겠습니다 

Replication 이란?

Redis를 사용하는 주된 이유 중 하나가 이 Replicaiton 때문입니다 Replication을 이용하면 다음과 같은 성능을 얻을 수 있습니다 

 

1. 장애 대비 

만일 Redis 서버가 한대만 있으면 어떤 일이 있을까?

Redis는 In-Memory Store 이기 때문에 서버가 터지면 캐시 데이터가 전부 날아가고 , 이로 인해 DB 트래픽 폭발 잘못하면 DB 가 다운 될 수도 있습니다 

 

이를 해결하기 위해 Replica 서버가 등장했습니다 

Master 죽음
→ Replica 승격 (failover)
→ 서비스 계속됨

 

2. 읽기 분산

Redis 서버 한대에서  read 트랙픽 이 초당 10만 개 이상이  들어오면 어떻게 될까 

Master는 혼자 처리하지 못하고 버티지 못하면 잘못하면 Redis 가 다운 될 수도 있습니다

그래서  Replica를 만들어 

Client → Master (Write) 
Client → Replica (Read)

읽기 작업은 Replica에서 진행하고 쓰기 작업은 Master에서 담당하게 해 트래픽을 분산할 수 있습니다 

 

3. 백업/데이터 안전성

캐시라 해도 날아가면 안 되는 데이터가 있을 수도 있습니다 

그래서 그런 데이터를 백업하기 위해서 Replica를 사용할 수 있습니다 

 

ReplicationLag

Redis의 복제뿐만 아니라 모든 레디스의 복제는 비동기 방식으로 동작합니다 따라서  마스터에서 복제본에 데이터가 잘 전달 됐는지 매번 확인하고 기다리지 않습니다 

이로 인해 Replication Lag가 발생하게 됩니다 

 

 

ReplicationLag란? 

비동기 방식이다 보니 A라는 데이터가 바뀌면 레플리케이션한테 데이터를 봐주라고 요청을 보내줘야 하는데 그 요청을 보내고 데이터를 바꿀 때 걸리는 시간 동안 데이터 불일치가 발생한다는 것을 의미합니다

그래서 마스터는 데이터가 있는데 슬레이브는 데이터가 없는 경우가 발생합니다

거의 발생하지 않을 것 같지만 부하에 따라 큰 차이가 생길 수가 있습니다 

큰 부하의 대표적인 예는

Replication 기능이 많이 발생하면 슬레이브가 Master와의 Connection을 끊어버리게 되고 나중에 다시 연결을 맺는데 그때 많은 부하가 발생하게 됩니다

 

 

Repliaction 설정 

리플리케이션 설정하는 방법은 세컨더리(slave)에서 

replaca of 아니면 slaveof

커맨드를 사용해  마스터의 ip or domain address + port를 정보를 입력해 주면 됩니다 

 

그러면 내부에 아래 동작이 일어나게 됩니다

• Secondary에 replicaof or slave of 명령을 전달
• Seconadry는 Primary에 sync 명령 전달
• Primary는 현재 메모리 상태를 저장하기 위해 Fork
• Fork 한 프로세서는 현재 메모리 정보를 disk에 dump
• 해당 정보를 secondary에 전달

---

Fork  주의

 

 

앞에서 말한 것 같이 레디스의 데이터를 파일로 저장할 때(영구저장) 포크를 통해 자식 프로세스를 생성한다

예전 C언어에서 배운 기억으로는 Fork는 자식 스레드를 만드는 명령어다

이로 인해 우리는  

 

자식스레드로 백그라운드에서는 데이터를 파일로 저장을 하고 있지만 원래 프로세스는 계속해서 일반적인 요청을 받아 데이터를 처리하고 있다

 

이게 가능한 이유는 copy on wirte이라는 기능으로 메모리를 복사해서 사용하기 때문인데

이로 인해 서버의 메모리 사용량이 2배로 증가하는 상황이 발생할 수 있다

 

복제 연결을 처음 시도하거나 혹은 연결이 끊겨 재시도할 때에 새로 RDB 파일을 저장하는 과정을 거치기 때문이다

따라서 이런 경우에 MAXMEMORY 값은 실제 메모리의 절반 정도로 설정해 두는 것이 좋다

---

Replication 시 주의 할 점

1. Replication 과정에서 fork 가 발생하므로 메모리 부족이 발생할 수 있다
2. Redis-cli—rdb 명령은 현재 상태의 메모리 스냅숏을 가져오므로 같은 문제를 발생시킨다
3. 많은 대수의 Redis 서버가 Replica를 두고 있으면 네트워크 이슈나, 사람의 작업으로 동시에 replication이 재시도되도록 하면 문제가 발생할 수 있다
   왜냐하면 네트워크 가 감당 할 수 있는 bandwidth 보다 더 큰 데이터를 전달하면 안 됨 네트워크가 마비돼서 끊어져서 다시 들어오고 또 끊어져서 다시 들어오고 반복될 수 있다

 

---

 

Sentinel

Sentinel은 Redis 장애를 자동 감지하고 Failover를 수행하는 시스템입니다 

 

센티넬이 Master와 Replica를 모니터링하고 있다가 

마스터 노드가 죽으면 페일 오버를 발생시켜  기존의 리플리카 노드를 마스터로 변경시킵니다 

 

센티넬이 없다면 

Master Redis가 죽으면 수동 복구 필요 하지만 (이 작업이 신경 써야 할 게 많다 )

 

센티넬이 있다면

1. Master 장애 감지

2. Replica 중 하나를 Master로 승격

3. Client에게 새 Master 정보 전달

 

를 통해 자동으로 Redis 구조를 복구합니다 

 

장점 

 

• 고가용성 확보
• 자동 Failover
• 운영 부담 감소

단점

• 구조 복잡해짐
• 운영 이해 필요

 

 

---

Redis Cluster

Replication + Sharding + Failover를 모두 포함한 구조다

 

특징은

• 자동 데이터 분산
• 자동 장애 대응
• 자동 확장

을 가지고 있어 대규모 서비스에서는 거의 Redis Cluster 사용한다.

 

Slot 기반 분산

Redis Cluster는 16384개의 Slot으로 데이터를 나눈다

 

Key → Hash → Slot → Redis Node

 

이 구조 덕분에 매우 빠른 라우팅, 안정적인 분산 이 가능하다 

 

최소 3개의 마스터가 필요하며 Sharding 기능을 제공한다

데이터가 여러 마스터 노드에 자동으로 분할되어 저장되고  이 구성에서 모든 노드가 서로를 감시하고 있다가 마스터가 비정상 상태일 때 자동으로 페일오버를 진행한다

 

장점

• 자체적인 Primary , Secondary Failover
• Slot 단위의 데이터 관리

단점

• 메모리 사용량이 더 많음
• Migration 자체는 관리자가 시점을 결정해야 함
• Library 구현이 필요함

---

데이터 분산 방법 

트래픽이 더 커지면  하나의 Redis에 모든 데이터를 넣는 것이 불가능해집니다.

이때는 데이터를 분산해야 하는데 보통 Data 분산 방법은 다음과 같이 분류할 수 있습니다 

• Application
  • Consistent Hashing
  • Sharding
• Redis Cluster

Redis Cluster는 위에서 알아봤으니 Consistent  Hashing과 Sharding에 대해서 알아보겠습니다 

 

---

Sharding 

하나의 Redis에 모든 데이터를 넣는 것이 불가능해지기 때문에 이때 사용하는 것이 Sharding입니다.

 

샤딩 전략

샤딩전략이란  데이터를 어떻게 나눌 것인가? 를 선택 한느전략으로 상황에 따라 전략이 달라집니다

대표적인 샤딩 전략은 다음과 같습니다

• Range
• Modular
• RedisCluster

---

Range 전략 

Range 방식은 Redis 서버들이 특정 범위를 다룰 수 있게 값을 가지고 있습니다.

예를 들어 3개의 Redis 서버가 있다고 가정해 보면

• 1번 Redis 서버는 0 ~ 1000
• 2번 Redis 서버는 1001 ~ 2000
• 3번 Redis 서버는 2001 ~ 3000

범위를 가지고 있고 들어오는 데이터가 Redis 서버가 다룰 수 있는 범위를 확인하고 그 범위에 맞게 들어가는 것입니다.

 

 

장점 

• 구현이 간단하다 
• 서버 확장이 매우 편하다 

단점 

• 놀고 있는 서버와 열심히 일하는 서버가 극심하게 갈린다
• 그렇다고 놀고 있는 서버로 데이터를 옮기 지도 못한다 

 

---

Modular 전략

기존 Range 방식은 단순히 범위에 맞춰서 해당 범위에 Redis 서버로 갔다면 Modular 현재 서버의 수 를 나눠서 나온 나머지로 서버를 찾아가는 방식이다 

 

이 전략을 사용할 때 주의 할 점은 서버를 한 대씩 올리고 내리면 새로 들어온 서버 때문에 내부에서 데이터 이동이 엄청 많이 일어난다

이를 극복하기 위해서는 한 대씩 추가하는 게 아니라 2의 제곱 순으로 서버를 추가해야 한다

즉 서버를 추가할 때 0→2 →4→8→16→32 이렇게 추가해야 한다 

 

장점 

• 2의 제곱으로 서버를 추가하기 때문에 내부에서 이동하는 데이터 수가 현저히 줄어든다 
• 또한 이로 인해 수학적으로 규칙이 생겨 자기가 가야 할 서버를 바로 결정할 수 있다 

단점 

• 그런데 이 방식의 문제는 2의 제곱으로 늘려야 하다 보니 0→2 →4→8→16→32 이렇게 늘려야 할 숫자가 계속 늘어난다

---

Consistent Hashing

Sharding에서 가장 중요한 것이 Key 분산 전략이다 

이것으로 인해 새로운 서버가 올라오거나 서버가 다운되는 상황 속에서 내부에서 데이터가 얼마큼 재배치되는지가 결정된다 

일반 Modular 연산을 사용하면 거의 50% 의 내부 데이터가 재배치되는 과정을 겪는다 

 

이를 줄이고자 나온 게 ConsistentHashing이다 

 

이 방법은 서버를 해시값으로 해두고 데이터를 해시값으로 돌려 자기보다 큰 해시값을 가진 서버 중 가장 가까운 데로 가야 한다

예를 들어 서버의 해시값이 1000, 2000,3000 이 있고 25000의 해시값의 데이터가 들어오면 30000으로 가고 15000 이면 2000으로 가고 이렇게 간다 

 

사실 말로 설명하면 너무 알아듣기 어렵다 

이 과정은 https://youtu.be/mPB2CZiAkKM?si=nhpWCxoXj5be6zbD

 

해당 영상의 59분부터 보면 쉽게 몸으로 잘 설명해 준다 한번 확인해 보자!

---

아키텍처 선택  기준 

 

 

---

마무리

Redis를 단순 캐시 서버로만 사용하는 단계에서 벗어나면 아키텍처 설계가 성능과 안정성을 결정한다.

 

실무에서는

• Replication → Read 확장
• Sentinel → 장애 대응
• Sharding → 저장 확장
• Cluster → 전체 통합

처럼 상황에 맞게 구조를 선택해야 한다.

 

다음 글에서는 Redis의 FailOver와 데 redis persistence를 정리해 보겠습니다