Application Load Balancer의 상태 확인 실패 문제를 해결하려면 어떻게 해야 합니까?
Application Load Balancer에 등록한 대상이 정상적이지 않은 이유를 알고 싶습니다.
해결 방법
Application Load Balancer의 상태 확인 실패 문제를 해결하려면 AWSSupport-TroubleshootELBHealthChecks 런북을 실행할 수 있습니다. 이 런북은 Amazon CloudWatch 대시보드의 상태 확인 지표 분석을 자동화합니다. 또한 런북은 Application Load Balancer 및 대상 전반의 네트워크 구성을 확인합니다. AWS Systems Manager에서 관리하는 대상의 경우, 런북은 Amazon S3에 선택 사항 로그 보존과 함께 고급 진단 명령을 제공합니다. 런북 솔루션은 인스턴스 대상 유형에 적용됩니다.
또한 Application Load Balancer 리소스 맵을 사용하여 로드 밸런서의 리소스를 확인하고 비정상 대상을 식별할 수 있습니다. 리소스 맵은 모든 Application Load Balancer 리소스를 단일 페이지에 표시합니다.
참고: Application Load Balancer의 대상 HTTP 응답이 예상 응답이 아닌 경우 애플리케이션 응답을 확인합니다. 애플리케이션이 로드 밸런서에 올바른 응답을 전송하는지 확인하십시오.
찾은 상태 확인 사유 코드에 따라 다음과 같은 문제 해결 작업을 수행하십시오.
Elb.InitialHealthChecking
대상이 로드 밸런서에서 요청을 수신하려면 먼저 해당 대상이 초기 상태 확인을 통과해야 합니다. 대상이 초기 상태 확인을 통과할 때까지 기다린 다음, 상태를 다시 확인합니다.
Elb.RegistrationInProgress
대상 등록이 진행 중입니다. 등록이 완료되고 대상이 초기 상태 확인을 통과할 때까지 기다리십시오. 로드 밸런서는 대상을 등록한 후 자동으로 요청을 대상으로 라우팅합니다.
Target.DeregistrationInProgress
대상 그룹에서 대상이 제거됩니다. 로드 밸런서는 진행 중인 요청을 완료하면서 대상에 대한 새 요청을 중지합니다. 기본 등록 취소 지연 시간은 300초입니다. 지연 값을 확인하거나 수정하려면 등록 취소 지연을 참조하십시오.
Target.FailedHealthChecks
대상 인스턴스와 동일한 가상 프라이빗 클라우드(VPC)에서 사용 가능한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 시작하거나 사용합니다. 이 인스턴스에 대한 액세스 권한이 있는지 확인하십시오. 공개적으로 액세스할 수 있는 대상의 경우 다음 명령을 실행하여 대상 인스턴스의 퍼블릭 IP 주소로 상태 확인 요청을 직접 전송합니다.
curl -vkso /dev/null HealthCheck_protocol://Target_IP:HealthCheck_port/HealthCheck_path
참고: Target_IP를 대상 인스턴스의 IP 주소로, HealthCheck_port를 상태 확인 포트로, HealthCheck_path를 상태 확인 경로로 바꿉니다. 위 명령은 로드 밸런서를 우회하여 대상의 응답을 테스트합니다.
애플리케이션이 로드 밸런서의 상태 확인 요청에 어떻게 응답하는지 확인하려면 다음 명령을 실행하여 상태 확인 요청을 시뮬레이션하십시오.
curl -H "User-Agent: ELB-HealthChecker/2.0" -I http://localhost:PORT/HEALTH_CHECK_PATH
참고: PORT를 애플리케이션의 포트 번호로 바꾸고 HEALTH_CHECK_PATH를 상태 확인 경로로 바꿉니다.
응답에 구성된 성공 코드와 일치하는 HTTP 상태 코드가 있는지 확인합니다. 기본 성공 코드는 200입니다. curl을 사용할 수 없는 경우 애플리케이션 로그에서 ELB-HealthChecker/2.0 사용자 에이전트의 요청을 확인하십시오.
다음 예는 유효한 HTTP 응답을 포함하는 Application Load Balancer의 일반적인 상태 확인 요청입니다.
GET / HTTP/1.1 Host: 10.0.0.1:80 Connection: close User-Agent: ELB-HealthChecker/2.0 Accept-Encoding: gzip, compressed
참고: 위 예에서 Host 헤더 값에는 대상의 프라이빗 IP 주소와 상태 확인 포트가 포함됩니다. User-agent가 ELB-HealthChecker/2.0으로 설정되어 있습니다. 애플리케이션이 상태 확인 요청을 받지 못하면 상태 확인 포트와 일치하는 기본 가상 호스트 항목을 추가하십시오.
대상에 탄력적 네트워크 인터페이스를 여러 개 연결한 경우 애플리케이션이 올바른 네트워크 인터페이스에서 수신 중인지 확인하십시오. 애플리케이션에서 사용하는 인터페이스를 확인하려면 다음 명령을 실행합니다.
netstat -an | grep LISTEN
애플리케이션 포트가 올바른 인터페이스 IP 주소를 사용하는지 확인합니다. 네트워크 인터페이스가 다양한 대상 유형에서 작동하는 방식과 이를 올바르게 구성하는 방법에 대한 자세한 내용은 대상 유형을 참조하십시오.
대상이 Elastic Load Balancing 보안 정책에 지정한 형식의 서버 인증서와 키를 제공하는지 확인합니다. 대상이 일치하는 암호와 로드 밸런서가 SSL/TLS 핸드셰이크를 수립하기 위해 제공하는 프로토콜을 지원하는지 확인합니다.
SSL/TLS 암호 지원을 확인하려면 대상에서 다음 명령을 실행합니다.
openssl s_client -connect your_target:443 -servername your_target
참고: your_target을 대상으로 바꿉니다.
출력에서 지원되는 암호를 로드 밸런서의 보안 정책에 목록으로 표시된 암호와 비교하십시오.
Linux 대상
Linux 대상의 경우 다음 명령을 실행하여 서비스가 활성 상태이고 실행 중인지 확인합니다.
service httpd status
참고: httpd를 서비스 이름으로 바꿉니다.
출력에서 active를 찾으십시오.
출력 예시:
Redirecting to /bin/systemctl status httpd.service httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; preset: disabled) Active: active (running) since Fri 2025-06-13 07:00:35 UTC; 16s ago ------------------------------------------------> server status Docs: man:httpd.service(8) Main PID: 10146 (httpd) Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec: 0 B/sec" Tasks: 177 (limit: 9486) Memory: 17.9M CPU: 90ms CGroup: /system.slice/httpd.service ├─10146 /usr/sbin/httpd -DFOREGROUND ├─10147 /usr/sbin/httpd -DFOREGROUND ├─10148 /usr/sbin/httpd -DFOREGROUND ├─10149 /usr/sbin/httpd -DFOREGROUND └─10150 /usr/sbin/httpd -DFOREGROUND Jun 13 07:00:35 ip-172-16-1-59.ec2.internal systemd[1]: Starting httpd.service - The Apache HTTP Server... Jun 13 07:00:35 ip-172-16-1-59.ec2.internal systemd[1]: Started httpd.service - The Apache HTTP Server. Jun 13 07:00:35 ip-172-16-1-59.ec2.internal httpd[10146]: Server configured, listening on: port 80 ---------------->listening port
서비스가 비활성 또는 실패로 표시되면 다음 명령을 실행하여 서비스를 시작합니다.
service httpd start
참고: httpd를 서비스 이름으로 바꿉니다.
Linux 대상이 상태 확인 포트에서 트래픽을 수신하고 있는지 확인하려면 다음 명령을 실행합니다.
ss -nral | grep PORT_NUMBER
참고: PORT_NUMBER를 상태 확인 포트로 바꿉니다. 예를 들어 HTTP에는 80을 사용합니다.
출력 예시:
tcp LISTEN 0 511 * :80 * :*
Windows 대상
Windows 대상의 경우 Windows 작업 관리자의 서비스 탭을 확인합니다. 서비스가 중지되면 서비스를 시작합니다. Windows에서 서비스를 인식하지 못하는 경우 서비스를 설치했는지 확인하십시오.
Windows 대상이 상태 확인 포트에서 트래픽을 수신하고 있는지 확인하려면 다음 명령을 실행합니다.
netstat -an | findstr LISTEN | findstr :PORT_NUMBER
참고: PORT_NUMBER를 상태 확인 포트로 바꿉니다.
Target.InvalidState
대상이 Amazon EC2 인스턴스인 경우 Amazon EC2 콘솔을 사용하여 인스턴스가 실행 중인지 확인합니다. 인스턴스가 실행되고 있지 않은 경우 인스턴스를 수동으로 시작합니다. 대상이 EC2 인스턴스가 아닌 경우 AWS Management Console에서 서비스의 대상 상태를 확인합니다.
Target.IpUnusable
대상 유형이 ip인 경우 로드 밸런서에서 이미 사용하는 IP 주소를 선택하지 마십시오. IP 주소를 업데이트하려면 다음 단계를 완료하십시오.
- Amazon EC2 콘솔을 엽니다.
- 탐색 창에서 인스턴스를 선택합니다.
- 작업을 선택한 다음, 네트워킹을 선택합니다.
- IP 주소 관리를 선택합니다.
- 기본 프라이빗 IP 주소를 수정합니다.
- 저장을 선택합니다.
- 인스턴스를 재부팅합니다.
Target.NotInUse
대상 그룹이 로드 밸런서에서 트래픽을 수신하도록 구성했는지 확인하려면 다음 단계를 완료하십시오.
- Amazon EC2 콘솔을 엽니다.
- 탐색 창에서 로드 밸런서를 선택합니다.
- 해당 로드 밸런서를 선택합니다.
- 작업을 선택한 다음, 리스너 관리를 선택합니다.
- 대상 그룹을 하나 이상의 활성 리스너와 연결했는지 확인합니다.
로드 밸런서의 가용 영역을 업데이트하려면 Application Load Balancer의 가용 영역 업데이트를 참조하십시오.
Target.NotRegistered
대상을 대상 그룹에 등록했는지 확인하십시오.
Target.ResponseCodeMismatch
성공 코드를 확인하려면 상태 확인 구성을 검토하여 로드 밸런서에서 예상하는 성공 코드를 식별합니다. 그런 다음, 웹 서버 액세스 로그를 열고 애플리케이션이 로드 밸런서에 반환하는 HTTP 상태 코드를 확인합니다. 코드가 구성된 성공 코드와 일치하는지 확인하십시오. 기본 성공 코드는 200이지만 200~499 범위에서 사용자 지정 성공 코드를 구성할 수 있습니다.
또한 핑 경로가 존재하고 유효한 URI를 사용하는지 확인하십시오. 기본값은 **/**입니다.
코드가 일치하지 않거나 핑 경로가 잘못된 경우 애플리케이션 또는 상태 확인 설정을 올바른 정보로 업데이트하십시오.
Target.Timeout
연결할 수 있더라도 상태 확인 제한 시간 이전에 대상 페이지가 응답하지 않을 수 있습니다. NGINX 및 IIS(인터넷 정보 서비스)와 같은 웹 서버의 경우 서버가 응답하는 데 걸리는 시간을 로깅할 수 있습니다. 자세한 내용은 NGINX 웹 사이트의 로깅 구성 및 Microsoft 웹 사이트의 IIS 로깅 구성을 참조하십시오.
상태 확인 요청이 구성된 제한 시간보다 오래 걸리는 경우 최소한의 동적 콘텐츠가 포함된 대상 페이지를 사용하십시오. 상태 확인 경로를 수정하려면 Application Load Balancer 대상 그룹의 상태 확인 설정 업데이트를 참조하십시오.
연결할 수 없는 경우 다음 작업을 수행하십시오.
- 상태 확인 포트 및 상태 확인 프로토콜을 사용하여 대상 인스턴스의 보안 그룹이 로드 밸런서에서 트래픽을 허용하는지 확인합니다. 보안 그룹에 규칙을 추가하여 로드 밸런서 보안 그룹의 모든 트래픽을 허용할 수 있습니다.
- Application Load Balancer의 보안 그룹이 대상 인스턴스로 향하는 트래픽을 허용하는지 확인합니다.
- 대상 인스턴스의 네트워크 액세스 제어 목록(네트워크 ACL)이 상태 확인 포트의 인바운드 트래픽과 임시 포트(1024-65535)의 아웃바운드 트래픽을 허용하는지 확인합니다.
- 노드 서브넷의 네트워크 ACL이 임시 포트의 인바운드 트래픽과 상태 확인 및 임시 포트의 아웃바운드 트래픽을 허용하는지 확인합니다.
- 대상의 운영 체제(OS) 방화벽에서 들어오고 나가는 상태 확인 트래픽을 허용하는지 확인합니다.
- 대상 서브넷의 라우팅 테이블에 상태 확인 트래픽을 로드 밸런서로 다시 전송할 수 있는 항목이 포함되어 있는지 확인합니다.
- 대상의 메모리와 CPU 사용량을 확인합니다. 메모리 또는 CPU 사용량이 너무 많으면 대상을 추가하거나 Amazon EC2 Auto Scaling 그룹의 용량을 늘리십시오. 대상이 Amazon EC2 인스턴스인 경우 인스턴스를 더 큰 인스턴스 유형으로 변경하십시오.
관련 정보
- 언어
- 한국어

