[Ep.35] [Argo CD 운영 최적화 #5] Argo CD와 Progressive Delivery(점진적 배포) 전략

🔹 Progressive Delivery란?

Progressive Delivery(점진적 배포) 는 새로운 기능을 배포할 때 트래픽을 점진적으로 이동시키면서 안전성을 보장하는 배포 전략입니다.
Argo CD와 Argo Rollouts를 함께 사용하면 Canary 배포, A/B 테스트, Feature Flag를 활용한 점진적 배포가 가능합니다.

 

✅ Progressive Delivery가 필요한 이유

 

✔ 신규 버전을 점진적으로 배포하여 서비스 안정성 보장
✔ 실제 사용자 피드백을 받아 기능을 점진적으로 활성화
✔ 배포 중 오류 발생 시 빠르게 롤백 가능
✔ Blue-Green, Canary, A/B 테스트 등 다양한 배포 전략 적용 가능

 

✅ Argo CD와 Progressive Delivery 연계 방식

전략	설명
Canary 배포	새로운 버전의 트래픽을 점진적으로 증가시키면서 모니터링
A/B 테스트	서로 다른 버전의 애플리케이션을 특정 사용자 그룹에 배포
Feature Flag	특정 기능을 단계적으로 활성화하여 배포 영향 최소화

---

🔹 1. Argo CD에서 Canary 배포를 활용한 Progressive Delivery

Argo Rollouts를 활용하여 Canary 배포를 점진적으로 진행하면서 모니터링할 수 있습니다.

✅ Canary 배포를 적용한 Rollout 예제

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-canary
  namespace: example
spec:
  replicas: 3
  strategy:
    canary:
      steps:
        - setWeight: 10  # 신규 버전에 10% 트래픽 할당
        - pause: {duration: 1m}  # 1분 대기 후 다음 단계 진행
        - setWeight: 50  # 신규 버전에 50% 트래픽 할당
        - pause: {}  # 수동 승격 필요

  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: example
          image: ghcr.io/example/app:v2
          ports:
            - containerPort: 80

 

✅ 설명:
✔ setWeight: 10 → 초기 Canary 트래픽 10% 할당
✔ pause: {duration: 1m} → 1분 동안 상태 모니터링 후 다음 단계 진행
✔ setWeight: 50 → 50% 트래픽을 Canary 버전에 할당
✔ pause: {} → 사용자가 직접 승격할 때까지 대기 (자동 전환 X)

 

✅ 배포 진행 상태 확인

kubectl argo rollouts get rollout example-canary -n example

 

✅ 출력 예시:

NAME             STRATEGY   STATUS        STEP
example-canary   Canary     Progressing   2/4

 

✅ 수동으로 승격하여 100% 전환

kubectl argo rollouts promote example-canary -n example

 

✅ 롤백(기존 버전으로 복구)

kubectl argo rollouts undo example-canary -n example

---

🔹 2. Argo CD에서 A/B 테스트를 활용한 Progressive Delivery

A/B 테스트 배포는 사용자 그룹에 따라 서로 다른 버전의 애플리케이션을 제공하는 방식입니다.
Argo CD와 Service Mesh(Istio, Linkerd)를 연동하면 트래픽을 특정 버전으로 라우팅할 수 있습니다.

✅ Istio를 활용한 A/B 테스트 예제

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-ab-test
  namespace: example
spec:
  hosts:
    - example.com
  http:
    - match:
        - headers:
            user-agent:
              regex: ".*Chrome.*"  # 크롬 브라우저 사용자에게 Canary 버전 제공
      route:
        - destination:
            host: example-app
            subset: canary
    - route:
        - destination:
            host: example-app
            subset: stable

 

✅ 설명:
✔ headers.user-agent.regex: ".*Chrome.*" → Chrome 브라우저 사용자에게 Canary 버전 제공
✔ route.destination.subset: canary → 일부 사용자만 Canary 버전을 사용하도록 설정
✔ route.destination.subset: stable → 나머지 사용자는 기존 Stable 버전 사용

 

✅ Istio의 DestinationRule 설정 예제

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: example-app
  namespace: example
spec:
  host: example-app
  subsets:
    - name: stable
      labels:
        version: v1
    - name: canary
      labels:
        version: v2

 

✅ 설명:
✔ subsets.name: stable → 기존 버전(v1)과 Canary 버전(v2)을 분리하여 관리
✔ 특정 사용자 그룹에만 새로운 기능을 제공 가능

 

✅ A/B 테스트 배포 적용 후 트래픽 분배 확인

kubectl get virtualservice -n example

---

🔹 3. Feature Flag를 활용한 Progressive Delivery

Feature Flag를 사용하면 애플리케이션 코드 배포 후 특정 기능을 점진적으로 활성화할 수 있습니다.

 

✅ Feature Flag를 적용한 애플리케이션 설정 예제

apiVersion: v1
kind: ConfigMap
metadata:
  name: feature-flags
  namespace: example
data:
  FEATURE_NEW_UI: "true"  # 신규 UI 기능 활성화
  FEATURE_EXPERIMENTAL: "false"  # 실험 기능 비활성화

 

✅ 설명:
✔ FEATURE_NEW_UI: "true" → 새로운 UI 기능 활성화
✔ FEATURE_EXPERIMENTAL: "false" → 실험적인 기능은 비활성화

 

✅ ConfigMap을 애플리케이션에 주입하여 Feature Flag 적용

env:
  - name: FEATURE_NEW_UI
    valueFrom:
      configMapKeyRef:
        name: feature-flags
        key: FEATURE_NEW_UI

 

✅ Feature Flag 변경 후 Argo CD에서 자동 동기화

kubectl edit configmap feature-flags -n example

 

✅ 새로운 기능이 활성화되었는지 확인

kubectl get configmap feature-flags -n example -o yaml

---

🔹 4. Progressive Delivery 운영 시 고려할 점

✅ 1️⃣ Canary 배포 시 모니터링 필수
✔ 신규 버전의 성능 및 오류를 모니터링하여 자동 롤백 설정 필요

 

✅ 2️⃣ A/B 테스트의 사용자 그룹 정의
✔ Istio, Linkerd 등의 서비스 메쉬를 활용하여 사용자 그룹을 세분화 가능

 

✅ 3️⃣ Feature Flag 적용 후 롤백 가능하도록 구성
✔ ConfigMap 변경 시 이전 상태로 복구할 수 있도록 GitOps 방식으로 관리

---

🔹 결론: 이번 글에서 배운 핵심 내용 정리

🟢 Argo Rollouts를 활용하면 Canary 배포를 통해 점진적인 배포가 가능
🟢 A/B 테스트를 적용하면 특정 사용자 그룹에게만 새로운 기능을 제공 가능
🟢 Feature Flag를 사용하면 코드 배포 후 특정 기능을 동적으로 활성화 가능
🟢 Argo CD와 Progressive Delivery를 결합하면 안정적이고 유연한 배포 전략을 운영할 수 있음