Argo Rollouts 자동 롤백 파이프라인 | Datadog · CloudWatch 멀티 프로바이더 AnalysisTemplate 임계값 단계별 강화 전략

배포할 때마다 슬랙에서 대기하다가 에러율이 튀면 직접 롤백 명령을 입력하던 시절이 있었습니다. 카나리를 도입하면 이 문제가 해결될 줄 알았는데, 막상 운영해보면 새로운 고민이 생깁니다. "임계값을 얼마로 잡아야 하지?", "5분 기다렸는데 샘플이 너무 적은 거 아닌가?", "분석이 끝나기도 전에 배포가 완료되면 어떻게 되는 거지?" — 이 고민들이 쌓이다 보면, 결국 자동화를 믿지 못하고 사람이 끝에 서게 됩니다. 카나리가 있어도 분석이 실제로 믿을 만한지 확신이 없으면, 새벽 배포 때 여전히 슬랙을 켜두게 되는 거죠. 저도 그랬습니다.

2025년부터 Datadog이 v1 API에 엄격한 rate limit을 적용하면서, 기존 AnalysisTemplate을 그냥 두면 배포 중 API 호출이 묵묵히 차단되는 상황이 생겼습니다. 이 참에 Argo Rollouts의 AnalysisTemplate에 Datadog APM 메트릭과 AWS CloudWatch 인프라 메트릭을 제대로 연동해서, 멀티 클라우드 환경에서도 사람 개입 없이 자동으로 승격(promote)하거나 롤백(rollback)하는 파이프라인을 구성하는 방법을 정리해봤습니다. 단순 연동 방법뿐 아니라 임계값을 어떻게 점진적으로 강화해나가는지, 어디서 흔히 막히는지도 솔직하게 풀어볼게요.

이 글을 읽고 나면 Datadog · CloudWatch 멀티 프로바이더 AnalysisTemplate을 직접 작성하고, 임계값 단계별 강화 전략을 실무에 적용할 수 있습니다.

핵심 개념

이 글은 Kubernetes 기본 운영 경험과 카나리 배포의 개념을 알고 있다는 전제로 작성되었습니다. Argo Rollouts가 이미 클러스터에 설치되어 있고, EKS 환경을 기준으로 설명합니다. Argo Rollouts 설치 방법은 공식 문서를 참고해보시면 됩니다.

Argo Rollouts와 AnalysisTemplate이 하는 일

Argo Rollouts는 Kubernetes에서 카나리·블루/그린·점진적 배포를 네이티브하게 지원하는 컨트롤러입니다. 표준 Deployment를 Rollout이라는 CRD(Custom Resource Definition, 사용자 정의 리소스)로 대체하거나, workloadRef를 통해 기존 Deployment와 함께 사용하는 방식 모두 지원합니다.

그렇다면 트래픽을 20%만 신규 버전에 흘린 다음 "이 버전이 괜찮은가?"를 판단하는 건 누가 할까요? 그게 바로 AnalysisTemplate입니다.

AnalysisTemplate은 메트릭 쿼리와 임계값을 정의한 CRD입니다. "이 쿼리를 5분마다 실행해서, 에러율이 1% 이하면 성공, 3번 연속 실패하면 롤백"처럼 룰을 선언해두는 거죠.

yaml

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-gate
spec:
  metrics:
  - name: error-percentage
    interval: 5m        # 측정 주기
    count: 3            # 총 측정 횟수
    successCondition: result[0] <= 0.01   # 에러율 1% 이하면 성공
    failureCondition: result[0] > 0.05    # 5% 초과면 즉시 실패
    failureLimit: 1     # 1번만 실패해도 롤백 트리거
    provider:
      # ...메트릭 프로바이더 설정

주요 필드가 하는 역할을 한눈에 보면 이렇습니다.

