Application Load Balancer의 상태 확인 실패 문제를 해결하려면 어떻게 해야 하나요?

해결 방법

Application Load Balancer에 대한 상태 확인 실패 문제를 해결하려면 문제의 원인 코드와 설명을 찾아보세요. 그런 다음에 다음 작업을 완료하여 문제를 해결하세요.

문제의 원인 코드 및 설명 찾기

대상 그룹의 콘솔 대신 리소스 맵을 사용하여 로드 밸런서의 리소스를 확인하고 비정상 대상을 식별합니다. 리소스 맵은 Application Load Balancer의 모든 리소스를 단일 페이지에 표시합니다.

**참고:**Application Load Balancer의 대상 HTTP 응답이 예상 응답이 아닌 경우 애플리케이션의 응답을 확인하세요. 애플리케이션이 로드 밸런서에 올바른 응답을 전송하는지 확인하세요.

사유 코드를 기반으로 문제 해결

찾은 상태 확인 사유 코드를 기반으로 다음 작업을 완료하여 문제를 해결하세요.

Elb.InitialHealthChecking

대상이 로드 밸런서로부터 요청을 수신하려면 먼저 해당 대상이 초기 상태 확인을 통과해야 합니다. 대상이 초기 상태 확인을 통과할 때까지 기다린 다음 상태를 다시 확인합니다.

Elb.RegistrationInProgress

로드 밸런서는 등록 프로세스가 완료되고 대상이 초기 상태 확인을 통과하는 즉시 대상에 라우팅 요청을 시작합니다.

Target.DeregistrationInProgress

대상을 등록 취소하면 로드 밸런서가 더 이상 대상에 요청을 보내지 않습니다. Elastic Load Balancing은 등록 취소를 완료하기 전에 300초를 기다립니다. 하지만 Amazon EC2 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하여 지연 값을 업데이트할 수 있습니다. 자세한 내용은 등록 취소 지연을 참조하세요.

참고: AWS CLI 명령을 실행할 때 오류가 발생하면, AWS CLI 오류 문제 해결을 참조하세요. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하세요.

Target.FailedHealthChecks

이 문제를 해결하려면 다음 작업을 완료하세요.

• 애플리케이션이 실행 중인지 확인합니다. service 명령을 실행하여 Linux 대상의 서비스 상태를 확인할 수 있습니다. Windows 대상의 경우 Windows 작업 관리자의 서비스 탭을 확인하세요. 서비스가 중지되면 서비스를 시작합니다. 서비스가 인식되지 않으면 서비스가 설치되어 있는지 확인하세요.

• 대상이 상태 확인 포트에서 트래픽을 수신하고 있는지 확인합니다. Linux 대상에서 ss 명령을 실행하여 서버가 수신 중인 포트를 확인할 수 있습니다. Windows 대상의 경우 netstat 명령을 실행할 수 있습니다.

• 대상 인스턴스와 동일한 Amazon 가상 프라이빗 클라우드(VPC) 에서 기존 인스턴스를 시작하거나 사용합니다. 이 인스턴스에 대한 액세스 권한이 있는지 확인하세요. 또는 대상이 공개적으로 액세스할 수 있는 경우 대상의 퍼블릭 IP 주소로 직접 상태 확인 요청을 보내세요.

  다음 CURL 명령을 실행합니다.

  $curl -vkso /dev/null <HealthCheck_protocol>://<Target_IP>:<HealthCheck_port>/<HealthCheck_path>

  **참고:**이 메서드를 사용하여 Application Load Balancer를 우회하고 대상이 로드 밸런서의 상태 확인 요청에 올바르게 응답하는지 확인할 수 있습니다.

• 애플리케이션이 로드 밸런서의 상태 확인 요청에 적절히 응답하는지 확인하세요. 다음 예시는 대상이 유효한 HTTP 응답과 함께 반환해야 하는 Application Load Balancer의 일반적인 상태 확인 요청을 보여줍니다.

  GET / HTTP/1.1Host: 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으로 설정되어 있습니다. 메시지 헤더 필드의 줄 종결자는 시퀀스 CRLF이며, 헤더는 첫 번째 빈 줄에서 끝나고 그 뒤에 CRLF가 옵니다. 상태 확인 요청을 받으려면 웹 서버 구성에 기본 가상 호스트를 추가해야 할 수 있습니다.

• 대상에 여러 인터페이스를 연결한 경우 애플리케이션이 올바른 네트워크 인터페이스에서 수신 대기 중인지 확인합니다. 자세한 내용을 보려면 대상 유형을 참조하세요.

