Application Load Balancer 상태 확인이 실패하는 문제를 수정 및 해결하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2019년 6월 19일

Application Load Balancer에 등록된 대상이 정상적이지 않습니다. 대상이 상태 확인에 실패한 이유를 어떻게 알 수 있습니까?

​해결 방법

Application Load Balancer에 대해 실패한 상태 확인을 수정하고 문제를 해결하려면 다음을 수행하십시오.

1.    문제의 원인 코드와 설명을 찾으려면 대상의 상태를 확인하십시오.

2.    수신한 오류에 대한 아래 해결 단계를 따르십시오.

Elb.InitialHealthChecking

설명: 초기 상태 확인이 진행 중입니다.

해결 방법: 대상이 로드 밸런서에서 요청을 수신하기 전에 해당 대상은 초기 상태 확인을 통과해야 합니다. 대상이 초기 상태 확인을 통과할 때까지 기다린 다음, 상태를 다시 확인하십시오.

Elb.RegistrationInProgress

설명: 대상 등록이 진행 중입니다.

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

Target.DeregistrationInProgress

설명: 대상 등록 취소가 진행 중입니다.

해결 방법: 대상이 등록 취소되면 로드 밸런서는 진행 중인 요청이 완료될 때까지 대기합니다. 이는 등록 취소 지연이라고 합니다. 기본적으로 Elastic Load Balancing은 등록 취소 프로세스를 완료하기 전에 300초를 대기합니다. 그러나 사용자가 이 값을 사용자 지정할 수 있습니다.

등록 취소 대상에 실행 중인 요청이 없고 활성화된 연결이 없는 경우 Elastic Load Balancing은 등록 취소 지연이 경과하기를 기다리지 않고 즉시 등록을 취소합니다. 등록 취소 대상의 초기 상태를 드레이닝합니다. 등록 취소 지연이 경과한 후에는 등록 취소 프로세스가 완료되고 대상의 상태가 사용되지 않습니다. 대상이 Auto Scaling 그룹의 일부인 경우 대상이 종료 및 교체될 수 있습니다.

Target.FailedHealthChecks

설명: 로드 밸런서가 대상에 대한 연결을 설정하는 동안 오류를 수신했거나 대상 응답의 형식이 잘못되었습니다.

​해결 방법:

  • 애플리케이션이 실행되고 있는지 확인하십시오. 서비스 명령을 사용하여 Linux 대상의 서비스 상태를 확인하십시오. Windows 대상의 경우 Windows 작업 관리자의 서비스 탭을 확인하십시오. 서비스가 중지된 경우 서비스를 시작하십시오. 서비스를 인식할 수 없는 경우 필요한 서비스가 설치되어 있는지 확인하십시오.
  • 대상이 상태 확인 포트에서 트래픽을 수신하는지 확인하십시오. Linux 대상에 있는 ss 명령을 사용하여 서버가 어떤 포트에서 수신하는지 확인할 수 있습니다. Windows 대상에 대해서는 netstat 명령을 사용할 수 있습니다.
  • 애플리케이션이 로드 밸런서의 상태 확인 요청에 맞게 반응하는지 확인하십시오. 다음 예제는 사용자의 대상이 유효한 HTTP 응답에 반환해야 하는 Application Load Balancer의 일반적인 상태 확인 요청을 보여줍니다. 호스트 헤더 값에는 로드 밸런서 노드의 프라이빗 IP 주소와 상태 확인 포트가 순서대로 포함되어 있습니다. User-agent는 ELB-HealthChecker/2.0로 설정됩니다. 메시지 헤더 필드에 대한 선 종료자는 시퀀스 CRLF이며 헤더는 첫 번째 빈 행에서 종료되며 그 뒤에는 CRLF가 이어집니다. 필요한 경우 웹 서버 구성에 기본 가상 호스트를 추가하여 상태 확인 요청을 수신하십시오.
GET / HTTP/1.1
Host: 10.0.0.1:80
Connection: close
User-Agent: ELB-HealthChecker/2.0
Accept-Encoding: gzip, compressed
  • 대상 그룹의 대상 유형은 대상에서 로드 밸런서가 상태 확인을 어떤 네트워크 인터페이스로 전송할지를 결정합니다. 예를 들어, 인스턴스 ID, IP 주소 및 Lambda 함수를 등록할 수 있습니다. 대상 유형이 인스턴스 ID인 경우 로드 밸런서는 대상의 기본 네트워크 인터페이스에 상태 확인 요청을 전송합니다. 대상 유형이 IP 주소인 경우 로드 밸런서는 해당 IP 주소와 연결된 네트워크 인터페이스에 상태 확인 요청을 전송합니다. 대상에 여러 개의 인터페이스가 연결되어있는 경우 애플리케이션이 올바른 네트워크 인터페이스에서 수신 중인지 확인하십시오.
  • ELBSecurityPolicy-2016-08 security policy는 대상 연결 및 HTTPS 상태 확인에 사용됩니다. 대상이 보안 정책에서 지정된 형식의 서버 인증서 및 키를 제공하는지 확인하십시오. 또한 대상이 하나 이상의 일치하는 암호와 TLS 핸드셰이크를 설정하기 위해 로드 밸런서가 제공하는 프로토콜을 지원하는지 확인하십시오.