필드	역할
`successCondition`	충족 시 해당 측정을 '성공'으로 기록
`failureCondition`	충족 시 즉시 실패 처리 (롤백 직행)
`failureLimit`	허용 실패 횟수. 초과 시 자동 롤백 트리거
`interval`	측정 주기
`count`	총 측정 횟수. 모두 성공하면 분석 통과

failureLimit × interval, 배포 시간보다 짧아야 하는 이유

이 부분이 처음 AnalysisTemplate을 설계할 때 가장 놓치기 쉬운 함정입니다. 저도 그랬고요.

failureLimit이 3이고 interval이 10분이면, 최악의 경우 분석이 완료되기까지 30분이 걸릴 수 있습니다. 만약 전체 카나리 배포 완료 시간이 20분이라면? 분석이 끝나기 전에 배포가 완료되어버립니다. 불량 릴리스가 그냥 통과하는 셈이죠.

핵심 제약: failureLimit × interval의 합산 시간은 반드시 Rollout 전체 소요 시간보다 짧아야 합니다. 카나리 단계가 총 40분이라면, 분석은 그 안에 완료되어야 의미가 있습니다.

배포 소요 시간을 먼저 측정한 뒤, failureLimit × interval이 그보다 짧게 맞춰지는 조합을 찾는 것을 권장합니다.

멀티 프로바이더 병렬 분석의 가치

Datadog과 CloudWatch를 동시에 통과해야 승격되도록 구성하면, APM 레이어(애플리케이션 에러율, 레이턴시)와 인프라 레이어(ALB 5xx, 타겟 응답시간)를 각각 독립적으로 감시할 수 있습니다. 어느 한 쪽이 이상해도 자동으로 막힙니다.

저희 팀이 이 구조로 전환한 이후, 애플리케이션 레이어에서는 정상이지만 인프라 레이어에서 이상 신호가 잡히는 케이스를 실제로 경험했습니다. 단일 프로바이더였다면 그냥 통과했을 배포였어요.

yaml

# Rollout spec 내 분석 블록
steps:
- setWeight: 20
- analysis:
    templates:
    - templateName: datadog-error-rate      # APM 레이어
    - templateName: cloudwatch-5xx-check    # 인프라 레이어

실전 적용

예시 1: Datadog APM 에러율 게이팅 AnalysisTemplate 구성

Datadog 연동의 핵심은 두 가지입니다. Secret에 자격증명을 등록하고, AnalysisTemplate에서 apiVersion: v2를 명시하는 것입니다.

2025년부터 Datadog이 v1 API를 deprecated 처리하고 rate limit을 강화했기 때문에, apiVersion 필드를 생략하거나 v1로 두면 배포 중에 API 호출이 차단되는 상황이 생길 수 있습니다. 저도 처음에 이걸 놓쳐서 배포 중에 분석이 갑자기 멈추는 경험을 했습니다.

yaml

# 1단계: Datadog 자격증명 Secret 등록
apiVersion: v1
kind: Secret
metadata:
  name: datadog-secret
  namespace: argo-rollouts
stringData:
  address: https://api.datadoghq.com
  api-key: <DATADOG_API_KEY>
  app-key: <DATADOG_APP_KEY>

yaml

# 2단계: AnalysisTemplate 정의
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: datadog-error-rate
spec:
  metrics:
  - name: error-percentage
    interval: 5m          # AnalysisRun 레벨: 측정을 얼마 주기로 반복할지
    count: 3
    successCondition: result[0] <= 0.01   # 에러율 1% 이하 (비율값, 0~1 범위)
    failureCondition: result[0] > 0.05    # 5% 초과면 즉시 롤백
    failureLimit: 1
    provider:
      datadog:
        apiVersion: v2                    # v1은 deprecated, 반드시 v2 명시
        interval: 5m                      # Datadog 쿼리 시간 윈도우: 최근 5분 데이터를 집계
        query: |
          sum:trace.web.request.errors{env:prod,service:payment-api}.as_rate()
          /
          sum:trace.web.request.hits{env:prod,service:payment-api}.as_rate()

