카나리 배포가 못 잡는 장애 5가지

카나리 배포를 도입했어요. 새 버전을 인스턴스 하나에 먼저 올리고 오류율을 지켜본 뒤 전체로 확대하는 방식이요.

몇 번은 잘 통했어요. 명백한 버그를 카나리에서 잡아냈거든요.

그런데 어느 배포는 카나리를 무사히 통과하고 전체 확대 후에 터졌어요. 카나리에서 30분을 지켜봤는데도요.

더 나빴던 건 판단이 늦어진 거예요. 카나리를 통과했으니 배포가 원인일 리 없다고 생각해서, 다른 곳을 한참 뒤졌거든요.

카나리는 "적은 트래픽에서 빠르게 드러나는 문제"만 잡아요. 그 밖의 것들은 통과시켜요. 그리고 그 밖의 것들이 실제로는 더 많습니다.

왜 그런가

카나리가 잡는 건 조건이 분명해요. 소수의 트래픽에서, 짧은 시간 안에, 지켜보고 있는 지표로 드러나는 문제요.

이 조건에서 벗어나는 것들을 보면 이래요.

부하 관련 문제. 인스턴스 하나가 받는 트래픽은 전체의 몇 퍼센트예요. 커넥션 풀 고갈, 메모리 압박, 락 경합은 전체 부하에서만 나타나요. 카나리는 한가하니 멀쩡해 보여요.

시간이 걸리는 문제. 메모리 누수는 몇 시간, 디스크 증가는 며칠, 인증서 만료는 몇 달 뒤예요. 30분 관찰로는 안 보여요.

드문 경로. 특정 조건에서만 타는 코드는 소수 트래픽에 안 걸릴 수 있어요. 월말 정산, 특정 국가 사용자, 예외 처리 경로 같은 것들이요.

누적되는 문제. 새 코드가 데이터를 조금씩 잘못 쓰고 있다면, 30분 뒤에는 오류가 안 나요. 며칠 뒤에 드러나요.

전체에서만 생기는 문제. 새 버전이 캐시를 다르게 쓴다면, 전체 확대 후 캐시 적중률이 떨어지면서 문제가 나요. 인스턴스 하나로는 재현이 안 돼요.

그리고 관찰 지표가 좁은 경우도 흔해요. 오류율만 보면 느려진 건 안 보여요.

코드로 보면

카나리가 못 보는 축을 따로 덮는다:

· 카나리가 보는 것
✓ 소수 트래픽 · 짧은 시간 · 지켜보는 지표

✕ 못 보는 것들 — 각각 다른 장치가 필요하다
✕ 부하 문제      → 부하 시험 · 단계적 확대(1→10→50→100%)
✕ 누수·증가      → 관찰 기간 연장 · 자원 추세 알림
✕ 드문 경로      → 트래픽 재생 · 합성 요청
✕ 데이터 오염    → 정합성 검사 · 대조 실행
✕ 전체에서만     → 확대 단계마다 다시 관찰

· 지켜보는 지표를 넓힌다
✕ 오류율만 보면 느려진 것은 안 보인다
✓ 오류율 + 지연 백분위 + 자원 + 핵심 업무 지표

✕ 문제 지점 · ✓ 해법 · 그대로 돌려 보기 전에 자기 환경에 맞게 고쳐 주세요.

실전에서는

카나리를 버리라는 얘기가 아니에요. 무엇을 잡고 무엇을 못 잡는지 알고 나머지를 다른 장치로 덮는 게 요점이에요.

단계적 확대가 첫 번째 보완이에요. 1% → 10% → 50% → 100% 로 가면서 각 단계마다 관찰하면, 부하 관련 문제가 전면 확대 전에 드러날 가능성이 커져요. 특히 10~50% 구간에서 나타나는 게 많아요.

관찰 지표를 넓히는 게 두 번째예요. 오류율만이 아니라 지연 백분위, 메모리·CPU 추세, 그리고 핵심 업무 지표(주문 수, 결제 성공률)까지 봐야 해요. 코드가 오류 없이 조용히 잘못된 결과를 내는 경우가 있는데, 그건 업무 지표에서만 보입니다.

관찰 기간도 문제예요. 짧으면 못 잡고 길면 배포가 느려져요. 실용적인 절충은 위험도에 따라 다르게 하는 거예요. 앞 편의 되돌릴 수 있는가 기준을 여기서 씁니다.

비교 방식도 중요해요. 카나리의 지표를 절대 기준과 비교하면 놓쳐요. 같은 시각의 나머지 인스턴스와 비교해야 해요. 그래야 트래픽 변동이나 외부 요인의 영향을 걷어 낼 수 있어요.

그리고 자동 판정이 있으면 좋아요. 사람이 대시보드를 30분 쳐다보는 건 지속 가능하지 않아요. 기준을 정해 두고 벗어나면 자동으로 되돌리는 게 낫습니다.

마지막으로 카나리에 들어가는 트래픽이 대표성이 있어야 해요. 특정 지역이나 특정 사용자군만 카나리로 가면 그쪽에 없는 문제는 안 잡혀요.

처방

1. 단계적으로 확대하세요. 1% → 10% → 50% → 100%, 각 단계마다 관찰하세요.
2. 관찰 지표를 넓히세요. 오류율 + 지연 백분위 + 자원 추세 + 핵심 업무 지표요.
3. 카나리를 절대 기준이 아니라 같은 시각의 나머지 인스턴스와 비교하세요.
4. 자동 판정과 자동 롤백을 넣으세요. 사람이 대시보드를 지켜보는 건 지속되지 않습니다.
5. 카나리 트래픽이 대표성 있는지 확인하세요. 특정 군만 가면 그 밖의 문제는 안 잡힙니다.
6. 위험도에 따라 관찰 기간을 다르게 하세요. 되돌릴 수 있는 변경은 짧게, 없는 변경은 길게요.
7. 카나리가 못 잡는 축마다 다른 장치를 두세요. 부하 시험, 자원 추세 알림, 정합성 검사요.
8. 카나리 통과 후 터진 사고를 기록하세요. 무엇이 빠져 있었는지가 다음 개선입니다.
9. 카나리 기간에도 두 버전이 공존한다는 걸 잊지 마세요. 스키마·캐시 호환이 그대로 적용됩니다.
10. "카나리 통과"를 안전 보증으로 쓰지 마세요. 장애 조사에서 배포를 후보에서 빼는 근거가 되면 안 됩니다.

지금 확인해 보세요

카나리가 실제로 무엇을 보는가:

· 지켜보는 지표 목록
✓ 오류율 · 지연 백분위 · 메모리/CPU · 핵심 업무 지표
✕ 오류율만이면 조용히 잘못된 결과는 못 잡는다

· 비교 대상
✕ 절대 기준이 아니라 같은 시각 나머지 인스턴스와 비교

· 카나리 트래픽의 대표성
✓ 특정 지역·특정 사용자군만 가고 있지 않은가

· 판정이 자동인가 사람인가
✕ 사람이면 관찰 기간이 형식적으로 무너진다

· 카나리 통과 후 터진 사고 목록
✓ 무엇이 빠져 있었는지가 다음 개선이다

핵심 한 줄카나리 통과는 안전 보증이 아니라 한 종류의 검사를 통과한 것이다.