Argo Rollouts AnalysisRun 실패를 Slack과 PagerDuty로 즉시 전달하는 카나리 배포 알림 자동화

그날 아침 출근 직후, 동료가 Slack 검색창에 'rollback'을 치고 있었습니다. 전날 밤 카나리 배포가 조용히 실패했고, AnalysisRun이 오류율 임계값을 넘어 자동 롤백이 시작됐는데 아무도 몰랐던 거였죠. 온콜 엔지니어는 PagerDuty 알림 대신 아침에 쌓인 에러 로그를 보며 상황을 파악하기 시작했습니다. 저도 비슷한 경험이 있었고, 그 이후로 배포 파이프라인에 알림을 제대로 연결하는 게 얼마나 중요한지 실감하게 됐습니다.

이 글에서는 Argo Rollouts v1.8 기준으로, AnalysisRun 실패와 롤백 이벤트를 Slack과 PagerDuty에 동시에 전달하는 알림 파이프라인을 처음부터 끝까지 구성하는 방법을 다룹니다. YAML 복붙으로 끝나는 내용이 아니라, 각 구성요소가 왜 그렇게 생겼는지, 어디서 자주 막히는지까지 솔직하게 풀어볼게요.

Argo Rollouts에는 알림 시스템이 내장되어 있습니다. 별도의 이벤트 버스나 사이드카 없이 — 즉, AlertManager나 외부 이벤트 처리 시스템을 따로 운영하지 않아도 — ConfigMap 하나와 Secret 하나, Rollout 리소스의 annotation 몇 줄만으로 AnalysisRun 실패부터 PagerDuty 인시던트 생성까지 연결됩니다. 운영 부담을 최소화하면서도 팀 전체가 배포 상태를 실시간으로 인지할 수 있게 됩니다.

핵심 개념

이 글을 읽기 전에 알면 좋은 것들

이 글은 Kubernetes를 운영해본 경험이 있고, Argo Rollouts가 무엇인지 어렴풋이 아는 분을 대상으로 합니다. 아래 세 가지를 알고 계시면 바로 따라오실 수 있습니다.

• 카나리 배포: 신규 버전을 전체 트래픽이 아닌 일부(예: 10%)에만 먼저 배포해 문제가 없으면 단계적으로 확대하는 방식입니다. Kubernetes 기본 Deployment로는 하기 어렵고, Argo Rollouts가 이를 선언적으로 관리해줍니다.
• Argo Rollouts: Kubernetes Deployment를 대체하는 Rollout 리소스를 제공하며, 카나리·블루그린 배포 전략과 자동 분석을 컨트롤러 수준에서 처리합니다.
• ConfigMap / Secret: Kubernetes의 설정 저장 방식입니다. 민감하지 않은 값은 ConfigMap, Slack 토큰 같은 자격증명은 Secret에 분리합니다.

Vault나 External Secrets는 Secret을 안전하게 GitOps로 관리할 때 쓰는 도구인데, 이 글의 주제는 아닙니다. External Secrets Operator나 HashiCorp Vault 문서를 참고해보시면 좋습니다.

알림 파이프라인의 전체 흐름

Argo Rollouts Notifications는 argoproj/notifications-engine을 기반으로 합니다. Argo CD 알림도 같은 엔진을 씁니다. 두 도구를 함께 운영하는 팀이라면 설정 방식을 금방 익힐 수 있습니다.

이벤트가 발생했을 때 알림이 흐르는 경로를 순서대로 따라가보면 이렇습니다.

AnalysisRun 실패 (오류율 임계값 초과) → Rollout 자동 Abort (카나리 롤백 시작) → Notifications Controller가 Rollout 상태 변화를 감지 → ConfigMap에 정의된 트리거 조건을 평가 → Slack #deploy-failures 채널로 메시지 발송 → PagerDuty Events API로 인시던트 생성

