클라우드 2025. 7. 28. 15:06

Redis 클러스터링이란?

정의

Redis 클러스터는 Redis가 데이터를 여러 노드에 자동 분산 저장(샤딩)하고, 장애 발생시 자동으로 복구 할 수 있도록 지원하는 분산형 구조입니다.

사용하는 이유

Redis는 기본적으로, 단일 프로세스, 단일 스레드 구조로 동작합니다.

하지만 단일 Redis 인스턴스는 한계가 존재합니다.

메모리 한계
- Redis는 인메모리 DB이므로, 한 인스턴스가 사용할 수 있는 RAM의 크기가 전체 데이터의 크기 한계가 됩니다.
장애시 전체 중단
- 마스터 하나에 장애가 나면 서비스 전체가 중단됩니다.
스케일 아웃 불가
- 단일 인스턴스로는 수평 확장(Scale-out)이 불가능합니다.

이를 해결하기 나온 것이 Redis 클러스터링입니다.

제공하는 기능

Redis 클러스터를 사용하면 다음과 같은 이점이 있습니다.

데이터를 여러 노드에 자동 분산 저장(샤딩)
각 마스터마다 하나 이상의 레플리카 설정(고가용성)
마스터 장애 시 자동 failover
클라이언트가 자동으로 해당 키의 노드를 찾아 접근(스마트 클라이언트)

클러스터는 기본적으로 16384개의 슬롯으로 나누어 데이터를 분산 저장합니다.

샤딩과 Replica의 원리

Redis는 내부적으로 16384개의 슬롯을 가집니다.

각 마스터 노드가 이 슬롯을 나눠서 데이터를 분산 저장(샤딩)합니다.

예를 들어 마스터 노드가 2개라면 16384 / 2 → 8192개의 슬롯을 가지게 되는데요

[마스터-1] 0~8191

[마스터-2]8192 ~ 16383

이렇게 나눠서 분산 저장하는데요

슬롯을 결정하는 공식은 HASH_SLOT = CRC16(<key>) % 16384 입니다.

예를 들어 SET hello world 명령어를 입력했을 때 key는 hello이고 value는 world 입니다.

그러면 다음 공식이 적용되어 번호가 나옵니다.

HASH_SLOT = CRC16("hello") % 16384
CRC16("hello") = 8669

그래서 key, hello는 슬롯번호 8669번에 저장을 해야하는데 클러스터가 8669 슬롯을 가진 마스터 노드(마스터-2)를 탐색하여 클라이언트가 그 노드에 명령어를 전달하고 마스터에 저장하고 레플리카에도 복제되게 됩니다.

그래서 테스트를 해봤습니다. 저는 EC2 4대를 가지고 마스터2대, 레플리카2대로 설정하였습니다.

우선 [마스터-1] 노드에 들어가서 다음 명령어를 입력합니다.

127.0.0.1:6379> SET hello world
OK

그리고 다음 명령어를 입력하여 어떤 슬롯에 저장되었는지 확인합니다.

127.0.0.1:6379> cluster keyslot hello
(integer) 866

866이면 [마스터-1] 노드입니다. 그래서 [마스터-1] 노드에서 get hello를 입력하면 결과가 잘 나옵니다.

127.0.0.1:6379> get hello
"world"

하지만 [마스터-2] 노드에서 입력한다면 어떻게 될까요?

127.0.0.1:6379> get hello
(error) MOVED 866 10.0.0.201:6379

그 키값은 [마스터-1] 노드가 가지고 있다고 거기로 가라고 합니다.

저는 클러스터 내부에 있으면 다른 노드에서 조회해도 될 것이라 생각했는데 예상과는 달랐습니다.

그래서 검색해본 결과 클러스터 대응 클라이언트(ex: redis-cli -c, Lettuce, ioredis)는 이걸 자동으로 처리해서 올바른 노드로 자동 라우팅 한다고 합니다.

그래서 redis-cli -c 로 클러스터 대응 클라이언트로 접속해서 명령어를 입력했을 때 리다이렉트 되어서 조회 되는 것을 확인할 수 있었습니다.

redis-cli -c
127.0.0.1:6379> get hello
-> Redirected to slot [866] located at 10.0.0.201:6379
"world"

