Argo Rollouts - 배포 전략

 

🌊 Blue-Green Deployment Strategy

• Blue-Green Deployment는 애플리케이션 배포 중 발생할 수 있는 Downtime을 최소화하고, 안정적인 버전 전환을 가능하게 하는 강력한 배포 전략입니다. 

---

🚀 Overview

https://www.allwin-solutions.com/post/how-to-do-a-zero-downtime-deployment-using-azure-kubernetes-service

• Blue-Green Deployment는 두 가지 버전의 애플리케이션을 동시에 관리합니다.
  • Active Service(Blue): 현재 사용자 트래픽을 받고 있는 기존 버전
  • Preview Service(Green): 새롭게 배포될 버전
• Rollout Controller는 ReplicaSet을 관리하는 동시에 Service의 selector를 조정해 트래픽을 두 버전 사이에서 안전하게 전환합니다.
• 즉, Rollout이 새 ReplicaSet을 생성하면,
  • 기존 Active Service는 이전 버전(Blue)에 연결되어 있고,
  • Preview Service는 새로운 버전(Green)에 트래픽을 보냅니다.
    새 버전이 정상적으로 준비되면 Active Service를 새 ReplicaSet으로 변경하고 일정 시간(scaleDownDelaySeconds)이 지난 후 이전 ReplicaSet을 정리합니다.

“Blue-Green Deployment는 서비스 중단 없이 애플리케이션 버전을 교체할 수 있는 전략이다.”

---

⚠️ 주의사항 (Important Notes)

1. Service Selector Propagation Delay
   Service의 selector가 변경되면, 각 Node의 IP table이 업데이트되는 데 약간의 시간이 필요합니다.
   이 시간 동안은 여전히 일부 트래픽이 이전 Pod으로 향할 수 있습니다.
   이를 방지하기 위해 scaleDownDelaySeconds 옵션으로 일정 지연시간을 두어 안정적인 전환을 보장합니다.
2. ALB Ingress 제한사항
   AWS ALB를 사용하는 경우, ALB Controller가 Target Group을 원자적(Atomic) 으로 업데이트하지 않습니다.
   이로 인해 일시적으로 Target Group에 등록된 Healthy Pod이 없게 되어, 잠깐의 Downtime이 발생할 수 있습니다.

“ALB Ingress 환경에서는 Blue-Green Deployment가 완전한 무중단을 보장하지 않는다.”

---

🧩 Example: Rollout Manifest

• 다음은 Argo Rollouts에서 Blue-Green 전략을 사용하는 기본 예시입니다.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen: 
      activeService: rollout-bluegreen-active
      previewService: rollout-bluegreen-preview
      autoPromotionEnabled: false

• activeService는 실제 트래픽을 받는 서비스,
• previewService는 새로운 버전 테스트용,
• autoPromotionEnabled: false는 자동 전환을 비활성화하여 수동 승인을 가능하게 합니다.

“Preview → Active 전환은 자동 또는 수동으로 제어할 수 있다.”

---

🔁 Sequence of Events (배포 흐름)

Blue-Green Deployment의 배포 순서는 다음과 같습니다:

1. 기본 상태
   Revision 1 ReplicaSet이 Active/Preview Service 모두에 연결되어 있음
2. 업데이트 시작
   .spec.template 변경 → 새로운 Revision 2 ReplicaSet 생성
3. Preview Service 업데이트
   Preview Service는 Revision 2 ReplicaSet으로 트래픽을 전환
4. Preview ReplicaSet 확장
   지정된 replicas 또는 previewReplicaCount 만큼 스케일 업
5. PrePromotion Analysis 수행
   트래픽 전환 전 사전 검증 수행
6. 프로모션 대기 또는 자동 전환
   autoPromotionEnabled가 false이면 대기, autoPromotionSeconds 설정 시 자동 전환
7. Active Service 전환
   Active Service가 Revision 2로 전환되며, 실제 트래픽이 이동
8. PostPromotion Analysis 수행
   트래픽 전환 후 검증 수행
9. Scale Down Delay 후 정리
   scaleDownDelaySeconds 후 이전 ReplicaSet 정리

“Blue-Green은 Preview → Active → ScaleDown의 명확한 단계를 거쳐 안전하게 전환된다.”

---

⚙️ Configurable Features (설정 가능한 옵션들)

Blue-Green 전략에서 유용하게 사용할 수 있는 주요 옵션들은 다음과 같습니다:

🔸 autoPromotionEnabled

• 새로운 ReplicaSet이 완전히 준비되면 자동으로 Active Service로 전환할지 결정합니다.
• 기본값: true