interval 필드가 두 군데 나오는 걸 보고 헷갈리실 수 있습니다. 역할이 다릅니다.

`interval` 위치	역할
`metrics` 레벨	AnalysisRun이 측정을 얼마 주기로 반복할지 결정
`provider.datadog` 레벨	Datadog API에 "최근 몇 분치 데이터를 집계해줘"라고 요청하는 시간 윈도우

두 값을 같게 맞춰두는 게 일반적이지만, 쿼리 데이터가 너무 희박하면 provider.datadog.interval을 더 길게 잡아서 더 넓은 범위를 집계하도록 조정할 수 있습니다.

이 쿼리는 **비율(0~1 범위)**을 반환한다는 점도 짚고 넘어가겠습니다. successCondition: result[0] <= 0.01에서 0.01은 1%를 의미합니다. CloudWatch 예시와 반환 타입이 다르기 때문에 조건식을 혼용하지 않도록 주의가 필요합니다.

쿼리 구성 요소	역할
`trace.web.request.errors`	APM이 기록한 에러 요청 수
`trace.web.request.hits`	전체 요청 수
`.as_rate()`	원시 카운트를 초당 비율로 변환
`env:prod,service:payment-api`	특정 서비스·환경 필터링

예시 2: CloudWatch ALB 5xx 모니터링 AnalysisTemplate 구성

CloudWatch 연동에서 가장 많이 막히는 부분은 권한 설정입니다. 처음에 cloudwatch:GetMetricData 하나면 된다고 생각했는데, 실제로 배포 중에 API 호출이 묵묵히 실패하는 걸 보고 IAM 권한부터 다시 확인했습니다. IRSA(IAM Roles for Service Accounts, EKS에서 특정 Kubernetes ServiceAccount에 IAM 역할을 연결하는 방식)를 통해 Argo Rollouts 컨트롤러 ServiceAccount에만 최소 권한으로 부여하는 것을 권장합니다.

json

// IAM 정책 — Argo Rollouts 컨트롤러 ServiceAccount에 연결
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["cloudwatch:GetMetricData"],
      "Resource": "*"
    }
  ]
}

yaml

# CloudWatch AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: cloudwatch-5xx-check
spec:
  metrics:
  - name: alb-5xx-count
    interval: 5m
    count: 5
    successCondition: result[0] <= 10     # 5분간 5xx 10건 이하 (절대 건수)
    failureLimit: 2
    provider:
      cloudWatch:
        metricDataQueries:
        - id: m1
          metricStat:
            metric:
              namespace: AWS/ApplicationELB
              metricName: HTTPCode_Target_5XX_Count
              dimensions:
              - name: LoadBalancer
                value: app/my-alb/abc123   # 실제 ALB ARN 마지막 부분
            period: 300    # 5분(300초) 집계
            stat: Sum

앞서 Datadog 예시의 result[0] <= 0.01이 **비율(0~1)**인 것과 달리, CloudWatch 예시의 result[0] <= 10은 절대 건수입니다. CloudWatch는 집계 함수(Sum, Average 등)에 따라 반환 타입이 달라지기 때문에, 조건식을 작성할 때 쿼리가 어떤 값을 돌려주는지 먼저 확인하는 것이 좋습니다.

AWS_REGION 환경변수도 Argo Rollouts 컨트롤러 Deployment에 설정되어 있어야 합니다. 이게 빠져 있으면 CloudWatch API 호출이 묵묵히 실패하는데, 컨트롤러 로그에 region을 찾지 못한다는 메시지가 나옵니다. Helm chart나 kustomize로 컨트롤러를 배포하고 있다면, 해당 Deployment의 env 블록에 아래를 추가해두는 것을 권장합니다.

yaml

# Argo Rollouts 컨트롤러 Deployment의 env 블록에 추가
env:
- name: AWS_REGION
  value: ap-northeast-2

예시 3: 임계값 단계별 강화 플로우

