🟥 RedisShake 학습 시리즈 - K8s
- RedisShake가 무엇이고 K8s에서 어디에 위치하는가
- Redis Pod / Service / StatefulSet 구조 이해
- Source / Target / RedisShake 연결 구조
- Full Sync / Incremental Sync 원리
- sync_reader와 PSync 동작 원리
- Standalone Redis → Standalone Redis 실습
- Redis Master/Replica + Sentinel 환경
- Redis Cluster → Redis Cluster 동기화
- K8s Service / DNS / Endpoint / Headless Service
- Namespace가 다를 때 연결 방법
- 방화벽 / NetworkPolicy / L4 구간 설계
- RedisShake Pod YAML / ConfigMap / Secret 구성
- 동기화 상태 및 성능 모니터링
- 서비스 Cutover
- 장애 발생 시 복구 및 Rollback
- 운영센터 → DR센터 Redis Migration 설계
이번 1단계에서는 전체 구조만 확실히 이해하면 됩니다.
1단계. K8s에서 RedisShake가 무엇인가? 🚀
1. 먼저 현재 환경을 이렇게 생각해보겠습니다
온프레미스에 Kubernetes 클러스터가 있습니다.
┌──────────────────────────────────────┐
│ On-Premises K8s │
│ │
│ Worker Node 1 │
│ ┌──────────────┐ │
│ │ Redis Pod │ │
│ └──────────────┘ │
│ │
│ Worker Node 2 │
│ ┌──────────────┐ │
│ │ Redis Pod │ │
│ └──────────────┘ │
│ │
│ Worker Node 3 │
│ ┌──────────────┐ │
│ │ Redis Pod │ │
│ └──────────────┘ │
│ │
└──────────────────────────────────────┘
여기서 중요한 것은:
K8s 환경이라고 해서 Redis 동작 원리가 완전히 달라지는 것은 아닙니다.
Redis는 여전히 Redis이고, 단지 Redis 프로세스가 VM이 아니라 Pod 안에서 실행되는 것입니다.
2. K8s에서는 Redis를 보통 Pod 하나만 띄우지 않는다
예를 들어 운영 Redis를 아래처럼 구성할 수 있습니다.
Kubernetes Cluster
Redis StatefulSet
│
├── redis-0
├── redis-1
└── redis-2
각각 Pod입니다.
예:
kubectl get pod -n redis
NAME READY STATUS
redis-0 1/1 Running
redis-1 1/1 Running
redis-2 1/1 Running
그리고 Redis Pod 앞에는 보통 Service가 존재합니다.
Application
│
▼
Redis Service
│
▼
Redis Pod
예를 들어:
redis-master.redis.svc.cluster.local:6379
처럼 접속할 수 있습니다.
3. RedisShake도 K8s Pod로 띄울 수 있다
여기서 핵심입니다.
RedisShake 자체는 Redis가 아닙니다.
Redis 데이터를 읽고 다른 Redis에 전달하는 프로그램입니다.
K8s에서는 이 프로그램을 Container로 만들어 Pod로 실행하면 됩니다.
Kubernetes
┌─────────────────┐
│ RedisShake Pod │
│ │
│ redis-shake │
│ process │
└─────────────────┘
즉 VM이 반드시 필요한 것은 아닙니다.
우리 환경에서는 다음처럼 생각할 수 있습니다.
Source Redis Pod
│
│
▼
RedisShake Pod
│
│
▼
Target Redis Pod
4. 가장 기본적인 K8s 구조
예를 들어 기존 Redis와 신규 Redis가 같은 K8s 클러스터에 있다고 하겠습니다.
┌─────────────────────────────────────────┐
│ Kubernetes │
│ │
│ Namespace: redis-old │
│ │
│ ┌─────────────┐ │
│ │ redis-old-0 │ │
│ │ Redis Pod │ │
│ └──────┬──────┘ │
│ │ │
│ redis-old Service │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ RedisShake │ │
│ │ Pod │ │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ redis-new Service │
│ │ │
│ ┌───────▼──────┐ │
│ │ redis-new-0 │ │
│ │ Redis Pod │ │
│ └──────────────┘ │
│ │
│ Namespace: redis-new │
└─────────────────────────────────────────┘
결국 핵심은 동일합니다.
Source Redis
↓
RedisShake
↓
Target Redis
단지 이것들이 모두 Pod와 Service 형태라는 차이입니다.
5. RedisShake는 Redis Pod IP에 직접 접속하나?
여기서 K8s에서 아주 중요한 개념이 나옵니다.
가능하면 이런 식으로 하면 안 됩니다.
RedisShake
↓
10.244.3.17:6379
Redis Pod
왜냐하면 Pod IP는 바뀔 수 있기 때문입니다.
Pod가 죽었다가 다시 생성되면:
기존
redis-0
10.244.3.17
↓ 장애
재생성
redis-0
10.244.5.21
IP가 바뀔 수 있습니다.
그래서 일반적으로 Service나 안정적인 DNS 이름을 이용합니다.
RedisShake
↓
redis-master.redis.svc.cluster.local:6379
이게 K8s에서 매우 중요한 차이입니다.
6. 그런데 Redis Cluster에서는 조금 다르다 ⚠️
여기서부터 조금 중요합니다.
Standalone Redis라면:
RedisShake
│
▼
Redis Service
│
▼
Redis Pod
정도로 이해하면 됩니다.
하지만 Redis Cluster라면:
redis-0
redis-1
redis-2
redis-3
redis-4
redis-5
여러 Redis 노드가 존재합니다.
RedisShake의 sync_reader에서 Source가 Cluster이면:
[sync_reader]
cluster = true
address = "redis-cluster:6379"
처럼 Cluster 모드를 사용할 수 있고, RedisShake는 초기 노드에 연결한 뒤 CLUSTER NODES 정보를 이용하여 Cluster 노드들을 찾습니다. 공식 문서도 Redis Cluster에서는 cluster = true로 설정하고 클러스터의 임의 노드 하나를 초기 주소로 지정할 수 있다고 설명합니다. (tair-opensource.github.io)
따라서 실제 운영에서는 단순히
RedisShake → Service 하나
만 보는 게 아니라:
Redis Cluster
┌── redis-0
│
RedisShake ──┼── redis-1
│
├── redis-2
│
├── redis-3
│
├── redis-4
│
└── redis-5
RedisShake가 각 Redis Cluster 노드와 통신할 수 있어야 합니다.
이 부분을 나중에 Service/Headless Service와 연결해서 자세히 보겠습니다.
7. RedisShake Pod는 어느 Namespace에 둬야 하나?
정답은:
어느 Namespace에 있어도 됩니다.
예를 들어:
Namespace: redis-source
redis-source-0
redis-source-1
redis-source-2
Namespace: migration
redis-shake
Namespace: redis-target
redis-target-0
redis-target-1
redis-target-2
이런 구조도 가능합니다.
redis-source namespace
│
▼
migration namespace
RedisShake
│
▼
redis-target namespace
K8s 내부 DNS를 사용하면 다른 Namespace도 접근할 수 있습니다.
예:
redis-source.redis-source.svc.cluster.local
또는:
redis-source.redis-source.svc:6379
같은 방식입니다.
8. 같은 K8s 클러스터라면 방화벽은 필요 없나?
꼭 그렇지는 않습니다.
전체적으로는 다음 두 레벨을 생각해야 합니다.
① Kubernetes NetworkPolicy
② 물리 Network / Firewall
같은 K8s 클러스터 안이라도 NetworkPolicy가 있다면:
RedisShake Pod
│
X
│
Source Redis
접속이 막힐 수 있습니다.
따라서:
RedisShake
│
├── Source Redis TCP 6379
│
└── Target Redis TCP 6379
통신이 허용되어야 합니다.
Redis Cluster라면 각 Redis 노드에 접근 가능한지도 확인해야 합니다.
9. 다른 K8s 클러스터끼리 Sync할 수도 있다
온프레미스 환경에서 실제로는 이 구조도 많이 생각할 수 있습니다.
Source Cluster
┌────────────────────────┐
│ K8s Cluster A │
│ │
│ Redis Cluster │
│ redis-0 │
│ redis-1 │
│ redis-2 │
└──────────┬─────────────┘
│
│
│ Network
▼
Target Cluster
┌────────────────────────┐
│ K8s Cluster B │
│ │
│ Redis Cluster │
│ redis-0 │
│ redis-1 │
│ redis-2 │
└────────────────────────┘
중간에 RedisShake가 있습니다.
K8s Cluster A
Source Redis
│
▼
RedisShake
│
▼
K8s Cluster B
Target Redis
이 경우에는 이야기가 조금 달라집니다.
K8s 내부의:
ClusterIP
는 일반적으로 다른 클러스터에서는 직접 접근할 수 없습니다.
그래서 외부 연결 방식을 별도로 설계해야 합니다.
예:
NodePort
LoadBalancer
External IP
L4 VIP
Ingress/TCP Proxy
전용 Network
등입니다.
이 부분은 나중에 네트워크 단계에서 아주 중요하게 다루겠습니다.
10. K8s에서 RedisShake의 가장 자연스러운 형태
온프레미스 K8s에서는 다음과 같은 구조를 추천 관점에서 생각하면 좋습니다.
Kubernetes
Source Redis
StatefulSet
┌──────┬──────┐
│ │ │
redis-0 redis-1 redis-2
│ │ │
└──────┼──────┘
│
Headless Service
│
▼
RedisShake Pod
│
│
▼
Headless Service
│
┌──────┼──────┐
│ │ │
redis-0 redis-1 redis-2
Target Redis
StatefulSet
다만 Redis 구조가:
Standalone
Master/Replica
Sentinel
Cluster
중 무엇인지에 따라 실제 연결 구조가 달라집니다.
그래서 이 부분을 먼저 파악하는 것이 중요합니다.
11. RedisShake Pod에서는 무엇을 설정하나?
RedisShake Pod 안에 설정 파일이 필요합니다.
예:
shake.toml
K8s에서는 보통:
ConfigMap
으로 관리합니다.
구조를 보면:
ConfigMap
shake.toml
│
│ mount
▼
RedisShake Pod
/etc/redis-shake/shake.toml
그리고 비밀번호는 ConfigMap에 넣기보다는:
Secret
사용을 고려합니다.
즉:
ConfigMap
│
│ 설정
▼
┌────────────────┐
│ RedisShake Pod │
└────────────────┘
▲
│ 인증정보
│
Secret
이렇게 됩니다.
12. RedisShake 동작은 그대로다
K8s라고 해서 RedisShake의 핵심 원리가 달라지지는 않습니다.
가장 일반적인 sync_reader는 Source Redis의 PSync 프로토콜을 사용합니다.
RedisShake가 Source의 Replica처럼 연결되고, 전체 RDB 데이터와 이후 증가분 명령 스트림을 Target으로 전달합니다. (tair-opensource.github.io)
쉽게 표현하면:
Source Redis
│
│
├── ① 기존 데이터 전체
│ RDB
│
└── ② 이후 변경 데이터
AOF Stream
│
▼
RedisShake Pod
│
▼
Target Redis
그래서:
Full Sync
+
Incremental Sync
가 가능합니다.
13. 실제 서비스까지 넣어보자
이제 Application까지 포함하면 이해가 훨씬 쉽습니다.
현재 운영
Application Pod
│
▼
Source Redis Service
│
▼
Source Redis
신규 Redis를 구축합니다.
Target Redis
RedisShake를 띄웁니다.
Kubernetes
Application Pod
│
│
▼
Source Redis Service
│
▼
┌───────────────┐
│ Source Redis │
└───────┬───────┘
│
│ Full + Incremental
▼
┌───────────────┐
│ RedisShake │
│ Pod │
└───────┬───────┘
│
▼
┌───────────────┐
│ Target Redis │
└───────────────┘
이 시점에도 Application은 계속 Source Redis를 사용합니다.
14. 데이터가 맞춰진 후 Cutover
충분히 동기화됐다고 확인되면 서비스 연결을 변경합니다.
변경 전
Application
│
▼
Source Redis
변경 후
Application
│
▼
Target Redis
K8s에서는 이게 여러 방식으로 가능합니다.
예를 들어 애플리케이션의 Redis 주소가:
REDIS_HOST: redis-old.redis.svc.cluster.local
였다면:
REDIS_HOST: redis-new.redis.svc.cluster.local
로 변경할 수 있습니다.
또는 더 잘 설계했다면 애플리케이션이 처음부터:
redis-service
같은 논리적인 Endpoint만 바라보게 해서 Backend를 변경할 수도 있습니다.
이 부분이 바로 Cutover 설계입니다.
15. RedisShake를 Deployment로 띄울까?
여기서 한 가지 기억해야 합니다.
RedisShake는 일반 웹 애플리케이션처럼:
replicas: 3
으로 여러 Pod를 무조건 띄우는 방식으로 접근하면 안 됩니다.
예를 들어:
redis-shake-1
redis-shake-2
redis-shake-3
가 동일 Source → Target을 동시에 처리하면 데이터 중복이나 예상하지 못한 동작이 발생할 수 있습니다.
공식 Quick Start도 동일 디렉터리에서 RedisShake 프로세스를 두 개 실행하면 임시 파일이 덮어쓰여 문제가 생길 수 있음을 경고합니다. (tair-opensource.github.io)
따라서 처음에는:
RedisShake Pod
replica = 1
로 이해하는 것이 좋습니다.
실제 대규모 Cluster migration에서는 shard별 RedisShake를 별도로 구성하는 고급 설계도 가능하지만, 그건 나중 단계에서 다루겠습니다.
16. 아주 중요한 주의사항 ⚠️
RedisShake는 K8s용 Redis Operator가 아닙니다.
즉:
RedisShake
가 해주는 것은:
Redis Pod 생성 ❌
Redis 장애복구 ❌
Redis Failover ❌
Redis Cluster 관리 ❌
Redis 데이터 Migration / Sync ⭕
입니다.
그리고 RedisShake 4.x는 체크포인트를 이용한 완전한 장기 재개 기능이나 Cluster topology 변경 추적 기능에 제약이 있어, 공식 문서에서도 장기간 DR 복제용 솔루션으로는 권장하지 않습니다. (tair-opensource.github.io)
🧩 K8s 관점에서 역할을 정리하면
| 구성요소 | 역할 |
| Redis Pod | 실제 Redis 프로세스 |
| StatefulSet | Redis Pod의 안정적 생성/관리 |
| PVC | Redis 데이터 저장 |
| Service | Redis 접속 Endpoint |
| Headless Service | Redis Pod별 DNS 제공 |
| ConfigMap | Redis/RedisShake 설정 관리 |
| Secret | Redis Password/ACL 정보 |
| RedisShake Pod | Source → Target 데이터 Migration |
| NetworkPolicy | Pod 간 통신 제어 |
| Application Pod | Redis를 실제 사용하는 서비스 |
🎯 1단계 핵심만 정리
온프레미스 K8s 환경에서는 이 그림을 기억하시면 됩니다.
[ Application Pod ]
│
▼
[ Source Service ]
│
▼
[ Source Redis ]
StatefulSet
│
│ PSync
▼
┌──────────────────┐
│ RedisShake Pod │
│ │
│ ConfigMap │
│ Secret │
└────────┬─────────┘
│
▼
[ Target Service ]
│
▼
[ Target Redis ]
StatefulSet
그리고 한 문장으로 정리하면:
RedisShake를 K8s Pod로 실행하고, Source Redis에서 데이터를 읽어 Target Redis로 전달한다. Redis 자체는 StatefulSet/Pod/PVC로 운영되고, RedisShake는 이 Redis들을 연결하는 Migration 도구 역할을 한다.
공식 문서 기준으로 실제 Migration에서는 PSync가 가능한 경우 sync_reader를 우선 권장하며, RedisShake가 Source에서 RDB 전체 데이터 + 이후 AOF 증분 스트림을 받아 Target으로 전달하는 방식입니다. (tair-opensource.github.io)
🔜 다음 2단계
다음은 바로 **「K8s에서 Redis가 실제로 어떻게 구성되는가」**를 먼저 보는 게 좋습니다.
StatefulSet
↓
redis-0 / redis-1 / redis-2
↓
PVC 각각 사용
↓
Service
↓
Headless Service
↓
Master / Replica / Sentinel / Cluster
특히 왜 Redis Pod들이 하나의 PVC를 공유하면 안 되는지, ClusterIP Service와 Headless Service가 왜 둘 다 필요한지, RedisShake는 어느 Service로 붙어야 하는지까지 2단계에서 아주 쉽게 연결해서 설명하면 이후 RedisShake 구조가 훨씬 잘 이해됩니다.
'J-H-T > Redis' 카테고리의 다른 글
| [참고] Kubernetes에서 Redis Cluster 구성 이해하기 🚀 (0) | 2026.08.13 |
|---|
댓글