1️⃣ 개요
실제 운영 환경에서 새로운 애플리케이션 버전이 예상과 다르게 동작할 가능성이 있습니다.
특히, 새로운 버전이 기존 시스템과 잘 동작하는지 검증하는 것이 중요하지만, Canary나 Blue-Green 방식으로 배포하더라도 실제 사용자 요청을 받으면서 테스트하기에는 위험이 따릅니다.
이때 활용할 수 있는 배포 전략이 Shadow Deployment(섀도우 배포) 입니다.
Shadow Deployment는 실제 트래픽을 복제하여 새로운 버전에 전달하면서도, 사용자의 응답에는 영향을 주지 않는 방식입니다.
이를 통해 실제 트래픽을 기반으로 새로운 버전을 검증할 수 있으며, 문제 발생 시 서비스에 영향을 주지 않고 분석할 수 있습니다.
이번 글에서는 Shadow Deployment의 개념과, 쿠버네티스 환경에서 트래픽 미러링을 활용하여 적용하는 방법을 설명하겠습니다. 🚀
2️⃣ Shadow Deployment란?
✅ 1. Shadow Deployment의 개념
• 운영 중인 애플리케이션(Stable 버전)으로 정상적으로 트래픽을 전달하면서, 동일한 트래픽을 새로운 버전(Shadow 버전)에도 복제하여 전달
• 새로운 버전이 실제 환경에서 어떻게 동작하는지 미리 테스트 가능
• Shadow 버전에서 발생하는 오류나 성능 이슈를 감지할 수 있음
• 사용자 응답에는 영향을 주지 않으므로 안전한 테스트가 가능
📌 Shadow Deployment vs Canary Deployment vs Blue-Green 비교
| 특징 | Shadow Deployment | Canary Deployment | Blue-Green Deployment |
| 배포 방식 | 실제 트래픽을 복제하여 테스트 | 일부 트래픽에만 새로운 버전 배포 | 기존 버전과 새로운 버전을 동시에 운영 후 트래픽 전환 |
| 서비스 응답 영향 | 🚫 없음 | ✅ 있음 | ✅ 있음 |
| 실제 데이터 기반 테스트 | ✅ 가능 | ✅ 가능 (일부 트래픽만) | 🚫 없음 (트래픽 전환 후 확인 가능) |
| 롤백 용이성 | 🚫 필요 없음 (테스트 목적) | ✅ 트래픽 비율만 조정 | ✅ 기존 버전으로 즉시 전환 가능 |
✅ Shadow Deployment는 새로운 버전을 실사용 트래픽으로 테스트하면서도, 사용자 응답에는 영향을 주지 않는 방식입니다.
3️⃣ Shadow Deployment 적용 방법
Shadow Deployment는 트래픽을 복제하여 두 개의 버전(Stable & Shadow)에 동시에 전달하는 방식으로 구현됩니다.
이를 위해 Service 및 Ingress에서 트래픽 미러링(Mirroring)을 활용합니다.
✅ 1. Stable Deployment (운영 중인 버전) 생성
먼저, 기존 운영 버전(Stable)을 배포합니다.
📌 Stable Deployment YAML (기존 버전, nginx:1.0)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-stable
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: stable
template:
metadata:
labels:
app: my-app
version: stable
spec:
containers:
- name: my-container
image: nginx:1.0
📌 Stable Deployment 배포
kubectl apply -f stable-deployment.yaml✅ 이제 Stable 버전이 운영 환경에서 실행 중입니다.
✅ 2. Shadow Deployment (새로운 버전) 생성
새로운 버전(Shadow)을 Stable과는 별도로 배포합니다.
📌 Shadow Deployment YAML (새로운 버전, nginx:1.1)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-shadow
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: shadow
template:
metadata:
labels:
app: my-app
version: shadow
spec:
containers:
- name: my-container
image: nginx:1.1📌 Shadow Deployment 배포
kubectl apply -f shadow-deployment.yaml✅ 이제 Stable 버전과 Shadow 버전이 동시에 운영됩니다.
✅ 3. 트래픽 미러링을 활용한 Shadow Deployment 적용
이제 Service를 통해 Stable 버전은 정상적으로 요청을 처리하고, 동일한 트래픽을 Shadow 버전에도 복제합니다.
📌 Service를 활용한 트래픽 미러링 (Stable → Shadow 트래픽 복제)
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
version: stable # 기존 Stable 버전과 연결
ports:
- protocol: TCP
port: 80
targetPort: 80
sessionAffinity: None
📌 Ingress를 활용하여 Shadow 트래픽 미러링 설정 (Istio 사용 시 적용 가능)
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app
spec:
hosts:
- my-app.example.com
http:
- route:
- destination:
host: my-app-service
subset: stable # Stable 버전으로 트래픽 전달
mirror:
host: my-app-service
subset: shadow # Shadow 버전에도 동일한 트래픽 복제
mirrorPercentage: 100.0 # 모든 트래픽을 Shadow에도 복제
📌 Ingress 적용
kubectl apply -f ingress-shadow.yaml✅ 이제 Stable 버전과 Shadow 버전이 동일한 요청을 받지만, Shadow 버전의 응답은 실제 사용자에게 반환되지 않습니다.
4️⃣ Shadow Deployment 테스트 및 모니터링
✅ 1. Shadow 버전 Pod 로그 확인
📌 Stable 버전 Pod 로그 확인
kubectl logs -l version=stable
📌 Shadow 버전 Pod 로그 확인
kubectl logs -l version=shadow✅ 두 버전의 로그를 비교하여 새로운 버전이 정상적으로 동작하는지 확인할 수 있습니다.
✅ 2. 트래픽 분석을 위한 모니터링 설정
• Shadow 버전이 예상대로 동작하는지 분석하기 위해 Prometheus, Grafana, ELK 스택 등을 활용
• Shadow 버전에서 발생하는 에러율 및 성능 비교
📌 Shadow 버전 Pod 상태 확인
kubectl get pods -l version=shadow✅ 트래픽이 정상적으로 Shadow 버전에 복제되고 있는지 반드시 모니터링해야 합니다.
🔥 5️⃣ 결론
✔ Shadow Deployment는 실제 운영 트래픽을 복제하여 새로운 버전을 안전하게 테스트할 수 있는 배포 전략
✔ Stable 버전과 Shadow 버전을 동시에 운영하며, 트래픽 미러링을 활용하여 검증 가능
✔ Shadow 버전의 응답은 사용자에게 반환되지 않으므로, 장애 발생 시에도 서비스에는 영향 없음
✔ Ingress 또는 Service 설정을 활용하여 트래픽 미러링을 적용 가능
✔ 배포 후 반드시 모니터링을 수행하여 새로운 버전의 성능 및 안정성을 분석해야 함