• 대상이 Elastic Load Balancing 보안 정책에 지정된 형식의 서버 인증서와 키를 제공하는지 확인합니다. 또한 대상이 일치하는 암호와 로드 밸런서가 TLS 핸드셰이크를 설정하기 위해 제공하는 프로토콜을 지원하는지 확인하세요.

Target.InvalidState

대상이 Amazon EC2 인스턴스인 경우 Amazon EC2 콘솔을 사용하여 인스턴스가 실행 중인지 확인합니다. 인스턴스가 실행되고 있지 않은 경우 인스턴스를 수동으로 시작합니다.

Target.IpUnusable

대상 유형이 ip인 경우 로드 밸런서에서 이미 사용 중인 IP 주소를 선택하지 마세요.

Target.NotInUse

이 문제를 해결하려면 다음 작업을 완료하세요.

• 대상 그룹을 확인하고 로드 밸런서로부터 트래픽을 수신하도록 구성되었는지 확인합니다.
• 로드 밸런서에서 대상의 가용 영역이 켜져 있는지 확인합니다.

Target.NotRegistered

대상이 대상 그룹에 등록되었는지 확인합니다.

Target.ResponseCodeMismatch

이 문제를 해결하려면 다음 작업을 완료하세요.

• 상태 확인 구성을 검토하여 로드 밸런서가 수신할 것으로 예상되는 성공 코드를 확인하세요. 기본적으로 성공 코드는 200이지만 200에서 499 사이의 값을 지정할 수 있습니다. 그런 다음 웹 서버 액세스 로그를 검사하여 예상 성공 코드가 반환되는지 확인합니다.
• Ping 경로가 유효한지 확인합니다. 유효한 URI를 지정해야 합니다. 기본값은 /입니다.

성공 코드 값 또는 ping 경로를 변경하려면 대상 그룹의 상태 확인 설정 수정을 참조하세요.

Target.Timeout

연결할 수 있는 경우 상태 확인 제한 시간 이전에 대상 페이지가 응답하지 않을 수 있습니다. NGINX 및 IIS와 같은 대부분의 웹 서버에서는 서버가 응답하는 데 걸리는 시간을 기록할 수 있습니다. 자세한 내용은 NGINX 웹 사이트에서 로깅 구성 및 Microsoft 웹 사이트에서 IIS 로깅 구성을 참조하세요.

상태 확인 요청이 구성된 제한 시간보다 오래 걸리는 경우 다음 작업을 완료하세요.

• 상태 확인을 위한 더 간단한 대상 페이지를 선택하세요.
• 상태 확인 설정을 조정합니다.

연결할 수 없는 경우 다음 작업을 완료하세요.

• 상태 확인 포트 및 상태 확인 프로토콜을 사용하여 대상과 연결된 보안 그룹이 로드 밸런서의 트래픽을 허용하는지 확인합니다. 보안 그룹에 규칙을 추가하여 로드 밸런서 보안 그룹의 모든 트래픽을 허용할 수 있습니다. 또한 로드 밸런서에 대한 보안 그룹은 대상으로의 트래픽을 허용해야 합니다.
• 대상의 서브넷과 연결된 네트워크 액세스 제어 목록(네트워크 ACL)이 상태 확인 포트의 인바운드 트래픽을 허용하는지 확인합니다. 또한 네트워크 ACL은 임시 포트(1024~65535)에서 아웃바운드 트래픽을 허용해야 합니다.
• 노드의 서브넷과 연결된 네트워크 ACL이 임시 포트의 인바운드 트래픽을 허용하는지 확인합니다. 또한 네트워크 ACL은 상태 확인 및 임시 포트에서 아웃바운드 트래픽을 허용해야 합니다.
• 대상의 OS 수준 방화벽이 상태 확인 트래픽의 들어오고 나가는 것을 허용하는지 확인합니다.
• 대상 서브넷의 라우팅 테이블에 상태 확인 트래픽을 로드 밸런서로 다시 전송할 수 있는 항목이 포함되어 있는지 확인합니다.
• 대상의 메모리 및 CPU 사용률이 허용 가능한 용량 이내인지 확인합니다. 메모리 또는 CPU 사용률이 너무 높으면 대상을 추가하거나 Auto Scaling 그룹의 용량을 늘리세요. 대상이 EC2 인스턴스인 경우 인스턴스를 더 큰 인스턴스 유형으로 변경하세요.

관련 정보

Application Load Balancer 문제 해결