[DevOps] Argo Rollouts

1. 개요

Argo Rollouts는 Kubernetes 환경에서 고급 배포 전략을 구현할 수 있는 컨트롤러입니다.

기존 Kubernetes Deployment 컨트롤러는 기본적인 RollingUpdate 전략만 제공하지만,

Argo Rollouts를 통해서는 블루-그린 배포, 카나리 배포, 프로그레시브 딜리버리와 같은 현대적인 배포 전략을 Kubernetes 환경에 적용할 수 있습니다. 또한, 자동 롤백, 트래픽 제어, 비즈니스 메트릭 기반 배포 분석 등을 지원하여 안정적인 배포 프로세스를 구현할 수 있습니다.

---

2. 기존 쿠버네티스 배포의 한계점

기존 Kubernetes의 Deployment는 RollingUpdate 전략을 사용하여 배포를 처리하지만, 다음과 같은 한계가 존재합니다:

• 트래픽 제어의 한계: 새로운 버전으로 트래픽을 점진적으로 전환하는 기능이 부족합니다.
• 새 버전으로의 점진적 트래픽 전환 불가: 모든 트래픽을 한 번에 새로운 버전으로 전환해야 하므로, 트래픽 제어가 어려운 상황이 발생할 수 있습니다.
• 특정 사용자 그룹에 대한 타겟팅 불가: 특정 사용자에게만 새로운 버전을 배포하는 기능이 부족합니다.
• 배포 안정성 검증의 어려움: 기본적인 readiness probe만으로는 배포의 안정성을 충분히 검증하기 어렵습니다.
• 비즈니스 메트릭 기반 검증 불가: 트래픽 전환의 성공 여부를 비즈니스 메트릭에 기반하여 검증할 수 없습니다.
• 자동 롤백 메커니즘 부재: 배포 실패 시, 수동으로 롤백을 해야 하며, 자동화된 롤백 메커니즘이 없습니다.
• 고급 배포 전략 미지원: RollingUpdate 외의 배포 전략(블루-그린, 카나리 배포 등)을 지원하지 않습니다.
• A/B 테스팅 불가: 여러 버전 간의 비교 테스트를 위한 A/B 테스팅을 지원하지 않습니다.

Argo Rollouts는 이러한 한계를 극복할 수 있는 여러 기능을 제공합니다.

---

3. Argo Rollouts 주요 기능

1. 블루-그린 배포 전략

블루-그린 배포는 새로운 버전을 완전히 배포한 후, 트래픽을 전환하는 방식으로 배포합니다. 기존 버전과 새 버전이 동시에 실행되며, 트래픽은 새 버전으로 안전하게 전환됩니다.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 3
  strategy:
    blueGreen: 
      activeService: rollout-bluegreen-active
      previewService: rollout-bluegreen-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
        - templateName: success-rate
      scaleDownDelaySeconds: 600  # 이전 버전 유지 시간
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        resources:
          requests:
            memory: 32Mi
            cpu: 5m

• activeService와 previewService를 사용해, 두 서비스 간의 트래픽을 관리합니다.
• autoPromotionEnabled를 false로 설정하면 수동으로 트래픽을 전환할 수 있습니다.

2. 카나리 배포 전략

카나리 배포는 새 버전을 점진적으로 배포하면서 트래픽을 점차적으로 전환하는 방식입니다. 카나리 배포는 실패 조건을 설정하고, 트래픽 비율을 단계적으로 증가시켜 안정성을 검증합니다.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-canary
spec:
  replicas: 5
  strategy:
    canary:
      analysis:
        templates:
        - templateName: success-rate
        startingStep: 2
      steps:
      - setWeight: 20
      - pause: {duration: 10m}
      - setWeight: 40
      - pause: {duration: 10m}
      - setWeight: 60
      - pause: {duration: 10m}
      - setWeight: 80
      - pause: {duration: 10m}
      trafficRouting:
        nginx:
          stableIngress: rollout-stable
          additionalIngressAnnotations:
            nginx.ingress.kubernetes.io/custom-header: "true"
  template:
    metadata:
      labels:
        app: rollout-canary
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:red
        resources:
          requests:
            memory: 32Mi
            cpu: 5m

• setWeight와 pause를 사용하여 트래픽 전환을 점진적으로 진행할 수 있습니다. (이때, pause: {}로 설정하면 비활성화로 설정할 수 있습니다.)
• trafficRouting 설정을 통해 NGINX와 같은 ingress 컨트롤러와 통합하여 트래픽을 제어합니다.

3. 메트릭 기반 분석

배포의 성공 여부를 메트릭 기반으로 판단할 수 있습니다.

