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 상태 확인을 사용하세요.

---

관련 정보

Classic Load Balancer를 위한 등록된 인스턴스