Argo Rollouts 실전 가이드 - Kubernetes에서 Progressive Delivery를 어떻게 운영할까

왜 Argo Rollouts가 필요한가

Blue-Green과 Canary 개념은 많이 알려져 있지만, 실제 운영에서는 아래가 더 중요합니다.

트래픽을 몇 퍼센트씩 어떻게 옮길 것인가
실패 판단을 어떤 지표로 할 것인가
수동 승인 단계를 어디에 둘 것인가
롤백은 얼마나 자동화할 것인가

Argo Rollouts는 이 과정을 Kubernetes 리소스로 선언적으로 관리할 수 있게 해줍니다.

기본 구조 이해하기

보통 구성은 아래와 같습니다.

Rollout 리소스
AnalysisTemplate
Ingress 또는 Service Mesh 연계
Prometheus 같은 메트릭 소스

즉, 배포 전략과 검증 로직을 함께 관리하는 구조입니다.

Deployment 대신 Rollout을 쓰는 이유

일반 Deployment는 새 ReplicaSet으로 교체하는 데 초점이 있습니다.
Rollout은 “검증된 방식으로 점진 배포”하는 데 초점이 있습니다.

가능한 것:

10% → 30% → 50% → 100% 전환
단계별 pause
분석 실패 시 자동 중단
수동 승인 후 다음 단계 진행

Canary 전략 설계 예시

strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 300 }
      - analysis:
          templates:
            - templateName: success-rate-check
      - setWeight: 30
      - pause: { duration: 300 }
      - setWeight: 60
      - pause: { duration: 300 }

중요한 점은 단순히 퍼센트를 나누는 것이 아니라, 각 단계에서 무엇을 검증할지 정하는 것입니다.

어떤 지표로 실패를 판단할까

실무에서는 아래 지표가 많이 쓰입니다.

5xx 비율
응답 시간 P95 / P99
특정 비즈니스 API 성공률
Pod restart 수
외부 의존성 오류율

배포 성공 여부는 “Pod가 살아 있느냐”보다 “서비스 품질이 유지되느냐”로 판단해야 합니다.

Prometheus 기반 AnalysisTemplate 예시

예를 들어 5분 평균 성공률을 기준으로 검증할 수 있습니다.

metrics:
  - name: success-rate
    interval: 1m
    successCondition: result[0] >= 99
    provider:
      prometheus:
        query: |
          100 * (
            sum(rate(http_requests_total{status!~"5.."}[5m])) /
            sum(rate(http_requests_total[5m]))
          )

이런 식으로 검증 로직을 배포 흐름에 직접 연결할 수 있습니다.

Ingress 연계 시 생각할 점

트래픽 분산은 Ingress Controller 또는 Service Mesh가 담당합니다.

보통 아래 방식 중 하나를 씁니다.

NGINX Ingress
ALB Ingress Controller
Istio / Linkerd

주의할 점:

세션 스티키니스 영향
캐시 계층이 새 버전 검증을 왜곡할 수 있음
내부 트래픽과 외부 트래픽이 섞일 수 있음

즉, 단순히 “10% 전환”이 실제 사용자 경험 10%와 동일하지 않을 수 있습니다.

수동 승인 단계를 어디에 둘까

모든 배포를 완전 자동으로 돌리는 것이 항상 좋은 것은 아닙니다.

수동 승인이 유효한 경우:

결제, 주문, 인증 같은 핵심 경로
대규모 프로모션 직전 배포
데이터 마이그레이션 포함 배포

반대로 자주 배포되는 일반 API는 자동 분석 기반으로 흘리는 편이 더 효율적입니다.

롤백은 빨라야 하고 명확해야 한다

실패한 배포에서 가장 중요한 것은 판단보다 복구 속도입니다.

Argo Rollouts 운영 팁:

실패 조건을 미리 정의
롤백은 사람이 고민하지 않도록 자동화
배포 중단과 롤백을 구분
분석 지표와 알림을 연결

운영팀이 “지금 멈춘 것인지, 되돌린 것인지”를 헷갈리면 대응이 늦어집니다.

자주 겪는 문제

메트릭 수집 지연으로 잘못된 성공 판단
배포 대상보다 전체 서비스 지표를 봐서 노이즈 발생
캐시 효과 때문에 실제 오류가 늦게 드러남
너무 짧은 pause로 의미 없는 분석 수행
분석 실패 후 후속 알림과 추적 체계가 없음

마무리

Argo Rollouts는 단순한 배포 도구가 아니라 “배포를 검증 가능한 운영 행위로 바꾸는 장치”입니다.

Canary나 Blue-Green을 말로 이해하는 것과, 실제 서비스 품질 지표에 따라 자동으로 확장하고 되돌리는 것은 완전히 다른 수준의 운영입니다.
Kubernetes에서 점진 배포를 진짜 운영하려면, 결국 배포 전략과 관측성을 함께 설계해야 합니다.