Argo Rollouts는 Prometheus와 같은 메트릭 제공자를 통해 실시간으로 성능을 모니터링하고, 성공/실패 조건을 정의할 수 있습니다.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 5m
    count: 2
    successCondition: result[0] >= 0.95
    failureCondition: result[0] < 0.85
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc.cluster.local:9090
        query: |
          sum(rate(http_request_total{job="{{args.service-name}}",status!~"5.*"}[5m])) /
          sum(rate(http_request_total{job="{{args.service-name}}"}[5m]))
  - name: latency-p95
    interval: 5m
    count: 2
    successCondition: result[0] <= 0.5
    failureCondition: result[0] > 1
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc.cluster.local:9090
        query: |
          histogram_quantile(0.95,
            sum(rate(http_request_duration_seconds_bucket{job="{{args.service-name}}"}[5m])) by (le))

• successCondition와 failureCondition을 설정하여 메트릭을 기준으로 배포를 검증합니다.
• Prometheus 쿼리 결과에 따라 자동으로 승격 또는 롤백이 수행됩니다.

---

4. 구축 시 고려사항

1. 리소스 설정

• CPU: 최소 200m
• Memory: 최소 256Mi
• 추가적으로 분석 작업을 위한 리소스도 고려해야 합니다.

2. 네트워킹 구성

• 서비스 메시 (선택 사항): Istio, Linkerd
• 인그레스 컨트롤러: NGINX, ALB
• 서비스 디스커버리: Kubernetes에서 제공하는 서비스 디스커버리 기능

3. 모니터링 및 알림

• Prometheus + Grafana 설정
• Alerting rules 구성
• 배포 실패 시 알림 설정

---

5. 실제 운영 시 모범 사례

• 점진적 도입: 카나리 배포부터 시작하여 블루-그린 배포로 확장합니다.
• 메트릭 임계값 보수적 설정: 임계값을 너무 공격적으로 설정하지 말고, 실패를 최소화합니다.
• 배포 전략 선택: 서비스 특성에 따라 적합한 배포 전략을 선택합니다.

1. 애플리케이션 호환성 검토

적합한 애플리케이션

• 지속적인 배포가 필요한 애플리케이션
• 동시에 여러 버전 실행이 가능한 애플리케이션
• 소스 코드 접근 및 수정이 가능한 애플리케이션

부적합한 애플리케이션

• 공유 리소스를 사용하는 애플리케이션 (예: 공유 파일 시스템)
• 큐 기반의 워커 애플리케이션 (코드 수정 없이는 부적합)
• 인프라 구성요소 (cert-manager, nginx, coredns 등)

사용 범위와 제한사항

1. 단일 클러스터 범위
   • 단일 Kubernetes 배포/애플리케이션만 관리
   • 다중 클러스터의 경우 각 클러스터에 컨트롤러 필요
2. 배포 시간 고려사항
   • 권장 배포 시간: 15-20분 ~ 1-2시간
   • 장기 실행 배포(수일~수주)는 부적합
   • 동시 다중 버전 운영은 미지원

실전 운영 팁

1. 메트릭 기반 자동화

• 완전 자동화된 배포를 목표로 설정
• 5-15분 내 배포 성공 여부 판단 가능한 메트릭 구성
• 수동 프로모션은 테스트 용도로만 사용

2. 시스템 통합 방안

# Kubernetes Downward API 활용 예시
spec:
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        env:
        - name: POD_LABELS
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels

3. 트래픽 라우팅 전략

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: service-rollout
spec:
  rules:
  - host: preview.example.com  # 프리뷰 환경
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service-preview
            port:
              number: 80
  - host: stable.example.com   # 안정 환경
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service-stable
            port:
              number: 80

4. 리소스 최적화

• RevisionHistoryLimit 조정으로 메모리 사용량 최적화
• 대규모 클러스터에서는 10에서 5 또는 그 이하로 조정 권장

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-rollout
spec:
  revisionHistoryLimit: 5  # 기본값 10에서 조정

도입을 위한 체크리스트

1. 애플리케이션 평가
   • 동시 실행 가능성 검토
   • 공유 리소스 의존성 확인
   • 코드 수정 필요성 평가
2. 메트릭 준비
   • 핵심 성능 지표 정의
   • 자동화된 판단 기준 수립
   • 모니터링 시스템 연동
3. 운영 계획 수립
   • 점진적 도입 전략
   • 롤백 절차 마련
   • 운영팀 교육 계획

이러한 고려사항들을 바탕으로 Argo Rollouts를 도입한다면, 안정적이고 효과적인 배포 자동화를 실현할 수 있습니다.

---

 

참고 자료 : https://www.nttdata.com/global/en/insights/focus/service-pauses-on-release-is-a-thing-of-the-past--non-stop-deploy-strategies-by-argo-rollouts

https://argo-rollouts.readthedocs.io/en/stable/best-practices/