Canary Release Metric Gate 설계

도입

Canary 배포는 작은 비율로 위험을 제한하는 전략이지만, 관측 게이트가 없으면 단순한 단계 배포에 불과하다. 많은 팀이 배포 비율만 조정하고 지표 해석 기준을 명확히 두지 않아 승격 시점을 감으로 결정한다. 이 글은 canary 승격을 자동화하기 위한 metric gate 설계를 단계별로 제시한다.

Canary Release Metric Gate 설계 커버 — Wikimedia Commons 기반 무료 이미지

문제 정의

게이트 없는 canary는 오히려 불안정하다. 다음 증상이 보이면 설계를 개선해야 한다.

error rate와 latency를 절대값으로만 비교해 트래픽 변화 영향을 반영하지 못한다.
business KPI와 시스템 KPI가 분리되어 품질 판단이 편향된다.
승격/중단 의사결정 권한이 모호해 장애 대응이 늦다.

핵심은 KPI를 계층화하는 것이다. 시스템 안정성, 사용자 경험, 비즈니스 전환율을 동시에 본다.

핵심 개념

관점	설계 기준	검증 포인트
시스템 게이트	error rate, p95 latency	기준 대비 증감률
사용자 게이트	LCP, checkout success	세그먼트별 편차
비즈니스 게이트	전환율/취소율	base 대비 통계 유의성
승격 정책	10->25->50->100 단계	각 단계 관찰 시간

게이트 설계는 배포 도구보다 조직 합의가 중요하다. 어떤 지표가 실패면 즉시 중단하는지 사전에 합의해야 자동화가 의미를 가진다.

코드 예시 1: 게이트 판정 함수

type GateInput = {
  errorRateDiffPct: number;
  latencyP95DiffMs: number;
  conversionDiffPct: number;
};

export function evaluateCanaryGate(input: GateInput) {
  if (input.errorRateDiffPct > 0.5) return "ROLLBACK";
  if (input.latencyP95DiffMs > 120) return "HOLD";
  if (input.conversionDiffPct < -1.0) return "ROLLBACK";
  return "PROMOTE";
}

코드 예시 2: Argo Rollouts metric gate 예시

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: canary-gate
spec:
  metrics:
    - name: error-rate
      successCondition: result < 1.5
      provider:
        prometheus:
          query: sum(rate(http_requests_total{status=~"5.."}[5m]))
    - name: p95-latency
      successCondition: result < 700
      provider:
        prometheus:
          query: histogram_quantile(0.95, sum(rate(http_request_duration_ms_bucket[5m])) by (le))

아키텍처 흐름

Mermaid diagram rendering...

트레이드오프

게이트 기준을 엄격히 하면 안전하지만 배포 속도가 느려질 수 있다.
자동 승격은 운영 부담을 줄이지만 지표 신뢰도가 낮으면 오판 위험이 있다.
비즈니스 지표를 포함하면 품질 판단이 정확해지지만 분석 지연 시간이 늘어난다.

정리

Canary의 가치는 소량 노출 자체가 아니라 검증 자동화에 있다. 계층화된 metric gate를 설계하고 승격/중단 규칙을 코드화하면 배포 품질을 일관되게 유지할 수 있다.

이미지 출처

Cover: source link
License: CC BY-SA 3.0 / Author: Abigor
Note: Wikimedia Commons 무료 라이선스 이미지를 다운로드 후 1600px 기준 JPG로 최적화했습니다.

도입