AWS ALB 503 Service Unavailable
정의 (Definition)
AWS ALB에서 HTTP 503 Service Unavailable은 로드 밸런서가 요청을 전달할 유효한 타겟(Target)을 찾을 수 없는 상태를 의미합니다. 이는 서버가 과부하 걸린 상태(RFC 표준)일 수도 있지만, AWS ALB 컨텍스트에서는 주로 **“Target Group에 등록된 Healthy 인스턴스가 0개임”**을 나타냅니다.
문제가 되는 배경 (Problem Context)
사용자는 “서버가 죽었다”고 생각하지만, 실제로는 애플리케이션 프로세스는 살아있는데 네트워크 경로나 서비스 등록 과정의 문제로 트래픽을 받지 못하는 경우가 많습니다. 특히 Kubernetes 환경에서는 Pod가 떠 있어도 ALB가 이를 인식하지 못해 503이 발생합니다.
핵심 메커니즘 (How it Works)
ALB가 503을 반환하는 주요 조건은 다음과 같습니다.
- No Registered Targets: Target Group에 등록된 대상이 아예 없음 (예: K8s Endpoints가 비어있음).
- All Targets Unhealthy: 대상은 있으나 모두 Health Check를 실패함.
- Target Not in Use: 등록은 되었으나 초기화 중이거나 Draining 상태임.
Kubernetes에서 이는 주로 Service Selector 불일치나 Readiness Probe 실패로 인해 Endpoints가 생성되지 않을 때 발생합니다.
불변 조건과 보장 범위 (Invariants & Guarantees)
- 보장: 유효한(Healthy) 타겟이 단 하나라도 있다면 ALB는 503을 반환하지 않습니다.
- 비보장: 503 오류가 항상 ALB에서 생성되는 것은 아닙니다. 백엔드 애플리케이션이 명시적으로 503을 응답할 수도 있습니다(이 경우
HTTPCode_Target_5XX지표 증가).
비유 (Analogy)
- 503 Error: “택배 기사(ALB)가 물건을 배송하려는데, 주소지(Target Group)에 갔더니 건물 자체가 없거나(No Targets), 문이 다 잠겨있는(All Unhealthy) 상황”입니다.
실무적 함의 (Operational Implications)
- 우선순위 점검: 503 발생 시 애플리케이션 로그보다 **
kubectl get endpoints**를 먼저 확인해야 합니다. - Readiness Probe: Pod가 Running이어도 Readiness Probe가 실패하면 ALB 입장에서는 타겟이 없는 것과 동일합니다. (관련: K8s Readiness Probe)
주의사항 / 오해 (Pitfalls & Misconceptions)
- “Pod가 떠 있으니 503이 아니다?”: Pod가 Running 상태인 것과 ALB Target Group에 Healthy로 등록된 것은 별개입니다.
- Ingress 설정 오류: Ingress가 가리키는
serviceName이나servicePort가 오타로 잘못되어 있어도 타겟을 못 찾아 503이 발생합니다.
References
- AWS Docs: Troubleshoot HTTP 503 errors
- Related Note: K8s Readiness Probe