카나리 배포(Canary Deployment): 탄광 속의 카나리아

1. 죽음의 가스를 감지하는 15그램의 새

19세기 말, 영국의 탄광은 칠흑 같은 어둠과 언제 터질지 모르는 위험이 도사리는 곳이었습니다. 가장 무서운 적은 일산화탄소(Carbon Monoxide)와 메탄(Methane) 가스였습니다. 색깔도 없고 냄새도 없는 이 '침묵의 살인자'는 갱도에 조용히 차올라 광부들을 질식시켰습니다. 전자기 센서가 없던 시절, 광부들은 기발하고도 슬픈 생체 감지기를 고안해냈습니다. 바로 노란색 작은 새, 카나리아(Canary)였습니다.

카나리아는 체구가 작고(약 15g) 신진대사가 빨라, 인간보다 유독 가스에 훨씬 민감하게 반응했습니다. 사람에게는 아무런 느낌이 없는 미량의 가스에도 카나리아는 비틀거리거나 노래를 멈췄고, 심하면 횃대에서 떨어졌습니다. 광부들은 작업 중에도 수시로 새장을 확인했고, 새가 이상 반응을 보이면 "가스다! 대피해!"라고 외치며 지상으로 탈출했습니다. 이 작은 새가 수천 명의 목숨을 구한 것입니다.

소프트웨어 엔지니어링의 카나리 배포(Canary Deployment)는 이 역사적 사실에서 이름을 따왔습니다. 거대하고 복잡한 운영 환경(탄광)에 새로운 코드(광부)를 투입하기 전, 극소수의 사용자(카나리아)에게 먼저 노출시켜 봅니다. 만약 이 1%의 사용자가 에러(유독 가스)를 겪는다면, 시스템은 즉시 배포를 멈추고 롤백하여 나머지 99%의 사용자를 보호합니다. 페이스북, 구글, 넷플릭스 같은 IT 거인들이 하루에 수천 번 배포하면서도 안정성을 유지하는 비결이 바로 이것입니다.

---

2. 배포 전략의 삼국지: Rolling vs Blue/Green vs Canary

서비스를 중단 없이 배포(Zero Downtime Deployment)하는 방법은 크게 3가지가 있습니다. 각각의 장단점을 명확히 알아야 상황에 맞는 전략을 짤 수 있습니다.

2.1. 롤링 배포 (Rolling Update)

서버가 100대 있다면, 한 번에 10대씩 순차적으로 갈아치우는 방식입니다.

• 비유: 달리는 기차의 바퀴를 하나씩 새것으로 교체하는 것.
• 장점: 추가적인 서버 비용이 거의 들지 않습니다(무중단 배포의 기본값).
• 단점:
  • 배포 중에는 구버전과 신버전이 공존합니다. (DB 스키마 변경 시 호환성 문제 발생 가능)
  • 배포가 50% 진행된 상태에서 치명적인 버그가 발견되면, 다시 50%를 되돌리는 데 시간이 오래 걸립니다(느린 롤백).

2.2. 블루/그린 배포 (Blue/Green Deployment)

현재 운영 중인 환경(Blue)과 똑같은 쌍둥이 환경(Green)을 미리 만들어두고, 로드 밸런서의 방향만 휙 돌리는 방식입니다.

• 비유: 새 집을 다 지어놓고 이사 가는 것.
• 장점:
  • 테스트가 완벽하게 끝난 상태에서 트래픽을 넘기므로 안정적입니다.
  • 문제가 생기면 스위치만 다시 내리면 되므로 롤백이 즉각적(Instant Rollback)입니다.
• 단점:
  • 비용이 2배 듭니다. 서버가 1,000대라면 잠시 2,000대가 필요합니다. 클라우드 비용 폭탄의 주범이 될 수 있습니다.
  • Cold Start(예열) 문제가 발생할 수 있습니다.

2.3. 카나리 배포 (Canary Deployment)