근데 이것을 보고 궁금해진게 있는데, 866에 슬롯은 [마스터-1] 노드가 관리하고 있는데, 어떻게 [마스터-2]가 그걸 알고 있고 MOVED 를 반환해주는 걸까요?

그 답은 Redis 클러스터는 전체 슬롯 맵을 모든 노드가 공유한다고 합니다.

즉, Redis 클러스터에 참여한 모든 노드는 16384개의 슬롯이 어떤 노드에 배정되어 있는지 알고 있습니다. 이 정보는 클러스터 초기 구성시 cluster meet, cluster addslots, cluster replicate 등으로 동기화 되고, 그 이후에도 지속적으로 Gossip 프로토콜을 통해 서로 상태 정보를 주고 받으며 갱신됩니다.

Gossip 프로토콜은 뭘까요?

이름 그대로 “가십하듯이 조금씩 서로 소문을 퍼뜨리는 구조”인데요, 노드들이 주기적으로 서로 정보를 퍼뜨리듯 전파하는 방식의 분산 프로토콜입니다.

Redis 클러스터는 각 노드가 다음과 같은 정보를 “주기적으로 공유(Gossip)” 합니다.

다음과 같은 메세지 타입들이 사용됩니다.

메시지 타입 (type)	설명
MEET	클러스터에 새 노드를 소개할 때
PING	주기적으로 다른 노드에 상태 확인
PONG	PING에 대한 응답 + 추가 정보 포함
FAIL	특정 노드가 장애났음을 전체에 알림
PUBLISH	Pub/Sub 채널에 메시지 전파
FAILOVER_AUTH_REQUEST	레플리카가 마스터 승격을 위해 승인 요청
FAILOVER_AUTH_ACK	승격 요청에 대한 승인 응답
UPDATE	노드의 슬롯 및 상태 정보 변경 전파
MFSTART	마이그레이션 시작 알림 (resharding 관련)

이 메세지들로 어떻게 슬롯 상태를 공유할 수 있는지 살펴보면

노드 A가 10초마다 다른 노드 중 몇 개를 선택해서 PING 을 보냅니다.
PING 안에는 본인 정보, 알고 있는 다른 노드들의 요약 정보(gossip table)를 포함합니다.
수신한 노드 B는 새로운 정보나 바뀐 정보가 있으면 업데이트 하고, PONG으로 응답하면서 gossip 정보를 보냅니다.
그럼 A와 B가 알고있는 소문들이 A와 B서로 한테 공유되고 상태 정보가 서서히 전체로 퍼집니다.

한가지 더, 마스터가 죽었을 때 레플리카가 마스터로 어떻게 승격되는지도 살펴보겠습니다.

만약 마스터 A가 죽으면, 다른 노드들(B,C,D)이 PING을 보내도 PONG을 받지 못합니다. 그러면 PFAIL 상태로 기록됩니다. PFAIL은 “내가 보기엔 죽은거 같아” 라는 정도의 로컬 판단입니다.
다른 노드들도 마스터 A한테 PING을 보내보고, 계속 실패할 경우 클러스터 내의 노드가 “마스터A는 죽었다” 라고 합의하면 마스터 A는 FAIL 상태로 바뀝니다. 합의는 클러스터에 있는 마스터 노드 수의 과반수 이상이 같은 판단을 해야합니다.
레플리카 노드들은 자신의 마스터가 FAIL 상태가 되었음을 감지하고, 자신이 마스터로 승격(Failover)될 수 있는지 판단합니다. 하지만 모든 레플리카가 동시에 승격되면 안되므로 투표 기반으로 하나만 올라갑니다.
레플리카들은 FAILOVER_AUTH_REQUEST 메세지를 다른 마스터 노드들에게 보냅니다. 그러면 다른 마스터 노드들은 투표권이 있다면 FAILOVER_AUTH_ACK 로 응답합니다. 가장 먼저 과반수 ACK를 받은 레플리카가 승격됩니다.
그럼 승격된 레플리가는 clusterNode→flags를 SLAVE→MASTER로 바꾸고 기존 마스터가 담당하던 슬롯 정보를 자신에게 등록합니다. 등록하는 과정은 기존 마스터보다 configEpoch 값을 높게 설정하는 것으로 합니다.