솔직히 처음부터 에러율 1% 임계값을 걸면 오탐(False Positive, 실제로는 문제없는 배포인데 분석이 실패로 판단해 불필요한 롤백이 발생하는 상황) 롤백이 너무 잦아집니다. 기준선 데이터가 없는 상태에서는 1%가 정상인지 비정상인지조차 알 수 없고요. 느슨하게 시작해서 서비스 안정성 데이터가 쌓이면 단계적으로 강화하는 방식을 권장합니다.

배포 단계	카나리 트래픽	에러율 임계값	failureLimit	비고
Phase 1 (초기 도입)	5%	≤ 5%	3	기준선 수집 기간
Phase 2 (1주 후)	20%	≤ 3%	2	안정성 데이터 반영
Phase 3 (안정화)	50%	≤ 1%	1	신뢰도 확보 후 강화
Full Rollout	100%	≤ 0.5%	1	SLO(Service Level Objective, 서비스 수준 목표) 기반 최종 기준

각 Phase는 별도 AnalysisTemplate으로 관리하거나, args를 활용해 단일 템플릿에서 파라미터로 분기할 수도 있습니다. 다만 successCondition 안에서 args 보간 문법이 지원되는지는 Argo Rollouts 버전에 따라 다를 수 있으므로, 직접 적용 전에 버전 호환 여부를 먼저 확인해보시면 좋습니다.

yaml

# args를 활용한 파라미터화된 AnalysisTemplate (버전 호환 확인 후 사용 권장)
spec:
  args:
  - name: error-threshold
  metrics:
  - name: error-rate
    successCondition: "result[0] <= {{args.error-threshold}}"
    # ...

yaml

# Rollout에서 호출 시 임계값 주입
analysis:
  templates:
  - templateName: parameterized-error-rate
  args:
  - name: error-threshold
    value: "0.03"   # Phase 2: 3%

장단점 분석

장점

항목	내용
자동화된 안전망	새벽 배포, 긴 연휴에도 SLI(Service Level Indicator, 서비스 수준 지표) 저하 시 즉시 롤백
데이터 기반 결정	직관이나 감이 아닌 실제 메트릭으로 승격/롤백 판단
멀티 프로바이더 지원	APM + 인프라 레이어를 동시에 감시, 사각지대 최소화
GitOps 친화적	AnalysisTemplate 자체를 Git으로 버전 관리, PR 리뷰 가능
점진적 위험 노출	전체 트래픽이 아닌 일부에만 신규 버전 노출

단점 및 주의사항

항목	내용	대응 방안
임계값 설정 난이도	기준선 없이 임계값을 잡으면 오탐 또는 불량 통과 발생	최소 2주 이상 운영 데이터 수집 후 기준선 설정
분석 시간 초과 맹점	`failureLimit × interval`이 배포 시간보다 길면 불량 승격	배포 총 소요 시간을 먼저 계산한 뒤 파라미터 설정
Datadog API 비용	짧은 `interval`로 잦은 API 호출 시 rate limit 초과	`interval`을 5m 이상으로 유지, API v2 사용
CloudWatch IAM 권한	과도한 권한 부여는 보안 위험	IRSA로 컨트롤러 ServiceAccount에만 최소 권한 부여
콜드 스타트 문제	트래픽 적은 시간대에 배포하면 샘플 수 부족으로 신뢰도 저하	`count`와 `interval`을 트래픽 피크 패턴에 맞게 조정
상태형 앱 복잡성	DB 스키마 변경 수반 시 롤백으로 데이터 정합성 문제 발생	마이그레이션을 배포와 분리하는 Expand/Contract 패턴 적용

실무에서 가장 흔한 실수

