Argo Rollouts vs Flagger, 뭘 쓸까
프로그레시브 딜리버리 도구를 고르라고 하면 대부분 두 개로 좁혀진다. Argo Rollouts와 Flagger. 둘 다 CNCF 프로젝트고, 둘 다 카나리를 자동화한다. 그런데 실제로 붙여보면 두 도구가 세상을 바라보는 방식이 꽤 다르다.
우리 팀에서는 작년 초에 Argo Rollouts로 시작했다가, 서비스 메시를 Linkerd로 굳히면서 Flagger를 병행하는 상황이 됐다. 반년 정도 두 개를 같이 굴려보면서 느낀 걸 정리해본다. 결론부터 말하면 어느 한 쪽이 압도적으로 낫다고는 못 하겠고, "우리가 이미 뭘 쓰고 있느냐"에 따라 답이 갈린다.
근본적인 차이: 워크로드를 소유하느냐
Argo Rollouts는 Deployment를 대체한다. Deployment 대신 Rollout이라는 CRD를 쓰고, 이게 ReplicaSet을 직접 관리한다. 그래서 트래픽 분기, 스텝 진행, 롤백까지 컨트롤러 하나가 다 붙잡고 있다. 대시보드와 kubectl argo rollouts CLI가 상태를 예쁘게 보여준다.
Flagger는 반대다. 기존 Deployment는 그대로 둔다. Canary라는 CRD를 하나 얹으면, Flagger가 primary/canary 두 개의 Deployment로 복제해서 트래픽을 서비스 메시(또는 Ingress)로 분기시킨다. 즉 워크로드를 "옆에서 관리"하는 형태다.
이 차이가 왜 중요하냐면, 기존 CI/CD 파이프라인에 넣을 때의 마찰이 완전히 달라지기 때문이다. Argo Rollouts로 가려면 팀 전체가 Deployment YAML을 Rollout으로 바꿔야 한다. Helm chart, Kustomize base, 스크립트, 관측성 알럿 셀렉터까지 다. 반대로 Flagger는 Canary 리소스만 하나 추가하면 끝이다. 대신 Flagger는 서비스 메시가 있어야 한다. Istio, Linkerd, App Mesh, Kuma 중 하나.
GitOps 조합
이건 좀 정치적인 얘긴데, 사실상 진영이 갈려 있다.
Argo CD를 쓰는 팀은 Argo Rollouts로 간다. 같은 UI에서 배포 상태와 카나리 진행을 한눈에 볼 수 있고, argocd-rollouts-plugin으로 통합도 자연스럽다. Flux를 쓰는 팀은 Flagger로 간다. Flagger가 Weaveworks에서 나온 만큼 Flux와 궁합이 좋고, HelmRelease + Canary 조합이 자연스럽게 굴러간다.
우리 팀은 Argo CD를 쓴다. 그래서 Argo Rollouts를 먼저 도입했다. 근데 Linkerd를 서비스 메시로 굳히고 나서, 어떤 서비스는 Flagger가 더 맞다는 판단이 섰다. Linkerd의 TrafficSplit이랑 Flagger가 워낙 매끄럽게 붙기 때문이다.
스텝 제어의 철학
Argo Rollouts는 스텝을 명시적으로 쓴다.
strategy:
canary:
steps:
- setWeight: 10
- pause: {duration: 5m}
- setWeight: 25
- pause: {} # 여기서 사람이 승인해야 넘어감
- analysis:
templates:
- templateName: success-rate
- setWeight: 50
- pause: {duration: 10m}각 단계가 눈에 보인다. 무엇보다 pause: {} 처럼 무기한 대기를 걸어 사람 승인을 강제할 수 있다. 규제 산업이나 결제처럼 "PM이 최종 확인하고 넘겨야 하는" 케이스에 딱이다.
Flagger는 접근이 다르다. 목표 상태를 선언한다.
analysis:
interval: 1m
threshold: 5
maxWeight: 50
stepWeight: 10
metrics:
- name: request-success-rate
thresholdRange:
min: 99
interval: 1mstepWeight: 10이면 10, 20, 30, 40, 50까지 자동으로 올라간다. 매 스텝마다 지정한 메트릭이 임계값을 넘으면 통과, 못 넘으면 롤백. 사람이 개입할 여지가 별로 없다. 좋게 말하면 "자동화 극대화", 나쁘게 말하면 "메트릭에 100% 걸어놓는 도박".
실무에서 우리 팀은 Argo Rollouts의 명시적 스텝을 더 신뢰한다. 왜냐하면 새벽 배포에서 자동 승진되는 게 무섭기 때문이다. 반면 하루에 수십 번 배포되는 사내 툴 같은 건 Flagger 방식이 편하다.
메트릭 소스
둘 다 Prometheus, Datadog, CloudWatch, New Relic 정도는 다 지원한다. 차이가 나는 부분:
Argo Rollouts는 Kayenta 연동을 지원한다. Kayenta는 Spinnaker에서 나온 자동화된 카나리 분석 엔진인데, 통계적 검정을 통해 카나리와 프로덕션의 메트릭을 비교해준다. 조직 규모가 크고 SRE가 통계 기반 분석을 원한다면 이건 좀 매력적이다. 또 Kubernetes Job과 웹 훅으로 커스텀 분석을 붙일 수 있어 유연하다.
Flagger는 Dynatrace, Splunk, Keptn을 기본 지원한다. Keptn 지원이 좀 특이한데, 조직에서 Keptn 기반의 SLO 자동화를 이미 하고 있다면 붙이기 편하다.
솔직히 우리 팀 기준으로는 Prometheus + Datadog만 있으면 둘 다 충분했다.
트래픽 라우팅
Argo Rollouts는 서비스 메시가 없어도 된다. Ingress 컨트롤러(NGINX, ALB, Traefik)만 있어도 카나리를 굴린다. 서비스 메시가 있다면 Istio, Linkerd SMI, Traefik 등도 지원한다.
Flagger는 서비스 메시가 사실상 필수다. Istio, Linkerd, Kuma, App Mesh 지원. Ingress 기반은 Contour, Gloo, NGINX, Skipper 지원하지만 메시가 있는 조합에서 훨씬 매끄럽게 굴러간다.
여기서 "우리는 서비스 메시 없이 간다"가 확정된 팀이라면 사실상 Argo Rollouts가 유일한 선택이 된다.
그럼 나는 뭘 쓰나
우리 팀 기준으로 정리하자면 이렇다.
- 결제, 주문 같은 핵심 트래픽은 Argo Rollouts. 스텝별 pause와 수동 승인이 필요해서.
- 내부 대시보드, 사내 툴, 실험적 서비스는 Flagger. 자동으로 지나가게 두고 메트릭 임계값에서 걸러지길 원해서.
만약 처음부터 다시 고른다면? Argo CD를 쓰고 서비스 메시가 없다면 Argo Rollouts 한 개로 통일한다. Flux + Linkerd라면 Flagger 한 개. 도구를 두 개 굴리는 건 인지 부하가 생각보다 크다. 온콜 엔지니어가 배포 실패 알럿 받았을 때 "이건 어느 컨트롤러가 관리하는 서비스지?" 하는 순간이 온다.
마무리
프로그레시브 딜리버리는 도구를 도입하는 게 목적이 아니라, 배포로 인한 장애를 줄이는 게 목적이다. 그래서 도구보다 더 중요한 건 (1) 신뢰할 수 있는 메트릭이 있느냐, (2) 롤백 자동화가 실제로 동작하느냐, (3) 팀이 카나리 실패를 정상 흐름으로 받아들이느냐다.
Argo Rollouts든 Flagger든, 이 세 가지가 안 되어 있으면 어차피 도구는 껍데기다. 반대로 세 가지가 되어 있다면, 도구 선택은 취향 문제에 가깝다.
혹시 두 도구 다 안 쓰고 다른 방식(예: 자체 스크립트, Spinnaker 등)으로 프로그레시브 딜리버리 하시는 분 있으면 어떻게 하시는지 궁금하다.