신규 버전을 운영 서버 한 귀퉁이에 살짝 띄우고, 간을 보는 방식입니다.

• 비유: 음식 간이 맞는지 한 숟가락만 먼저 먹어보는 것.
• 장점:
  • 실제 트래픽으로 검증(Production Test)할 수 있습니다. (QA 환경에서는 절대 발견 못 하는 버그를 찾을 수 있음).
  • 문제가 생겨도 영향 범위가 1% 미만으로 매우 작습니다(Blast Radius 최소화).
  • 블루/그린처럼 2배의 리소스가 필요하지 않습니다.
• 단점:
  • 구현 난이도가 가장 높습니다. L7 로드 밸런서나 Service Mesh 같은 고급 인프라가 필요합니다.

---

3. 카나리 배포의 4단계 라이프사이클

카나리 배포는 단순히 "조금 배포하고 끝"이 아닙니다. 정교한 관측(Observability)과 판단(Judgement) 프로세스입니다.

1단계 - 배포 (Deploy) - "정찰병 투입"

• 기존 버전(V1)은 그대로 두고, 신규 버전(V2) 파드(Pod)나 인스턴스를 소규모(1개~5%)로 실행합니다.
• 이때 일반 사용자에게는 아직 V2가 노출되지 않습니다.

2단계 - 라우팅 (Traffic Shifting) - "문 열어"

• 로드 밸런서 설정을 변경하여 실제 트래픽의 1% ~ 5%를 V2로 흘려보냅니다.
• 고급 기법: 무작위 5%가 아니라, 특정 조건을 만족하는 사용자만 보낼 수도 있습니다.
  • 내부 직원 (Thinking-Face-Inc-Employee: true 헤더)
  • 베타 테스터 그룹
  • 특정 지역 (예: '뉴질랜드' 사용자만 먼저 배포)

3단계 - 분석 (Analysis) - "카나리아는 살아있는가?"

• 가장 중요한 단계입니다. V1(대조군)과 V2(실험군)의 핵심 지표를 실시간으로 비교합니다.
• 모니터링 대상 (Golden Signals):
  1. 에러율 (Error Rate): HTTP 500 응답이 늘어났는가?
  2. 지연 시간 (Latency): V1은 100ms인데 V2가 300ms로 느려지진 않았는가?
  3. 리소스 사용량 (Saturation): 메모리 누수(Memory Leak)나 CPU 급증이 없는가?
  4. 비즈니스 지표: 결제 성공률이나 클릭률이 떨어지진 않았는가?

4단계 - 승격 또는 롤백 (Promotion or Rollback)

• 판단: "에러율이 1% 미만이고, Latency 변화가 5% 이내인가?"
• 성공(Pass): 트래픽을 10% -> 30% -> 50% -> 100%로 점진적으로 늘립니다. 마지막엔 V1을 모두 제거합니다.
• 실패(Fail): 즉시 트래픽을 0%로 차단하고 알람을 보냅니다.

---

4. Kubernetes와 Istio로 구현하는 방법

AWS 로드 밸런서(ALB)의 가중치 기반 라우팅을 쓸 수도 있지만, 클라우드 네이티브 환경에서는 Istio 같은 서비스 메쉬가 사실상의 표준입니다.

4.1. Kubernetes Native 방식 (파드 개수 조절)

가장 원시적인 방법입니다. Service 하나에 V1 Deployment와 V2 Deployment를 같이 연결합니다.

• V1 파드: 9개
• V2 파드: 1개
• 결과: 자연스럽게 10% 트래픽이 V2로 갑니다.
• 한계: 1% 테스트를 하려면 파드가 100개 필요합니다. 정교한 제어가 불가능합니다.

4.2. Istio VirtualService (가중치 기반)

Istio를 쓰면 파드 개수와 상관없이 트래픽 비율을 조절할 수 있습니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service
spec:
  hosts:
  - payment
  http:
  - route:
    - destination:
        host: payment
        subset: v1
      weight: 95
    - destination:
        host: payment
        subset: v2
      weight: 5

