7.1단계는 RedisShake 운영 설계에서 정말 중요한 네트워크 단계입니다.
핵심은 하나입니다.
RedisShake가 “대표 Service”에만 붙을 수 있으면 되는 게 아니라, Source/Target Redis Cluster가 알려주는 각 Master 노드 주소까지 실제로 도달할 수 있어야 합니다.
Redis Cluster 클라이언트는 CLUSTER SLOTS/CLUSTER SHARDS 등으로 각 Slot과 실제 노드 주소를 학습하고 그 노드로 직접 통신합니다. RedisShake도 Cluster Reader/Writer로 동작하므로 이 원리가 그대로 중요합니다. Redis
🟥 7.1단계 - K8s Redis Cluster → DR/신규 K8s Redis Cluster 네트워크 설계
7.1.1 먼저 가장 중요한 전체 그림
예를 들어 센터가 두 개 있다고 하겠습니다.
[운영센터 K8s]
Source Redis Cluster
redis-0 Master
redis-1 Master
redis-2 Master
redis-3 Replica
redis-4 Replica
redis-5 Replica
│
│ 센터간 Network
▼
[DR센터 K8s]
RedisShake Pod
│
▼
Target Redis Cluster
redis-0 ~ redis-5조금 더 네트워크 관점으로 보면:
운영센터
┌─────────────────────────────────────────┐
│ Source Redis Cluster │
│ │
│ M1 : 6379 │
│ M2 : 6379 │
│ M3 : 6379 │
│ │
│ Redis Node ↔ Redis Node │
│ Cluster Bus │
└───────────────┬─────────────────────────┘
│
│ 방화벽 / 라우팅
│
▼
┌─────────────────────────────────────────┐
│ DR센터 │
│ │
│ RedisShake Pod │
│ │ │
│ ├────→ Source M1:6379 │
│ ├────→ Source M2:6379 │
│ ├────→ Source M3:6379 │
│ │ │
│ ├────→ Target M1:6379 │
│ ├────→ Target M2:6379 │
│ └────→ Target M3:6379 │
│ │
└─────────────────────────────────────────┘RedisShake sync_reader는 Source Master에 Replica처럼 연결해 Full RDB와 Incremental stream을 받습니다. Tair Open Source
7.1.2 Headless Service는 왜 필요한가?
Kubernetes StatefulSet은 각 Pod에 안정적인 네트워크 ID를 제공하기 위해 Headless Service를 사용합니다.
Kubernetes 공식 문서도 StatefulSet의 Pod 네트워크 정체성을 위해 Headless Service가 필요하다고 설명합니다. Kubernetes
예를 들어:
StatefulSet
redisHeadless Service:
redis-headlessNamespace:
redis-source이면 개별 Pod를:
redis-0.redis-headless.redis-source.svc.cluster.local
redis-1.redis-headless.redis-source.svc.cluster.local
redis-2.redis-headless.redis-source.svc.cluster.local처럼 접근할 수 있습니다.
Headless Service는 일반 ClusterIP 하나를 주는 대신, selector에 매칭되는 Pod들의 IP를 DNS로 직접 반환합니다. Kubernetes
7.1.3 같은 K8s Cluster라면 Headless Service가 매우 편하다
예를 들어 RedisShake도 같은 K8s Cluster 안에 있다면:
RedisShake
│
├──→ redis-0.redis-headless...:6379
├──→ redis-1.redis-headless...:6379
└──→ redis-2.redis-headless...:6379이 가능합니다.
Pod IP가 바뀌어도:
10.244.1.20
↓ Pod 재생성
10.244.7.31DNS 이름은 그대로 유지됩니다.
즉:
같은 K8s Cluster 내부 통신에서는 Headless Service + StatefulSet DNS가 매우 자연스럽습니다.
7.1.4 하지만 DR센터가 다른 K8s Cluster면 문제가 생긴다 ⚠️
이게 오늘의 핵심입니다.
운영센터 Source Redis가 RedisShake에게 다음 주소를 알려준다고 합시다.
redis-0.redis-headless.redis-source.svc.cluster.local그런데 RedisShake는 DR센터 K8s에 있습니다.
그러면 보통:
DR CoreDNS
│
X
│
운영 K8s 내부 DNS이 됩니다.
즉:
*.svc.cluster.local은 기본적으로 해당 Kubernetes Cluster 내부 DNS 영역입니다.
다른 Cluster에서는 그대로 해석되지 않습니다.
7.1.5 Pod IP도 마찬가지 문제
Source의 CLUSTER NODES가:
redis-0 = 10.244.1.21:6379
redis-1 = 10.244.2.34:6379
redis-2 = 10.244.3.15:6379를 반환했다고 합시다.
운영 K8s 내부에서는 문제없습니다.
하지만 DR센터 RedisShake가:
10.244.1.21에 라우팅할 수 없다면:
RedisShake
│
│ initial VIP 접속
▼
Source Redis ✅
CLUSTER topology 획득
│
▼
M2 = 10.244.2.34
RedisShake
│
X
10.244.2.34가 됩니다.
즉 첫 접속은 성공했는데 실제 Cluster Sync는 실패할 수 있습니다.
7.1.6 그래서 가장 중요한 질문
Redis Cluster Migration 설계에서 반드시 물어야 합니다.
Redis Cluster가 RedisShake에게 광고하는 주소
=
RedisShake가 실제 접근 가능한 주소인가?이게 YES여야 합니다.
Redis Cluster의 slot/topology 응답에는 실제 노드의 IP 또는 hostname이 포함될 수 있고, Client는 그 정보를 이용해 해당 노드로 이동합니다. Redis
7.1.7 cluster-announce-ip는 무엇인가?
Redis Cluster 노드는 다른 노드/Client에게:
“나는 이 주소로 접근해”
라는 정보를 광고합니다.
대표적으로:
cluster-announce-ip같은 설정을 사용할 수 있습니다.
예:
cluster-announce-ip 192.168.100.21
cluster-announce-port 6379
cluster-announce-bus-port 16379개념적으로:
Redis Pod 실제 내부 IP
10.244.1.21
하지만 외부 Client에게는
192.168.100.21
로 알려줌입니다.
7.1.8 cluster-announce-hostname은?
Redis는 topology 정보에서 hostname을 사용할 수도 있습니다. CLUSTER SLOTS는 cluster-announce-hostname이 설정된 경우 hostname을 노드 정보로 제공할 수 있습니다. Redis
예:
redis01.prod.company.local
redis02.prod.company.local
redis03.prod.company.local을 광고하도록 설계할 수 있습니다.
그러면 RedisShake는:
redis01.prod.company.local:6379
redis02.prod.company.local:6379
redis03.prod.company.local:6379에 접근하면 됩니다.
개념상 Cross-K8s에서는 이 방식이 더 관리하기 쉬운 경우가 많습니다.
7.1.9 IP 광고와 Hostname 광고 비교
| Pod IP 광고 | K8s 내부에서는 단순 | 다른 Cluster/센터에서 라우팅 어려움 |
| Node IP 광고 | 외부 라우팅 가능 | Node 변경/Pod 매핑 복잡 |
| External/LB IP 광고 | 외부에서 명확 | 노드별 Endpoint 설계 필요 |
| Hostname 광고 | DNS로 유연하게 관리 | DNS/라우팅 설계 필요 |
Cross-K8s/DR 환경에서는:
Pod 내부 주소가 아닌, 양 센터에서 해석·라우팅 가능한 주소를 광고하는 설계
가 중요합니다.
7.1.10 일반 L4 VIP 하나면 해결되지 않나?
여기서 정말 많이 헷갈립니다.
예를 들어 Source 앞에:
redis-source.company.local
↓
VIP
192.168.10.100가 있다고 합시다.
RedisShake 초기 접속은:
RedisShake
│
▼
VIP
│
▼
Redis Master로 성공합니다.
하지만 Cluster topology가:
M1 = 10.244.1.21
M2 = 10.244.2.22
M3 = 10.244.3.23를 반환하면 결국 RedisShake는 이 주소로 가야 합니다.
따라서:
VIP 하나
= 초기 접속 해결일 뿐,
Cluster Node별 접근까지 자동으로 해결되는 것은 아닙니다.
7.1.11 Redis Cluster는 일반 웹 Load Balancing과 다르다
일반 웹 서버:
Client
│
▼
VIP
│
├─ Web1
├─ Web2
└─ Web3Client는 Backend가 누군지 몰라도 됩니다.
하지만 Redis Cluster는:
Client
│
▼
Redis Node 1
"이 Key는 Node 2 담당"
│
▼
Client → Node 2처럼 Client가 개별 Node를 알아야 하는 구조입니다.
그래서 Redis Cluster를 단순히:
VIP 하나 뒤에 Master 3개로 감싸는 것만으로 모든 문제가 해결되지는 않습니다.
7.1.12 그렇다면 L4/VIP는 어떻게 써야 하나?
Cross-K8s 환경에서는 여러 설계가 가능합니다.
예를 들어 Source Master 3개를 각각 외부에서 접근 가능하게:
Source M1
redis-m1.prod.company.local
192.168.100.21:6379
Source M2
redis-m2.prod.company.local
192.168.100.22:6379
Source M3
redis-m3.prod.company.local
192.168.100.23:6379처럼 만들 수 있습니다.
구조:
운영 K8s
redis-0 Pod
│
▼
Service / L4
│
▼
192.168.100.21
redis-1 Pod
│
▼
Service / L4
│
▼
192.168.100.22
redis-2 Pod
│
▼
Service / L4
│
▼
192.168.100.23Redis Cluster가 이 외부 접근 가능한 주소를 광고하게 하는 방식입니다.
7.1.13 Node별 VIP가 꼭 필요한가?
꼭 VIP만이 답은 아닙니다.
온프레미스에서는 다음 방법들이 가능합니다.
① Pod CIDR을 센터 간 Routing
② NodePort + Node IP
③ LoadBalancer 서비스
④ MetalLB
⑤ F5/L4 VIP
⑥ External IP
⑦ 별도 TCP Proxy다만 어떤 방식을 쓰더라도 핵심 조건은 같습니다.
RedisShake에서 Cluster가 알려주는 각 Master 주소:6379로 접속 가능해야 함
입니다.
7.1.14 가장 단순한 방법: Pod CIDR 간 라우팅
네트워크팀이 두 K8s Cluster의 Pod Network를 서로 라우팅 가능하게 만들 수 있다면:
운영 Pod CIDR
10.244.0.0/16
DR Pod CIDR
10.245.0.0/16사이에 Routing을 구성할 수 있습니다.
그러면:
DR RedisShake
│
▼
10.244.1.21:6379같은 직접 통신이 가능합니다.
구조상 가장 단순할 수 있지만:
CNI 설계
센터간 Routing
보안정책
Pod CIDR 중복 여부를 반드시 확인해야 합니다.
특히 두 Cluster가 똑같이:
10.244.0.0/16을 사용하고 있으면 직접 라우팅이 매우 어렵습니다.
7.1.15 NodePort 방식
각 Redis Pod/Node를 NodePort로 노출하는 방법도 생각할 수 있습니다.
예:
Worker-1:30001 → redis-0:6379
Worker-2:30002 → redis-1:6379
Worker-3:30003 → redis-2:6379그리고 Redis가:
worker1.company.local:30001
worker2.company.local:30002
worker3.company.local:30003를 광고하도록 설계합니다.
장점:
별도 LoadBalancer 없어도 됨단점:
Node 장애
Pod 재배치
NodePort 매핑
운영 복잡도가 커집니다.
7.1.16 LoadBalancer / MetalLB / F5 방식
온프레미스라면 이런 구조도 가능합니다.
Redis Pod
│
▼
K8s Service
type: LoadBalancer
│
▼
MetalLB / F5
│
▼
외부 VIP예:
redis-0 → 192.168.100.21
redis-1 → 192.168.100.22
redis-2 → 192.168.100.23RedisShake는 DR센터에서 이 주소로 접속합니다.
이 경우 Network/ADC 담당자가:
VIP
Backend
Health Check
방화벽
Routing을 같이 설계해야 합니다.
7.1.17 F5 하나에 VIP 여러 개 써도 되나?
네.
예를 들어:
F5
VIP 192.168.100.21 → redis-0
VIP 192.168.100.22 → redis-1
VIP 192.168.100.23 → redis-2같은 방식이 가능합니다.
또는 포트별로:
192.168.100.20:7001 → redis-0:6379
192.168.100.20:7002 → redis-1:6379
192.168.100.20:7003 → redis-2:6379처럼 설계할 수도 있습니다.
다만 Redis가 광고하는 주소/포트와 실제 외부 매핑이 정확히 일치해야 합니다.
7.1.18 Cluster Bus 16379도 DR RedisShake에 열어야 하나?
RedisShake에는 일반적으로 필요하지 않습니다.
구분하면:
RedisShake → Redis
TCP 6379는 필요합니다.
반면:
Redis Node ↔ Redis Node
Cluster Bus는 Redis Cluster 내부 통신입니다.
Redis Cluster spec에서도 Node들은 cluster bus를 통해 gossip, failover, configuration 정보를 교환합니다. Redis
따라서:
RedisShake → 16379를 열어야 하는 구조는 아닙니다.
하지만 Source Redis Node들끼리, 그리고 Target Redis Node들끼리는 Cluster Bus 통신이 반드시 가능해야 합니다.
7.1.19 기본 Cluster Bus Port
기본적인 Redis Cluster에서는:
Redis Client Port
6379
Cluster Bus
16379처럼 client port + 10000을 사용하는 경우가 많습니다.
다만 최근 Redis에서는 cluster bus 포트를 별도로 설정할 수 있으므로:
무조건 16379라고 단정하지 말고 실제 cluster-port 설정을 확인
해야 합니다.
Redis 공식 Cluster spec은 Cluster Bus가 노드 간 gossip과 failover 등에 사용된다는 점을 설명합니다. Redis
7.1.20 방화벽 정책은 이렇게 생각하면 쉽다
운영센터 → DR센터 RedisShake 기준
RedisShake가 DR센터에 있다면:
DR RedisShake
│
│ TCP 6379
▼
운영 Source M1
DR RedisShake
│
│ TCP 6379
▼
운영 Source M2
DR RedisShake
│
│ TCP 6379
▼
운영 Source M3가 허용되어야 합니다.
그리고 Target은 같은 DR K8s라면 내부 통신으로 처리할 수도 있고, NetworkPolicy가 있다면:
RedisShake Namespace
↓ TCP 6379
Target Redis Namespace허용이 필요합니다.
7.1.21 방화벽 표로 정리
예:
| RedisShake | Source M1 | TCP 6379 | PSync/Data |
| RedisShake | Source M2 | TCP 6379 | PSync/Data |
| RedisShake | Source M3 | TCP 6379 | PSync/Data |
| RedisShake | Target M1 | TCP 6379 | Write |
| RedisShake | Target M2 | TCP 6379 | Write |
| RedisShake | Target M3 | TCP 6379 | Write |
| Source Redis Nodes | Source Redis Nodes | Cluster Bus | Cluster gossip/Failover |
| Target Redis Nodes | Target Redis Nodes | Cluster Bus | Cluster gossip/Failover |
RedisShake 자체는 Cluster Bus 참가자가 아니므로 핵심은 Redis client port 접근입니다.
RedisShake sync_reader는 Master에 Replica처럼 연결하고, Writer는 Target Redis로 Redis 명령을 전달합니다. Tair Open Source
7.1.22 NetworkPolicy도 잊으면 안 된다
물리 방화벽이 열려 있어도 Kubernetes NetworkPolicy가:
Default Deny라면:
RedisShake
│
X
Target Redis가 될 수 있습니다.
따라서 두 레이어를 모두 확인합니다.
① IDC / Data Center Firewall
② Kubernetes NetworkPolicy입니다.
7.1.23 가장 권장되는 개념 구조
Cross-K8s/DR 환경에서는 이런 형태가 이해하기 쉽습니다.
운영센터 K8s
Source Redis Cluster
redis-0 redis-1 redis-2
Master Master Master
│ │ │
▼ ▼ ▼
External TCP Endpoint per Node
redis-m1.prod.company.local:6379
redis-m2.prod.company.local:6379
redis-m3.prod.company.local:6379
│ │ │
└────┬────┴────┬────┘
│
Firewall
│
▼
DR센터 K8s
┌───────────────┐
│ RedisShake │
│ Pod │
└───────┬───────┘
│
▼
Target Redis Cluster
M1 M2 M3이렇게 하면 Redis Cluster가 광고하는 hostname과 RedisShake가 실제 접근하는 주소를 일치시키기 쉽습니다.
7.1.24 Headless Service는 어디까지 쓰나?
정리하면:
같은 K8s Cluster 내부
Headless Service
⭐⭐⭐⭐⭐아주 좋습니다.
다른 K8s Cluster
*.svc.cluster.local은 일반적으로 상대 Cluster에서 바로 사용할 수 없습니다.
따라서:
Headless Service
+
External DNS / External Endpoint를 별도로 설계해야 합니다.
Kubernetes Headless Service는 Cluster 내부 Pod DNS를 제공하는 기능입니다. Kubernetes
7.1.25 Source와 Target 모두 Cross-K8s이면?
예를 들어 RedisShake를 별도 Migration K8s에 둔다면:
Source K8s
│
▼
RedisShake K8s
│
▼
Target K8sSource와 Target 양쪽 모두:
RedisShake → 각 Master접근 가능한 외부 주소가 필요합니다.
즉:
Source M1/M2/M3
External Routable
Target M1/M2/M3
External Routable조건이 모두 필요합니다.
7.1.26 실제 Migration 전 확인 명령
먼저 Source에서:
redis-cli -h source-entry.company.local -p 6379 CLUSTER NODES또는:
redis-cli -h source-entry.company.local -p 6379 CLUSTER SHARDS를 봅니다.
Redis 공식 문서에서 CLUSTER SHARDS는 Shard별 Master/Replica와 네트워크 정보를 제공하는 명령입니다. Redis
7.1.27 여기서 꼭 볼 부분
결과에서:
Master 1
192.168.100.21:6379
Master 2
192.168.100.22:6379
Master 3
192.168.100.23:6379가 나오면 바로 RedisShake Pod에서:
nc -zv 192.168.100.21 6379
nc -zv 192.168.100.22 6379
nc -zv 192.168.100.23 6379를 확인합니다.
모두 성공해야 합니다.
7.1.28 DNS를 광고한다면
예:
redis-m1.prod.company.local
redis-m2.prod.company.local
redis-m3.prod.company.localRedisShake에서:
nslookup redis-m1.prod.company.local
nslookup redis-m2.prod.company.local
nslookup redis-m3.prod.company.local를 먼저 확인합니다.
그 다음:
nc -zv redis-m1.prod.company.local 6379처럼 TCP 연결을 테스트합니다.
7.1.29 그다음 Redis 프로토콜 확인
redis-cli \
-h redis-m1.prod.company.local \
-p 6379 \
PING인증이 있다면:
redis-cli \
-h redis-m1.prod.company.local \
-p 6379 \
--user redis-shake \
-a 'PASSWORD' \
PING정상:
PONG입니다.
7.1.30 CLUSTER SHARDS까지 RedisShake 위치에서 확인
RedisShake가 보는 Network 기준으로:
redis-cli \
-h source-entry.company.local \
-p 6379 \
CLUSTER SHARDS를 실행해 봅니다.
그리고 출력되는 각 Master 주소가:
DNS 해석 가능?
↓
Routing 가능?
↓
TCP 6379 가능?
↓
Redis 인증 가능?전부 YES여야 합니다.
7.1.31 가장 흔한 실패 패턴 ①
Initial Service
접속 성공RedisShake 실행.
그런데:
CLUSTER NODES
M1 = 10.244.1.10
M2 = 10.244.2.10
M3 = 10.244.3.10RedisShake는 다른 센터.
결과:
M1 Connection timeout
M2 Connection timeout
M3 Connection timeout원인은 RedisShake가 아니라:
Cluster advertised address가 외부에서 Routable하지 않음
입니다.
7.1.32 흔한 실패 패턴 ②
DNS는 됩니다.
redis-m1.company.local
→ 192.168.100.21하지만 방화벽:
TCP 6379 DENY입니다.
결과:
DNS ✅
Routing ✅
TCP ❌이므로 RedisShake 실패.
7.1.33 흔한 실패 패턴 ③
RedisShake → Source는 정상.
하지만:
RedisShake → Target M2만 막혀 있습니다.
그러면 일부 Key/Slot Write가 실패할 수 있습니다.
따라서 Source뿐 아니라 Target 전체 Master도 반드시 테스트해야 합니다.
7.1.34 흔한 실패 패턴 ④ — DNS 혼용
예:
M1
redis-m1.company.local
M2
10.244.2.10
M3
redis-m3.company.local처럼 hostname/IP가 섞여 있으면 운영이 복잡해집니다.
Redis 공식 Sentinel 문서에서도 hostname을 사용할 경우 hostname과 IP를 혼용하지 않는 방향을 권장하는 사례가 있습니다. Redis
Redis Cluster도 마찬가지로 광고 주소 정책을 통일하는 게 관리하기 좋습니다.
7.1.35 그러면 가장 현실적인 권장안은?
현재처럼:
온프레미스
+
운영 K8s
+
DR K8s
+
Redis Cluster라면 저는 우선 아래 두 가지를 검토합니다.
안 A — Pod Network 직접 Routing
DR RedisShake
↓
Source Pod IP 직접 접근조건:
Pod CIDR 중복 없음
센터간 Routing 가능
보안 허용장점:
구조 단순
추가 L4 적음안 B — Node별 외부 DNS/VIP
redis-m1.prod.company.local
redis-m2.prod.company.local
redis-m3.prod.company.local을 각 Source Master 접근 Endpoint로 제공.
Redis Cluster도 이 주소들을 광고하도록 맞춥니다.
장점:
네트워크 경계 명확
방화벽 정책 명확
DNS 기반 관리대규모 기업 온프레미스 환경에서는 이 방식이 네트워크 운영팀과 협업하기 쉬운 경우가 많습니다.
7.1.36 다만 “Master 3개 VIP 고정”도 Failover를 생각해야 한다 ⭐
이건 매우 중요합니다.
예:
redis-0 = Master
redis-3 = Replica였는데 장애로:
redis-3 = New Master가 됐습니다.
그런데 외부 VIP가 계속:
VIP → redis-0만 바라보면 안 됩니다.
따라서 Node별 외부 Endpoint 설계 시:
Pod Identity 기준인지
Shard/Master Role 기준인지
Failover 후 Backend를 어떻게 바꿀지까지 고려해야 합니다.
Redis Cluster의 Node ID는 IP/port 변화와 분리되어 있고 Cluster 자체가 topology 변경을 gossip으로 공유할 수 있습니다. Redis
7.1.37 그래서 Migration Window에는 topology 변경을 최소화
RedisShake 공식 문서는 장기 지속 동기화나 topology 변화를 계속 추적하는 DR 엔진으로 사용하는 것에 제약이 있다고 명시합니다. Tair Open Source
그래서 Migration 기간에는 가능하면:
Resharding ❌
Node Add/Remove ❌
계획 Failover ❌
Redis Upgrade ❌를 피하는 게 좋습니다.
장애 Failover는 어쩔 수 없지만, 발생하면 RedisShake 연결과 정합성을 다시 검증해야 합니다.
7.1.38 권장 네트워크 체크 구조
운영센터
Source Redis Cluster
M1 M2 M3
│ │ │
▼ ▼ ▼
외부 접근 가능한 Endpoint
│ │ │
└────┬───┴───┬────┘
│
방화벽 TCP 6379
│
▼
DR센터
RedisShake Pod
│
│
┌─────────┼─────────┐
▼ ▼ ▼
TM1 TM2 TM3
Target ClusterRedisShake 관점에서는 Source/Target Cluster의 모든 Master client endpoint가 도달 가능해야 합니다. RedisShake의 Cluster Reader는 Source Shard별 Reader를 구성하고, Cluster Writer는 Target Cluster로 명령을 전달합니다. Tair Open Source
🎯 7.1단계 핵심 정리
이번 단계에서 딱 6개만 기억하시면 됩니다.
① Headless Service
같은 K8s 안에서 StatefulSet Pod별 DNS를 제공하는 데 매우 유용합니다. Kubernetes
② Pod IP
Pod 재생성 시 변할 수 있고 다른 K8s/센터에서 Routable하지 않을 수 있습니다.
③ cluster-announce-ip/hostname
Redis Cluster가 Client에게 “각 노드는 이 주소로 접근하라”고 알려주는 주소 설계와 연결됩니다. CLUSTER SLOTS 등은 실제 노드의 IP/hostname 정보를 반환합니다. Redis
④ L4/VIP
초기 Endpoint 하나만 제공해서는 부족할 수 있습니다. RedisShake가 결국 각 Master에 도달해야 합니다.
⑤ 방화벽
RedisShake → Source/Target 각 Redis Master의 TCP 6379 접근을 확인합니다. Cluster Bus는 Redis Node 간 통신용입니다. Redis
⑥ 최종 판단 기준
RedisShake에서
Initial Endpoint 접속 ✅
CLUSTER SHARDS 조회 ✅
각 Master DNS 해석 ✅
각 Master Routing ✅
각 Master TCP 6379 ✅
Redis AUTH/PING ✅여기까지 모두 성공해야 Redis Cluster → Redis Cluster RedisShake Migration 네트워크 준비 완료라고 보는 것이 맞습니다.
다음 7.2단계에서는 이 구조를 실제 운영 점검 절차로 바꿔서, kubectl, nslookup, nc, redis-cli CLUSTER SHARDS/NODES, 방화벽 테스트를 순서대로 실행하는 “RedisShake 사전점검 Runbook” 형태로 연결하면 바로 구축/검증 작업에 사용할 수 있습니다.
'J-H-T > Redis' 카테고리의 다른 글
| [REDIS-9단계] 서비스 무중단 전환(Cutover) 절차! (0) | 2026.08.18 |
|---|---|
| [REDIS-8단계] 방화벽·포트·네트워크 구성! (0) | 2026.08.17 |
| [REDIS-7단계] Redis Cluster → Redis Cluster 동기화! (0) | 2026.08.17 |
| [REDIS-6단계] Master/Replica + Sentinel 환경에서 동기화! (0) | 2026.08.17 |
| [REDIS-5단계] Standalone Redis → Standalone Redis 실습! (0) | 2026.08.16 |
| [REDIS-4.2단계] RedisShake CPU / RAM / Disk 산정! (0) | 2026.08.16 |
| [REDIS-4.1단계] sync_reader를 실제 K8s ConfigMap + Secret + RedisShake Pod + shake.toml 구성 예제! (0) | 2026.08.16 |
| [REDIS-4단계] sync_reader / scan_reader / rdb_reader 차이! (0) | 2026.08.16 |
댓글