Canary 배포가 *놓친* 7가지 인시던트 — 실측 사례

Canary 배포는 대부분의 변경 에 잘 작동한다. 우리도 매주 25~30 회 canary 를 돌리고, 그중 97~98% 가 예상대로 끝난다. 그런데 2~3% 의 실패 패턴이 모두 비슷하게 생겼다. 7 가지 형태로 정리할 수 있다.

이 글은 그 7가지를 실측 사례 로 다룬다.

1. 트래픽 비율 은 같지만 분포 가 다른 사용자

10% 카나리에 전체 사용자의 10% 가 들어가는 게 아니라 특정 segment 의 10% 가 들어가는 패턴. 보통 sticky session 이 ID 기반으로 라우팅하고, 그 ID 가 시간대 / 지역 / 결제 수단 과 상관관계가 있을 때.

우리 사례 — 새 결제 검증 단계. canary 10% 에서 정상이라고 판단해 100% 로 올렸는데, 기업 결제 사용자에게서만 실패. canary 의 10% 는 개인 사용자만 들어가 있었음. 3시간 영향.

방어: traffic split 의 segment 분포 를 명시적으로 검증. 단순 비율 매칭 으로 안심하지 않기.

2. 읽기 사용량 만 검증하고 쓰기 는 안 함

canary 가 95% 트래픽이 read 인 시간대에 진행됐다. 그 시간대에는 새 코드의 read path 만 검증됨. write path 의 deadlock 이 피크 시간 100% 배포 후 9분 만에 드러남.

방어: canary 시간을 write peak 시간 에 의도적으로 잡거나, read/write 비율 이 baseline 과 같은 시간대에서만 진행.

3. 연결 풀 이 천천히 새는 메모리 누수

10% canary 의 connection pool 사용량 — 정상 범위. 30분 검증 윈도우 내에서는 증가 추세 였지만 임계는 안 넘김. 100% 배포 후 6시간 뒤 전체 가 풀 고갈로 연쇄 실패.

방어: 증가 추세 를 신호로 받기. 현재 값 만 보면 누수성 버그를 못 잡음.

4. 외부 API 호출이 baseline 보다 빠른 패턴

canary 가 외부 API 호출을 baseline 보다 빠르게 처리. 처음에는 개선 으로 해석. 사실은 retry 로직 제거 버그 — 외부 API 가 일시 실패할 때 retry 안 하고 바로 빈 응답 으로 fallback. canary 의 30분 윈도우에는 외부 API 가 건강 했고, fallback 경로가 호출되지 않았음. 100% 배포 후 외부 API 가 3분간 흔들림 발생, 그 3분 동안 모든 사용자가 빈 응답.

방어: 외부 API 의 failure injection 이 canary 단계에 포함되어야 함. 외부 의존성이 건강한 상태 만 검증하면 fallback 버그를 못 잡음.

5. 시간대 가 다른 background job

canary 가 낮 시간에 진행됐고, 변경된 코드는 야간 배치 잡 만 영향. 직접 트래픽 검증으로는 보이지 않음. 야간 배치가 깨지는 건 24시간 이상 후.

방어: 변경된 코드가 어떤 트리거 로 실행되는지 매핑. trigger 가 cron / queue / event 라면 canary 만으로 부족.

6. 상위 시스템 가정 변경

API 응답 형태에 optional 필드 추가. canary 의 검증은 기존 클라이언트가 깨지지 않는다 는 것. 그 시점에서는 정확. 100% 배포 후, 우리 API 를 사용하는 다운스트림 시스템 이 예상치 못한 필드 때문에 enum 검증 실패 로 깨짐.

방어: API 변경의 canary 는 우리 트래픽 이 아니라 다운스트림 통합 테스트 도 포함되어야 함. 다운스트림 인벤토리 없으면 canary 가 의미 작음.

7. Canary 자체의 모니터링 이 안 보일 때

canary 검증의 메트릭 dashboard 가 5분 캐시 였다. 우리는 실시간 이라고 가정하고 canary 결과 본 후 3분 만에 100% 로 올림. 사실 그 3분 의 데이터가 5분 전 데이터 였음. 진짜 데이터가 문제 신호 를 보이고 있었지만 보지 못함.

방어: canary 데이터 source 의 latency 를 명시적으로 알기. 실시간으로 보이는 dashboard 가 5분 지연 인 경우가 흔함.

7가지의 공통점

위 7가지의 공통점은 canary 가 작동했다 는 것이다 — 주어진 검증 윈도우 안에서는. 실패는 윈도우 밖 에서 일어났다. 시간 분포, 사용자 분포, 외부 의존성, 다운스트림 통합, 데이터 latency.

Canary 는 변경의 안전성 을 검증하는 게 아니라 베이스라인과의 차이 를 검증한다. 베이스라인이 불완전 하면 canary 도 불완전.

누가 이 글을 읽으면 좋은가

이미 canary 인프라를 갖췄지만 canary 통과 후 100% 배포에서 사고가 나는 경험을 한 SRE / 플랫폼 리드. 위 7가지 중 2~3개 는 거의 모든 팀에 해당함. 하나씩 방어해 가면 분기당 1~2 건 의 사고가 줄어든다.