Classic Load Balancer의 상태 확인이 실패하는 문제는 어떻게 해결하고 수정합니까?

최종 업데이트 날짜: 2018년 6월 8일

Classic Load Balancer에서 실행 중인 하나 이상의 인스턴스가 상태 확인에 실패합니다. 잠재적 원인으로는 어떠한 것이 있으며 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

ELB(Elastic Load Balancing)는 Application Load Balancer, Network Load Balancer 및 Classic Load Balancer를 지원합니다. Classic Load Balancer에서 시행 중인 인스턴스는 다음과 같은 원인으로 인해 상태 확인에 실패할 수 있습니다.

  • 로드 밸런서와 백엔드 사이의 연결 문제
  • 애플리케이션의 구성 문제
  • 상태 확인 요청에 대해 백엔드로부터 "200 OK" 응답을 수신하지 않음
  • HTTPS 또는 SSL 상태 확인을 실패하게 만드는 SSL 문제

해결 방법

상태 확인 관련 문제를 해결하려면 다음을 확인하세요.

로드 밸런서와 백엔드 사이의 잠재적 연결 문제 해결

다음 조건이 참인지 확인하세요.

  • 백엔드가 상태 확인 트래픽을 허용합니다. 보안 그룹 규칙을 확인하려면 로드 밸런서 보안 그룹에 권장되는 규칙을 참조하세요. 백엔드 인스턴스는 VPC의 인스턴스를 위한 보안 그룹을 참조하세요.
  • 로드 밸런서 또는 백엔드가 있는 서브넷에 대한 네트워크 ACL(액세스 제어 목록)이 상태 확인 트래픽을 허용합니다. 로드 밸런서 및 백엔드가 있는 서브넷에 대한 ACL 규칙을 확인하려면 VPC의 로드 밸런서를 위한 네트워크 ACL을 참조하세요.
  • 백엔드의 인스턴스 수준 또는 OS 수준 방화벽이 상태 확인 트래픽을 허용합니다. 백엔드의 인스턴스 또는 OS 수준 방화벽이 상태 확인 트래픽의 송수신을 허용하는지 확인하세요.
  • 백엔드 인스턴스의 리소스가 과다하게 사용되고 있지 않습니다. 메모리와 CPU 사용률이 허용되는 한도 내인지 확인하세요. 메모리 또는 CPU 사용률이 너무 높은 경우 더 많은 백엔드를 추가하거나 백엔드를 더 큰 인스턴스 유형으로 업그레이드합니다.
  • 추가 리소스가 모두 상태 확인 트래픽을 허용합니다. 상태 확인 요청은 백엔드에 의해 추가 리소스에 전달되어야 합니다. 추가 종속성이 응답에 실패하거나 응답하는 데 너무 오래 걸리는 경우 상태 확인이 시간 초과되어 실패합니다. 추가 리소스가 상태 확인 요청에 응답하는지 확인하세요.

애플리케이션의 잠재적 구성 문제 해결

  • 애플리케이션이 실행 중입니다. 예를 들어, Linux 인스턴스에서 Apache를 실행하는 경우 sudo service httpd status 명령을 사용하여 Apache가 실행 중인지 확인합니다.
  • 애플리케이션이 상태 확인 포트에서 수신 대기 중입니다. 서버가 상태 확인 포트에서 수신 대기 중인지 확인하려면 서버에 netstat -ant 명령을 실행합니다. 애플리케이션 구성 포트가 작동 중인지 확인하세요. 로드 밸런서와 백엔드 사이의 TCP 연결을 시뮬레이션하려면 인스턴스에 telnet <backend private IP> <health-check port> 명령을 실행합니다.  출력이 "Connected(연결됨)"인 경우에는 백엔드가 상태 확인 포트에서 수신 대기 중인 것입니다.
  • 애플리케이션이 사용자 지정 호스트 헤더를 가진 요청에 응답하도록 설정되어 있습니다. HTTP 및 HTTPS 상태 확인의 경우, Classic Load Balancer가 헤더를 백엔드의 기본 네트워크 인터페이스의 프라이빗 IP 주소로 설정하고 사용자 에이전트를 "ELB-HealthChecker/1.0"으로 설정합니다. 백엔드가 사용자 지정 호스트 헤더 또는 사용자 에이전트를 가진 요청에만 응답하는 경우에는 상태 확인 요청이 실패합니다.
  • 애플리케이션이 백엔드의 기본 네트워크 인터페이스에서 수신 대기 중입니다. Classic Load Balancer는 백엔드 인스턴스의 기본 네트워크 인터페이스에 연결합니다. 백엔드가 상태 확인 요청에 대한 응답을 전송할 수 있도록 애플리케이션이 백엔드 인스턴스의 기본 네트워크 인터페이스에서 수신 대기 중인지 확인합니다.

상태 확인 요청에 대한 백엔드의 "200 OK" 응답 확인

다음 조건이 참인지 확인하세요.

  • ping 경로가 유효합니다. ping 경로에 지정된 파일이 백엔드에 구성되어 있지 않은 경우 백엔드에서 "404 Not Found(404 찾을 수 없음)" 응답 코드로 응답하고 상태 확인이 실패할 수 있습니다. 참고: ping 경로에 대한 기본값은 /index.html입니다. 백엔드에 index.html 파일이 없는 경우, 파일을 생성하고 ping 경로의 값을 백엔드의 파일 이름으로 변경합니다.
  • 리디렉션이 백엔드에 구성되어 있지 않습니다. 백엔드에 리디렉션이 구성되어 있으면 301 또는 302 응답 코드가 발생하고 상태 확인에 실패할 수 있습니다. 예를 들어, 백엔드의 HTTP:80에서 HTTPS:443으로 리디렉션이 설정된 경우에는 상태 확인을 HTTPS로 변경하고 상태 확인 포트를 443으로 변경하기 전에는 포트 80에서 HTTP 상태 확인이 실패합니다. 참고: 로드 밸런서와 연관된 서브넷의 인스턴스에서 curl -Ivk http[s]://<private-IP-address-of-the-backend-instance>:<health-check-port>/<health-check-target-page> 명령을 사용하면 해당 로드 밸런서가 전송한 상태 확인 요청을 시뮬레이션할 수 있습니다.

SSL 관련 문제 해결

다음 조건이 참인지 확인하세요.

  • 모든 프로토콜과 암호가 일치합니다. HTTPS 또는 SSL 상태 확인의 경우, 로드 밸런스와 백엔드가 동일한 프로토콜 및 암호를 사용해야 합니다. 백엔드 인스턴스에서 캡처된 패킷은 로드 밸런서에서 전송한 client hello에 로드 밸런서에서 지원되는 암호와 프로토콜을 표시합니다. 등록된 백엔드 인스턴스는 로드 밸런서에서 전송한 하나 이상의 암호 및 프로토콜을 지원해야 합니다.
  • SNI(서버 이름 표시)가 백엔드 서버에 활성화되어 있지 않습니다. 상태 확인이 HTTPS/SSL이며 백엔드 인스턴스에 SNI가 활성화되어 있는 경우, 로드 밸런서와 백엔드가 SSL 핸드섀이크를 설정할 수 있습니다. 이는 백엔드 서버가 client hello 이후에 RST를 전송하기 때문입니다. SNI를 비활성화하거나 TCP 상태 확인을 사용하세요.

이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요하세요?