카나리 배포란? 단계, 지표, 함정 정리

카나리 배포란 새 버전을 운영 트래픽의 일부에만 먼저 내보내고, 기존 버전과 수치를 비교한 뒤 지표가 괜찮을 때만 배포 범위를 넓히는 방식입니다. 배포 자체에 판단 지점이 들어 있는 셈입니다. 변경 사항은 먼저 사용자의 1~5%에 닿고, 지표 점검이 계속 진행할지 되돌릴지를 정합니다. 이 글은 원리, 실패하는 지점, 그리고 무엇을 자동화해야 하는지 다룹니다.

새벽 3시 호출을 Slack 메시지로 바꿔 줄 수 있었던 장애

목요일 16시 40분에 배포가 나갑니다. 결제 서비스의 오류율이 0.2%에서 4%로 올라갑니다. 고객 지원 티켓이 두 시간 뒤에 들어올 때까지 아무도 알아채지 못하고, 그사이 모든 사용자가 새 빌드를 실행하게 됩니다. 마이그레이션이 절반만 적용된 상태라 롤백에만 25분이 걸립니다.

같은 변경을 트래픽 5%에 카나리로 배포했다면 피해가 제한됩니다. 대략 20명 중 1명만 버그를 보게 되고, 대조군과의 비교는 몇 분 안에 실패로 판정되어 파이프라인이 멈춥니다. 사후 분석 문서에는 놓친 장애가 아니라 카나리가 무엇을 잡아냈는지가 남습니다.

이름은 탄광에서 왔습니다. 공기가 치명적으로 변하기 전에 카나리아가 울음을 멈추곤 했습니다. 작은 카나리 집단도 같은 역할을 합니다. 나쁜 릴리스를 막지는 못하지만, 그 피해를 누가 마시게 될지를 제한합니다.

카나리 배포는 실제로 무엇을 하는가

Google SRE Workbook은 카나리를 변경 사항을 일부에만, 시간을 정해 배포하고 이후 롤아웃을 계속할지 판단하는 평가라고 정의합니다. 변경을 실행하는 일부가 카나리이고 나머지 플릿이 대조군입니다. 이 정의가 중요한 이유는 카나리를 느린 배포가 아니라 자기 신뢰성을 대상으로 한 A/B 테스트로 만들어 주기 때문입니다.

일반적인 순서는 다음과 같습니다.

• 트래픽을 받지 않은 상태로 새 버전을 기존 버전 옆에 배포합니다.

• 작은 비율의 트래픽을 새 버전으로 보냅니다. Workbook 예시는 5%입니다.

• 정해진 시간 창, 같은 예시에서는 30분 동안 카나리와 대조군을 비교합니다.

• 다음 단계, 예를 들어 25%, 50%, 100%로 승격하거나, 중단하고 트래픽을 되돌립니다.

흐름 자체는 단순합니다. 어려운 부분은 비교 단계이고, 대부분의 팀은 이를 "누군가 대시보드를 지켜보는 일"로 구현합니다.

카나리, 블루그린, 롤링 중 무엇을 고를까

이 셋은 자주 혼동되므로, 고를 때 중요한 차이를 먼저 짚겠습니다.

• 롤링 업데이트: 인스턴스를 점진적으로 교체합니다. 저렴하고 모든 오케스트레이터에 기본으로 들어 있지만, 대조군과의 비교가 없고 깔끔한 트래픽 분할도 안 됩니다. 끝날 때까지 두 버전이 부하를 나눠 받습니다.

• 블루그린: 완전한 환경을 두 개 두고 트래픽을 한 번에 전환합니다. 롤백은 즉시 가능하지만, 전환 순간의 피해 범위는 전체 사용자 100%입니다. 용량 비용도 두 배입니다.

• 카나리: 실제 트래픽의 통제된 일부를 새 버전으로 보내고 기존 버전과 비교합니다. 피해 범위가 가장 작지만 운영 복잡도가 가장 높습니다.

배포가 깨졌는지 스모크 테스트로 확인할 수 있고 몇 초 안에 되돌릴 수 있다면 블루그린을 고르세요. 실제 트래픽에서만 드러나는 미묘한 회귀, 예를 들어 p99 지연 시간의 점진적 증가, 느린 메모리 누수, 운영 데이터 형태에서만 무너지는 쿼리 플랜이 위험이라면 카나리를 고르세요.

트래픽이 매우 적은 서비스라면 카나리를 건너뛰세요. 시간당 수백 건의 요청에서 5% 조각은 몇 개의 샘플만 줄 뿐 신호가 되지 못합니다. Workbook도 이를 분명히 말합니다. 쿼리가 아주 적으면 다양한 워크로드에 대해 쓸 만한 신호를 얻을 수 없습니다.

1% 카나리가 아마 거짓말을 하고 있는 이유