“자동 프로모션을 끄면 사용자가 직접 승인할 수 있다.”

---

⏱️ autoPromotionSeconds

• 프로모션 대기 후 자동으로 전환되기까지의 지연 시간(초 단위)
• autoPromotionEnabled가 false일 때는 무시됩니다.

“자동 프로모션 대기 시간을 설정할 수 있다.”

---

🧱 antiAffinity

• 새 버전과 이전 버전의 Pod이 동일한 노드에 배치되지 않도록 하는 설정입니다.
• 기본값: nil

“Pod 간 충돌을 피하기 위해 antiAffinity를 설정할 수 있다.”

---

🧪 prePromotionAnalysis

• 트래픽 전환 전 실행되는 사전 검증(AnalysisRun) 입니다.
• 실패 시 전환이 중단되고 Rollout이 중지됩니다.
• 기본값: nil

“prePromotionAnalysis는 안정적인 전환을 위한 필수 검증 단계다.”

---

🧾 postPromotionAnalysis

• 트래픽 전환 후 실행되는 사후 검증(AnalysisRun) 입니다.
• 실패 시 Rollout이 이전 버전으로 롤백됩니다.
• 기본값: nil

“postPromotionAnalysis 실패 시 즉시 롤백이 수행된다.”

---

🔍 previewService

• 새로운 ReplicaSet에 트래픽을 보내는 테스트용 Service
• 기본값: "" (없음)

“Preview Service를 통해 실제 트래픽 전 전용 테스트 환경을 확보할 수 있다.”

---

🧩 previewReplicaCount

• 테스트 중 실행할 Replica 수를 지정
• 기본값: spec.replicas (전체 복제 수)

“리소스를 절약하기 위해 Preview Replica 수를 제한할 수 있다.”

---

⏳ scaleDownDelaySeconds

• Active Service 전환 후 이전 ReplicaSet을 정리하기까지의 대기 시간
• 기본값: 30

“scaleDownDelaySeconds는 트래픽 전환 안정성을 높이기 위한 지연 설정이다.”

---

🧮 scaleDownDelayRevisionLimit

• 동시에 유지할 수 있는 이전 ReplicaSet의 개수를 제한
• 기본값: 전체 ReplicaSet 유지

“이전 버전이 너무 많이 남지 않도록 제한할 수 있다.”

---

📌 핵심 요약

• Blue-Green Deployment는 Downtime 없는 배포를 가능하게 하는 전략
• Active Service는 현재 운영 버전, Preview Service는 테스트 버전
• Rollout Controller가 Service selector를 조정해 안전하게 전환
• autoPromotionEnabled와 autoPromotionSeconds로 전환 시점 제어
• pre/post Promotion Analysis로 안정성 검증 가능
• scaleDownDelaySeconds로 네트워크 전환 지연에 대응
• ALB Ingress 환경에서는 완전한 무중단이 어려움

“Blue-Green Deployment는 트래픽 전환의 위험을 최소화하면서도 배포 효율성을 극대화하는 전략이다.”

 

---

🐤 Canary Deployment Strategy

• Canary Deployment은 새로운 버전을 전체 서비스에 적용하기 전에 일부 트래픽에만 먼저 배포하는 전략입니다. 이를 통해 새로운 버전의 안정성을 검증하고, 문제가 발생할 경우 빠르게 롤백할 수 있습니다. Kubernetes 환경에서는 Argo Rollouts를 활용해 Canary Deployment를 손쉽게 구현할 수 있습니다.
• "Canary Deployment는 작은 비율로 배포하여 위험을 최소화하는 전략입니다."

---

⚙️ Overview

https://www.allwin-solutions.com/post/how-to-do-a-zero-downtime-deployment-using-azure-kubernetes-service

• Canary Deployment에는 공식적인 표준이 없기 때문에, Rollouts Controller가 사용자가 정의한 steps를 기반으로 배포를 진행합니다.
• 사용자는 .spec.template 변경 시 새로운 ReplicaSet을 어떻게 진행할지 단계별로 정의할 수 있습니다.
• 각 단계(step)는 다음 ReplicaSet이 stable 버전으로 승격되기 전에 평가됩니다.

기본 Step

1. setWeight: Canary에 할당할 트래픽 비율을 설정합니다.
2. pause: 배포를 일시 중단합니다.
   • duration이 설정되면 해당 시간만큼 자동으로 대기합니다.
   • 설정이 없으면 수동으로 promote 명령을 통해 다음 단계로 진행해야 합니다.

