이 단계가 중요한 이유는 RedisShake가 왜 Redis Cluster에서 Master Shard별로 데이터를 읽어야 하는지가 여기서 결정되기 때문입니다.
🟥 1.2단계 - Redis Cluster 구조 이해하기
먼저 핵심 관계부터 보겠습니다.
Redis Cluster
│
├─ Shard 1
│ ├─ Master 1
│ └─ Replica 1
│
├─ Shard 2
│ ├─ Master 2
│ └─ Replica 2
│
└─ Shard 3
├─ Master 3
└─ Replica 3
전체 데이터
↓
16,384개의 Hash Slot으로 분리
↓
각 Master Shard에 Slot 분배
Redis Node끼리
↕
Cluster Bus로 상태/장애/구성 정보 교환즉, Shard → Master/Replica → Slot → Cluster Bus 순으로 이해하면 쉽습니다.
1.2.1 Master는 무엇인가?
Redis Cluster의 Master는 실제 데이터를 담당하는 Redis 노드입니다.
예를 들어 Master가 3개라면:
Redis Cluster
┌──────────┬──────────┬──────────┐
│ │ │
▼ ▼ ▼
Master 1 Master 2 Master 3하지만 세 Master가 똑같은 데이터를 가지고 있는 것이 아닙니다.
Master 1
├─ user:100
├─ user:101
└─ session:555
Master 2
├─ product:100
├─ product:200
└─ cart:300
Master 3
├─ order:500
├─ order:501
└─ payment:800즉,
Redis Cluster의 Master들은 데이터를 나누어 가지고 있습니다.
이것이 일반 Master/Replica 구조와 가장 큰 차이입니다.
1.2.2 Replica는 무엇인가?
Replica는 특정 Master의 데이터를 복제해서 가지고 있는 백업 노드입니다.
예를 들어:
Shard 1
┌────────────┐
│ Master 1 │
│ │
│ Key A │
│ Key B │
└─────┬──────┘
│
│ Replication
▼
┌────────────┐
│ Replica 1 │
│ │
│ Key A │
│ Key B │
└────────────┘Master와 Replica는 같은 데이터를 가지고 있습니다.
따라서:
Master 1 데이터
=
Replica 1 데이터가 기본 개념입니다.
1.2.3 Shard란 무엇인가?
여기서 Shard라는 개념이 중요합니다.
쉽게 말하면:
전체 Redis 데이터를 나누어 담당하는 하나의 데이터 묶음
입니다.
예를 들어:
Redis 전체 데이터
██████████████████████████████
↓
3등분한다고 생각
↓
┌──────────┬──────────┬──────────┐
│ Shard 1 │ Shard 2 │ Shard 3 │
│ │ │ │
│ Master1 │ Master2 │ Master3 │
└──────────┴──────────┴──────────┘다만 Redis는 실제 데이터를 정확히 3등분해서 관리하는 것이 아니라 Hash Slot이라는 단위로 나눕니다.
1.2.4 Shard와 Master는 같은 말인가?
엄밀하게는 다릅니다.
예를 들어:
Shard 1
├─ Master 1
└─ Replica 1입니다.
즉 Shard가 좀 더 큰 개념입니다.
Shard
│
├─ 데이터를 실제 처리하는 Master
│
└─ Master 데이터를 복제하는 Replica따라서 3 Master + 3 Replica 구성이라면:
Redis Cluster
Shard 1
├─ Master 1
└─ Replica 1
Shard 2
├─ Master 2
└─ Replica 2
Shard 3
├─ Master 3
└─ Replica 3라고 보는 것이 가장 정확합니다.
1.2.5 Redis Cluster에서 왜 Shard가 필요한가?
데이터가 너무 많아 Redis 한 대에 넣기 어렵다고 생각해보겠습니다.
예를 들어 Redis 데이터가 1TB라면:
Redis 1대
1TB 전부 저장해야 합니다.
메모리가 부족해질 수 있습니다.
Cluster로 나누면:
1TB
↓
┌────────┼────────┐
Shard1 Shard2 Shard3
약333GB 약333GB 약333GB처럼 여러 Redis에 분산할 수 있습니다.
그래서 Redis Cluster의 대표적인 목적 중 하나가 Scale-Out입니다.
서버 하나를 엄청 크게 만드는 Scale-Up 대신:
Redis 1대
↓
Redis 여러 대로 확장하는 것입니다.
1.2.6 그러면 어떤 Key를 어느 Master에 저장하지?
여기서 Hash Slot이 등장합니다.
Redis Cluster에는 총:
16,384개의 Hash Slot
이 존재합니다.
번호는:
0
1
2
3
...
16382
16383입니다.
즉:
Slot 0 ~ Slot 16383
총 16,384개입니다.
1.2.7 Slot을 Master에 나눠준다
Master가 3개 있다고 해보겠습니다.
보통 개념적으로:
Master 1
Slot 0 ~ 5460
Master 2
Slot 5461 ~ 10922
Master 3
Slot 10923 ~ 16383처럼 나눌 수 있습니다.
그림으로 보면:
전체 Hash Slot
0 16383
│ │
▼ ▼
██████████████████████████████████████████
↓ 3개 Master에 분배
┌─────────────┬─────────────┬─────────────┐
M1 M2 M3
0 ~ 5460 5461 ~ 10922 10923 ~ 16383Redis Cluster가 정상 서비스하려면 전체 16,384 Slot을 Master들이 담당해야 합니다.
1.2.8 Key는 Slot을 어떻게 결정할까?
예를 들어 애플리케이션에서:
SET user:100 kim을 실행했다고 하겠습니다.
Redis Cluster는 user:100이라는 Key를 계산합니다.
개념적으로:
user:100
↓
CRC16 Hash 계산
↓
나머지 연산
↓
Hash Slot
예: Slot 2500Redis Cluster의 계산은 개념적으로:
CRC16(Key) MOD 16384입니다.
그리고 Slot 2500을 담당하는 Master가:
Master 1
Slot 0 ~ 5460라면:
user:100
↓
Slot 2500
↓
Master 1에 저장됩니다.
1.2.9 다른 Key를 넣으면?
예:
SET product:500 notebook계산 결과:
product:500
↓
CRC16
↓
Slot 7200이라고 해보겠습니다.
Slot 7200은:
Master 2
Slot 5461 ~ 10922이므로:
product:500
↓
Slot 7200
↓
Master 2에 들어갑니다.
또:
order:999
↓
Slot 15000
↓
Master 3가 될 수 있습니다.
1.2.10 그래서 실제 데이터 분산은 이렇게 된다
Redis Cluster
│
16,384 Slots
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
Master 1 Master 2 Master 3
Slot 0~5460 5461~10922 10923~16383
user:100 product:500 order:999
login:10 cart:100 payment:30
session:20 product:501 order:1000이게 Redis Cluster에서 데이터가 분산되는 핵심 원리입니다.
1.2.11 Replica는 Slot을 따로 담당하나?
아닙니다.
이 부분도 중요합니다.
Master 1
Slot 0 ~ 5460
│
│ Replication
▼
Replica 1
Master 1 데이터 복제Replica가 독립적으로:
Slot 5461 ~ 7000같은 것을 추가로 담당하는 개념이 아닙니다.
Replica는 자기가 따라가는 Master의 데이터를 그대로 복제합니다.
따라서:
Shard 1
Master 1
Slot 0~5460
│
│ Replication
▼
Replica 1
Slot 0~5460의 데이터 복제본으로 이해하면 됩니다.
1.2.12 Master가 장애 나면 어떻게 될까?
예를 들어:
Shard 1
Master 1
│
▼
Replica 1에서 Master 1이 장애가 났다고 해보겠습니다.
Master 1
X 장애
Replica 1Redis Cluster의 다른 노드들이 장애를 판단하고 Replica를 Master로 승격시킬 수 있습니다.
장애 전
Master 1
│
▼
Replica 1
↓ 장애
장애 후
Master 1 ❌
Replica 1
↓
New Master새 Master가 기존 Master의 Slot을 이어받습니다.
기존 Master 1
Slot 0 ~ 5460
↓
새로운 Master
Slot 0 ~ 5460그래서 서비스가 계속될 수 있습니다.
1.2.13 그런데 누가 Master 장애를 알아차릴까?
여기서 Cluster Bus가 등장합니다.
Redis Cluster의 Redis Node들은 서로 통신합니다.
Master 1
↕ ↖
↕ ↖
↕ ↖
Master 2 ↔──────────── Master 3
↕ ↕
Replica 2 Replica 3이 노드들 사이에서 Cluster 상태 정보를 주고받는 통신망을 이해하기 쉽게:
Cluster Bus
라고 생각하면 됩니다.
1.2.14 Cluster Bus가 하는 일
Cluster Bus에서는 대표적으로 이런 정보를 주고받습니다.
"나 정상이다"
"Master 1이 응답하지 않는다"
"현재 내가 담당하는 Slot은 이것이다"
"저 Node가 Master다"
"저 Node가 Replica다"
"Failover가 필요하다"
"새 Master가 선출되었다"즉 애플리케이션 데이터 자체를 주고받기 위한 통신이라기보다 Redis Cluster를 관리하기 위한 Node 간 통신입니다.
1.2.15 일반 Redis Port와 Cluster Bus Port
예를 들어 Redis Port가:
6379라면 일반적인 Redis OSS Cluster 구성에서 Cluster Bus 포트는 기본적으로:
6379 + 10000
= 16379가 됩니다.
즉:
6379
→ Client / Redis 명령 통신
16379
→ Redis Node 간 Cluster Bus 통신입니다.
예:
Application
│
│ TCP 6379
▼
Redis Master
Redis Master 1
│
│ TCP 16379
▼
Redis Master 2이라고 이해하면 쉽습니다.
1.2.16 K8s에서는 이게 왜 중요한가? ⭐
온프레미스 K8s이기 때문에 굉장히 중요합니다.
예를 들어:
Worker Node 1
└─ redis-0
Worker Node 2
└─ redis-1
Worker Node 3
└─ redis-2라고 해보겠습니다.
Redis Cluster 노드끼리:
redis-0 ↔ redis-1
redis-0 ↔ redis-2
redis-1 ↔ redis-2통신할 수 있어야 합니다.
따라서 NetworkPolicy나 방화벽이 존재한다면 최소한 Redis 구성에 따라:
6379
Cluster Bus Port통신을 확인해야 합니다.
다만 Cluster Bus port를 단순히 항상 6379+10000이라고 고정해서 설계하면 안 되고, 실제 cluster-port 설정을 확인하는 것이 안전합니다.
1.2.17 Redis Cluster 전체를 그림 하나로 합쳐보자
현재 가장 일반적인 3 Master + 3 Replica 구조라고 하겠습니다.
Redis Cluster
총 16,384 Hash Slots
┌─────────────────────────────────────────────┐
│ │
│ Shard 1 │
│ │
│ ┌───────────────────────┐ │
│ │ Master 1 │ │
│ │ Slot 0 ~ 5460 │ │
│ └───────────┬───────────┘ │
│ │ Replication │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Replica 1 │ │
│ └───────────────────────┘ │
│ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ Shard 2 │
│ │
│ ┌───────────────────────┐ │
│ │ Master 2 │ │
│ │ Slot 5461 ~ 10922 │ │
│ └───────────┬───────────┘ │
│ │ Replication │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Replica 2 │ │
│ └───────────────────────┘ │
│ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ Shard 3 │
│ │
│ ┌───────────────────────┐ │
│ │ Master 3 │ │
│ │ Slot 10923 ~ 16383 │ │
│ └───────────┬───────────┘ │
│ │ Replication │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Replica 3 │ │
│ └───────────────────────┘ │
│ │
└─────────────────────────────────────────────┘그리고 모든 Redis Node는 Cluster Bus를 통해 서로 상태를 교환합니다.
Cluster Bus
Master 1 ←────────────────→ Master 2
↑ ↑
│ │
│ │
↓ ↓
Replica 1 Replica 2
↖ ↗
↖ ↗
Master 3
↕
Replica 31.2.18 여기서 RedisShake를 붙이면?
드디어 RedisShake와 연결됩니다.
Source가 Redis Cluster라면 데이터 전체가 Master 1에 존재하지 않습니다.
Master 1
약 1/3
Master 2
약 1/3
Master 3
약 1/3따라서 이렇게 하면 안 됩니다.
RedisShake
│
▼
Master 1
→ 전체 데이터가 아님RedisShake는 Cluster topology를 파악하고 각 Source Shard의 Master에서 데이터를 읽어야 합니다.
개념적으로:
Source Redis Cluster
16,384 Hash Slots
┌─────────┬─────────┬─────────┐
│ │ │
▼ ▼ ▼
Master 1 Master 2 Master 3
Shard 1 Shard 2 Shard 3
│ │ │
│ │ │
└────┐ │ ┌────┘
│ │ │
▼ ▼ ▼
┌──────────────┐
│ RedisShake │
│ │
│ Reader 1 │
│ Reader 2 │
│ Reader 3 │
└──────┬───────┘
│
▼
Target Redis바로 이 이유 때문에 앞 단계에서:
[sync_reader]
cluster = true가 중요했던 것입니다.
1.2.19 K8s까지 포함한 환경 그림
사용자 환경 형태로 그리면:
On-Premises Kubernetes
┌─────────────────────────────────────────────────────────┐
│ │
│ Source Redis Cluster │
│ │
│ Worker Node A Worker Node B Worker Node C │
│ │
│ redis-0 redis-1 redis-2 │
│ Master Master Master │
│ Slot 0~5460 Slot 5461~10922 Slot 10923~16383 │
│ │ │ │ │
│ │ │ │ │
│ redis-3 redis-4 redis-5 │
│ Replica Replica Replica │
│ │
│ Redis Node ↔ Cluster Bus ↔ Redis Node │
│ │
│ │ │
│ │ PSync │
│ ▼ │
│ ┌───────────────┐ │
│ │ RedisShake │ │
│ │ Pod │ │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ Target Redis Cluster │
│ │
└─────────────────────────────────────────────────────────┘
1.2.20 Service와 Cluster Bus는 다른 개념이다
이 부분은 K8s에서 특히 헷갈립니다.
Kubernetes의:
Service와 Redis의:
Cluster Bus는 전혀 다른 것입니다.
Kubernetes Service
Application
│
▼
K8s Service
│
▼
Redis PodPod에 안정적인 접속 Endpoint를 제공합니다.
Redis Cluster Bus
Redis Pod
↕
Redis Pod
↕
Redis PodRedis Cluster Node끼리 Cluster 상태를 주고받는 프로토콜입니다.
따라서:
| K8s Service | Client → Redis 접근 |
| Headless Service | Redis Pod별 DNS/Discovery |
| Redis Port | Redis 명령 처리 |
| Cluster Bus | Redis Node 간 Cluster 관리 통신 |
서로 섞어 이해하면 안 됩니다.
1.2.21 Cluster Bus가 데이터 복제도 하나?
여기도 많이 헷갈리는 부분입니다.
아닙니다.
Master → Replica의 실제 Redis 데이터 복제와:
Node ↔ Node
Cluster Bus는 목적이 다릅니다.
쉽게 구분하면:
Redis Replication
Master
│
│ 실제 데이터
▼
Replica반면:
Cluster Bus
Master 1
↕
Master 2
"나 살아 있음"
"저 노드 장애"
"Slot 담당 변경"
"Failover 진행"입니다.
1.2.22 초보자가 가장 헷갈리는 4가지만 비교
| Master | 실제 데이터를 담당하는 Redis | Master1 |
| Replica | Master 데이터 복제본 | Replica1 |
| Shard | 하나의 데이터 분할 영역 | Master1 + Replica1 |
| Slot | 어떤 Shard에 Key를 보낼지 결정하는 번호 | 0~16383 |
| Cluster Bus | Redis Node끼리 상태를 공유하는 내부 통신 | 장애감지/Failover |
1.2.23 가장 쉬운 비유 🏢
Redis Cluster를 대형 물류센터라고 생각해보겠습니다.
전체 물건 번호가:
0 ~ 16383개 있다고 해보겠습니다.
Shard
물류창고 구역입니다.
A창고
B창고
C창고Slot
각 창고가 담당하는 물품 번호입니다.
A창고
0 ~ 5460
B창고
5461 ~ 10922
C창고
10923 ~ 16383Master
각 창고의 실제 담당자입니다.
A창고 관리자
Master 1Replica
관리자에게 문제가 생겼을 때 대신할 부관리자입니다.
Master 1
│
▼
Replica 1Cluster Bus
관리자들끼리 사용하는 내부 무전망입니다.
Master 1:
"A창고 정상!"
Master 2:
"B창고 정상!"
Master 3:
"Master 1 응답 없어!"
→ 장애 판단
→ Replica 1을 Master로 승격RedisShake는 이 물류센터의 물건을 새 물류센터로 이전하는 업체와 비슷합니다.
A창고 ─┐
B창고 ─┼─→ RedisShake → 새 Redis Cluster
C창고 ─┘한 창고만 복사해서는 전체 데이터가 아니기 때문에 모든 Shard의 Master 데이터를 가져와야 하는 것입니다.
🎯 1.2단계 핵심 정리
이 관계만 확실하게 기억하시면 됩니다.
Redis Cluster
16,384 Slots
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
Shard 1 Shard 2 Shard 3
│ │ │
Master1 Master2 Master3
│ │ │
Replica1 Replica2 Replica3
↕ ↕ ↕
Cluster Bus① Slot
0~16383, 총 16,384개이며 Key가 어느 Master에 저장될지를 결정합니다.
② Shard
Redis 데이터를 나눈 논리적인 영역입니다.
③ Master
해당 Shard의 Slot과 실제 데이터를 담당합니다.
④ Replica
해당 Master의 데이터를 복제하고 장애 발생 시 Master로 승격될 수 있습니다.
⑤ Cluster Bus
Redis Node들이 서로 생존 상태, Slot 정보, Failover 정보를 주고받는 내부 통신입니다.
그리고 RedisShake 관점에서 제일 중요한 결론은:
Redis Cluster에서는 데이터가 여러 Master Shard에 나눠져 있기 때문에 RedisShake가 전체 Cluster topology를 파악하고 각 Shard의 데이터를 가져와야 한다.
이제 1.3단계에서는 K8s 환경을 기준으로 redis-0 ~ redis-5 + StatefulSet + PVC + Headless Service + 일반 Service가 어떻게 연결되는지를 보는 것이 가장 자연스럽습니다. 여기까지 이해하면 그다음부터 RedisShake 설정 YAML과 shake.toml을 실제 구조에 맞춰 들어갈 수 있습니다.
'J-H-T > Redis' 카테고리의 다른 글
| [REDIS-4단계] sync_reader / scan_reader / rdb_reader 차이! (0) | 2026.08.16 |
|---|---|
| [REDIS-3단계] Full Sync와 Incremental Sync 원리! (0) | 2026.08.15 |
| [REDIS-2단계] Source / Target / RedisShake 구성 이해! (0) | 2026.08.15 |
| [REDIS-1.4단계] K8s Redis Cluster 네트워크 흐름 이해하기! (0) | 2026.08.15 |
| [REDIS-1.3단계] K8s Redis Cluster 구성 이해하기! (0) | 2026.08.15 |
| [REDIS-1.1단계] Redis 구조별 RedisShake 차이 이해하기! (0) | 2026.08.14 |
| [REDIS - 1단계] RedisShake가 무엇이고 K8s에서 어디에 위치하는가 ! (0) | 2026.08.14 |
| [참고] Kubernetes에서 Redis Cluster 구성 이해하기 🚀 (0) | 2026.08.13 |
댓글