configEpoch는 Redis 클러스터의 슬롯 소유권을 추적하고 충돌을 방지하기 위한 버전 번호입니다.

즉, 동일한 슬롯을 여러 노드가 가지고 있다고 하면, 더 높은 configEpoch를 가진 노드가 그 슬롯의 소유자로 간주됩니다.

Redis 클러스터 구축 실습

이제 이론을 학습했으니 레디스 클러스터 구축 실습을 해보겠습니다.

저는 9개의 인스턴스에다가 프라이머리3대 세컨더리 6대로 클러스터 구축 하려고 합니다.

우선 9개를 다 만들기 귀찮으니 하나에 기본 설정 다해놓고 ami로 만들어 8개 생성하겠습니다.

우선 저는 ubuntu24.04 에서 실행했습니다. 인스턴스 타입은 t3.small 입니다.

우선 다음 명령어로 redis를 설치해줍니다.

sudo apt update && sudo apt install redis -y

그러면 레디스 설정 파일이 생성되는데 다음과 같이 들어가줍니다.

sudo vi /etc/redis/redis.conf

들어간 후에 다음 설정들로 바꿔줍니다.

port 6379 # 포트를 6379로 띄우겠다는 설정
cluster-enabled yes # Redis를 클러스터 모드로 실행하겠다는 설정입니다. (슬롯 분산, 자동 failover 기능 활성화)
cluster-config-file nodes.conf # 클러스터 구성 정보를 담는 로컬 캐시 파일로 Redis가 시작될 때 이 파일을 읽어 클러스터 상태를 복원합니다.
cluster-node-timeout 15000 # Redis 노드간 통신 타임아웃을 설정합니다. 15초 동안 heartbeat응답이 없으면 다운된 것으로 간주합니다. 
appendonly yes # 레디스의 AOF 기능 활성화 레디스는 인메모리라 꺼지면 데이터가 사라지기 때문에 모든 쓰기 명령을 로그 파일(aof 파일)에 기록하여 다시 켜질때 이 파일의 명령들을 실행합니다. 
bind 0.0.0.0 # 외부 접근을 허용합니다. -> 다른 레디스 클러스터의 접근을 허용하기 위함입니다.
protected-mode no # 보호 모드 비활성화 -> 보호 모드가 활성화일때는 외부 접근을 차단하기 때문에 비활성화 해줍니다.

이렇게 설정파일을 바꿔주면 됩니다만 모든 외부 접근을 허용해줬기 때문에 보안그룹을 잘 설정하여 보안을 챙겨야 합니다.

저는 실습용으로 퍼블릭 서브넷에 두긴 했는데 DB서브넷에 두는게 맞는 설정입니다.

어쨌든 퍼블릭 서브넷의 CIDR 대역에서 허용해주는 보안그룹 설정을 작성합니다.

퍼블릭 서브넷-1(us-east-1a) : 10.1.0.0/24

퍼블릭 서브넷-2(us-east-1b) : 10.1.10.0/24

퍼블릭 서브넷-3(us-east-1c) : 10.1.20.24/24

이 세가지 대역에서 오는 요청의 6379포트와 16379 요청을 허용해줍니다.

6379 요청은 레디스 클라이언트 통신용입니다.(SET, GET 용)

16379 요청은 클러스터 내부 통신용입니다.(슬롯 이동, failover 용도)

클러스터 통신은 기본 포트에 + 10000을 한 포트가 클러스터 내부 통신용 포트가 됩니다. 만약 redis 포트가 7000이라면 17000이 클러스터 내부 통신용이 되는겁니다.

그래서 다음과 같이 보안그룹 설정을 해줍니다.

그리고 아까 만들었던 인스턴스의 AMI를 만들어줍니다.

인스턴스 선택 → 작업 → 이미지 및 템플릿 → 이미지 생성 에서 이미지를 만들어준 후 5분 정도 기다리면 이미지가 생성됩니다.

이미지가 생성될동안 시작 템플릿을 만들어둡니다.

우선 이름은 redis-cluster-template으로 지정해주고

OS이미지는 생성한 AMI를 선택합니다.

그리고 키페어도 설정해주고 네트워크 설정은 서브넷과 가용영역 설정하지 않고 보안그룹은 기존 생성했던 redis-sg를 넣어줍니다.

