Canary Release

케이스 1토스 — 결제 SDK 카나리 배포

토스는 백엔드가 아니라 가맹점 결제 페이지에 바로 실리는 자바스크립트 SDK에 카나리 배포를 적용했습니다. CloudFront와 엣지 함수, S3를 쓰며 요청의 JA3 지문을 해싱해 고정된 집단으로 나눈 뒤 집단별로 신규·기존 버전을 라우팅합니다. 실시간 롤백과 비율 조정을 지원하면서도 CDN 캐시를 유지했습니다.
도입효과: 캐시 적중률 목표 99% 이상, SDK 요청 1,000만 건당 CloudFront Function 비용 0.6달러, 함수 실행 1밀리초 미만(2024-03-05)^[5]

케이스 2숨고 — 쿠버네티스 마이크로서비스 카나리 배포

숨고는 ALB와 NLB 사이, NLB와 서비스 사이에 Nginx 프록시 두 단을 넣어 가중치로 트래픽을 나눕니다. 배포는 GitOps 흐름으로 굴리고 관측은 New Relic으로 합니다. 롤백은 이전 버전 비율을 100%로 되돌리는 한 번의 설정 변경입니다.
도입효과: 트래픽 단계 0·1·5·10·20·50·80·100% 총 8단계, 프록시 자원 CPU 50m 이하(2023-05-26)^[6]

케이스 3넷플릭스 — Kayenta 자동 카나리 분석

넷플릭스는 사람이 대시보드를 눈으로 비교하는 방식을 통계 판정으로 바꾸기 위해 Kayenta를 만들어 공개했습니다. 운영·기준·카나리 세 클러스터를 동시에 띄워 클러스터 수명 차이가 비교를 오염하지 않게 했습니다. 지표별로 통계 검정을 거쳐 합격 비율을 점수로 계산합니다.
도입효과: 자동 판정 비중 약 30%, 하루 평균 판정 200건(발표 시점 기준)^[7]

케이스 4웨이즈 — Kayenta 운영 적용

구글과 넷플릭스는 2018년 4월 10일 Kayenta를 오픈소스로 공개하며 스피네이커와의 통합을 알렸습니다. 사용자가 지정한 지표를 모아 통계 검정을 돌리고 0에서 100 사이 점수를 내 자동 승격·실패·사람 승인을 가릅니다. 발표문은 웨이즈를 운영 사용자로 소개했습니다.
도입효과: 웨이즈 프로덕션 파이프라인 1,000개 이상(2018-04-10 공개 인용)^[8]

오늘 바로 해보기
1. 되돌리기 쉬운 서비스 하나를 골라 이전 버전을 남겨 둡니다.
2. 트래픽 1%를 새 버전으로 보내는 라우팅 규칙을 만듭니다.
3. 오류율·지연 시간·핵심 전환 지표 세 가지를 자동으로 비교합니다.
4. 5%에서 20%, 50% 순으로 올리되 단계마다 관찰 시간을 정해 둡니다.
5. 되돌리기 명령을 문서 첫 줄에 적어 당직자가 바로 실행할 수 있게 합니다.

한계와 진화
두 버전을 동시에 운영해야 합니다. 사토는 이 점을 주요 단점으로 꼽으며, 데이터베이스 스키마 변경은 두 버전을 모두 받아주는 병행 변경으로 풀어야 한다고 설명합니다. 사용자 기기에 설치되는 소프트웨어처럼 업그레이드 시점을 통제할 수 없는 경우에도 적용이 어렵습니다.

안전하게 잡을수록 느려집니다. Flagger 문서는 승격 최소 시간이 관찰 주기에 비례하고 롤백 시간도 주기와 임계 횟수의 곱이라고 명시합니다. 그만큼 나쁜 버전이 실제 트래픽을 받는 시간도 길어집니다. 구글 클라우드 배포 문서는 비교할 이전 버전이 없으면 첫 배포에는 카나리를 쓸 수 없다고 안내합니다. 판정을 사람 눈에 맡기는 방식은 확장되지 않아 넷플릭스처럼 통계 기반 자동 판정으로 옮기는 흐름입니다.