이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Canary 배포는 어떤 상황에서 Rolling이나 Blue-Green보다 유리한가?
- 트래픽 비율을 올리기 전에 어떤 지표와 중단 조건을 봐야 하는가?
- Canary 중 문제가 생기면 어떻게 영향 범위를 고정하고 되돌리는가?
개요
Canary는 새 버전을 전체 사용자에게 바로 공개하지 않고 일부 트래픽에만 먼저 노출하는 배포 방식이다.
새 버전의 위험을 작은 사용자 집단에서 먼저 관찰한 뒤, 지표가 안정적이면 트래픽 비율을 늘린다.
Canary의 핵심은 트래픽 비율이 아니라 관측과 중단 조건이다.
중단 조건 없이 비율만 천천히 올리면 실패를 늦게 확산시키는 배포가 된다.
전환 흐름
0% new version
1% canary
5% canary
25% canary
50% canary
100% new version각 단계 사이에는 관측 창이 필요하다.
관측 창은 서비스 트래픽 패턴에 맞아야 한다.
요청량이 적은 서비스는 5분 동안 error가 없다는 사실만으로 충분하지 않을 수 있다.
핵심 API가 호출될 만큼의 sample이 모였는지 확인해야 한다.
Canary 대상
Canary 트래픽은 무작위 비율, 특정 사용자 그룹, 내부 직원, 특정 region, 특정 endpoint 기준으로 나눌 수 있다.
백엔드 관점에서는 요청이 어떤 version으로 갔는지 로그와 metric에서 구분되어야 한다.
metric label: app_version=1.8.3
log field: version=1.8.3 request_id=...
response header: X-App-Version: 1.8.3version 구분이 없으면 canary의 error만 따로 볼 수 없다.
관측 지표
Canary에서는 기술 지표와 제품 지표를 함께 본다.
기술 지표는 error rate, latency p95/p99, saturation, timeout, retry, DB query time이다.
제품 지표는 결제 성공률, 주문 생성률, 로그인 성공률처럼 서비스 핵심 행동과 연결된다.
Spring에서는 Actuator, structured log, metric tag로 version별 신호를 남긴다.
단순 health UP은 canary 통과 기준으로 부족하다.
중단 조건
Canary는 사전에 중단 조건을 정해야 한다.
canary 5% -> 25% 조건:
- 15분 관측
- canary error rate <= baseline + 0.2%
- p95 latency <= baseline + 100ms
- order-create smoke test 성공
- critical log pattern 없음조건은 사람이 즉석에서 해석하지 않아도 될 정도로 구체적이어야 한다.
조건을 만족하지 못하면 다음 단계로 가지 않는다.
운영 체크리스트
- canary 트래픽을 어떤 기준으로 나눌지 정했는가?
- 로그와 metric에서 version별 신호를 구분할 수 있는가?
- 각 단계의 비율, 관측 시간, 중단 조건이 문서화되어 있는가?
- error rate와 latency 기준이 baseline과 비교되는가?
- 핵심 business metric이 canary 판단에 포함되는가?
- DB migration과 message format이 old/new version 공존을 지원하는가?
- canary 중단 시 트래픽을 0%로 되돌리는 방법이 준비되어 있는가?
장애 신호
- 전체 error rate는 정상인데 canary version만 5xx가 높다.
- canary 비율을 올릴 때마다 latency가 단계적으로 상승한다.
- 특정 사용자 그룹에서만 login, payment, order API가 실패한다.
- metric에 version label이 없어 canary 영향만 분리할 수 없다.
- business metric은 악화되는데 health check는 계속 UP이다.
- canary 중단 후에도 background job이나 message consumer가 새 format을 계속 만든다.
안전한 완화 조치
Canary에서 이상 신호가 보이면 먼저 트래픽 증가를 멈춘다.
그 다음 canary 비율을 0%로 되돌릴 수 있는지 확인한다.
이미 생성된 데이터나 message가 이전 버전과 호환되는지 확인한다.
문제가 특정 endpoint나 사용자 그룹에 한정되면 feature flag로 기능만 끄는 방법도 검토한다.
Canary 실패 원인을 찾기 전에는 25%, 50%로 올리지 않는다.
인프라 담당자와 공유할 자료
배포 전략: canary
service: order-api
version: 1.8.3-abc1234
traffic: 5%
관측 창: 15분
증상: canary version p95 +180ms, order-create error rate +0.5%
baseline: previous version p95 240ms, error rate 0.1%
요청: canary traffic 0%로 전환, version label 로그 보존Canary 공유 자료에는 전체 지표가 아니라 canary와 baseline의 비교가 있어야 한다.
실전 팁
- Canary는 지표 분리가 가능할 때 의미가 있다.
- 낮은 트래픽 서비스는 관측 시간이 더 길어야 한다.
- health UP보다 endpoint별 error와 latency가 중요하다.
- business metric을 포함하지 않으면 기술적으로 정상인 실패를 놓칠 수 있다.
- canary 실패 후 로그와 metric label을 보존한다.
위험 신호!
- version별 metric 없이 canary를 진행한다.
- 중단 조건이 “문제 없으면 진행”처럼 모호하다.
- canary 비율을 시간만 지나면 자동으로 올린다.
- DB나 message 변경이 old/new version 공존을 깨는데 canary를 진행한다.
- canary 실패를 새 배포로 덮어쓴다.
확인 질문
확인 질문
- Canary에서 version별 metric이 필요한 이유는 무엇인가?
- 전체 지표가 정상이어도 canary version만 실패할 수 있으므로 새 버전의 영향을 분리해서 봐야 하기 때문이다.
- Canary 단계 증가 조건은 어떻게 정해야 하는가?
- 관측 시간, error rate, latency, smoke test, business metric, critical log 기준을 사전에 수치로 정해야 한다.
- Canary 중 문제가 생기면 가장 먼저 할 일은 무엇인가?
- 다음 단계 진행을 멈추고 canary 트래픽을 줄이거나 0%로 되돌려 영향 범위를 고정하는 것이다.