Datadog API v1을 그대로 사용하는 경우 — apiVersion 필드를 생략하거나 v1로 두면 2025년 이후 rate limit 정책으로 인해 분석 실행 중 API 호출이 차단됩니다. apiVersion: v2를 명시하는 습관을 들이는 것을 권장합니다.
failureLimit × interval 계산을 생략하는 경우 — 쿼리와 임계값만 신경 쓰다 보면 이 시간 제약을 간과하기 쉽습니다. 배포 완료 전에 분석이 끝날 수 있는지 먼저 시뮬레이션해보시면 좋습니다.
트래픽 없는 시간대에 임계값을 검증하는 경우 — 새벽 3시에 테스트 배포를 하면 샘플이 너무 적어서 분석 결과 자체를 신뢰하기 어렵습니다. 임계값 검증은 트래픽이 정상 수준인 시간대에 진행하는 것을 권장합니다.

마치며

이 글을 읽기 전에는 임계값을 얼마로 잡아야 할지, Datadog과 CloudWatch를 어떻게 함께 써야 할지 막막했다면, 이제는 멀티 프로바이더 AnalysisTemplate을 직접 구성하고 기준선 데이터부터 시작해 단계별로 임계값을 강화하는 전략까지 손에 쥐었을 겁니다. 남은 건 지금 서비스의 에러율 기준선을 측정해보는 것, 그 하나뿐입니다.

지금 바로 시작해볼 수 있는 3단계:

기존 서비스의 에러율 기준선을 먼저 측정해보시면 좋습니다. Datadog의 경우 sum:trace.web.request.errors{service:your-service}.as_rate() / sum:trace.web.request.hits{service:your-service}.as_rate()를 지난 2주 데이터로 실행해서 P95 에러율을 확인해볼 수 있습니다. 이 값이 임계값 설정의 출발점이 됩니다.
위 예시 코드를 참고해 failureLimit: 3, interval: 5m, successCondition: result[0] <= 0.05처럼 느슨한 설정으로 AnalysisTemplate을 먼저 배포해볼 수 있습니다. 처음부터 엄격하게 잡기보다는 실제 배포 흐름에서 분석이 제대로 동작하는지 확인하는 게 우선입니다.
1~2주 운영 데이터가 쌓이면 위에서 설명한 Phase 전략에 따라 임계값을 단계적으로 강화해 나가시면 됩니다. args를 활용한 파라미터화된 AnalysisTemplate으로 만들어두면 Phase별 임계값 변경이 훨씬 수월합니다.

참고 자료

#ArgoRollouts#카나리배포#Kubernetes#AnalysisTemplate#Datadog#CloudWatch#GitOps#IRSA#프로그레시브딜리버리#SLO

Argo Rollouts 자동 롤백 파이프라인 | Datadog · CloudWatch 멀티 프로바이더 AnalysisTemplate 임계값 단계별 강화 전략 | DEV BAK - 기술블로그

DevOps

Argo Rollouts 자동 롤백 파이프라인 | Datadog · CloudWatch 멀티 프로바이더 AnalysisTemplate 임계값 단계별 강화 전략

이 글을 읽고 나면 Datadog · CloudWatch 멀티 프로바이더 AnalysisTemplate을 직접 작성하고, 임계값 단계별 강화 전략을 실무에 적용할 수 있습니다.

핵심 개념

이 글은 Kubernetes 기본 운영 경험과 카나리 배포의 개념을 알고 있다는 전제로 작성되었습니다. Argo Rollouts가 이미 클러스터에 설치되어 있고, EKS 환경을 기준으로 설명합니다. Argo Rollouts 설치 방법은 공식 문서를 참고해보시면 됩니다.

Argo Rollouts와 AnalysisTemplate이 하는 일

그렇다면 트래픽을 20%만 신규 버전에 흘린 다음 "이 버전이 괜찮은가?"를 판단하는 건 누가 할까요? 그게 바로 AnalysisTemplate입니다.

