카나리 vs 롤링 업데이트

Source: Dev.to

쿠버네티스에서 트래픽 라우팅

Kubernetes는 트래픽을 포드 IP 기준으로 라우팅하며, 비율 기준으로 라우팅하지 않습니다.
Service(가상 IP)는 요청을 준비된(any Ready) 포드로 전달합니다; 이 Service는 다음에 대해 알지 못합니다:

• 애플리케이션 버전
• 위험 수준
• 트래픽 비율

User
 ↓
Service (virtual IP)
 ↓
Random Pod IP

만약 10개의 포드가 있고 새로운 포드(v2)가 추가되면 이제 11개의 포드가 됩니다. Service는 단일 사용자의 모든 요청을 같은 포드(연결 재사용)로 보낼 수 있으므로, 해당 사용자는 모든 요청이 v2에 도달할 수 있습니다. 결과적으로, 하나의 포드는 트래픽의 **0 %**에서 **80 %**까지 받을 수 있습니다.

Kubernetes는 어떤 포드가 새로운 코드를 받는지, 몇 명의 사용자가 영향을 받는지에 대해 어떠한 약속도 하지 않습니다.

롤링 업데이트

롤링 업데이트는 다음을 보장합니다:

• 파드가 한 번에 모두 종료되지 않습니다.
• 전체 용량이 유지됩니다.

보장되지 않는 사항:

• 어떤 사용자가 새 버전을 받는지.
• 영향을 받는 사용자 수.
• 오류가 제한된다는 것.

따라서 롤링 업데이트는 availability‑safe하지만 user‑safe하지는 않습니다.

예시 시나리오

1. v1은 정상 작동하고, v2는 토큰 검증 버그를 도입합니다.
2. v2 파드가 하나 시작됩니다.
3. 첫 실제 사용자가 해당 파드에 접근하면 → 로그인에 실패합니다.
4. 사용자가 재시도하면 → 같은 파드(세션 스티키니스) → 사용자가 잠깁니다.
5. 지원 티켓이 열리고 배포가 롤백되지만, 이미 손상이 발생했습니다.

단일 실패만으로도 인증 또는 결제 시스템에 치명적일 수 있습니다.

Source: …

카나리 배포

카나리 배포는 무작위에 의존하지 않습니다. 새로운 버전에 대한 트래픽 비율을 명시적으로 지정합니다. 예:

• “전체 트래픽의 **5 %**만 v2 로 보냅니다.”

1 000개의 요청 중:

• 950 → v1
• 50 → v2

이는 강제 라우팅이며, “아마도” 혹은 “운이 좋다면”이 아닙니다.

구현 방법

• 가중치가 지정된 경로를 가진 Ingress 규칙
• 로드‑밸런서 가중치 설정
• Service‑mesh 트래픽 분할

복제본 기반 카나리 (정확한 비율이 아님)

4 v1 pods
1 v2 pod

복제본 수만으로는 확률을 낮출 뿐이며, 트래픽 제한을 보장하지 못합니다. 따라서 프로덕션 환경에서는 명시적인 트래픽 가중치를 사용합니다.

장점

• v2 팟이 외부 타임아웃(예: Stripe API)에 걸리면, 작은 카나리 트래픽만 영향을 받습니다.
• 지연 시간 급증을 조기에 감지할 수 있어, 카나리를 중단하면 **99 %**의 고객을 안전하게 유지할 수 있습니다.

비교: 롤링 업데이트 vs. 카나리

준비성 프로브

readiness probe는 하나의 질문에 답합니다:

“Kubernetes가 이 파드에 트래픽을 보내야 할까요?”

이는 기술적인 가용성(프로세스 실행 중, 포트 열림, HTTP 200 등)만 확인합니다. 비즈니스 로직, 지연 시간, 외부 의존성, 정확성은 검증하지 않습니다.

일반적인 프로브 정의

readinessProbe:
  httpGet:
    path: /health
    port: 8080
# or
readinessProbe:
  tcpSocket:
    port: 8080

• 프로브 성공 → 파드가 Ready 상태로 표시되고 Service에 추가됩니다.
• 프로브 실패 → 파드가 Service에서 제거됩니다.

파드가 /health에서 200 OK를 반환하더라도 핵심 기능(예: 결제, Kafka 소비)이 손상될 수 있습니다.

How a Canary Deployment Works

1. Readiness – Pod가 readiness probe를 통과하면 → 트래픽을 받을 수 있게 됩니다.
2. Canary traffic (예: 5 %) – 요청이 새로운 버전으로 라우팅됩니다.
3. Monitoring – 실제 사용자 행동, 지연 시간, 오류 비율, 외부 시스템 응답을 관찰합니다.
4. Decision
   • 메트릭이 정상이면 → 트래픽 비율을 늘립니다.
   • 오류가 임계값을 초과하면 → 카나리를 중단하고 안정 버전을 유지합니다.

Without a canary, 100 % of traffic would be exposed to any defect.

인터뷰‑스타일 요약

• Readiness probes는 파드가 트래픽을 받을 기술적으로 준비가 되었는지를 확인합니다.
• Canary deployments는 새 버전이 사용자에게 안전한지를 실시간 트래픽의 제한된 일부를 노출하고 동작을 관찰함으로써 검증합니다.

두 메커니즘은 상호 보완적입니다:

• Readiness는 쿠버네티스 컨트롤 플레인이 실행 중이 아닌 파드에 트래픽을 보내는 것을 방지합니다.
• Canary는 비즈니스와 사용자를 기능 회귀로부터 보호합니다.

다음과 같이 생각할 수 있습니다:

• Readiness = “엔진이 시동 걸렸나요?”
• Canary = “고속도로 속도로 주행해도 차가 안전한가요?”