Canary
카나리 배포
일부 사용자에게만 새 버전을 배포하는 전략. 문제 발생 시 영향 최소화.
카나리 배포
일부 사용자에게만 새 버전을 배포하는 전략. 문제 발생 시 영향 최소화.
카나리 배포는 새 버전을 소수의 사용자에게 먼저 배포하여 문제를 조기에 발견하는 점진적 배포 전략입니다. 이름은 광산에서 유독가스를 감지하기 위해 카나리아 새를 사용한 것에서 유래했습니다.
전체 트래픽의 일부(예: 1~5%)만 새 버전으로 보내고, 에러율, 지연시간, 비즈니스 메트릭을 모니터링합니다. 문제가 없으면 트래픽 비율을 점진적으로 늘려 최종적으로 100% 전환합니다. 문제 발생 시 즉시 트래픽을 이전 버전으로 돌립니다.
Kubernetes 환경에서는 Argo Rollouts, Flagger, Istio 등으로 구현합니다. 트래픽 분배, 메트릭 분석, 자동 롤백까지 자동화할 수 있습니다. 클라우드 서비스에서는 AWS App Mesh, GCP Traffic Director 등을 활용합니다.
실무에서는 카나리 배포와 함께 피처 플래그를 사용하여 더 세밀한 제어를 합니다. 특정 사용자 그룹(베타 테스터, 내부 직원)에게만 새 기능을 노출하고, 메트릭 기반 자동 승격(Promotion)으로 운영 부담을 줄입니다.
# Argo Rollouts - 카나리 배포 설정
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
replicas: 10
strategy:
canary:
# 카나리 단계 정의
steps:
- setWeight: 5 # 5% 트래픽
- pause: {duration: 5m}
- setWeight: 20 # 20% 트래픽
- pause: {duration: 5m}
- setWeight: 50 # 50% 트래픽
- pause: {duration: 10m}
# 이후 100%로 자동 전환
# 자동 분석 (Prometheus 메트릭 기반)
analysis:
templates:
- templateName: success-rate
startingStep: 1
args:
- name: service-name
value: my-app
# 트래픽 라우팅 (Istio/Nginx 연동)
trafficRouting:
istio:
virtualService:
name: my-app-vsvc
routes:
- primary
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: myregistry/my-app:v2.0.0
시니어: "지난 장애 때 롤백까지 30분 걸렸잖아요. 카나리 배포하면 5% 트래픽에서 문제 발견되니까 영향 범위가 훨씬 작아져요."
주니어: "모니터링 메트릭은 뭘 봐야 하나요?"
시니어: "에러율, p99 레이턴시, 그리고 비즈니스 메트릭(전환율, 결제 성공률 등)이요. Argo Rollouts로 자동 분석해서 실패하면 자동 롤백되도록 설정해요."
면접관: "카나리 배포에서 트래픽 분배는 어떻게 구현하나요?"
지원자: "여러 방법이 있습니다. Kubernetes에서는 Replica 비율로 간단히 할 수 있고, Istio VirtualService의 weight로 정밀 제어가 가능합니다. 로드밸런서의 가중치 라우팅이나 CDN의 A/B 테스팅 기능도 활용합니다."
리뷰어: "분석 단계에서 success-rate만 보는데, latency-p99도 추가하면 성능 저하도 감지할 수 있어요."
개발자: "좋은 지적이에요. 복합 메트릭으로 분석하도록 AnalysisTemplate 수정하겠습니다."