이 설정 파일 하나만 적용하면(kubectl apply), 즉시 5%의 트래픽만 V2로 흐르게 됩니다. 개발자가 물리적인 서버 댓수를 신경 쓸 필요가 없습니다.

---

5. 자동화 도구들 - 사람이 하지 마세요 (Automated Canary Analysis)

"로그를 보고 에러가 났는지 판단한다"를 사람이 하면 100% 실수합니다. 밤새 모니터를 쳐다볼 수도 없습니다. 그래서 ACA(Automated Canary Analysis) 도구가 등장했습니다.

1. Spinnaker (Kayak)

• 넷플릭스와 구글이 만든 지속적 배포(CD) 도구입니다.
• 내장된 Kayenta 엔진이 Prometheus나 Datadog의 데이터를 가져와 통계적 검증(Mann-Whitney U Test 등)을 수행합니다.
• "지난 30분간 V2의 에러율이 V1보다 통계적으로 유의미하게 높습니다"라고 판단하면 알아서 롤백합니다.

2. Argo Rollouts

• Kubernetes 전용 CD 컨트롤러입니다. Deployment 리소스 대신 Rollout이라는 CRD를 사용합니다.
• 쿠버네티스 네이티브하게 작동하며, 설정이 비교적 간단합니다.

  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {duration: 10m} # 10분간 관찰
      - setWeight: 40
      - pause: {duration: 10m}
      - setWeight: 100
  

3. AWS CodeDeploy & AppMesh

• AWS 생태계를 쓴다면 가장 좋은 선택입니다. Lambda 함수나 ECS 서비스에 대해 Linear(직선형) 또는 Canary 배포를 원클릭으로 지원합니다.

---

6. 주의사항 및 Best Practices

1. 스티키 세션 (Sticky Session) 유지

가장 흔한 실수입니다. 사용자가 새로고침할 때마다 V1(구버전)과 V2(신버전)를 왔다 갔다 하면 안 됩니다. 어떤 사용자는 버튼이 파란색이었다가 빨간색이었다가 하면 혼란에 빠집니다. 반드시 Cookie나 User ID 해시를 기반으로, "한 번 카나리아 그룹에 속한 사용자는 배포가 끝날 때까지 계속 카나리아 버전을 보게" 해야 합니다.

2. 하위 호환성 (Backward Compatibility)

V2 코드가 DB 스키마를 변경했다면, V1 서버들이 에러를 뿜을 수 있습니다.

• 원칙: DB 변경은 코드 배포보다 항상 먼저, 그리고 하위 호환성을 지키면서 이루어져야 합니다.
• 컬럼 삭제 같은 파괴적인 변경은 배포 단계에서 절대 수행하지 않습니다. (N+1 버전에서 수행).

3. 충분한 트래픽과 시간

새벽 4시에 카나리 배포를 하고 "에러가 0건이네? 성공!"이라고 판단하면 안 됩니다. 트래픽이 너무 적으면 통계적 유의성이 없습니다. 충분한 표본(Sample Size)이 모일 때까지 기다리거나, 트래픽이 많은 시간대에 배포해야 합니다.

---

7. 마무리 - 개발자의 베개 높이를 높여주는 기술

"금요일 오후 5시에 배포하고 퇴근할 수 있나요?" 일반적인 회사라면 무모하다고 하겠지만, 완벽한 카나리 배포 파이프라인이 구축된 팀이라면 "Why not?"이라고 대답할 수 있습니다. 문제가 생겨도 자동으로 감지하고, 자동으로 롤백되고, 나에게 알람 하나만 보내줄 테니까요.

카나리 배포는 단순한 기술이 아닙니다. 실패를 허용하고 통제 가능한 범위 내에 가두는 엔지니어링의 철학입니다. 여러분의 시스템에 카나리아 한 마리를 키워보세요. 그 작은 새가 여러분의 주말을 지켜줄 것입니다.

---

---