그리고 고급 네트워크 구성에서 퍼블릭 IP 자동할당을 설정해줘야 퍼블릭 IP가 있는채로 인스턴스가 생성되니 퍼블릭 서브넷에 생성하실분은 참고 하시면 됩니다.

그리고 엄청 중요한 설정을 하나 해줘야 하는데요

바로 /var/lib/redis 디렉토리 아래에 있는 nodes-6379.conf 파일을 삭제해줘야 합니다.

이렇게 해야하는 이유는 저희는 AMI를 만들어서 인스턴스를 시작할 것입니다. 그래서 AMI 만든 노드의 정보(ex. 클러스터 노드의 ID, IP, 슬롯 상태)는 nodes-6379.conf 파일에 그대로 들어가있고, 9개의 인스턴스를 띄운다면 9개의 노드가 똑같은 노드라고 인식을 하게 되어 클러스터 구성이 안됩니다.

그래서 시작템플릿 고급 세부정보의 맨 아래의 사용자 데이터에 다음 스크립트를 넣어주어 설정을 지우고 레디스를 재시작해줍니다.

#!/bin/bash

sudo rm /var/lib/redis/nodes-6379.conf
sudo systemctl restart redis

설정 파일을 삭제하고 redis를 재시작하면 설정파일이 현재 노드 기준으로 잘 생성됩니다.

그리고 다음 명령어를 사용하여 레디스 클러스터에 노드들을 참가 시킵니다.

redis-cli --cluster create \\
10.1.20.178:6379 \\
10.1.20.82:6379 \\
10.1.20.8:6379 \\
10.1.20.6:6379 \\
10.1.20.222:6379 \\
10.1.20.68:6379 \\
10.1.20.18:6379 \\
10.1.20.180:6379 \\
10.1.20.36:6379 \\
--cluster-replicas 2

이 명령어를 입력하면 위의 3 노드는 primary로 참여하고 밑의 6개의 노드는 replica로 참여한다고 합니다. 하지만 처음에 GPT가 4,5는 1번 primary의 replica가 되고 6,7은 2번, 8,9는 3번 이라고 했는데 확인해본 결과 그러지 않았고, 무작위로 설정되었습니다.

저 명령어는 레플리카를 자동으로 랜덤하게 분산 지정하는데, 같은 호스트에 있는 마스터의 복제본이 되지 않도록 회피하고, 레플리카를 최대한 균형 있게 배정하려고 한다합니다.

하지만 저는 인스턴스를 이번에는 하나의 가용영역에만 넣어 고르게 분산되지 않았던 것 같습니다.

그래서 3개씩 다른 가용영역에 넣고 수행하면 어떤 결과가 나올지 실험해보겠습니다.

시작템플릿으로 3개씩 3번 생성하여 a,b,c 가용영역에 redis를 넣었습니다. 우선 primary인스턴스를 1번 노드로 하겠습니다.

각 인스턴스의 ip는 다음과 같습니다.

인스턴스 이름	프라이빗 IP	퍼블릭 IP
redis-a1	10.1.0.19	98.85.221.48
redis-a2	10.1.0.138	13.217.141.168
redis-a3	10.1.0.133	34.229.109.84
redis-b1	10.1.10.206	3.216.30.223
redis-b2	10.1.10.33	3.237.188.67
redis-b3	10.1.10.118	3.234.224.46
redis-c1	10.1.20.122	3.91.177.75
redis-c2	10.1.20.234	3.82.175.137
redis-c3	10.1.20.4	52.55.56.178

이러고 redis-a1 내부로 들어가서 클러스터 구축 명령어를 입력해보겠습니다.

redis-cli --cluster create \\
10.1.0.19:6379 \\
10.1.10.206:6379 \\
10.1.20.122:6379 \\
10.1.0.138:6379 \\
10.1.0.133:6379 \\
10.1.10.33:6379 \\
10.1.10.118:6379 \\
10.1.20.234:6379 \\
10.1.20.4:6379 \\
--cluster-replicas 2

이럼 클러스터가 구축되는데 클러스터를 확인해보면 다음과 같이 나옵니다.