대부분의 팀이 도입 후 3개월 안에 겪는 실패가 있습니다. 카나리가 트래픽 5%를 받고, 그 요청의 20%가 실패합니다. 서비스 전체 오류율은 0.2%에서 약 1.2%로 올라갑니다. 알림 임계값이 2%라면 아무 알림도 울리지 않습니다.

집계 모니터링은 카나리의 실패를 가립니다. 같은 계산이 SRE Workbook에도 나옵니다. 트래픽의 5%에서 요청의 20%가 실패하는 카나리는 전체 오류율로 보면 1%만 보입니다. 지표를 카나리와 대조군, 즉 모집단별로 나누지 않으면 신호가 분모 속에 묻혀 사라집니다.

그 밖에도 알아둘 함정이 세 가지 있습니다.

• 배포 전후 비교: 카나리 구간을 직전 한 시간과 비교하면 변경과 시간이 뒤섞입니다. 평일과 주말의 트래픽 차이만으로도 실제 회귀를 덮어버릴 수 있습니다. 대신 같은 시간에 돌아가는 대조군과 비교하세요.

• 공유 의존성: 카나리와 대조군이 같은 캐시나 데이터베이스를 쓴다면, 나쁜 카나리가 둘 다를 악화시킬 수 있고 비교 결과는 아무것도 보여주지 않습니다. 장애 도메인을 확인하세요.

• 노이즈가 많은 지표: CPU 사용률은 좋은 게이트가 되지 못합니다. 에러 코드와 지연 시간이 사용자가 실제로 느끼는 문제를 더 잘 반영합니다. Workbook은 후보 지표를 사용자에게 보이는 문제를 얼마나 잘 반영하는지로 순위를 매기고, 열두 개 안팎의 상위 몇 개만 남기라고 권합니다.

배포 전에 게이트 지표를 정하세요, 장애 중에 정하지 말고

SLI에서 출발하세요. 서비스에 가용성 SLI와 지연 시간 SLI가 이미 있다면, 그 두 개가 첫 게이트입니다. 요청 기반 서비스라면 기본 세트는 다음과 같습니다.

• 관찰 구간 동안 대조군 대비 카나리의 오류율(5xx)

• 대조군 대비 카나리의 p99 지연 시간

• 파드별 메모리 증가처럼 변경에 기인하는 포화 신호

• 코호트별로 분리할 수 있다면 결제 완료율 같은 비즈니스 지표 하나

임계값에서 몇 주를 잃는 팀이 많습니다. 너무 빡빡하면 모든 카나리가 노이즈 때문에 중단되고, 엔지니어들은 게이트를 무시하는 법을 배웁니다. 너무 느슨하면 나쁜 빌드가 그대로 통과합니다. 일정을 정해 다시 검토하세요. 여섯 달 동안 아무것도 중단시키지 못한 게이트는 완벽하거나 장식일 뿐이니, 어느 쪽인지 확인해야 합니다.

지표 집계 간격도 카나리 관찰 구간보다 길면 안 됩니다. 5분짜리 카나리에 10분 단위 롤업을 쓰면 모든 것이 흐려집니다.

Kubernetes에서는 Argo Rollouts 카나리 명세가 이 순서를 steps 목록으로 표현합니다. 문서의 형태를 따른 축약본은 다음과 같습니다.

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

문서에서 눈여겨볼 세부 사항이 두 가지 있습니다. 트래픽 라우터가 없으면 가중치는 파드 수로 대략 근사됩니다. 레플리카 10개에서 10%는 카나리 파드 1개와 안정 파드 9개를 뜻합니다. 이는 요청 기준이 아니라 레플리카 계산입니다. 그리고 duration이 없는 pause: {}는 누군가 kubectl argo rollouts promote를 실행할 때까지 무기한 기다립니다. 원하든 원하지 않든 사람이 개입하는 게이트가 됩니다.

분석 단계가 실패하면 롤아웃은 중단됩니다. 투자할 가치가 있는 부분이 바로 여기입니다.

피처 플래그는 안전한 카나리의 다른 절반이다

인프라 카나리는 인스턴스나 파드 단위로 트래픽을 나눕니다. 플래그 기반 카나리는 사용자, 계정, 혹은 대상으로 지정할 수 있는 모든 속성 단위로 나눕니다. 둘은 서로 다른 질문에 답합니다. 첫 번째는 새 빌드가 건강한지 묻고, 두 번째는 새 동작이 받아들여질 만한지 묻습니다. 플래그는 재배포 없이 끌 수 있다는 장점도 있습니다.

플래그 기반 롤아웃에서는 도구 선택이 중요합니다. LaunchDarkly는 가장 성숙한 타겟팅 규칙과 감사 이력을 갖추고 있고, 생태계의 폭에서도 앞섭니다. 다만 대규모 엔터프라이즈 가격은 플랫폼 리더들이 흔히 불만으로 꼽는 부분입니다.