Target.InvalidState

설명: 대상이 중지 또는 종료된 상태입니다.

해결 방법 : 대상이 EC2 인스턴스인 경우 Amazon EC2 콘솔을 열고 인스턴스가 실행 중인지 확인하십시오. 필요에 따라 인스턴스를 시작하십시오.

Target.IpUnusable

설명: IP 주소는 로드 밸런서에서 사용 중이므로 대상으로 사용할 수 없습니다.

해결 방법: 대상 그룹을 생성할 때 대상 유형을 지정하십시오. 대상 유형이 IP인 경우 로드 밸런서에서 이미 사용 중인 IP 주소를 선택하지 마십시오.

Target.NotInUse

설명: 대상 그룹이 로드 밸런서에서 사용되지 않거나 대상이 로드 밸런서에 대해 활성화되지 않은 가용 영역에 있습니다.

​해결 방법:

  • 대상 그룹을 확인하고 로드 밸런서에서 트래픽을 수신하도록 구성되었는지 확인하십시오.
  • 로드 밸런서에 대해 대상의 가용 영역이 활성화되어 있는지 확인하십시오.

Target.NotRegistered

설명: 대상이 대상 그룹에 등록되어 있지 않습니다.

해결 방법: 대상이 대상 그룹에 등록되어 있는지 확인하십시오.

Target.ResponseCodeMismatch

설명: 상태 확인이 예상 HTTP 코드를 반환하지 않았습니다.

​해결 방법:

  • 성공 코드는 대상으로부터 성공적인 응답을 확인할 때 사용하는 HTTP 코드입니다. 200~499 사이의 값 또는 값 범위를 지정할 수 있습니다. 기본값은 200입니다. 로드 밸런서 상태 확인 구성을 확인하여 수신할 것으로 예상되는 성공 코드를 확인하십시오. 그런 다음, 웹 서버 액세스 로그를 검사하여 예상 성공 코드가 반환되는지 확인하십시오. 필요에 따라 성공 코드 값을 수정하십시오.
  • ping 경로가 유효한지 확인하십시오. ping 경로는 상태 확인을 위한 대상에 대한 대상입니다. 반드시 유효한 URI(/path?query)를 지정하십시오. 기본값은 /입니다. 필요에 따라 ping 경로 값을 수정하십시오.

Target.Timeout

설명: 요청이 시간 초과되었습니다.

해결 방법: 사용자가 연결할 수 있는 경우, 상태 확인 시간 제한 기간 이전에는 대상 페이지가 응답하지 않을 수 있습니다. nginxIIS와 같은 대부분의 웹 서버를 사용하면 서버가 응답하는 데 걸리는 시간을 기록할 수 있습니다. 상태 확인 요청이 구성된 제한 시간보다 오래 걸리면 다음 작업을 수행해 볼 수 있습니다.

연결할 수 없는 경우에는 다음 작업을 수행하십시오.

  • 상태 확인 포트 및 상태 확인 프로토콜을 사용하여 대상과 연결된 보안 그룹이 로드 밸런서의 트래픽을 허용하는지 확인하십시오. 보안 그룹에 규칙을 추가하여 로드 밸런서 보안 그룹의 모든 트래픽을 허용할 수 있습니다. 또한 로드 밸런서에 대한 보안 그룹 은 대상에 대한 트래픽을 허용해야 합니다.
  • 대상의 서브넷과 연결된 네트워크 ACL이 상태 확인 포트의 인바운드 트래픽을 허용하는지 확인하십시오. 또한 휘발성 포트(1024-65535)에서 아웃바운드 트래픽을 허용하는지 확인하십시오.
  • 로드 밸런서 노드의 서브넷과 연결된 네트워크 ACL이 휘발성 포트에서 인바운드 트래픽을 허용하는지 확인하십시오. 또한 상태 확인 및 휘발성 포트에서 아웃바운드 트래픽을 허용하는지도 확인하십시오.
  • 대상의 OS 수준 방화벽이 상태 확인 트래픽의 출입을 허용하는지 확인하십시오.
  • 대상과 연결된 서브넷에 대한 라우팅 테이블에 로드 밸런서로 상태 확인 트래픽 백을 허용하는 항목이 포함되어 있는지 확인하십시오.
  • 대상의 메모리 및 CPU 사용이 허용 가능한 범위 내에 있는지 확인하십시오. 메모리 또는 CPU 사용률이 너무 높으면 대상을 추가하거나 Auto Scaling 그룹의 용량을 증가시키십시오. 대상이 EC2 인스턴스인 경우 인스턴스를 더 큰 인스턴스 유형으로 업그레이드할 수도 있습니다.

이 문서가 도움이 되었습니까?

AWS에서 개선해야 할 부분이 있습니까?


도움이 필요하십니까?