📦 Redis Cluster Topology
--------------------------
🔴 Master: 10.1.20.122:6379 (slots: 10923-16383)
  └── 🟢 Replica: 10.1.20.4:6379
  └── 🟢 Replica: 10.1.0.138:6379
🔴 Master: 10.1.0.19:6379 (slots: 0-5460)
  └── 🟢 Replica: 10.1.10.33:6379
  └── 🟢 Replica: 10.1.0.133:6379
🔴 Master: 10.1.10.206:6379 (slots: 5461-10922)
  └── 🟢 Replica: 10.1.10.118:6379
  └── 🟢 Replica: 10.1.20.234:6379

제가 예상한것은 primary가 가용영역 A에 있다면 replica 두개는 B, C에 들어가는 것이 안전하다고 생각하고 이렇게 들어가는 것을 예상했었는데, 예상한대로 들어가지 않았습니다.

IP대역 기반으로 나눌줄 알았지만 무작위로 지정한 것 같습니다.

그래서 저 명령어 대신 수동으로 replica들을 지정해주는 방식으로 해야 합니다.

우선 기존 클러스터를 초기화하는 스크립트를 짭니다. 이를 로컬에서 돌리면 됩니다.

#!/bin/bash

KEY_PATH=~/.ssh/new_jason_key.pem
USER=ubuntu
REDIS_CONF_PATH=/var/lib/redis/nodes-6379.conf
REDIS_SERVICE_NAME=redis

# 퍼블릭 IP 목록
PUBLIC_IPS=(
  98.85.221.48
  13.217.141.168
  34.229.109.84
  3.216.30.223
  3.237.188.67
  3.234.224.46
  3.91.177.75
  3.82.175.137
  52.55.56.178
)

for ip in "${PUBLIC_IPS[@]}"; do
  echo "🔧 Connecting to $ip ..."
  ssh -o StrictHostKeyChecking=no -i "$KEY_PATH" $USER@$ip <<EOF
    echo "📂 Deleting $REDIS_CONF_PATH..."
    sudo rm -f "$REDIS_CONF_PATH"

    echo "🔄 Restarting Redis ($REDIS_SERVICE_NAME)..."
    sudo systemctl restart "$REDIS_SERVICE_N"

    echo "✅ Done on \\$(hostname)"
EOF
  echo ""
done

저는 다음과 같이 짰습니다. 그러면 ssh로 접근해서 설정파일 삭제하고 재시작합니다.

이제 초기화는 했으니 수동으로 설정하겠습니다.

우선 primary 노드 3개로 클러스터를 생성합니다.

redis-cli --cluster create \\
10.1.0.19:6379 \\
10.1.10.206:6379 \\
10.1.20.122:6379 \\
--cluster-replicas 0

실행이 성공하면 다음과 같이 로그가 나옵니다.

redis-cli --cluster create \\
10.1.0.19:6379 \\
10.1.10.206:6379 \\
10.1.20.122:6379 \\
--cluster-replicas 0
>>> Performing hash slots allocation on 3 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
M: 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe 10.1.0.19:6379
   slots:[0-5460] (5461 slots) master
M: a26f9a3925cac72016f9d8eea82a64d2e3ad43fa 10.1.10.206:6379
   slots:[5461-10922] (5462 slots) master
M: 1a35242bdd69c150742fdc34e015d2f136d87928 10.1.20.122:6379
   slots:[10923-16383] (5461 slots) master
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 10.1.0.19:6379)
M: 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe 10.1.0.19:6379
   slots:[0-5460] (5461 slots) master
M: a26f9a3925cac72016f9d8eea82a64d2e3ad43fa 10.1.10.206:6379
   slots:[5461-10922] (5462 slots) master
M: 1a35242bdd69c150742fdc34e015d2f136d87928 10.1.20.122:6379
   slots:[10923-16383] (5461 slots) master
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

여기서 primary노드의 ID를 기억해서 replica로 지정하게 됩니다. 다음 명령어들을 실행하여 replica노드들을 구축합니다.

# b2 (10.1.10.33) → a1의 replica
redis-cli -h 10.1.10.33 -p 6379 cluster replicate 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe

# c3 (10.1.20.4) → a1의 replica
redis-cli -h 10.1.20.4 -p 6379 cluster replicate 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe

# a2 (10.1.0.138) → b1의 replica
redis-cli -h 10.1.0.138 -p 6379 cluster replicate a26f9a3925cac72016f9d8eea82a64d2e3ad43fa

# c2 (10.1.20.234) → b1의 replica
redis-cli -h 10.1.20.234 -p 6379 cluster replicate a26f9a3925cac72016f9d8eea82a64d2e3ad43fa

# a3 (10.1.0.133) → c1의 replica
redis-cli -h 10.1.0.133 -p 6379 cluster replicate 1a35242bdd69c150742fdc34e015d2f136d87928

# b3 (10.1.10.118) → c1의 replica
redis-cli -h 10.1.10.118 -p 6379 cluster replicate 1a35242bdd69c150742fdc34e015d2f136d87928

이렇게 하면 다음 에러가 뜹니다. 그 이유는 replica 노드들은 클러스터에 아직 참여하지 않았기 때문에 찾을 수 없는 것입니다.

(error) ERR Unknown node 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe
(error) ERR Unknown node 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe
(error) ERR Unknown node a26f9a3925cac72016f9d8eea82a64d2e3ad43fa
(error) ERR Unknown node a26f9a3925cac72016f9d8eea82a64d2e3ad43fa
(error) ERR Unknown node 1a35242bdd69c150742fdc34e015d2f136d87928
(error) ERR Unknown node 1a35242bdd69c150742fdc34e015d2f136d87928

그래서 MEET을 해주어 replica 노드들을 클러스터에 참여 시킵니다.

# a2
redis-cli -h 10.1.0.138 -p 6379 cluster meet 10.1.0.19 6379

# a3
redis-cli -h 10.1.0.133 -p 6379 cluster meet 10.1.0.19 6379

# b2
redis-cli -h 10.1.10.33 -p 6379 cluster meet 10.1.0.19 6379

# b3
redis-cli -h 10.1.10.118 -p 6379 cluster meet 10.1.0.19 6379

# c2
redis-cli -h 10.1.20.234 -p 6379 cluster meet 10.1.0.19 6379

# c3
redis-cli -h 10.1.20.4 -p 6379 cluster meet 10.1.0.19 6379

그리고 약간의 시간이 지나고 클러스터 정보를 확인했을 때 참여한 것을 확인할 수 있습니다.

root@ip-10-1-0-19:/var/lib/redis# redis-cli -c cluster nodes
209e35b8f42ec8fa3991c1c29b1a93857e5db3fe 10.1.0.19:6379@16379 myself,master - 0 1753675661000 1 connected 0-5460
7d3c7f28cfc788fb2b62e37bdf07517e934985c0 10.1.20.234:6379@16379 master - 0 1753675660000 4 connected
427b8e2c092693c42c82870ed166024f328dd8a6 10.1.0.138:6379@16379 master - 0 1753675661000 7 connected
ee7192faeaa502b1dfef1c5c8970655e0b1cf6b3 10.1.10.118:6379@16379 master - 0 1753675663000 0 connected
e8a2c11f6a65853e60a5023db6df8c7d23b66547 10.1.20.4:6379@16379 master - 0 1753675665700 6 connected
a26f9a3925cac72016f9d8eea82a64d2e3ad43fa 10.1.10.206:6379@16379 master - 0 1753675665000 2 connected 5461-10922
971e43f334de3bf54e68a74f954a312071a182c1 10.1.0.133:6379@16379 master - 0 1753675663693 8 connected
201a11c662101dd23067b602b13306721f7db933 10.1.10.33:6379@16379 master - 0 1753675661684 5 connected
1a35242bdd69c150742fdc34e015d2f136d87928 10.1.20.122:6379@16379 master - 0 1753675664697 3 connected 10923-16383

그리고 다시 레플리카를 마스터에 등록하는 명령어를 입력하면 성공이 나옵니다.

# b2 (10.1.10.33) → a1의 replica
redis-cli -h 10.1.10.33 -p 6379 cluster replicate 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe

# c3 (10.1.20.4) → a1의 replica
redis-cli -h 10.1.20.4 -p 6379 cluster replicate 209e35b8f42ec8fa3991c1c29b1a93857e5db3fe