"setWeight와 pause를 이용하면 배포 진행을 선언적으로 정의할 수 있습니다."

예제

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-rollout
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.15.4
          ports:
            - containerPort: 80
  minReadySeconds: 30
  revisionHistoryLimit: 3
  strategy:
    canary:
      maxSurge: '25%'
      maxUnavailable: 0
      steps:
        - setWeight: 10
        - pause:
            duration: 1h
        - setWeight: 20
        - pause: {}

---

⏸️ Pause Duration

• Pause 단계에서는 시간을 지정할 수 있습니다.
• 유효한 단위: s (초), m (분), h (시간). 기본값은 초(s)입니다.

spec:
  strategy:
    canary:
      steps:
        - pause: { duration: 10 }   # 10초
        - pause: { duration: 10s }  # 10초
        - pause: { duration: 10m }  # 10분
        - pause: { duration: 10h }  # 10시간
        - pause: {}                  # 무기한

• 무기한 pause를 해제하려면 kubectl argo rollouts promote <rollout> 명령을 사용합니다.

"Pause duration은 배포 진행을 유연하게 제어할 수 있는 중요한 옵션입니다."

---

📈 Dynamic Canary Scale (with Traffic Routing)

• 기본적으로 Canary ReplicaSet은 setWeight에 따라 자동으로 scale 됩니다.
• 그러나 트래픽을 노출하지 않고 테스트용으로 Canary를 확장하거나, 일부 트래픽만 분리하고 싶은 경우 setCanaryScale을 사용합니다.

setCanaryScale 옵션

1. replicas: 명시적인 복제 수 설정
2. weight: 전체 spec.replicas 대비 비율
3. matchTrafficWeight: setWeight에 맞춰 Canary scale 조정

spec:
  strategy:
    canary:
      steps:
        - setCanaryScale:
            replicas: 3
        - setCanaryScale:
            weight: 25
        - setCanaryScale:
            matchTrafficWeight: true

"setCanaryScale는 Canary replica 수를 유연하게 조정할 수 있는 기능입니다."

 

⚠️ 주의: setCanaryScale과 setWeight를 잘못 조합하면 트래픽 불균형이 발생할 수 있습니다.

---

🔄 Dynamic Stable Scale (with Traffic Routing)

• 기본적으로 stable ReplicaSet은 업데이트 동안 100% scale로 유지됩니다.
• 자원 비용이 큰 경우 dynamicStableScale: true를 설정하여 트래픽 비율에 따라 stable ReplicaSet을 동적으로 줄일 수 있습니다.

spec:
  strategy:
    canary:
      dynamicStableScale: true
      abortScaleDownDelaySeconds: 600

"dynamicStableScale을 통해 자원 낭비를 줄이면서 안정적인 Canary 배포가 가능합니다."

---

🔹 Mimicking Rolling Update

• steps를 생략하면 Canary 전략이 Rolling Update와 유사하게 동작합니다.
• maxSurge와 maxUnavailable을 활용해 배포 진행 방식을 조정할 수 있습니다.

"steps를 생략하면 Canary가 Rolling Update처럼 동작합니다."

---

⚙️ Other Configurable Features

필드 설명 기본값

analysis	배포 중 background analysis 수행, 실패 시 롤아웃 abort	nil
antiAffinity	Pod anti-affinity 설정	nil
canaryService	Canary ReplicaSet만 트래픽 라우팅	""
stableService	Stable ReplicaSet만 트래픽 라우팅	""
maxSurge	최대 추가 Replica 수	"25%"
maxUnavailable	업데이트 중 불가용 Pod 최대 수	25%
trafficRouting	트래픽 라우팅 규칙 설정	weighted pod replica

"Canary 전략은 다양한 옵션으로 배포 세부 동작을 세밀하게 제어할 수 있습니다."

---

📌 핵심 요약

• Canary Deployment는 새로운 버전을 소규모 트래픽에 먼저 배포해 안정성을 검증하는 전략입니다.
• setWeight와 pause를 통해 트래픽 분할과 배포 단계 조정 가능
• setCanaryScale로 Canary replica 수를 유연하게 제어 가능
• dynamicStableScale을 사용하면 리소스 낭비를 최소화하면서 안정적인 배포 가능
• Steps를 생략하면 Rolling Update와 유사한 동작
• 다양한 옵션(analysis, antiAffinity, canaryService, stableService, trafficRouting)을 통해 배포를 세밀하게 제어 가능

"Canary Deployment는 점진적 배포를 통해 위험을 최소화하고 안정성을 극대화하는 전략입니다."