AnalysisRun — Argo Rollouts가 카나리/블루그린 배포 중 자동 생성하는 분석 실행 단위입니다. Prometheus, Datadog, New Relic 등 외부 메트릭 소스에서 값을 가져와 성공/실패를 판정하고, 실패 시 롤백을 트리거합니다.

Notifications Controller — Argo Rollouts v1.x에서 알림 처리 기능은 rollouts-controller에 내장되어 있습니다. 별도 컨트롤러를 배포할 필요가 없습니다. GitHub의 notifications-install.yaml은 기본 ConfigMap 템플릿/트리거 모음을 한 번에 설치하는 편의 파일이며, 커스텀 설정을 처음부터 작성할 때는 필수가 아닙니다. 로그는 kubectl logs -n argo-rollouts -l app.kubernetes.io/name=argo-rollouts로 확인할 수 있습니다.

네 가지 핵심 구성요소

실제로 설정에 손을 대기 전에 구성요소 네 가지를 머릿속에 정리해두면 훨씬 수월합니다.

ConfigMap과 Secret을 분리하는 방식이 처음엔 번거롭게 느껴질 수 있는데, GitOps 관점에서는 당연한 설계입니다. 설정(ConfigMap)은 Git에 커밋하고, 자격증명(Secret)은 Vault나 External Secrets로 관리하는 흐름과 자연스럽게 맞아 떨어집니다.

v1.7에서 달라진 것 — .analysisRuns 배열 접근

솔직히 v1.7 이전까지는 알림 메시지에 "롤백이 발생했습니다"라고만 적을 수 있어서 온콜 입장에서 컨텍스트가 너무 부족했습니다. v1.7부터 템플릿 안에서 .analysisRuns 배열을 참조할 수 있게 되어, 어떤 메트릭이 얼마나 초과했는지를 알림 메시지에 직접 담을 수 있게 됐습니다. 이게 생각보다 운영 경험에 큰 차이를 만들어 줍니다.

실전 적용

아래 네 단계는 순서대로 적용하는 것을 권장합니다. Step 1~2가 클러스터에 배포된 다음 Step 3로 넘어가야 알림 연결이 정상 작동합니다.

Step 1: ConfigMap으로 서비스·템플릿·트리거 선언하기

모든 설정의 시작점은 argo-rollouts-notification-configmap입니다. 저는 ConfigMap을 먼저 배포해서 구조를 검증한 다음 annotation을 붙이는 순서를 선호하는데, 어디서 오류가 났는지 범위를 좁히기 훨씬 쉽기 때문입니다.

# argo-rollouts-notification-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: argo-rollouts-notification-configmap
  namespace: argo-rollouts
