이제 8단계 — 방화벽·포트·네트워크 구성입니다.
앞의 7.1단계가 “왜 각 Redis Node까지 접근해야 하는가”였다면, 이번에는 실제로 방화벽 요청서를 어떻게 작성하고, 어떤 포트를 어디서 어디로 열어야 하는지까지 연결하겠습니다.
기준 환경은 다음과 같습니다.
운영센터 K8s
Source Redis Cluster
3 Master + 3 Replica
│
│ 센터 간 네트워크
▼
DR센터 K8s
RedisShake Pod
│
▼
Target Redis Cluster
3 Master + 3 ReplicaRedis Cluster의 각 노드는 일반 Redis Client/Data Port와 별도의 Cluster Bus Port를 사용합니다.
기본 예에서는 Redis가 6379를 사용하면 Cluster Bus는 16379이며, cluster-port로 변경할 수 있습니다. Redis
🟥 8단계 — 방화벽·포트·네트워크 구성
8.1 가장 먼저 포트를 2종류로 구분하자
Redis Cluster에서는 크게 두 종류가 있습니다.
① Client / Data Port
예: TCP 6379
② Cluster Bus Port
예: TCP 16379둘의 용도가 완전히 다릅니다. Redis 공식 문서에서도 각 Cluster Node는 Client용 TCP Port와 Node 간 Cluster Bus Port 두 개가 필요하다고 설명합니다. Redis
| 6379 | App / redis-cli / RedisShake ↔ Redis | GET, SET, PSync, Migration |
| 16379 예시 | Redis Node ↔ Redis Node | Gossip, Cluster 상태, Failover |
8.2 RedisShake에는 어떤 포트가 필요한가?
핵심은:
RedisShake
│
│ TCP 6379
▼
Redis입니다.
RedisShake sync_reader는 Source Master에 Replica처럼 연결하여 Full RDB와 Incremental stream을 받습니다. RedisShake Cluster mode는 Cluster 정보를 얻고 각 Node에 연결하는 방식입니다. Tair Open Source
따라서 RedisShake는 기본적으로 다음이 필요합니다.
RedisShake → Source Redis Master : TCP 6379
RedisShake → Target Redis Master : TCP 6379반면:
RedisShake → Redis Cluster Bus :16379는 일반적인 RedisShake 데이터 Migration 경로에는 필요하지 않습니다.
16379는 Redis Node끼리 사용하는 통신입니다. Redis
8.3 전체 방화벽 흐름부터 보자
현재 구조를 기준으로 하면:
[운영센터]
Source Redis Cluster
M1 M2 M3
:6379 :6379 :6379
│ │ │
│ │ │
└─────┬───┴───┬─────┘
│
센터간 방화벽
│
TCP 6379 허용
│
▼
[DR센터]
RedisShake Pod
│
│ TCP 6379
▼
Target Redis Cluster
TM1 TM2 TM3
:6379 :6379 :6379즉 RedisShake 입장에서 핵심 경로는 Source/Target Master들의 Redis Client Port입니다. Tair Open Source
8.4 Source 쪽 방화벽
Source Redis가 운영센터에 있고 RedisShake가 DR센터라면:
DR RedisShake
│
├──→ Source M1 :6379
├──→ Source M2 :6379
└──→ Source M3 :6379가 필요합니다.
예를 들어:
Source M1 = 192.168.10.21
Source M2 = 192.168.10.22
Source M3 = 192.168.10.23
RedisShake = 192.168.50.30이면 방화벽 정책 개념은:
SRC
192.168.50.30
DST
192.168.10.21
192.168.10.22
192.168.10.23
Protocol
TCP
Port
6379입니다.
8.5 초기 Service 하나만 열면 부족할 수 있다 ⭐
예:
redis-prod.company.local
↓
192.168.10.100:6379VIP 하나만 열었다고 합시다.
RedisShake:
RedisShake
│
▼
VIP :6379
│
▼
M1처음 연결은 성공할 수 있습니다.
그런데 RedisShake가 Cluster 정보를 얻어:
M1 192.168.10.21:6379
M2 192.168.10.22:6379
M3 192.168.10.23:6379를 발견하면 결국 이 노드들로 연결해야 합니다.
RedisShake의 Cluster mode는 Cluster Node 정보를 자동으로 얻고 연결합니다. Tair Open Source
따라서 방화벽을:
RedisShake → VIP 하나만열고 끝내면 안 될 수 있습니다.
8.6 Target도 동일하다
Target이 같은 DR K8s 안에 있다고 해도 RedisShake는 Target Cluster Node들에 접근해야 합니다.
RedisShake
│
├──→ Target M1 :6379
├──→ Target M2 :6379
└──→ Target M3 :6379Redis Cluster Writer는 Target Cluster topology를 이용하므로 각 필요한 Node로 Redis 명령을 전달할 수 있어야 합니다. Tair Open Source
8.7 Replica 6379도 열어야 하나?
Migration의 기본 데이터 Source가 Master이고 Target Write도 Master 기준이라면 Master 접근이 핵심입니다.
하지만 Cluster Failover를 고려하면 Replica가 Master로 승격될 수 있습니다.
예:
현재
M1 : 192.168.10.21
R1 : 192.168.10.24
장애 발생
R1
↓
New Master
192.168.10.24그러면 기존 Master 3개의 IP만 방화벽에 등록해 두었다면 새 Master로 접근하지 못할 수 있습니다.
그래서 운영적인 관점에서는 다음 두 방식 중 하나를 검토합니다.
방법 A
Redis Cluster 전체 Node subnet 허용
단, 보안범위가 넓어짐
방법 B
각 Node의 고정 External Endpoint/VIP 설계
보안범위가 명확하지만 구성 복잡Redis Cluster에서는 Replica가 Failover를 통해 Master가 될 수 있으므로 이 부분은 네트워크 설계에 반영해야 합니다. Redis
8.8 Redis Node끼리는 Cluster Bus가 필요하다
이번에는 RedisShake가 아니라 Redis Cluster 내부입니다.
M1 ←────────→ M2
│ │
│ Cluster Bus │
│ │
└──────────→ M3그리고 Replica도 Cluster 구성원입니다.
M1 M2 M3
R1 R2 R3
↕
Cluster BusRedis Cluster Bus는 Node 간 장애 감지, Gossip, Failover, Cluster 구성정보 교환에 사용됩니다.
기본값은 data port + 10000이고, 별도의 cluster-port 설정도 가능합니다. Redis
따라서 실제 Redis 설정이:
Client Port = 6379
Cluster Bus = 16379라면 같은 Redis Cluster의 Node들 사이에는:
TCP 6379
TCP 16379통신 가능 여부를 확인하는 것이 좋습니다.
8.9 왜 Node끼리 6379도 필요한가?
Cluster Bus만 있다고 Redis replication이 되는 것은 아닙니다.
예:
Master
│
│ Replication
▼
ReplicaMaster/Replica replication은 Redis replication protocol을 사용합니다. Redis replication은 Master와 Replica가 데이터 복제를 위해 연결하는 구조입니다. Redis
따라서:
Redis Node ↔ Redis Node
6379
Replication / Redis protocol
16379
Cluster Bus라고 이해하면 쉽습니다.
8.10 가장 중요한 포트 그림
RedisShake
│
│ TCP 6379
▼
┌──────────────────────────┐
│ Redis Cluster │
│ │
│ M1 ←──6379──→ R1 │
│ │ │
│ │16379 Cluster Bus │
│ ↕ │
│ M2 ←──────→ M3 │
│ │
└──────────────────────────┘쉽게 외우면:
6379
= 데이터 길
16379
= Cluster 관리 길입니다. Redis
8.11 방화벽 요청서를 실제로 작성하면
현재 예시 기준으로 이렇게 만들 수 있습니다.
| 1 | DR RedisShake | Source Redis M1~M3 | TCP 6379 | DR → PROD | Full/Incremental Sync |
| 2 | DR RedisShake | Source Redis Replica 후보 | TCP 6379 | DR → PROD | Failover 대비 |
| 3 | RedisShake | Target Redis M1~M3 | TCP 6379 | DR 내부 | Target Write |
| 4 | Source Redis Nodes | Source Redis Nodes | TCP 6379 | 양방향 | Replication/Redis |
| 5 | Source Redis Nodes | Source Redis Nodes | TCP Cluster Bus | 양방향 | Gossip/Failover |
| 6 | Target Redis Nodes | Target Redis Nodes | TCP 6379 | 양방향 | Replication/Redis |
| 7 | Target Redis Nodes | Target Redis Nodes | TCP Cluster Bus | 양방향 | Gossip/Failover |
| 8 | RedisShake | DNS | UDP/TCP 53 | Egress | hostname 사용 시 DNS |
여기서 Cluster Bus의 실제 포트는 반드시 redis.conf의 cluster-port 및 운영 설정을 확인하세요.
기본적인 6379 기반 예시는 16379입니다. Redis
8.12 DNS 53도 놓치면 안 된다
예를 들어 RedisShake 설정이:
address = "redis-source.prod.company.local:6379"이라면 RedisShake가 먼저:
redis-source.prod.company.local
│
▼
DNS를 조회해야 합니다.
즉 NetworkPolicy나 방화벽에서 DNS Egress까지 막아버리면:
TCP 6379 OPEN ✅
하지만
DNS ❌
결과
Redis 접속 ❌가 됩니다.
K8s 내부 DNS 이름을 사용할 때도 동일하게 DNS 접근이 필요합니다.
8.13 물리 방화벽만 열면 끝인가?
아닙니다.
K8s에서는 NetworkPolicy도 확인해야 합니다.
IDC Firewall
│
▼
Kubernetes Node
│
▼
NetworkPolicy
│
▼
Redis Pod즉 외부 방화벽에서 6379를 허용해도:
NetworkPolicy
Default Deny가 적용되어 있으면 Pod 통신은 차단될 수 있습니다.
Kubernetes NetworkPolicy는 선택된 Pod의 ingress/egress 트래픽을 제어하며, namespace 전체를 default-deny ingress/egress로 구성할 수도 있습니다. Kubernetes
8.14 RedisShake Egress NetworkPolicy 예
예를 들어 RedisShake Pod:
namespace = redis-migration
label = app=redis-shake라고 합시다.
Target Redis가:
namespace = redis-target
label = app=redis이면 개념적으로:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: redis-shake-egress
namespace: redis-migration
spec:
podSelector:
matchLabels:
app: redis-shake
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: redis-target
podSelector:
matchLabels:
app: redis
ports:
- protocol: TCP
port: 6379같은 정책을 검토할 수 있습니다.
NetworkPolicy가 실제로 동작하려면 사용하는 CNI가 NetworkPolicy 적용을 지원해야 합니다. Kubernetes 공식 문서도 NetworkPolicy 구현은 Network Plugin의 지원이 필요하다고 설명합니다. Kubernetes
8.15 Source가 다른 센터 IP라면 ipBlock
Source Redis External Endpoint가:
192.168.10.0/24라고 하면 RedisShake Egress 정책을:
egress:
- to:
- ipBlock:
cidr: 192.168.10.0/24
ports:
- protocol: TCP
port: 6379처럼 검토할 수 있습니다.
다만 실제 Pod→Service→NAT 처리 위치에 따라 NetworkPolicy가 보는 Source/Destination IP가 달라질 수 있으므로 사용하는 CNI/F5/Service 구조와 함께 검증해야 합니다.
8.16 Target의 Ingress도 필요할 수 있다
Target namespace가 default-deny라면 RedisShake에서 나가는 것만 허용해서 끝나는 게 아닐 수 있습니다.
RedisShake
Egress ✅
│
▼
Target
Ingress ❌가 될 수 있습니다.
따라서:
RedisShake Egress Allow
+
Target Redis Ingress Allow둘 다 확인합니다.
Kubernetes NetworkPolicy는 ingress와 egress를 각각 제어할 수 있습니다. Kubernetes
8.17 Ingress Controller를 써야 하나?
일반적인 Redis TCP Migration에서는 Kubernetes의 일반 Ingress 리소스를 기본 선택으로 보지 않는 것이 좋습니다.
일반 Kubernetes Ingress는 기본적으로 HTTP/HTTPS 외부 라우팅을 위한 리소스입니다. Redis는 TCP 프로토콜이므로 일반 HTTP Ingress와 목적이 다릅니다. Kubernetes
따라서 Redis는 보통:
LoadBalancer Service
NodePort
F5 L4
MetalLB
Pod routing
별도 TCP Proxy같은 방식이 더 자연스럽습니다.
단, 특정 Ingress Controller가 별도의 TCP stream 기능을 제공한다면 구현할 수는 있지만 이는 Controller별 기능입니다.
8.18 F5는 여기서 어떤 역할을 할까?
F5를 L4로 사용한다고 가정하면:
RedisShake
│
▼
F5 VIP :6379
│
▼
K8s Redis Endpoint같은 경로를 만들 수 있습니다.
예:
redis-m1.prod.company.local
192.168.100.21:6379
↓ F5
redis-0:6379redis-m2.prod.company.local
192.168.100.22:6379
↓ F5
redis-1:6379처럼 Cluster Node별 접근 Endpoint를 제공하는 방법입니다.
8.19 F5 Health Check도 중요하다
단순 TCP Health Check:
Can connect :6379?만 사용하면 Redis Replica도 “정상 Redis”로 판단될 수 있습니다.
하지만 어떤 VIP가 반드시 특정 역할의 Master를 향해야 하는 구조라면:
role:master까지 식별하는 Health Check나 backend 전환 로직이 필요할 수 있습니다.
즉:
TCP 연결됨
≠
현재 올바른 Master입니다.
특히 Redis Cluster Failover까지 고려한다면 VIP와 Redis Role의 연계 방식을 사전에 정해야 합니다.
8.20 Source와 Target의 Cluster Bus는 센터 간에도 열어야 하나?
이건 Cluster가 센터를 걸쳐 구성되는지에 따라 다릅니다.
현재 구조가:
운영센터
Source Cluster
DR센터
Target Cluster이고 서로 독립된 Redis Cluster라면:
Source Cluster Bus
→ 운영센터 Source Node끼리
Target Cluster Bus
→ DR센터 Target Node끼리만 필요합니다.
즉 Source와 Target 사이:
Source M1 :16379
↔
Target M1 :16379통신은 필요하지 않습니다.
두 Redis Cluster는 서로 하나의 Redis Cluster가 아니기 때문입니다.
8.21 이 부분을 그림으로 보면
[운영센터]
M1 ←──────────→ M2
↑ 16379 ↑
│ │
└────→ M3 ←─────┘
Source Cluster 내부 Bus
│
│ RedisShake는 6379
▼
[DR센터]
RedisShake
│
│ 6379
▼
TM1 ←─────────→ TM2
↑ 16379 ↑
│ │
└────→ TM3 ←────┘
Target Cluster 내부 BusRedis Cluster Bus는 해당 Cluster의 Node 간 전용 통신입니다. Redis
8.22 운영센터↔DR센터 네트워크 Bandwidth도 계산해야 한다
방화벽이 열려 있어도:
센터간 Link = 100Mbps라면 3TB Migration은 현실적으로 오래 걸립니다.
예:
RedisShake
│
│ 센터간 WAN/LAN
▼
Source여기서 봐야 할 것은:
Bandwidth
Latency
Packet Loss
Firewall Session Timeout
MTU
NAT
QoS입니다.
특히 Incremental Sync가 계속 발생하므로:
센터간 유효 처리량 > Source의 지속 Write 증가량
이 되어야 결국 Target이 Source를 따라잡을 수 있습니다.
8.23 방화벽 Session Timeout도 확인
Full Sync가 몇 시간씩 지속될 수 있다면:
RedisShake
│
│ Long-lived TCP Connection
▼
Source Redis형태가 됩니다.
Redis replication은 Master/Replica 간 지속적인 연결을 사용하는 구조이고 RedisShake sync_reader도 Replica처럼 Source에 연결합니다. Tair Open Source
따라서 중간 F5/Firewall에서 너무 짧은 TCP idle/session timeout을 적용하고 있지는 않은지 확인하는 것이 좋습니다.
8.24 NAT도 주의해야 한다
예:
DR RedisShake
10.20.1.50
↓ NAT
172.16.100.50
↓
Source RedisSource에서는 RedisShake의 실제 Pod IP가 아니라 NAT IP로 보일 수 있습니다.
따라서 방화벽 요청 시:
실제 Source IP?
SNAT IP?
F5 Self IP?
Node IP?를 네트워크팀과 확인해야 합니다.
Kubernetes/F5 환경에서는 “Pod IP를 Source IP로 요청했는데 실제 트래픽은 Node SNAT IP로 나가는” 경우도 생길 수 있으므로 실제 패킷 기준으로 검증하는 것이 중요합니다.
8.25 방화벽 테스트 순서 ⭐
이 순서대로 하면 문제 위치를 쉽게 찾을 수 있습니다.
① DNS
nslookup redis-m1.prod.company.local정상:
Name: redis-m1.prod.company.local
Address: 192.168.10.21② Routing
환경이 허용한다면:
ip route get 192.168.10.21등으로 경로를 봅니다.
③ TCP Port
nc -zv 192.168.10.21 6379정상:
succeeded④ Redis Protocol
redis-cli \
-h 192.168.10.21 \
-p 6379 \
PING정상:
PONG⑤ Authentication
redis-cli \
-h 192.168.10.21 \
-p 6379 \
--user redis-shake \
-a 'PASSWORD' \
PING⑥ Cluster topology
redis-cli \
-h 192.168.10.21 \
-p 6379 \
CLUSTER NODESRedisShake Cluster mode도 Cluster Node 정보를 사용해 각 Node에 연결합니다. Tair Open Source
8.26 CLUSTER NODES 결과가 진짜 방화벽 기준이다
예를 들어 결과가:
M1 192.168.10.21:6379
M2 192.168.10.22:6379
M3 192.168.10.23:6379이면 바로:
nc -zv 192.168.10.21 6379
nc -zv 192.168.10.22 6379
nc -zv 192.168.10.23 6379를 실행합니다.
전부:
SUCCESS여야 합니다.
이걸 RedisShake 실행 전에 하는 게 좋습니다.
8.27 Target도 똑같이 검사
redis-cli \
-h target-entry \
-p 6379 \
CLUSTER NODES결과가:
TM1 10.245.1.21:6379
TM2 10.245.2.22:6379
TM3 10.245.3.23:6379이면 RedisShake Pod에서:
nc -zv 10.245.1.21 6379
nc -zv 10.245.2.22 6379
nc -zv 10.245.3.23 6379까지 확인합니다.
8.28 장애 증상별로 원인을 찾자
| DNS 이름 자체가 안 풀림 | CoreDNS / 사내 DNS |
| DNS는 되지만 nc 실패 | Routing / Firewall / NetworkPolicy |
| nc 성공, PING 실패 | Redis ACL/TLS/Protocol |
| 초기 Node 접속 성공, 이후 실패 | Cluster advertised address 문제 |
| 특정 Shard만 실패 | 특정 Master IP/Port 방화벽 |
| Full 중간에 자주 끊김 | Network/FW timeout/Packet loss |
| Target 일부 Key Write 실패 | Target Master 접근 문제 |
| Pod끼리 16379 실패 | Redis Cluster Bus/NetworkPolicy |
8.29 가장 현실적인 방화벽 정책 구조
현재 운영→DR 환경이라면 다음처럼 정리하면 이해하기 쉽습니다.
[정책 A]
DR RedisShake
│
│ TCP 6379
▼
Source Redis Cluster Nodes
[정책 B]
DR RedisShake
│
│ TCP 6379
▼
Target Redis Cluster Nodes
[정책 C]
Source Redis Nodes
│
│ TCP Redis Port + Cluster Bus
↕
Source Redis Nodes
[정책 D]
Target Redis Nodes
│
│ TCP Redis Port + Cluster Bus
↕
Target Redis Nodes8.30 방화벽 요청서 예시 ⭐
네트워크팀에 전달한다면 다음 정도로 작성하면 상당히 명확합니다.
RedisShake Migration 방화벽
[목적]
운영 Redis Cluster → DR Redis Cluster
RedisShake 데이터 Migration
[Source]
DR K8s RedisShake Egress IP/SNAT IP
[Destination]
운영 Redis Cluster 전체 Node External IP
또는 Redis Node별 VIP
[Protocol]
TCP
[Port]
6379
[Direction]
DR → 운영
[비고]
RedisShake PSync Full/Incremental Migration
Cluster topology 조회 후 각 Source Master 직접 연결 필요그리고 Target 쪽도 별도 정책으로 작성합니다.
8.31 최종 점검 체크리스트
RedisShake 실행 전에 이것만 확인하면 됩니다.
□ RedisShake에서 Source DNS 조회 가능
□ RedisShake에서 Source Initial Endpoint 6379 가능
□ CLUSTER NODES/SHARDS 결과 확인
□ Source 각 Master 6379 가능
□ Failover 후보 Replica 주소도 접근 가능한지 확인
□ RedisShake에서 Target Initial Endpoint 6379 가능
□ Target 각 Master 6379 가능
□ Source Redis Node 간 Client/Replication Port 정상
□ Source Redis Node 간 Cluster Bus 정상
□ Target Redis Node 간 Client/Replication Port 정상
□ Target Redis Node 간 Cluster Bus 정상
□ IDC Firewall 확인
□ K8s NetworkPolicy 확인
□ DNS 53 확인
□ NAT/SNAT 실제 Source IP 확인
□ F5/L4 Session Timeout 확인🎯 8단계 핵심 그림 하나로 정리
운영센터 K8s
Source Redis Cluster
M1 M2 M3
:6379 :6379 :6379
↕ ↕ ↕
─── Cluster Bus ─────
예: TCP 16379
Redis Node끼리 사용
│
│
┌───────┴───────┐
│ IDC Firewall │
│ TCP 6379 │
└───────┬───────┘
│
▼
DR센터 K8s
RedisShake Pod
│
│ TCP 6379
▼
Target Redis Cluster
TM1 TM2 TM3
:6379 :6379 :6379
↕ ↕ ↕
─── Cluster Bus ─────
예: TCP 16379🔑 딱 두 줄만 외우면
RedisShake ↔ Redis = Redis Client/Data Port(보통 TCP 6379)
Redis Node ↔ Redis Node = Redis Port + Cluster Bus(6379 + 기본 예 16379)
그리고 실무적으로 가장 중요한 것은 “VIP 6379 하나 열었으니 끝”이 아니라 CLUSTER NODES/SHARDS에서 RedisShake에게 알려지는 각 Redis Node 주소가 실제 방화벽·Routing·NetworkPolicy를 통과할 수 있는지 확인하는 것입니다.
RedisShake Cluster mode는 Cluster Node 정보를 얻어 연결하므로 이 검증이 핵심입니다. Tair Open Source
다음 단계에서는 이 내용을 그대로 작업자가 사용할 수 있게 9단계 — RedisShake 실행 전 사전점검 Runbook으로 만들어 kubectl → DNS → nc → redis-cli → Cluster 상태 → PSync 권한 → Target Write → PVC → RedisShake 시작 순으로 체크하는 절차로 연결하면 좋습니다.
'J-H-T > Redis' 카테고리의 다른 글
| [REDIS-9단계] 서비스 무중단 전환(Cutover) 절차! (0) | 2026.08.18 |
|---|---|
| [REDIS-7.1단계] RedisShake 운영 네트워크 설계! (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 |
댓글