개인정보처리방침© 2026 DEV BAK - 기술블로그. All rights reserved.
DEV BAK - 기술블로그
DevOps

Argo Events로 Argo Rollouts 롤백을 감지해 Jira 인시던트와 Confluence 포스트모템을 자동 생성하는 방법

새벽 두 시, 카나리 배포가 조용히 롤백되고 있습니다. Argo Rollouts는 척척 이전 버전으로 되돌아가지만, 그 사실을 아는 사람은 아무도 없습니다. 다음 날 아침 출근해서야 Slack에 뒤늦게 올라온 메시지로 상황을 파악하고, 포스트모템은 일주일 뒤에야 허겁지겁 작성합니다. 저도 이 상황을 꽤 오랫동안 반복했습니다.

이 글에서는 Argo Rollouts의 Notifications Engine과 Argo Events를 연결해, 롤백이 감지되는 순간 Jira 인시던트가 자동으로 열리고 Confluence 포스트모템 페이지 초안이 만들어지는 워크플로우를 구성하는 방법을 다룹니다. 스테이징 환경이 갖춰져 있다면 이 글을 따라가며 30분 안에 이벤트 수신까지 확인해볼 수 있습니다.

사전 조건 한 가지만 짚고 들어가겠습니다: Kubernetes 클러스터와 kubectl 접근 권한, 그리고 Argo Rollouts가 설치된 환경이 필요합니다. Secret, ConfigMap, 네임스페이스 같은 Kubernetes 기초 개념은 이미 알고 있다는 전제로 진행하고, Argo Events와 Atlassian API는 처음이어도 괜찮습니다.


핵심 개념

세 가지 컴포넌트, 하나의 흐름

이 자동화의 뼈대는 두 개의 Argo 프로젝트입니다. Argo Rollouts는 Kubernetes 위에서 Canary·Blue/Green 배포를 관리하고 자동 롤백을 처리하는 컨트롤러이고, Argo Events는 배포 상태 변화를 이벤트로 받아 외부 API 호출까지 이어주는 이벤트 기반 자동화 프레임워크입니다.

전체 흐름을 한 줄로 요약하면 이렇습니다.

Argo Rollouts 롤백 감지
  → Notifications Engine이 Webhook 발송
  → Argo Events Webhook EventSource가 수신
  → EventBus(NATS JetStream)를 통해 Sensor에 전달
  → Sensor의 HTTP Trigger로 Jira REST API 호출 → 인시던트 이슈 생성
  → 동시에 Confluence REST API 호출 → 포스트모템 페이지 초기화

Argo Events를 처음 접하면 구성요소 이름이 헷갈리는데, 딱 세 가지만 기억하면 됩니다.

컴포넌트 역할 비유
EventSource 외부 이벤트를 수신하는 정의체 귀
EventBus 이벤트를 전달하는 내부 채널 신경
Sensor 조건을 평가하고 트리거를 실행하는 컴포넌트 뇌 + 손

EventBus와 NATS JetStream: EventBus는 EventSource와 Sensor 사이의 메시지 버스입니다. 내부적으로 NATS JetStream을 사용하며, 별도 설치 없이 EventBus 리소스를 선언하면 Argo Events가 NATS 파드를 자동으로 띄워줍니다. 기본값이 단일 노드라 프로덕션에서는 반드시 HA 설정을 해야 합니다 — 이 부분은 장단점 섹션에서 자세히 다룹니다.

CloudEvents: Argo Events가 준수하는 이벤트 형식 표준(v1.0). source, type, data 등의 필드를 정형화해서 다른 시스템과의 연동을 쉽게 만들어줍니다.

Argo Rollouts Notifications Engine

Rollouts v1.2.x 이후부터 Notifications Engine이 안정화되어 프로덕션 적용이 가능합니다. 롤백 관련해서 주로 쓰이는 이벤트 타입은 아래 세 가지입니다.

  • on-rollout-degraded: Rollout이 Degraded 상태로 전환될 때
  • on-analysis-run-failed: AnalysisRun(메트릭 분석)이 실패할 때
  • on-rollout-aborted: 롤아웃이 중단(Abort)될 때