Statsig은 실험 기능과 플래그를 한 제품에 묶어 제공합니다. 같은 플랫폼에서 지표 기반 판단을 원하는 팀에 어울리고, 킬 스위치만 필요하다면 맞지 않을 수 있습니다.

솔직한 트레이드오프도 하나 있습니다. 플래그 플랫폼은 비율 기반 롤아웃을 제공하지만, 대부분은 스스로 SLO를 읽지 않습니다. 지표를 결정에 연결하는 일은 여전히 누군가의 몫입니다.

어떤 방식으로 롤아웃하든 판단의 근거는 결국 텔레메트리입니다. 모든 지표에 버전이나 코호트 라벨이 있어야 하고, 백엔드가 10분의 지연 없이 그 라벨로 질의할 수 있어야 합니다.

Datadog은 태그 기반 분할을 잘 지원하고, 배포 추적으로 릴리스와 오류 급증을 연결해 줍니다. 모든 것에 태그를 붙이기 전에 높은 카디널리티의 비용부터 계산해 보세요.

이미 Prometheus와 Grafana를 운영하고 있다면, 롤아웃 리비전으로 지표에 라벨을 붙여 쓸 수 있습니다. 완전한 통제권을 얻는 대신 유지보수도 직접 떠안게 됩니다.

중단 자동화: AI 파일럿 아이디어가 나온 자리

수동 카나리 분석은 확장되지 않습니다. 하루에 배포가 열 번 나간다면 아무도 매번 30분씩 대시보드를 들여다보지 않고, 게이트는 조용히 "보기에는 괜찮았다"가 됩니다. 버틸 수 있는 패턴은 자동화된 판정자입니다. SLO를 정의하고, 비교 방식을 정의하고, 카나리가 대조군보다 빠르게 에러 예산을 태우면 컨트롤러가 중단하고 되돌리게 합니다.

upstreamapi의 AI Pilot이 노리는 문제가 바로 이것입니다. 롤아웃 중에 SLO 신호를 읽고, 설정한 임계값을 오류율이 넘으면 자동 롤백을 실행합니다. 그 이상의 신비한 일은 없습니다. 안정 코호트와 비교한 오류율과 지연 시간을 측정할 뿐입니다. 이미 좋은 Prometheus 쿼리로 Argo Rollouts 분석 템플릿을 운영하고 있다면 같은 기능의 대부분을 이미 갖고 있는 것이고, 마법을 파는 사람에게는 그렇게 말해야 합니다. 호스팅 파일럿이 제 몫을 하는 곳은 이기종 스택 전반입니다. 팀마다 자체 분석 템플릿을 따로 관리해야 하는 환경이죠.

흔한 실패 패턴도 있습니다. 팀들은 승격 단계는 자동화하면서 중단은 자동화하지 않습니다. 앞으로만 갈 줄 아는 파이프라인은 컨베이어 벨트일 뿐입니다.

카나리 프로세스가 작동하는지 측정하고, 이번 주에 시작하기

카나리 프로그램에도 자체 지표가 있습니다. 한 분기 동안 다음을 추적하세요.

• 카나리 중단률: 게이트가 멈춘 카나리의 비율입니다. 0이면 게이트가 눈이 멀었다는 뜻입니다. 20~30%를 넘으면 보통 임계값이 불안정하거나 머지 전 테스트가 부실하다는 신호입니다.

• 카나리에서의 감지 시간: 첫 번째 나쁜 요청부터 중단까지 걸린 시간입니다. 릴리스 기준으로 보는 실제 MTTD입니다.

• 빠져나간 회귀: 카나리를 통과한 릴리스로 추적되는 장애입니다. 하나가 생길 때마다 게이트 하나가 바뀌어야 합니다.

• 평균 되돌리기 시간: 중단 결정부터 트래픽 100%가 안정 버전으로 돌아가기까지 걸린 시간입니다.

Workbook은 서비스당 카나리를 한 번에 하나만 돌리라고 강하게 권합니다. 이유는 실용적입니다. 겹치는 변경 두 개가 있으면 원인을 가릴 수 없고, 무엇이 문제를 일으켰는지 알 수 없습니다.

이번 주에 시작한다면 이렇게 하세요. 15분 안에 신호를 낼 만큼 트래픽이 있는 무상태 서비스 하나를 고릅니다. 오류와 지연 지표에 버전 라벨을 추가합니다. 카나리 대 대조군을 비교하는 쿼리를 하나 씁니다. 5% 카나리를 수동 승격으로 돌리고, 최근 장애 세 건에서 무엇을 잡아냈을지 기록합니다.

그다음 불편한 질문을 던져 보세요. 카나리가 새벽 2시에 실패했다면, 깨어 있는 사람이 없어도 무언가가 멈춰 세웠을까요?