# a2 (10.1.0.138) → b1의 replica
redis-cli -h 10.1.0.138 -p 6379 cluster replicate a26f9a3925cac72016f9d8eea82a64d2e3ad43fa

# c2 (10.1.20.234) → b1의 replica
redis-cli -h 10.1.20.234 -p 6379 cluster replicate a26f9a3925cac72016f9d8eea82a64d2e3ad43fa

# a3 (10.1.0.133) → c1의 replica
redis-cli -h 10.1.0.133 -p 6379 cluster replicate 1a35242bdd69c150742fdc34e015d2f136d87928

# b3 (10.1.10.118) → c1의 replica
redis-cli -h 10.1.10.118 -p 6379 cluster replicate 1a35242bdd69c150742fdc34e015d2f136d87928

그리고 약간 시간이 지난후에 클러스터 정보를 출력하는 명령어를 입력하면

📦 Redis Cluster Topology
--------------------------
🔴 Master: 10.1.10.206:6379 (a26f9a3925cac72016f9d8eea82a64d2e3ad43fa)
    └── Slots: 5461-10922
    └── 🟢 Replica: 10.1.20.234:6379 (7d3c7f28cfc788fb2b62e37bdf07517e934985c0)
    └── 🟢 Replica: 10.1.0.138:6379 (427b8e2c092693c42c82870ed166024f328dd8a6)

🔴 Master: 10.1.0.19:6379 (209e35b8f42ec8fa3991c1c29b1a93857e5db3fe)
    └── Slots: 0-5460
    └── 🟢 Replica: 10.1.20.4:6379 (e8a2c11f6a65853e60a5023db6df8c7d23b66547)
    └── 🟢 Replica: 10.1.10.33:6379 (201a11c662101dd23067b602b13306721f7db933)

🔴 Master: 10.1.20.122:6379 (1a35242bdd69c150742fdc34e015d2f136d87928)
    └── Slots: 10923-16383
    └── 🟢 Replica: 10.1.10.118:6379 (ee7192faeaa502b1dfef1c5c8970655e0b1cf6b3)
    └── 🟢 Replica: 10.1.0.133:6379 (971e43f334de3bf54e68a74f954a312071a182c1)

이렇게 가용영역이 분산되어 클러스터가 구성된 것을 확인할 수 있습니다.

이렇게 레디스 클러스터 구성을 해보았습니다.

회고

처음에 레디스 클러스터를 구성했을 때 설정파일을 일일히 수정해주는 방식으로 했었는데, 9개의 클러스터의 설정 파일을 일일히 설정해주는 것은 매우 번거로운 작업이였고 이를 AMI를 통해서 하려 했던 아이디어는 괜찮았던 것 같습니다.

하지만 /var/lib/redis/nodes-6379.conf 파일에 노드의 ID 정보 같은 것이 그대로 다른 인스턴스에 들어가 클러스터가 구축이 안되는 이유를 파악하기 까지 좀 오랜시간이 걸렸습니다.

또한, 레디스의 레자도 몰랐었는데 이론 공부하면서 어떻게 클러스터들이 통신하고 내부 메세지는 어떤 것들을 통해 클러스터가 유지되는지 알 수 있어 보람찼던 공부였습니다.

'클라우드' 카테고리의 다른 글

Github Actions Self-hosted-runner 사용 방법 (5)	2025.07.12
EC2로 SSH 접속이 되는 원리 (0)	2025.06.30
CloudFront + S3 + ACM + Route53으로 프론트(Vite + React) 정적 파일 배포 하기 (1)	2025.06.14
Infisical CLI 설치하는 파이프라인 최적화 (1)	2025.06.07
신한 DS ICT 인프라 실기시험 실습 (2)	2025.06.07

ABOUT ME

성준이의 개발블로그 성준이의 개발블로그

Redis 클러스터링이란?

정의

사용하는 이유

제공하는 기능

샤딩과 Replica의 원리

Redis 클러스터 구축 실습

회고

'클라우드' 카테고리의 다른 글

티스토리툴바

ABOUT ME

Redis 클러스터링이란?

정의

사용하는 이유

제공하는 기능

샤딩과 Replica의 원리

Redis 클러스터 구축 실습

회고

'클라우드' 카테고리의 다른 글

관련글 관련글 더보기

티스토리툴바