EKS+ALB 환경에서 Argo Rollouts로 503 에러 없는 카나리 배포 적용기

Deployment 롤링 업데이트는 즉각 롤백이 어렵고, 기존 Blue/Green과 기본 Canary는 EKS+ALB 환경에서 Promote 시 약 30초 503이 발생했다. Promote 순간 Service selector가 바뀌며 EndpointSlice와 ALB Target Group이 재등록되고, 새 target이 헬스체크를 통과하기 전 initial 상태로 남기 때문이다.

AWS Load Balancer Controller의 readiness gate도 해법이 되지 못했다. 이 gate는 Pod 생성 시점에만 주입되므로, 이미 running 중인 Pod의 selector를 나중에 바꾸는 Blue/Green과 기본 Canary에는 적용되지 않는다.

해결책으로 Argo Rollouts v1.2의 Canary PingPong을 적용했다. pingService/pongService 두 Service를 고정해 배포마다 stable/canary 역할만 교대하고, Promote 때는 selector를 바꾸지 않고 ALB ForwardConfig weight만 swap한다. 그 결과 target 재등록이 발생하지 않아 503 구간이 사라진다.

적용 포인트는 다음과 같다.

• 3개 Service: rootService, pingService, pongService
• Ingress backend: name: use-annotation
• Rollout: pingPong, trafficRouting.alb, maxUnavailable: 0, maxSurge: 1
• 배포 단계: setWeight, pause
• 선택 기능: setCanaryScale, analysis

운영에서는 단계별로 충분한 관찰 시간을 두는 것이 중요하며, pause: {}로 수동 Promote하는 방식도 활용할 수 있다.