yaml

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-gate
spec:
  metrics:
  - name: error-percentage
    interval: 5m        # 측정 주기
    count: 3            # 총 측정 횟수
    successCondition: result[0] <= 0.01   # 에러율 1% 이하면 성공
    failureCondition: result[0] > 0.05    # 5% 초과면 즉시 실패
    failureLimit: 1     # 1번만 실패해도 롤백 트리거
    provider:
      # ...메트릭 프로바이더 설정

주요 필드가 하는 역할을 한눈에 보면 이렇습니다.

필드	역할
`successCondition`	충족 시 해당 측정을 '성공'으로 기록
`failureCondition`	충족 시 즉시 실패 처리 (롤백 직행)
`failureLimit`	허용 실패 횟수. 초과 시 자동 롤백 트리거
`interval`	측정 주기
`count`	총 측정 횟수. 모두 성공하면 분석 통과

failureLimit × interval, 배포 시간보다 짧아야 하는 이유

이 부분이 처음 AnalysisTemplate을 설계할 때 가장 놓치기 쉬운 함정입니다. 저도 그랬고요.

핵심 제약: failureLimit × interval의 합산 시간은 반드시 Rollout 전체 소요 시간보다 짧아야 합니다. 카나리 단계가 총 40분이라면, 분석은 그 안에 완료되어야 의미가 있습니다.

배포 소요 시간을 먼저 측정한 뒤, failureLimit × interval이 그보다 짧게 맞춰지는 조합을 찾는 것을 권장합니다.

멀티 프로바이더 병렬 분석의 가치

yaml

# Rollout spec 내 분석 블록
steps:
- setWeight: 20
- analysis:
    templates:
    - templateName: datadog-error-rate      # APM 레이어
    - templateName: cloudwatch-5xx-check    # 인프라 레이어

실전 적용

예시 1: Datadog APM 에러율 게이팅 AnalysisTemplate 구성

Datadog 연동의 핵심은 두 가지입니다. Secret에 자격증명을 등록하고, AnalysisTemplate에서 apiVersion: v2를 명시하는 것입니다.

yaml

# 1단계: Datadog 자격증명 Secret 등록
apiVersion: v1
kind: Secret
metadata:
  name: datadog-secret
  namespace: argo-rollouts
stringData:
  address: https://api.datadoghq.com
  api-key: <DATADOG_API_KEY>
  app-key: <DATADOG_APP_KEY>

yaml

# 2단계: AnalysisTemplate 정의
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: datadog-error-rate
spec:
  metrics:
  - name: error-percentage
    interval: 5m          # AnalysisRun 레벨: 측정을 얼마 주기로 반복할지
    count: 3
    successCondition: result[0] <= 0.01   # 에러율 1% 이하 (비율값, 0~1 범위)
    failureCondition: result[0] > 0.05    # 5% 초과면 즉시 롤백
    failureLimit: 1
    provider:
      datadog:
        apiVersion: v2                    # v1은 deprecated, 반드시 v2 명시
        interval: 5m                      # Datadog 쿼리 시간 윈도우: 최근 5분 데이터를 집계
        query: |
          sum:trace.web.request.errors{env:prod,service:payment-api}.as_rate()
          /
          sum:trace.web.request.hits{env:prod,service:payment-api}.as_rate()

interval 필드가 두 군데 나오는 걸 보고 헷갈리실 수 있습니다. 역할이 다릅니다.

`interval` 위치	역할
`metrics` 레벨	AnalysisRun이 측정을 얼마 주기로 반복할지 결정
`provider.datadog` 레벨	Datadog API에 "최근 몇 분치 데이터를 집계해줘"라고 요청하는 시간 윈도우

쿼리 구성 요소	역할
`trace.web.request.errors`	APM이 기록한 에러 요청 수
`trace.web.request.hits`	전체 요청 수
`.as_rate()`	원시 카운트를 초당 비율로 변환
`env:prod,service:payment-api`	특정 서비스·환경 필터링

예시 2: CloudWatch ALB 5xx 모니터링 AnalysisTemplate 구성

json