AnalysisRun: Argo Rollouts가 배포 중 Prometheus 메트릭, Webhook 등으로 품질을 검증하는 객체. AnalysisRun이 실패하면 자동 롤백이 트리거됩니다.

Rollout 오브젝트의 애노테이션 하나로 알림 구독을 제어할 수 있어서, 특정 서비스만 선택적으로 인시던트 자동화를 활성화할 수 있습니다.

yaml
metadata:
  annotations:
    notifications.argoproj.io/subscribe.on-rollout-degraded.webhook: ""

두 가지 이벤트 수신 전략

롤백 이벤트를 받는 방식은 두 가지가 있습니다. 처음엔 어떤 걸 써야 할지 헷갈렸는데, 판단 기준은 생각보다 단순합니다.

방식 A — Rollouts Notifications Engine → Webhook EventSource

Rollouts가 직접 Webhook을 발송하고, Argo Events가 그 Webhook을 받습니다. 이미 Notifications Engine을 운영 중이거나, 알림 조건을 Rollout 오브젝트 단위로 세밀하게 제어하고 싶다면 A가 더 자연스러운 확장입니다.

방식 B — Resource EventSource로 Rollout 직접 Watch

Argo Events가 Kubernetes API를 통해 Rollout 리소스를 직접 감시합니다. Notifications Engine 설정 없이 빠르게 시작하거나, 특정 네임스페이스의 모든 Rollout을 일괄 감시하고 싶다면 B가 설정이 더 간단합니다. 대신 Degraded 상태 필터링을 Sensor 레벨에서 직접 처리해야 합니다.


장단점 분석

실전 예시로 들어가기 전에 이 스택을 선택할지 판단하는 데 도움이 될 정보를 먼저 정리합니다.

장점

항목 내용
Kubernetes 네이티브 Argo Events·Rollouts 모두 CNCF 프로젝트. YAML로 선언적 관리, GitOps와 자연스럽게 통합됩니다
이벤트 소스 다양성 Webhook 외에도 Kafka, S3, Pub/Sub 등 20가지 이상의 소스를 단일 플랫폼에서 처리할 수 있습니다
컨텍스트 자동 보존 롤백 발생 시점의 이미지 태그, 네임스페이스, 타임스탬프가 자동으로 Jira/Confluence에 기록됩니다
낮은 운영 오버헤드 워크플로우 변경을 코드로 추적·버전 관리할 수 있어 GitOps 파이프라인과 자연스럽게 통합됩니다
세밀한 필터링 라벨 셀렉터·필드 셀렉터로 원하는 Rollout만 선택적으로 감지할 수 있습니다

단점 및 주의사항

항목 내용 대응 방안
학습 곡선 EventSource → EventBus → Sensor → Trigger 4계층 구조, 초기 설정이 복잡합니다 공식 예제 저장소의 샘플을 기반으로 점진적으로 확장하는 것이 낫습니다
NATS JetStream 의존성 기본값이 단일 노드라 Pod 재시작 시 이벤트가 유실될 수 있습니다. 저도 처음에 이 상황을 겪었습니다 EventBus 리소스에서 nats.native.replicas: 3 이상으로 설정해두는 것이 훨씬 안전합니다
Jira API 레이트 리밋 Jira Cloud는 사용자당 분당 300건 제한이 있습니다 Sensor에 retryStrategy를 설정하고, 대규모 동시 롤백 시 Argo Workflows를 큐잉 레이어로 추가하는 방법을 고려해볼 수 있습니다
중복 인시던트 방지 하나의 롤백에서 여러 MODIFIED 이벤트가 발생할 수 있습니다 Sensor의 filters.data로 정확한 상태 전환만 처리하고, Jira에서 중복 이슈 검색 후 생성하는 로직을 추가하는 것이 좋습니다
포스트모템 품질 한계 자동 초기화된 문서는 구조만 제공합니다 근본 원인 분석은 담당자가 직접 보완해야 하며, 이 자동화의 목표는 '시작점 확보'입니다