data:
  # $slack-token은 같은 네임스페이스의 Secret 키 이름과 정확히 일치해야 합니다
  service.slack: |
    token: $slack-token
 
  # serviceKeys의 키 이름("production")이 subscription annotation의 채널명이 됩니다
  service.pagerduty-v2: |
    serviceKeys:
      production: $pagerduty-integration-key
 
  # AnalysisRun 실패 메시지 템플릿
  # attachments는 Slack 공식 deprecated API입니다. 신규 구성은 Block Kit(blocks 필드)을 권장합니다
  template.analysis-run-failed: |
    message: |
      :x: *AnalysisRun 실패* — 롤백이 시작되었습니다
      Rollout: {{.rollout.metadata.name}}
      Namespace: {{.rollout.metadata.namespace}}
    slack:
      blocks: |
        [{
          "type": "header",
          "text": {
            "type": "plain_text",
            "text": "배포 실패: {{.rollout.metadata.name}}",
            "emoji": true
          }
        }, {
          "type": "section",
          "fields": [
            {
              "type": "mrkdwn",
              "text": "*Namespace*\n{{.rollout.metadata.namespace}}"
            },
            {
              "type": "mrkdwn",
              "text": "*Strategy*\n{{if .rollout.spec.strategy.canary}}Canary{{else}}BlueGreen{{end}}"
            },
            {
              "type": "mrkdwn",
              "text": "*Image*\n`{{(index .rollout.spec.template.spec.containers 0).image}}`"
            }
          ]
        }]
 
  # 롤백(Abort) 템플릿 — PagerDuty 인시던트 생성용
  # 템플릿 키에서 "template." 접두사를 뺀 값("rollout-aborted")이
  # trigger의 send 배열에서 참조하는 이름이 됩니다
  template.rollout-aborted: |
    message: "롤백 발생: {{.rollout.metadata.name}}"
    pagerdutyV2:
      summary: "{{.rollout.metadata.name}} 롤백 발생 — {{.rollout.metadata.namespace}}"
      severity: critical
      source: "argo-rollouts"
      component: "{{.rollout.metadata.name}}"
 
  # on-analysis-run-failed: 메트릭 수집은 성공했지만 임계값을 초과한 경우
  # on-analysis-run-error:  Prometheus 연결 실패 등 메트릭 수집 자체가 불가능한 경우
  # 둘 다 결국 롤백으로 이어지므로 같은 템플릿으로 처리합니다
  trigger.on-analysis-run-failed: |
    - send: [analysis-run-failed]
 
  trigger.on-analysis-run-error: |
    - send: [analysis-run-failed]
 
  trigger.on-rollout-aborted: |
    - send: [rollout-aborted]

on-analysis-run-failed와 on-analysis-run-error의 차이가 처음엔 헷갈릴 수 있는데, failed는 Prometheus가 오류율을 정상 수집했지만 그 값이 임계값을 초과한 경우이고, error는 Prometheus 서버 연결이 안 되거나 쿼리 실행이 실패해서 메트릭을 아예 가져오지 못한 경우입니다. 운영 중 error가 빈번하게 발생한다면 알림보다 메트릭 수집 인프라를 먼저 점검하는 게 우선입니다.

Step 2: Secret으로 자격증명 분리하기

여기서 처음에 막히는 경우가 많습니다. ConfigMap의 $변수명과 Secret의 키 이름이 정확히 일치해야 자동으로 바인딩되고, Secret은 ConfigMap과 반드시 같은 네임스페이스에 있어야 합니다.

# argo-rollouts-notification-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: argo-rollouts-notification-secret
  namespace: argo-rollouts
type: Opaque
stringData:
  slack-token: "xoxb-your-slack-bot-token"
  pagerduty-integration-key: "your-pagerduty-v2-integration-key"

실제 운영 환경에서는 stringData에 직접 값을 넣기보다 External Secrets Operator나 Vault Agent Injector로 주입하는 방식이 더 안전합니다. 이 예시는 구조를 이해하기 위한 참고용입니다.

PagerDuty Events API v2 vs Incidents API — Argo Rollouts는 두 가지 PagerDuty 통합을 지원합니다. service.pagerduty-v2는 Events API v2(자동 중복 제거, 이벤트 기반)를 사용하고, service.pagerduty는 Incidents API를 직접 호출합니다. 새로 구성하는 경우라면 pagerduty-v2를 권장합니다.

Step 3: Rollout 리소스에 subscription annotation 추가하기

ConfigMap에 아무리 잘 설정해도, Rollout 리소스에 subscription annotation이 없으면 알림은 발송되지 않습니다. 이 부분이 빠져서 한참 디버깅했던 경험이 있어서, 잊기 쉬운 단계라는 걸 강조하고 싶습니다.

# rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-service
  namespace: my-team
  annotations:
    # AnalysisRun 실패(임계값 초과) 시 → Slack #deploy-failures
    notifications.argoproj.io/subscribe.on-analysis-run-failed.slack: "deploy-failures"
 
    # AnalysisRun 오류(메트릭 수집 실패) 시 → 동일 채널
    notifications.argoproj.io/subscribe.on-analysis-run-error.slack: "deploy-failures"
 
    # 롤백 발생 시 → Slack 두 채널 동시 + PagerDuty production 서비스 키
    notifications.argoproj.io/subscribe.on-rollout-aborted.slack: "incidents,deploy-failures"
    notifications.argoproj.io/subscribe.on-rollout-aborted.pagerduty-v2: "production"
spec:
  # ... 이하 Rollout 스펙

annotation 키의 구조는 notifications.argoproj.io/subscribe.{트리거명}.{서비스명}: "{채널명}" 형식입니다. Slack 채널은 쉼표로 여러 개를 지정하면 동시에 발송됩니다.

Step 4: Prometheus 기반 AnalysisTemplate — 자동 롤백의 출발점

알림만 설정하면 절반입니다. AnalysisRun이 실제로 실패하려면 AnalysisTemplate이 정의되어 있어야 하고, 그 결과가 알림 파이프라인을 작동시킵니다.

Spring Boot 서비스를 예로 들면, HTTP 5xx 오류율을 기준으로 배포 성공 여부를 판단하는 템플릿을 다음과 같이 구성할 수 있습니다.

# analysis-template.yaml
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: http-error-rate
  namespace: my-team
spec:
  args:
    # namespace를 인자로 받아 여러 팀에서 재사용할 수 있게 분리합니다
    - name: namespace
      value: my-team
  metrics:
    - name: error-rate
      interval: 5m
      count: 3
      failureLimit: 1
      provider:
        prometheus:
          address: http://prometheus-server.monitoring.svc.cluster.local
          query: |
            sum(rate(http_requests_total{
              namespace="{{args.namespace}}",
              status=~"5.."
            }[5m]))
            /
            sum(rate(http_requests_total{
              namespace="{{args.namespace}}"
            }[5m]))
      # 두 조건 사이에 "회색 지대"를 두어 경계값에서의 모호한 동작을 방지합니다
      # 1~2% 구간은 Inconclusive 상태로 남아 사람이 판단할 여지가 생깁니다
      successCondition: result[0] < 0.01    # 오류율 1% 미만 → 성공
      failureCondition: result[0] >= 0.02   # 오류율 2% 이상 → 실패

namespace를 하드코딩하지 않고 args로 분리했습니다. 네임스페이스 이름이 바뀌거나 여러 팀이 같은 템플릿을 쓸 때 일일이 수정하지 않아도 됩니다.

successCondition과 failureCondition의 임계값을 의도적으로 다르게 설정한 점도 주목할 만합니다. 두 값을 동일하게 설정하면 경계값(예: 정확히 1%)에서 동작이 모호해집니다. 실무에서 장애 대응 중에 "왜 이게 실패도 성공도 아니지?"라는 혼란이 생기면 꽤 당황스럽습니다. 1~2% 구간을 Inconclusive로 두면, 3번 측정(count: 3) 동안 미결 상태가 반복될 경우 배포가 hold 상태로 유지되어 사람이 직접 판단할 수 있는 여지가 생깁니다.

장단점 분석

장점

단점 및 주의사항

운영을 거쳐보면서 실제로 가장 많이 만난 문제는 중복 발송이었습니다. 배포 빈도가 높은 서비스에서는 하나의 롤백에 알림이 3~4개씩 연달아 오는 경험을 했습니다. 특히 스테이징 환경에서 의도적인 실패 테스트가 많아지니 채널이 빠르게 노이즈로 가득 찼고, 결국 팀원들이 알림을 무시하게 됐습니다. staging은 별도 채널로 분리하거나 트리거에 조건을 추가해 필터링하는 방식으로 해결했습니다.

실무에서 가장 흔한 실수

1. Secret과 ConfigMap의 네임스페이스가 다른 경우 — $slack-token 참조가 조용히 실패하면서 토큰 없이 API를 호출해 인증 오류가 납니다. kubectl get configmap,secret -n argo-rollouts로 두 리소스가 같은 네임스페이스에 있는지 먼저 확인해보시면 좋습니다.

