🚀 Argo Rollouts 배포 전략 완벽 가이드: 무중단 배포의 모든 것

쿠버네티스 환경에서 서비스를 중단 없이, 그리고 안전하게 배포하는 것은 모든 엔지니어의 꿈이죠. 오늘은 그 꿈을 현실로 만들어주는 강력한 도구, Argo Rollouts의 핵심 전략들을 아주 깊이 있게 파헤쳐 보겠습니다.

단순한 이론을 넘어 실무에서 어떤 전략을 선택해야 할지 가이드라인까지 준비했으니, 10분만 집중해 주세요! 🚀

 

쿠버네티스 기본 Deployment 리소스는 'RollingUpdate'라는 훌륭한 기능을 제공하지만, 트래픽 제어나 세밀한 검증에는 한계가 있습니다. Argo Rollouts는 이를 보완하여 대규모 서비스에서도 안심하고 배포할 수 있는 다양한 전략을 제공합니다.

---

1. Blue-Green 배포: 완벽한 전환과 즉각적인 롤백 🔵🟢

블루-그린 배포는 구버전(Blue)과 신버전(Green) 환경을 동시에 띄워두고, 트래픽을 한 번에 전환하는 방식입니다.

• 동작 방식: 새로운 버전이 모두 준비되면 서비스(Service)의 Selector를 업데이트하여 트래픽을 Green으로 돌립니다.
• 장점: 롤백이 매우 빠릅니다(Selector만 다시 돌리면 됨).
• 단점: 리소스가 일시적으로 두 배로 필요합니다.

📝 Blue-Green 실전 코드

YAML

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 4
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
  strategy:
    blueGreen: 
      # 신버전으로 트래픽을 넘기기 전 활성화될 서비스 이름
      activeService: rollout-bluegreen-active
      # 신버전이 생성될 때 연결될 미리보기 서비스
      previewService: rollout-bluegreen-preview
      # 배포 후 수동 승인을 기다릴지 여부 (자동화 가능)
      autoPromotionEnabled: false

---

2. Canary 배포: 위험을 최소화하는 점진적 배포 🐤

카나리 배포는 광산의 카나리아처럼, 새로운 버전을 일부 사용자에게만 먼저 노출하여 안정성을 검증한 뒤 점진적으로 확대하는 방식입니다.

• 동작 방식: 10% -> 30% -> 50% -> 100% 식으로 트래픽 비중을 높입니다.
• 장점: 잠재적인 버그가 전체 사용자에게 영향을 주는 것을 방지합니다.
• 단점: 배포 프로세스가 길어질 수 있습니다.

📝 Canary 실전 코드 (기본 단계 설정)

YAML

 

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-canary
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10 # 10%의 트래픽만 신버전으로 보냄
      - pause: {duration: 1h} # 1시간 동안 관찰하며 대기
      - setWeight: 30 # 문제 없으면 30%로 확대
      - pause: {} # 사용자가 직접 승인할 때까지 무한 대기 (Manual Pause)
      - setWeight: 70
      - pause: {duration: 10m}

---

3. Advanced Canary: Service Mesh 연동 전략 🌐

기본 카나리는 '복제본(Replica) 수'로 트래픽을 조절하지만, Istio나 Linkerd, Nginx Ingress를 사용하면 훨씬 정교한 제어가 가능합니다.

• 특징: 단 1개의 신버전 파드만 띄우고도 가상 서비스(Virtual Service)를 통해 정확히 1%의 트래픽만 보낼 수 있습니다.
• 헤더 기반 라우팅: 특정 헤더(debug=true)를 가진 요청이나 특정 지역의 사용자만 신버전을 보게 할 수 있습니다.

📝 Istio 연동 예시

YAML

  strategy:
    canary:
      trafficRouting:
        istio:
          virtualService:
            name: my-vsvc # 이스티오 가상 서비스 이름
            routes:
            - primary # 메인 루트 설정
      steps:
      - setWeight: 5 # 단 5%만 이스티오 레벨에서 조정
      - pause: {duration: 10m}

---

4. Progressive Delivery: 분석(Analysis) 기반의 자동 배포 📈

단순히 시간만 기다리는 게 아니라, 메트릭을 보고 배포 진행 여부를 결정하는 것을 Progressive Delivery라고 합니다.

• 동작: Prometheus에서 에러율(Error Rate)을 조회하여 5% 이상이면 자동으로 롤백하고, 정상이면 다음 단계로 승격(Promote)합니다.

📝 Analysis 연동 코드

YAML

  strategy:
    canary:
      analysis:
        templates:
        - templateName: success-rate-check # 미리 정의된 분석 템플릿 참조
        startingStep: 1 # 두 번째 단계(index 1)부터 분석 시작
      steps:
      - setWeight: 20
      - pause: {duration: 5m}

---

5. 어떤 전략을 선택해야 할까요? 🎯

상황	추천 전략	이유
빠른 롤백이 최우선	Blue-Green	Selector만 바꾸면 즉시 복구됨
사용자 영향을 최소화하고 싶을 때	Canary	일부에게만 노출하여 리스크 분산
리소스(CPU/MEM)가 부족할 때	Canary	점진적으로 교체하므로 여유 자원이 적어도 가능
데이터 정합성이 매우 중요할 때	Blue-Green	두 버전이 섞여서 요청을 받는 기간이 없음
자동화된 안정성 검증이 필요할 때	Progressive	메트릭 기반 자동 롤백으로 야간 배포도 안심

---

🏁 마치며

Argo Rollouts는 쿠버네티스 배포를 단순한 '교체'에서 '전략적 운영'으로 격상시킵니다. 처음에는 단순한 Canary부터 시작해서, 점차 Analysis를 도입하여 사람의 개입 없는 완전 자동화된 안전 배포 시스템을 구축해 보시는 것을 추천합니다.

여러분의 환경에는 어떤 전략이 가장 매력적인가요? 🛠️