// IAM 정책 — Argo Rollouts 컨트롤러 ServiceAccount에 연결
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["cloudwatch:GetMetricData"],
      "Resource": "*"
    }
  ]
}

yaml

# CloudWatch AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: cloudwatch-5xx-check
spec:
  metrics:
  - name: alb-5xx-count
    interval: 5m
    count: 5
    successCondition: result[0] <= 10     # 5분간 5xx 10건 이하 (절대 건수)
    failureLimit: 2
    provider:
      cloudWatch:
        metricDataQueries:
        - id: m1
          metricStat:
            metric:
              namespace: AWS/ApplicationELB
              metricName: HTTPCode_Target_5XX_Count
              dimensions:
              - name: LoadBalancer
                value: app/my-alb/abc123   # 실제 ALB ARN 마지막 부분
            period: 300    # 5분(300초) 집계
            stat: Sum

yaml

# Argo Rollouts 컨트롤러 Deployment의 env 블록에 추가
env:
- name: AWS_REGION
  value: ap-northeast-2

예시 3: 임계값 단계별 강화 플로우

배포 단계	카나리 트래픽	에러율 임계값	failureLimit	비고
Phase 1 (초기 도입)	5%	≤ 5%	3	기준선 수집 기간
Phase 2 (1주 후)	20%	≤ 3%	2	안정성 데이터 반영
Phase 3 (안정화)	50%	≤ 1%	1	신뢰도 확보 후 강화
Full Rollout	100%	≤ 0.5%	1	SLO(Service Level Objective, 서비스 수준 목표) 기반 최종 기준

yaml

# args를 활용한 파라미터화된 AnalysisTemplate (버전 호환 확인 후 사용 권장)
spec:
  args:
  - name: error-threshold
  metrics:
  - name: error-rate
    successCondition: "result[0] <= {{args.error-threshold}}"
    # ...

yaml

# Rollout에서 호출 시 임계값 주입
analysis:
  templates:
  - templateName: parameterized-error-rate
  args:
  - name: error-threshold
    value: "0.03"   # Phase 2: 3%

장단점 분석

장점

항목	내용
자동화된 안전망	새벽 배포, 긴 연휴에도 SLI(Service Level Indicator, 서비스 수준 지표) 저하 시 즉시 롤백
데이터 기반 결정	직관이나 감이 아닌 실제 메트릭으로 승격/롤백 판단
멀티 프로바이더 지원	APM + 인프라 레이어를 동시에 감시, 사각지대 최소화
GitOps 친화적	AnalysisTemplate 자체를 Git으로 버전 관리, PR 리뷰 가능
점진적 위험 노출	전체 트래픽이 아닌 일부에만 신규 버전 노출

단점 및 주의사항

항목	내용	대응 방안
임계값 설정 난이도	기준선 없이 임계값을 잡으면 오탐 또는 불량 통과 발생	최소 2주 이상 운영 데이터 수집 후 기준선 설정
분석 시간 초과 맹점	`failureLimit × interval`이 배포 시간보다 길면 불량 승격	배포 총 소요 시간을 먼저 계산한 뒤 파라미터 설정
Datadog API 비용	짧은 `interval`로 잦은 API 호출 시 rate limit 초과	`interval`을 5m 이상으로 유지, API v2 사용
CloudWatch IAM 권한	과도한 권한 부여는 보안 위험	IRSA로 컨트롤러 ServiceAccount에만 최소 권한 부여
콜드 스타트 문제	트래픽 적은 시간대에 배포하면 샘플 수 부족으로 신뢰도 저하	`count`와 `interval`을 트래픽 피크 패턴에 맞게 조정
상태형 앱 복잡성	DB 스키마 변경 수반 시 롤백으로 데이터 정합성 문제 발생	마이그레이션을 배포와 분리하는 Expand/Contract 패턴 적용

실무에서 가장 흔한 실수