실무에서 가장 흔한 실수

  1. EventBus를 단일 노드로 두는 것: 기본 설정 그대로 프로덕션에 올리면 Pod 재시작 시 이벤트를 통째로 날려먹을 수 있습니다. nats.native.replicas: 3 이상으로 설정해두는 것이 필수입니다.
  2. Jira/Confluence API 자격증명을 YAML에 직접 쓰는 것: ConfigMap이나 Sensor YAML에 토큰을 넣으면 GitOps 리포지토리에 그대로 올라갑니다. 팀 전체 자격증명을 로테이션하는 사태로 이어지기 전에 secretKeyRef 참조나 External Secrets Operator를 쓰는 것이 훨씬 낫습니다.
  3. 모든 Rollout에 알림을 일괄 적용하는 것: 개발·스테이징 환경의 잦은 롤백까지 인시던트로 만들면 노이즈가 너무 많아집니다. Rollout 애노테이션으로 프로덕션 네임스페이스 대상만 선택적으로 활성화하는 것이 좋습니다.

실전 적용

YAML을 적용할 순서는 EventBus → EventSource → Sensor 순입니다. 이 순서를 지켜야 의존 관계 오류 없이 배포됩니다.

1단계: 롤아웃 알림 설정

Argo Rollouts가 롤백 이벤트를 Webhook으로 발송하도록 설정합니다. 이때 Jira에 필요한 필수 필드(jiraProject, jiraIssueType)를 페이로드에 미리 포함해두면 Sensor 쪽 코드가 훨씬 깔끔해집니다.

yaml
# argo-rollouts-notification-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: argo-rollouts-notification-cm
  namespace: argo-rollouts
data:
  service.webhook.argo-events: |
    url: http://argo-events-webhook-eventsource-svc.argo-events.svc.cluster.local:12000/rollout
    headers:
      - name: Content-Type
        value: application/json
    retryMax: 3
    retryWaitMin: 5s
    retryWaitMax: 30s
 
  template.rollback-alert: |
    webhook:
      argo-events:
        method: POST
        body: |
          {
            "rolloutName": "{{.rollout.metadata.name}}",
            "namespace": "{{.rollout.metadata.namespace}}",
            "phase": "{{.rollout.status.phase}}",
            "message": "{{.rollout.status.message}}",
            "timestamp": "{{now | date \"2006-01-02T15:04:05Z07:00\"}}",
            "jiraProject": "OPS",
            "jiraIssueType": "Incident"
          }
 
  trigger.on-rollout-degraded: |
    - send: [rollback-alert]

방식 A를 선택했다면, 이 Webhook을 수신할 EventSource도 함께 배포해야 합니다.

yaml
# rollout-webhook-eventsource.yaml
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: rollout-webhook-eventsource
  namespace: argo-events
spec:
  service:
    ports:
      - port: 12000
        targetPort: 12000
  webhook:
    rollout:
      port: "12000"
      endpoint: /rollout
      method: POST

방식 B를 선택했다면, Rollout 리소스를 직접 감시하는 EventSource를 배포합니다. Degraded 상태 필터링은 Sensor에서 처리하므로 여기서는 MODIFIED 이벤트만 수신합니다.

yaml
# rollout-resource-eventsource.yaml
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: rollout-watcher
  namespace: argo-events
spec:
  resource:
    rollout-degraded:
      group: argoproj.io
      version: v1alpha1
      resource: rollouts
      namespace: production
      eventTypes:
        - MODIFIED

2단계: EventBus 구성

EventSource와 Sensor 사이에서 이벤트를 전달할 EventBus를 배포합니다. Sensor보다 먼저 배포해야 합니다.

yaml
# eventbus.yaml
apiVersion: argoproj.io/v1alpha1
kind: EventBus
metadata:
  name: default
  namespace: argo-events
spec:
  nats:
    native:
      replicas: 3
      auth: token

3단계: Sensor 연결 — Jira 인시던트 + Confluence 포스트모템 동시 생성

Sensor가 Webhook을 받아 두 가지 HTTP Trigger를 동시에 실행합니다. status.phase == "Degraded" 조건 필터로 불필요한 중복 실행을 방지하는 부분이 핵심입니다.

Jira Cloud REST API v3의 POST /issue는 fields.project.key와 fields.issuetype.name이 필수값입니다. 이 두 필드가 빠지면 400 오류가 발생합니다. 1단계에서 페이로드에 미리 포함해둔 덕분에 여기서는 깔끔하게 매핑만 하면 됩니다.

