EKS + ALB 환경에서 Argo Rollouts 카나리 배포 503 에러, PingPong으로 해결!
EKS + ALB 환경에서 Argo Rollouts의 Blue/Green 및 기본 카나리 배포(Canary Deployment) 시 Promote 단계에서 503 에러 발생
503 에러의 원인은 Service selector 변경으로 인한 ALB Target Group 재등록(Target Group Re-registration) 시 헬스 체크(Health Check) 문제
Argo Rollouts v1.2에서 도입된 Canary PingPong 전략(Canary PingPong Strategy)을 통해 Service selector 변경 없이 503 에러 해결
PingPong 전략은 두 개의 Target Group을 고정하고 weight만 교체하여 무중단 배포(Zero-downtime Deployment)를 보장
실제 운영 환경에서 PingPong 전략 적용 후 503 에러 없이 안정적인 배포(Stable Deployment)를 확인
EKS + ALB 환경에서 503 에러의 근본 원인
본문에 따르면 EKS + ALB 환경에서 Blue/Green 및 기본 카나리 배포(Canary Deployment) 시 Promote 단계에서 503 에러가 발생하는 근본적인 원인은 Service selector 변경(Service Selector Change)에 있다.
Service selector 변경 → ALB Controller가 감지 → Target Group(TG)의 target 재등록(Target Re-registration)
재등록된 target은 헬스 체크(Health Check)를 통과하기 전까지 initial 상태 → 503 에러 발생
AWS Load Balancer Controller의 구조적 한계로 인해, Promote 시점에 이미 running 중인 Pod에는 Readiness Gate(Readiness Gate)가 주입되지 않음
결과적으로, Promote 시점에 Service selector를 변경하는 모든 전략은 503 에러의 위험을 내포하고 있다.
Canary PingPong 전략의 핵심 원리
Canary PingPong 전략은 503 에러를 해결하기 위해 Promote 시 Service selector를 변경하지 않는 방식을 사용한다. 이는 Argo Rollouts v1.2에서 도입된 기능이다.
두 개의 Target Group(TG-A, TG-B)을 고정하고, 배포마다 역할 교대
Promote 시, ALB ForwardConfig의 weight만 교체(Weight Swap)
Service selector 변경 X → EndpointSlice 변경 X → AWS target 재등록 X
PingPong 전략은 이미 헬스 체크를 통과한 Pod에 트래픽을 전달하므로, 503 에러 발생 가능성을 원천적으로 차단한다.
PingPong 전략 적용을 위한 설정 가이드
PingPong 전략을 적용하기 위해서는 3개의 Service, Rollout Strategy 설정, Ingress 설정이 필요하다. 각 설정 항목에 대한 상세 설명은 다음과 같다.
3개의 Service: rootService, pingService, pongService 구성
Rollout Strategy: pingPong, trafficRouting 설정 (pingService, pongService, rootService, servicePort)
Ingress 설정: backend port를 use-annotation으로 설정 (PingPong/trafficRouting 사용 시 필수)
특히, Ingress의 backend port 설정을 use-annotation으로 설정해야 ALB Controller가 ForwardConfig annotation을 인식하여 가중치 기반 라우팅(Weight-based Routing)이 정상적으로 동작한다.
PingPong 전략의 장점: 무중단 배포 보장
PingPong 전략은 기존 Blue/Green 및 기본 카나리 배포 전략에서 발생하는 503 에러 문제를 해결하고, 무중단 배포(Zero-downtime Deployment)를 보장한다. 이는 다음과 같은 이점을 제공한다.
Promote 시, Service selector 변경 X → 트래픽 유실 X
Pod 생성 시점에 readiness gate 주입 → 헬스 체크 문제 해결
카나리(Canary) 및 Blue/Green 배포를 단일 Rollout으로 관리 가능
결과적으로, PingPong 전략은 배포 안정성을 높이고, 운영 효율성을 향상시키는 데 기여한다.
PingPong 전략의 실제 테스트 결과
저자는 실제 운영 환경과 유사한 환경에서 PingPong 전략의 503 에러 발생 여부를 테스트했다. 테스트 결과, 대부분의 시나리오에서 503 에러 없이 안정적인 배포(Stable Deployment)를 확인했다.
정상 자동 배포, 롤백, 수동 제어 등 모든 정상 운영 시나리오에서 503 에러 미발생
가중치 전환 중 새 버전 배포 시, 약 6초간 503 에러 발생 (비정상적인 운영 케이스)
CI/CD 파이프라인에서 진행 중인 Rollout 여부 확인하는 guard 추가 권장
결론적으로, PingPong 전략은 EKS + ALB 환경에서 503 에러를 효과적으로 해결하고, 배포 안정성을 향상시키는 데 기여한다.