Datadog API v1을 그대로 사용하는 경우 — apiVersion 필드를 생략하거나 v1로 두면 2025년 이후 rate limit 정책으로 인해 분석 실행 중 API 호출이 차단됩니다. apiVersion: v2를 명시하는 습관을 들이는 것을 권장합니다.
failureLimit × interval 계산을 생략하는 경우 — 쿼리와 임계값만 신경 쓰다 보면 이 시간 제약을 간과하기 쉽습니다. 배포 완료 전에 분석이 끝날 수 있는지 먼저 시뮬레이션해보시면 좋습니다.
트래픽 없는 시간대에 임계값을 검증하는 경우 — 새벽 3시에 테스트 배포를 하면 샘플이 너무 적어서 분석 결과 자체를 신뢰하기 어렵습니다. 임계값 검증은 트래픽이 정상 수준인 시간대에 진행하는 것을 권장합니다.

마치며

지금 바로 시작해볼 수 있는 3단계:

기존 서비스의 에러율 기준선을 먼저 측정해보시면 좋습니다. Datadog의 경우 sum:trace.web.request.errors{service:your-service}.as_rate() / sum:trace.web.request.hits{service:your-service}.as_rate()를 지난 2주 데이터로 실행해서 P95 에러율을 확인해볼 수 있습니다. 이 값이 임계값 설정의 출발점이 됩니다.
위 예시 코드를 참고해 failureLimit: 3, interval: 5m, successCondition: result[0] <= 0.05처럼 느슨한 설정으로 AnalysisTemplate을 먼저 배포해볼 수 있습니다. 처음부터 엄격하게 잡기보다는 실제 배포 흐름에서 분석이 제대로 동작하는지 확인하는 게 우선입니다.
1~2주 운영 데이터가 쌓이면 위에서 설명한 Phase 전략에 따라 임계값을 단계적으로 강화해 나가시면 됩니다. args를 활용한 파라미터화된 AnalysisTemplate으로 만들어두면 Phase별 임계값 변경이 훨씬 수월합니다.

참고 자료

#ArgoRollouts#카나리배포#Kubernetes#AnalysisTemplate#Datadog#CloudWatch#GitOps#IRSA#프로그레시브딜리버리#SLO

핵심 개념

Argo Rollouts와 AnalysisTemplate이 하는 일

failureLimit × interval, 배포 시간보다 짧아야 하는 이유

멀티 프로바이더 병렬 분석의 가치

실전 적용

예시 1: Datadog APM 에러율 게이팅 AnalysisTemplate 구성

예시 2: CloudWatch ALB 5xx 모니터링 AnalysisTemplate 구성

예시 3: 임계값 단계별 강화 플로우

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

Argo Rollouts와 AnalysisTemplate이 하는 일

failureLimit × interval, 배포 시간보다 짧아야 하는 이유

멀티 프로바이더 병렬 분석의 가치

실전 적용

예시 1: Datadog APM 에러율 게이팅 AnalysisTemplate 구성

예시 2: CloudWatch ALB 5xx 모니터링 AnalysisTemplate 구성

예시 3: 임계값 단계별 강화 플로우

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

PR 머지 하나로 Kubernetes 카나리 배포를 자동화하는 ArgoCD + Argo Rollouts 파이프라인

Argo Rollouts BlueGreen 배포 전략 — 카나리와 다른 점, 그리고 언제 선택해야 하는가

Argo Rollouts AnalysisTemplate — Prometheus·Datadog·Webhook으로 카나리 배포 자동 롤백 구현하기

Rancher Fleet과 Argo Rollouts를 조합해 500개 Kubernetes 클러스터에 카나리 배포하기 — Blast Radius를 파티션 단위로 제한하는 Progressive Delivery

Rancher Fleet으로 Kubernetes 멀티클러스터 운영하기 — 드리프트 없이 수십 개 클러스터를 Git 하나로 관리하는 패턴

Vercel CDN 비용 폭탄 없애기: Flat Rate CDN과 FinOps로 예측 가능한 인프라 비용 만들기 (2026)