ADF (Atlassian Document Format): Jira Cloud REST API v3에서 description 필드는 단순 문자열이 아닌 JSON 트리 구조를 요구합니다. 최소 구조는 { "type": "doc", "version": 1, "content": [{ "type": "paragraph", "content": [{ "type": "text", "text": "..." }] }] } 입니다. Argo Events payload로 description.content[0].content[0].text 경로에 텍스트를 주입하면 이 구조를 충족할 수 있습니다.

yaml
# rollback-sensor.yaml
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: rollback-incident-sensor
  namespace: argo-events
spec:
  dependencies:
    - name: rollout-dep
      eventSourceName: rollout-webhook-eventsource  # 방식 B라면 rollout-watcher
      eventName: rollout
      filters:
        data:
          - path: body.phase
            type: string
            value:
              - "Degraded"
  triggers:
    # 트리거 1: Jira 인시던트 생성
    - template:
        name: create-jira-incident
        http:
          url: "https://$(JIRA_DOMAIN)/rest/api/3/issue"
          method: POST
          headers:
            - name: Authorization
              valueFrom:
                secretKeyRef:
                  name: atlassian-credentials
                  key: basic-auth
            - name: Content-Type
              value: application/json
          # payload: 이벤트 데이터를 request body의 특정 경로에 복사
          payload:
            - src:
                dependencyName: rollout-dep
                dataKey: body.jiraProject
              dest: body.fields.project.key
            - src:
                dependencyName: rollout-dep
                dataKey: body.jiraIssueType
              dest: body.fields.issuetype.name
            - src:
                dependencyName: rollout-dep
                dataKey: body.rolloutName
              dest: body.fields.summary
            - src:
                dependencyName: rollout-dep
                dataKey: body.namespace
              dest: body.fields.description.content[0].content[0].text
          # parameters: payload로 구성된 body 값을 prepend/append/override로 수정
          # payload와 달리 연산 변환이 가능하며, 같은 dest에 함께 쓰면 payload 적용 후 parameters가 덮습니다
          parameters:
            - src:
                dependencyName: rollout-dep
                dataKey: body.rolloutName
              dest: body.fields.summary
              operation: prepend
              value: "[INCIDENT] Rollback detected: "
        retryStrategy:
          steps: 3
          duration: 10s
 
    # 트리거 2: Confluence 포스트모템 페이지 초기화
    - template:
        name: create-confluence-postmortem
        http:
          url: "https://$(CONFLUENCE_DOMAIN)/wiki/rest/api/content"
          method: POST
          headers:
            - name: Authorization
              valueFrom:
                secretKeyRef:
                  name: atlassian-credentials
                  key: basic-auth
            - name: Content-Type
              value: application/json
          payload:
            - src:
                dependencyName: rollout-dep
                dataKey: body.rolloutName
              dest: body.title
          parameters:
            - src:
                dependencyName: rollout-dep
                dataKey: body.rolloutName
              dest: body.title
              operation: prepend
              value: "Postmortem — Rollback: "
        retryStrategy:
          steps: 3
          duration: 10s

$(JIRA_DOMAIN)과 $(CONFLUENCE_DOMAIN)은 하드코딩 대신 ConfigMap에서 주입받는 것이 좋습니다.

yaml
# atlassian-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: atlassian-config
  namespace: argo-events
data:
  JIRA_DOMAIN: "your-team.atlassian.net"
  CONFLUENCE_DOMAIN: "your-team.atlassian.net"

4단계: Confluence 포스트모템 페이지 본문 구성

Confluence REST API의 POST /wiki/rest/api/content를 쓸 때, 페이지 본문을 storage format으로 구성해야 합니다. 롤백 컨텍스트를 자동으로 채워 넣는 템플릿을 Sensor 외부에서 ConfigMap으로 관리하면 유지보수가 편합니다.

json
{
  "type": "page",
  "title": "Postmortem — Rollback: my-service [2026-05-26]",
  "space": { "key": "INCIDENTS" },
  "ancestors": [{ "id": "123456" }],
  "body": {
    "storage": {
      "value": "<h2>인시던트 개요</h2><table><tr><th>항목</th><th>내용</th></tr><tr><td>서비스</td><td>{{rolloutName}}</td></tr><tr><td>네임스페이스</td><td>{{namespace}}</td></tr><tr><td>발생 시각</td><td>{{timestamp}}</td></tr><tr><td>연관 Jira</td><td>{{jiraIssueKey}}</td></tr></table><h2>타임라인</h2><p>(작성 필요)</p><h2>근본 원인</h2><p>(작성 필요)</p><h2>재발 방지 액션 아이템</h2><p>(작성 필요)</p>",
      "representation": "storage"
    }
  }
}