2. annotation 키의 트리거명 오타 — on-analysis-run-faild처럼 오타가 있어도 오류 없이 그냥 동작하지 않습니다. kubectl argo rollouts notifications trigger get 명령어로 트리거 목록을 먼저 확인한 후 annotation을 작성하는 것이 안전합니다. kubectl argo rollouts 플러그인이 설치되어 있지 않다면 공식 설치 문서를 참고해 먼저 설치해주시면 됩니다.

3. PagerDuty serviceKey 이름과 annotation 채널명 불일치 — ConfigMap에서 serviceKeys.production으로 정의했는데 annotation에 pagerduty-v2: "prod"라고 적으면 발송이 되지 않습니다. service.pagerduty-v2의 키 이름과 annotation의 채널명이 정확히 일치해야 합니다.

마치며

이 파이프라인을 갖추고 나면, 한밤중 롤백이 발생해도 온콜 엔지니어는 PagerDuty 모바일 알림과 Slack 메시지로 즉시 어떤 서비스의 어느 이미지에서 문제가 생겼는지까지 확인할 수 있게 됩니다. 아침에 출근해서 Slack 검색창에 'rollback'을 치는 상황은 더 이상 없어도 됩니다.

지금 바로 시작해볼 수 있는 3단계입니다.

1. ConfigMap과 Secret을 먼저 배포하고 dry-run으로 검증 — kubectl apply -f argo-rollouts-notification-configmap.yaml 후, 아래 명령어로 실제 Slack 메시지가 전달되는지 확인해볼 수 있습니다. kubectl argo rollouts 플러그인이 사전에 설치되어 있어야 합니다.

   bash

   kubectl argo rollouts notifications template notify \
     analysis-run-failed {rollout-name} -n {namespace}

   여기서 오류가 없으면 핵심 경로가 검증된 것입니다.

2. 스테이징 Rollout에 annotation을 추가하고 실패 시나리오를 재현 — 테스트용 AnalysisTemplate에서 failureLimit: 0으로 설정하면 첫 번째 측정에서 바로 실패 판정이 나서 알림 파이프라인을 빠르게 검증해볼 수 있습니다.

3. PagerDuty 에스컬레이션 정책을 연동하고 운영 Rollout에 점진적으로 적용 — 스테이징에서 검증이 끝났다면, 트래픽이 적은 서비스부터 on-rollout-aborted.pagerduty-v2 annotation을 추가해나가는 것이 안전합니다. 앞서 언급한 알림 지연(30초~수 분)을 고려해 PagerDuty 에스컬레이션 정책의 첫 번째 단계 대기 시간을 5분 이상으로 설정해두는 것도 좋습니다.

참고 자료

• Argo Rollouts Notifications 공식 문서 | Argo Rollouts
• Slack 통합 공식 문서 | Argo Rollouts
• PagerDuty V2 통합 공식 문서 | Argo Rollouts
• PagerDuty 통합 공식 문서 | Argo Rollouts
• Best Practices | Argo Rollouts
• Analysis & Progressive Delivery | Argo Rollouts
• notifications-install.yaml | GitHub argoproj/argo-rollouts
• Argo Rollouts v1.7 Release Candidate | Argo 공식 블로그
• Notifications for Argo | Argo 공식 블로그
• Progressive Delivery with Argo Rollouts: Canary with Analysis | InfraCloud
• Automating Rollbacks in Spring Boot with Argo Rollouts and Prometheus | Medium
• Implementing Production-Grade Progressive Delivery with Automated SLO-Based Rollbacks | Medium
• Stop Watching the Argo CD Dashboard: Set Up Slack and PagerDuty Notifications | burrell.tech
• Argo Rollouts GitHub Releases | GitHub