Elastic Load Balancer (ELB, AWS 기준)에 클라이언트 연결은 성공적으로 이루어졌지만(DNS 조회 정상, 리스너 포트 수신 정상 작동), 실제 백엔드 서버(타겟 인스턴스)로 트래픽이 제대로 전달되지 않고 접속 지연, 504 Gateway Timeout, 또는 502/503/504 같은 5xx 계열 오류가 지속적으로 발생하는 문제는 주로 헬스 체크(Health Check) 실패와 보안 그룹(Security Group) 및 네트워크 ACL(NACL) 설정 불일치 때문에 발생합니다. ELB는 오직 Healthy 상태로 판정된 타겟 인스턴스에게만 트래픽을 라우팅하도록 설계되어 있기 때문에, 타겟 그룹(Target Group)의 헬스 체크 경로, 임계값, 프로토콜/포트 일치 여부, 그리고 타겟 인스턴스의 방화벽 및 애플리케이션 응답 상태를 중심으로 체계적이고 단계적인 진단이 반드시 필요합니다.
Elastic Load Balancer (ELB, AWS 기준)에 클라이언트 연결은 성공적으로 이루어졌지만(DNS 조회 정상, 리스너 포트 수신 정상 작동), 실제 백엔드 서버(타겟 인스턴스)로 트래픽이 제대로 전달되지 않고 접속 지연, 504 Gateway Timeout, 또는 502/503/504 같은 5xx 계열 오류가 지속적으로 발생하는 문제는 주로 헬스 체크(Health Check) 실패와 보안 그룹(Security Group) 및 네트워크 ACL(NACL) 설정 불일치 때문에 발생합니다. ELB는 오직 Healthy 상태로 판정된 타겟 인스턴스에게만 트래픽을 라우팅하도록 설계되어 있기 때문에, 타겟 그룹(Target Group)의 헬스 체크 경로, 임계값, 프로토콜/포트 일치 여부, 그리고 타겟 인스턴스의 방화벽 및 애플리케이션 응답 상태를 중심으로 체계적이고 단계적인 진단이 반드시 필요합니다.
1. 헬스 체크 상태 진단 (가장 흔한 원인)
ELB가 타겟 인스턴스를 Unhealthy(비정상) 상태로 판단하면 해당 인스턴스로 트래픽을 보내지 않습니다.
1.1. 타겟 그룹 헬스 체크 확인
- 상태 확인: AWS 콘솔의 ELB 타겟 그룹(Target Group) 페이지에서 타겟 인스턴스의 상태가
Healthy인지Unhealthy인지 확인합니다. - 프로토콜 및 포트: 헬스 체크 설정이 타겟 인스턴스에서 실제 서비스가 리스닝하는 포트와 프로토콜과 정확히 일치하는지 확인합니다. (예: 애플리케이션이 8080 포트에서 실행 중이면 헬스 체크 포트도 8080이어야 함)
- 경로(Path) 확인: 헬스 체크 경로(기본값
/)가 타겟 서버에서 HTTP 200 상태 코드를 반환하도록 올바르게 설정되었는지 확인합니다. 이 경로가 404나 5xx를 반환하면 헬스 체크는 실패합니다.
1.2. 인스턴스 내부 응답 확인
- 타겟 인스턴스에 직접 접근(SSH/RDP)하여 헬스 체크 경로(
curl localhost:<port>/<path>)로 요청했을 때 정상적인 200 응답이 오는지 확인합니다. 인스턴스 내부의 웹 서버(Nginx, Apache)가 중단되었거나 응답하지 않는다면 헬스 체크는 실패합니다.
2. 보안 그룹 및 네트워크 방화벽 점검
헬스 체크가 타겟 인스턴스에 도달하는 경로를 보안 그룹이 차단하고 있을 수 있습니다.
2.1. 타겟 인스턴스 보안 그룹 (인바운드)
- ELB 트래픽 허용: 타겟 인스턴스에 연결된 보안 그룹의 인바운드(Inbound) 규칙이 ELB로부터 오는 트래픽을 허용해야 합니다.
- 포트: 타겟 포트(예: 80, 443 또는 8080)가 열려 있어야 합니다.
- 소스: 소스는 로드 밸런서가 사용하는 보안 그룹 ID 또는 VPC CIDR 블록으로 지정해야 합니다. (ELB는 사설 IP를 통해 타겟과 통신하므로, 공인 IP를 소스로 지정해서는 안 됩니다.)
- 헬스 체크 트래픽 허용: 헬스 체크 포트(일반적으로 서비스 포트와 동일)에 대한 접근 역시 허용되어야 합니다.
2.2. 로드 밸런서 보안 그룹 (아웃바운드)
- 로드 밸런서에 연결된 보안 그룹의 아웃바운드(Outbound) 규칙이 타겟 인스턴스의 사설 IP 주소 및 포트로 트래픽을 보낼 수 있도록 허용되어 있는지 확인합니다. 일반적으로
0.0.0.0/0또는 타겟 인스턴스가 속한 VPC CIDR에 대해 허용됩니다.
3. 리스너 및 타겟 그룹 설정 일치
ELB의 프론트엔드와 백엔드 간의 통신 프로토콜 일치 여부를 확인합니다.
- 리스너 포트/프로토콜: 리스너가 클라이언트로부터 HTTPS(443)를 수신하고 있다면, 타겟 그룹으로 전달할 때의 프로토콜 설정(HTTP vs HTTPS)을 확인해야 합니다.
- HTTPS to HTTP (일반적): ALB는 HTTPS를 받아 암호 해독 후, 타겟 그룹으로는 일반 HTTP로 전달할 수 있습니다.
- HTTPS to HTTPS: 타겟 그룹으로 HTTPS를 사용한다면, 타겟 인스턴스에 유효한 SSL 인증서가 설치되어 있어야 합니다. 유효하지 않은 인증서는 502 Bad Gateway 오류를 유발합니다.
- VPC 및 서브넷 일치: 로드 밸런서와 타겟 인스턴스가 동일한 VPC 내에 있으며, 타겟 인스턴스가 로드 밸런서의 서브넷(혹은 ELB가 접근할 수 있는 경로를 가진 서브넷)에 위치하는지 확인합니다.
4. 최종 진단: CloudWatch 및 로그 분석
위의 기본 설정이 모두 올바른 경우, 로그를 통해 문제의 근원을 파악합니다.
- CloudWatch 지표: AWS CloudWatch에서 ELB 지표를 확인합니다.
HealthyHostCount: 이 수치가 0이라면 모든 타겟이 비정상 상태입니다.HTTPCode_Target_5XX_Count: 이 수치가 증가하면 타겟 인스턴스가 5xx 오류 코드를 반환하고 있음을 의미합니다.
- Access Log 분석: ELB Access Log를 활성화하고 5xx 오류가 발생한 시점의 로그를 분석하여,
target_status_code와error_reason필드를 통해 정확한 실패 원인(예:Target_Connection_Error,Target_TLS_Error)을 파악합니다.
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.