ancestors.id 조회 방법: 팀마다 다른 값이라 직접 확인이 필요합니다. GET /wiki/rest/api/content?title=<부모페이지명>&spaceKey=INCIDENTS로 부모 페이지의 ID를 조회한 뒤, 해당 값을 ConfigMap에 저장해두면 재사용하기 편합니다.

5단계: 시크릿 관리 — External Secrets Operator 연동

솔직히 말하면, 처음 연동할 때 ConfigMap에 Base64 인코딩 토큰을 그대로 넣었다가 GitOps 리포에 올라가는 바람에 팀 전체 자격증명을 로테이션한 적이 있습니다. 그 이후로는 External Secrets Operator(ESO)를 반드시 씁니다. AWS Secrets Manager나 Vault와 연동하는 패턴이 실무에서 많이 쓰입니다.

yaml
# atlassian-external-secret.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: atlassian-credentials
  namespace: argo-events
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: atlassian-credentials
  data:
    - secretKey: basic-auth
      remoteRef:
        key: prod/atlassian
        property: basic-auth-token

마치며

롤백이 일어나는 순간 인시던트 문서가 자동으로 열린다는 건, 아무도 깨어 있지 않아도 대응의 첫 삽이 떠진다는 뜻입니다. 포스트모템 품질은 결국 사람이 채워야 하지만, 시작점을 자동으로 확보하는 것만으로도 인시던트 대응 속도와 문서화 완성도가 눈에 띄게 달라집니다.

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

  1. Argo Events 설치 상태 확인: kubectl get pods -n argo-events로 EventSource Controller, Sensor Controller, EventBus가 모두 Running 상태인지 확인해볼 수 있습니다. 처음 설치한다면 kubectl apply -f https://github.com/argoproj/argo-events/releases/download/v1.9.2/install.yaml로 시작할 수 있습니다. 릴리스 페이지에서 최신 버전 태그를 확인해 고정하는 것이 재현 가능한 환경을 만드는 데 중요합니다. 이미 Argo를 운영 중이라면 바로 2번으로 넘어가도 됩니다.
  2. 스테이징 환경에서 Resource EventSource 연결: 2단계의 rollout-watcher EventSource를 스테이징 네임스페이스에 적용하고, 실제 Rollout을 수동으로 Degraded 상태로 만들어 이벤트가 잘 수신되는지 kubectl logs로 확인해볼 수 있습니다.
  3. Jira Webhook 테스트: Sensor HTTP Trigger의 url을 실제 Jira API 대신 https://webhook.site 같은 임시 엔드포인트로 먼저 연결해보면, 페이로드 구조를 안전하게 검증한 뒤 실 API로 전환할 수 있습니다.

참고 자료

  • Argo Events 공식 문서 | argoproj.github.io
  • Argo Events GitHub 저장소 | github.com
  • Argo Events — Resource EventSource 설정 | argoproj.github.io
  • Argo Events — HTTP Trigger 문서 | argoproj.github.io
  • Argo Rollouts — Notifications 개요 | argo-rollouts.readthedocs.io
  • Argo Rollouts — Webhook Notification Service | argo-rollouts.readthedocs.io
  • Notifications for Argo | Argo 공식 블로그
  • Tracking k8s resource changes using Argo Events | Kinaxis Engineering Blog
  • Automating Rollbacks in Spring Boot with Argo Rollouts and Prometheus | Medium
  • Jira Cloud Platform REST API — Issues | Atlassian Developer
  • Confluence Cloud REST API v2 | Atlassian Developer
  • Incident postmortem templates | Atlassian
  • Automated Post-Mortem Generation: The Complete Guide for SRE Teams | dev.to
#ArgoRollouts#ArgoEvents#Kubernetes#Jira#Confluence#GitOps#NATS-JetStream#Webhook#ExternalSecretsOperator#Canary배포
공유하기

목차

핵심 개념세 가지 컴포넌트, 하나의 흐름Argo Rollouts Notifications Engine두 가지 이벤트 수신 전략장단점 분석장점단점 및 주의사항실무에서 가장 흔한 실수실전 적용1단계: 롤아웃 알림 설정2단계: EventBus 구성3단계: Sensor 연결 — Jira 인시던트 + Confluence 포스트모템 동시 생성4단계: Confluence 포스트모템 페이지 본문 구성5단계: 시크릿 관리 — External Secrets Operator 연동마치며참고 자료

추천 포스트

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

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

그날 아침 출근 직후, 동료가 Slack 검색창에 'rollback'을 치고 있었습니다. 전날 밤 카나리 배포가 조용히 실패했고, AnalysisRun이 오류율 임계값을 넘어 자동 롤백이 시작됐는데 아무도 몰랐던 거였죠. 온콜 엔지니어는 PagerDuty 알림 대신 아침에 쌓인 에러 로...

2026년 05월 26일읽는 데 23분
Argo Rollouts AnalysisTemplate — Prometheus·Datadog·Webhook으로 카나리 배포 자동 롤백 구현하기
DevOps

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

카나리 배포를 처음 도입했을 때, 저는 꽤 오랫동안 Grafana 대시보드를 뚫어지게 바라보는 것이 배포 프로세스의 일부였습니다. 트래픽 10%를 카나리로 흘리고, 에러율 그래프가 잠잠한 것을 확인한 뒤 수동으로 명령을 날리는 방식이었는데요. 어느 날 밤, P99 레이턴시가 슬금슬금 ...

2026년 05월 26일읽는 데 23분
Argo Rollouts BlueGreen 배포 전략 — 카나리와 다른 점, 그리고 언제 선택해야 하는가
DevOps

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

배포 전략을 고민할 때마다 "카나리로 할까, BlueGreen으로 할까?" 앞에서 잠깐 멈추게 됩니다. 저도 처음엔 카나리가 더 안전하다고 막연히 생각했는데, 막상 DB 스키마를 바꾸는 릴리스를 카나리로 밀어붙였다가 꽤 곤란한 상황을 겪었습니다. 구버전 Pod이 새 스키마를 읽다가 오류...

2026년 05월 26일읽는 데 19분
PR 머지 하나로 Kubernetes 카나리 배포를 자동화하는 ArgoCD + Argo Rollouts 파이프라인
DevOps

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

솔직히 말하면, 처음 카나리 배포를 도입했을 때 저는 배포 스크립트를 직접 손으로 실행하고 있었습니다. 명령어를 터미널에 치고, Slack에 "지금 카나리 5% 올렸습니다" 메시지를 남기고, 30분 뒤에 다시 콘솔에 들어가서 메트릭 확인하고, 또 손으로 가중치를 올리고. 자동화라고 부...

2026년 05월 26일읽는 데 23분
Argo Rollouts 자동 롤백 파이프라인 | Datadog · CloudWatch 멀티 프로바이더 AnalysisTemplate 임계값 단계별 강화 전략
DevOps

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

배포할 때마다 슬랙에서 대기하다가 에러율이 튀면 직접 롤백 명령을 입력하던 시절이 있었습니다. 카나리를 도입하면 이 문제가 해결될 줄 알았는데, 막상 운영해보면 새로운 고민이 생깁니다. "임계값을 얼마로 잡아야 하지?", "5분 기다렸는데 샘플이 너무 적은 거 아닌가?", "분석이 끝나...

2026년 05월 26일읽는 데 20분
Rancher Fleet과 Argo Rollouts를 조합해 500개 Kubernetes 클러스터에 카나리 배포하기 — Blast Radius를 파티션 단위로 제한하는 Progressive Delivery
DevOps

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

솔직히 말하면, 저도 처음 수십 개 클러스터를 동시에 관리해야 할 때 꽤 막막했습니다. 단일 클러스터에서 카나리 배포 하나 굴리는 건 어렵지 않은데, 클러스터가 수백 개로 늘어나는 순간 얘기가 달라집니다. "이 변경이 전체 프로덕션에 터지면 어떡하지?"라는 두려움이 배포를 망설이게 만들...

2026년 05월 26일읽는 데 24분