Application Load Balancer 문제 해결

다음 정보는 Application Load Balancer와 관련된 문제를 해결하는 데 도움이 될 수 있습니다.

리소스 맵을 사용하여 상태 점검 문제 해결

Application Load Balancer 대상의 상태 확인이 실패하는 경우 Elastic Load Balancing 리소스 맵을 사용하여 비정상 대상을 찾고 실패 원인 코드에 따라 조치를 취할 수 있습니다.

리소스 맵 액세스

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 리소스 맵 탭을 선택하여 리소스 시각화를 표시합니다.

리소스 맵 탐색하기

• 리소스 타일에 마우스를 갖다 대거나 선택하면 해당 타일과 다른 리소스 간의 관계가 강조 표시됩니다.

• 리소스 타일을 선택하면 해당 리소스에 대한 추가 세부 정보를 볼 수 있습니다.

• 타일 내에서 리소스 이름을 선택하면 해당 리소스의 세부 정보 페이지로 이동합니다.

리소스 맵 사용

리소스 맵은 개요 및 비정상 대상 맵이라는 두 가지 보기를 제공합니다. 개요는 기본적으로 선택되며 로드 밸런서의 모든 리소스를 표시합니다. 비정상 대상 맵 보기를 선택하면 Application Load Balancer와 관련된 각 대상 그룹의 비정상 대상만 표시됩니다.

참고

리소스 맵 내의 상태 점검 요약 및 오류 메시지를 보려면 리소스 세부 정보 표시를 활성화해야 합니다. 활성화되지 않은 경우 각 리소스를 선택하여 해당 세부 정보를 확인해야 합니다.

대상 그룹 열에는 각 대상 그룹의 정상 및 비정상 대상 요약이 표시됩니다. 이를 통해 모든 대상이 상태 점검에 실패했는지 아니면 특정 대상만 실패했는지 확인할 수 있습니다. 대상 그룹의 모든 대상이 상태 점검에 실패하는 경우 대상 그룹의 구성을 확인하십시오. 대상 그룹 이름을 선택하면 새 탭에서 해당 세부 정보 페이지가 열립니다.

Targets 열에는 TargetId와 각 대상의 현재 상태 점검 상태가 표시됩니다. 대상이 비정상인 경우 상태 점검 실패 사유 코드가 표시됩니다. 단일 대상이 상태 점검에 실패하는 경우 대상에 충분한 리소스가 있는지 확인하고 대상에서 실행되는 애플리케이션을 사용할 수 있는지 확인하십시오. 대상 이름을 선택하면 해당 세부 정보 페이지가 새 탭에서 열립니다.

내보내기를 선택하면 Application Load Balancer 리소스 맵의 현재 보기를 PDF로 내보낼 수 있습니다.

비정상 대상 상태 문제 해결

• 비정상: HTTP 응답 불일치

  • 대상에서 실행되는 애플리케이션이 애플리케이션 로드 밸런서의 상태 확인 요청에 올바른 HTTP 응답을 보내고 있는지 확인하십시오.

  • 또는 대상에서 실행 중인 애플리케이션의 응답과 일치하도록 Application Load Balancer의 상태 확인 요청을 업데이트할 수 있습니다.

• 비정상: 요청 제한 시간이 초과되었습니다.

  • 대상 및 Application Load Balancer와 관련된 보안 그룹 및 네트워크 액세스 제어 목록 (ACL) 이 연결을 차단하지 않는지 확인하십시오.

  • 대상에 Application Load Balancer의 연결을 수락하는 데 사용할 수 있는 리소스가 충분한지 확인합니다.

  • 대상에서 실행 중인 모든 애플리케이션의 상태를 확인합니다.

  • Application Load Balancer의 상태 점검 응답은 각 대상의 애플리케이션 로그에서 볼 수 있습니다. 자세한 내용은 건강 진단 사유 코드를 참조하십시오.

• 비정상: FailedHealthChecks

  • 타겟에서 실행 중인 모든 애플리케이션의 상태를 확인합니다.

  • 대상이 상태 점검 포트에서 트래픽을 수신하고 있는지 확인합니다.

    HTTPS 리스너를 사용하는 경우

    프런트 엔드 연결에 사용할 보안 정책을 선택합니다. 백엔드 연결에 사용되는 보안 정책은 사용 중인 프런트 엔드 보안 정책에 따라 자동으로 선택됩니다.

    • HTTPS 수신기가 프런트 엔드 연결에 TLS 1.3 보안 정책을 사용하는 경우 보안 정책은 백엔드 연결에 사용됩니다. ELBSecurityPolicy-TLS13-1-0-2021-06

    • HTTPS 수신기가 프런트 엔드 연결에 TLS 1.3 보안 정책을 사용하지 않는 경우 보안 정책은 백엔드 연결에 사용됩니다. ELBSecurityPolicy-2016-08

    자세한 내용은 보안 정책을 참조하십시오.

  • 대상이 보안 정책에 지정된 올바른 형식의 서버 인증서 및 키를 제공하고 있는지 확인하십시오.

  • TLS 연결의 경우 대상이 하나 이상의 일치하는 암호와 Application Load Balancer에서 제공하는 프로토콜을 지원하는지 확인하십시오.

등록된 대상은 서비스되지 않고 있습니다.

대상이 InService 상태로 들어가는 데 예상보다 시간이 오래 걸릴 경우 상태 확인에 실패할 수 있습니다. 한번이라도 상태 확인을 통과할 때까지 대상이 서비스되지 않습니다. 자세한 내용은 대상 그룹에 대한 상태 확인 단원을 참조하십시오.

인스턴스가 상태 확인에 실패하고 있는지 확인한 다음, 다음 문제를 점검합니다.

보안 그룹이 트래픽을 허용하지 않음

인스턴스에 연결된 보안 그룹은 반드시 상태 확인 포트와 상태 확인 프로토콜을 사용하여 로드 밸런서에서의 트래픽을 허용해야 합니다. 로드 밸런서 보안 그룹에서의 모든 트래픽을 허용할 수 있도록 인스턴스 보안 그룹에 규칙을 추가할 수 있습니다. 또한 로드 밸런서를 위한 보안 그룹은 반드시 인스턴스로의 트래픽을 허용해야 합니다.

ACL(액세스 제어 목록)이 트래픽을 허용하지 않음

인스턴스를 위해 서브넷에 연결된 네트워크 ACL은 상태 확인 포트에서 인바운드 트래픽을, 휘발성 포트(1024-65535)에서 아웃바운드 트래픽을 허용해야 합니다. 로드 밸런서 노드를 위해 서브넷에 연결된 네트워크 ACL은 휘발성 포트에서 인바운드 트래픽을, 상태 확인 및 휘발성 포트에서 아웃바운드 트래픽을 허용해야 합니다.

핑 경로가 존재하지 않습니다.

상태 확인을 위한 대상 페이지를 생성하고 이것의 경로를 핑 경로로 지정합니다.

유휴 연결 제한 시간

먼저, 대상의 프라이빗 IP 주소와 상태 확인 프로토콜을 사용하여 네트워크 내에서 직접 대상을 연결할 수 있는지 확인합니다. 연결이 불가능하면 인스턴스가 과도하게 사용되고 있는지 확인하고, 이 인스턴스가 처리할 요청이 너무 많은 경우 대상 그룹에 더 많은 대상을 추가합니다. 연결이 가능한 경우, 상태 확인 시간 제한이 시작되기 전에 대상 페이지가 응답을 하지 않을 수 있습니다. 상태 확인을 위해 더 간단한 대상 페이지를 선택하거나 상태 확인 설정을 조정합니다.

대상이 성공적 응답 코드를 반환하지 않음

성공 코드는 200으로 기본 설정되어 있지만, 상태 확인을 구성할 때 선택에 따라 성공 코드를 추가적으로 지정할 수 있습니다. 성공 코드가 로드 밸런서가 기대하고 있는 것인지, 그리고 성공 시 이들 코드를 반환하도록 애플리케이션이 구성되어 있는지 확인합니다.

대상 응답 코드의 형식이 잘못되었거나 대상에 연결하는 동안 오류가 발생했습니다.

애플리케이션이 로드 밸런서의 상태 확인 요청에 응답하는지 확인합니다. 일부 애플리케이션에서는 로드 밸런서가 보낸 HTTP 호스트 헤더에 응답하기 위한 가상 호스트 구성과 같이 상태 확인에 응답하기 위해 추가 구성이 필요합니다. 호스트 헤더 값에는 대상의 사설 IP 주소가 포함되며, 기본 포트를 사용하지 않는 경우에는 상태 확인 포트가 뒤따릅니다. 대상이 기본 상태 점검 포트를 사용하는 경우 호스트 헤더 값에는 대상의 사설 IP 주소만 포함됩니다. 예를 들어 대상의 사설 IP 주소가 10.0.0.10 이고 상태 확인 포트가 인 경우 상태 확인에서 로드 밸런서가 보내는 HTTP Host 헤더는 입니다Host: 10.0.0.10:8080. 8080 대상의 사설 IP 주소가 10.0.0.10 이고 상태 확인 포트인 경우 상태 점검 시 로드 밸런서가 보내는 HTTP Host 헤더는 입니다80. Host: 10.0.0.10 애플리케이션 상태를 확인하려면 해당 호스트에 응답하는 가상 호스트 구성 또는 기본 구성이 필요할 수 있습니다. 상태 확인 요청에는 다음 속성이 포함됩니다. User-Agent는 ELB-HealthChecker/2.0로 설정되고, 메시지 헤더 필드의 행 종결자는 시퀀스 CRLF이며, 헤더는 첫 번째 빈 행에서 종료되고 그 뒤에 CRLF가 옵니다.

클라이언트가 인터넷 경계 로드 밸런서에 연결할 수 없음

로드 밸런서가 요청에 응답하지 않는 경우에는 다음 문제를 점검하세요.

인터넷 경계 로드 밸런서가 프라이빗 서브넷에 연결됩니다.

로드 밸런서를 위한 퍼블릭 서브넷을 지정해야 합니다. 퍼브릭 서브넷은 가상 프라이빗 클라우드(VPC)를 위한 인터넷 게이트웨이로 연결되는 경로를 가지고 있습니다.

보안 그룹이나 네트워크 ACL이 트래픽을 허용하지 않음

로드 밸런서를 위한 보안 그룹과 로드 밸런서 서브넷을 위한 모든 네트워크 ACL은 클라이언트에서의 인바운드 트래픽과 리스너 포트의 클라이언트로의 아웃바운드 트래픽을 허용해야 합니다.

사용자 지정 도메인으로 전송된 요청은 로드 밸런서에 수신되지 않음

로드 밸런서가 커스텀 도메인에 보낸 요청을 받지 않는 경우에는 다음 문제를 점검하세요.

사용자 지정 도메인 이름이 로드 밸런서 IP 주소로 확인되지 않음

• 명령줄 인터페이스를 사용하여 사용자 지정 도메인 이름이 어떤 IP 주소로 변환되는지 확인합니다.

  • Linux, macOS 또는 Unix — 터미널에서 dig 명령을 사용할 수 있습니다. Ex.dig example.com

  • Windows — 명령 프롬프트에서 nslookup 명령을 사용할 수 있습니다. Ex.nslookup example.com

• 명령줄 인터페이스를 사용하여 로드 밸런서 DNS 이름이 어떤 IP 주소로 변환되는지 확인합니다.

• 두 출력의 결과를 비교합니다. IP 주소는 일치해야 합니다.

Route 53을 사용하여 사용자 지정 도메인을 호스팅하는 경우 Amazon Route 53 개발자 안내서의 인터넷에서 내 도메인을 사용할 수 없음을 참조하세요.

로드 밸런서로 전송된 HTTPS 요청은 “NET: :ERR_CERT_COMMON_NAME_INVALID”를 반환합니다.

HTTPS 요청이 로드 밸런서에서 NET::ERR_CERT_COMMON_NAME_INVALID을 받는 경우 다음과 같은 가능한 원인을 확인하세요.

• HTTPS 요청에 사용된 도메인 이름이 리스너 관련 ACM 인증서에 지정된 대체 이름과 일치하지 않습니다.

• 로드 밸런서의 기본 DNS 이름이 사용되고 있습니다. *.amazonaws.com 도메인에 공개 인증서를 요청할 수 없으므로 기본 DNS 이름을 사용하여 HTTPS 요청을 할 수 없습니다.

로드 밸런서가 높은 처리 시간을 표시합니다

로드 밸런서가 구성에 따라 처리 시간을 다르게 계산합니다.

• Application Load Balancer와 연결되어 있고 클라이언트가 HTTP POST 요청을 보내는 경우 AWS WAF POST 요청에 대한 데이터를 보내는 데 걸리는 시간은 로드 밸런서 액세스 로그의 request_processing_time 필드에 반영됩니다. 이는 HTTP POST 요청에 대해 예상된 동작입니다.

• Application Load Balancer와 연결되어 있지 않고 클라이언트가 HTTP POST 요청을 보내는 경우 AWS WAF POST 요청에 대한 데이터를 보내는 데 걸리는 시간이 로드 밸런서 액세스 로그의 target_processing_time 필드에 반영됩니다. 이는 HTTP POST 요청에 대해 예상된 동작입니다.

로드 밸런서가 응답 코드 000을 보냅니다.

HTTP/2 연결을 사용하는 경우 헤더의 압축 길이가 8K를 초과하거나 하나의 연결에서 지원하는 요청 수가 10,000개를 초과하면 로드 밸런서는 GOAWY 프레임을 보내고 TCP FIN과의 연결을 종료합니다.

로드 밸런서가 HTTP 오류 코드를 생성

로드 밸런서는 다음과 같은 HTTP 오류 코드를 생성합니다. 로드 밸런서는 클라이언트에 HTTP 코드를 전송하고 액세스 로그에 대한 요청을 저장하며, HTTPCode_ELB_4XX_Count 또는 HTTPCode_ELB_5XX_Count 지표를 증분합니다.

오류

• HTTP 400: 잘못된 요청
• HTTP 401: 권한 없음
• HTTP 403: 금지됨
• HTTP 405: 허용되지 않은 메서드
• HTTP 408: 요청 제한 시간
• HTTP 413: 페이로드가 너무 큼
• HTTP 414: URI가 너무 긺
• HTTP 460
• HTTP 463
• HTTP 464
• HTTP 500: 내부 서버 오류
• HTTP 501: 구현되지 않음
• HTTP 502: 잘못된 게이트웨이
• HTTP 503: 서비스 사용 불가
• HTTP 504: 게이트웨이 제한 시간
• HTTP 505: 버전이 지원되지 않습니다.
• HTTP 507: 스토리지 부족
• HTTP 561: 권한 없음

HTTP 400: 잘못된 요청

가능한 원인:

• 클라이언트가 HTTP 사양을 충족하지 않는 잘못된 형식의 요청을 전송했습니다.

• 요청 헤더가 요청 줄당 16K, 단일 헤더당 16K 또는 전체 요청 헤더에서 64K를 초과했습니다.

• 클라이언트가 전체 요청 본문을 보내기 전에 연결을 종료했습니다.

HTTP 401: 권한 없음

사용자를 인증하도록 리스너 규칙을 구성했지만, 다음 중 하나가 true입니다.

• 인증되지 않은 사용자를 거부하도록 OnUnauthenticatedRequest를 구성했거나 IdP가 액세스를 거부했습니다.

• IdP에서 반환된 클레임 크기가 로드 밸런서에서 지원되는 최대 크기를 초과했습니다.

• 클라이언트가 호스트 헤더 없이 HTTP/1.0 요청을 제출했으며, 로드 밸런서가 리디렉션 URL을 생성하지 못했습니다.

• 요청된 범위가 ID 토큰을 반환하지 않습니다.

• 클라이언트 로그인 제한 시간이 만료되기 전에 로그인 프로세스를 완료하지 않았습니다. 자세한 내용은 클라이언트 로그인 시간 초과 단원을 참조하세요.

HTTP 403: 금지됨

Application Load Balancer에 대한 요청을 모니터링하도록 AWS WAF 웹 액세스 제어 목록 (웹 ACL) 을 구성하고 요청을 차단했습니다.

HTTP 405: 허용되지 않은 메서드

클라이언트가 사용한 TRACE 방법은 Application Load Balancer에서 지원하지 않습니다.

HTTP 408: 요청 제한 시간

클라이언트가 유휴 제한 시간 만료 전에 데이터를 전송하지 않았습니다. TCP 연결 유지를 전송해도 이 시간 제한을 막지 못합니다. 각 유휴 제한 시간이 지나기 전에 최소 1바이트의 데이터를 전송하십시오. 필요한 만큼 유휴 제한 시간의 길이를 늘립니다.

HTTP 413: 페이로드가 너무 큼

가능한 원인:

• 대상이 Lambda 함수이고 요청 본문이 1MB를 초과합니다.

• 요청 헤더가 요청 줄당 16K, 단일 헤더당 16K 또는 전체 요청 헤더에서 64K를 초과했습니다.

HTTP 414: URI가 너무 긺

요청 URL 또는 쿼리 문자열 파라미터가 너무 큽니다.

HTTP 460

로드 밸런서가 클라이언트에서 요청을 수신했지만, 유휴 제한 시간이 종료되기 전에 클라이언트가 로드 밸런서와의 연결을 종료했습니다.

클라이언트 제한 시간이 로드 밸런서의 유휴 제한 시간보다 큰지 확인합니다. 클라이언트 제한 시간이 끝나기 전에 대상이 클라이언트에 응답을 제공하는지 확인하거나, 클라이언트가 제한 시간을 지원할 경우 로드 밸런서의 유휴 제한 시간에 맞게 클라이언트 제한 시간을 늘립니다.

HTTP 463

로드 밸런서가 너무 많은 IP 주소를 가진 X-Forwarded-For 요청 헤더를 받았습니다. IP 주소의 상한은 30입니다.

HTTP 464

로드 밸런서가 대상 그룹 프로토콜의 버전 구성과 호환되지 않는 수신 요청 프로토콜을 받았습니다.

가능한 원인:

• 요청 프로토콜은 HTTP/1.1이지만, 대상 그룹 프로토콜 버전은 gRPC 또는 HTTP/2입니다.

• 요청 프로토콜은 GRPC이지만, 대상 그룹 프로토콜 버전은 HTTP/1.1입니다.

• 요청 프로토콜은 HTTP/2이고 요청은 POST가 아니지만, 대상 그룹 프로토콜 버전은 gRPC입니다.

HTTP 500: 내부 서버 오류

가능한 원인:

• AWS WAF 웹 ACL (액세스 제어 목록) 을 구성했는데 웹 ACL 규칙을 실행하는 중 오류가 발생했습니다.

• 로드 밸런서가 IdP 토큰 엔드포인트 또는 IdP 사용자 정보 엔드포인트와 통신할 수 없습니다.

  • IdP의 DNS를 공개적으로 확인할 수 있는지 확인합니다.

  • 로드 밸런서의 보안 그룹과 VPC의 네트워크 ACL이 이러한 엔드포인트에 대한 발신 액세스를 허용하는지 확인합니다.

  • VPC에서 인터넷에 액세스할 수 있는지 확인합니다. 내부 로드 밸런서가 있는 경우, NAT 게이트웨이를 사용하여 인터넷 액세스를 활성화하십시오.

• IdP로부터 받은 사용자 클레임의 크기가 11KB를 초과합니다.

HTTP 501: 구현되지 않음

로드 밸런서가 미지원 값이 포함된 Transfer-Encoding 헤더를 받았습니다. Transfer-Encoding에서 지원하는 값은 chunked 및 identity입니다. 대신 Content-Encoding 헤더를 사용할 수 있습니다.

HTTP 502: 잘못된 게이트웨이

가능한 원인:

• 연결 설정을 시도하는 동안 로드 밸런서가 대상에서 TCP RST를 수신했습니다.

• 연결을 설정하려고 했을 때 로드 밸런서가 "ICMP 대상에 연결할 수 없음(호스트에 연결할 수 없음"과 같이 대상으로부터 예기치 않은 응답을 받았습니다. 로드 밸런서 서브넷부터 대상 포트의 대상에 이르기까지 트래픽 허용 여부를 점검하십시오.

• 로드 밸런서가 대상에 대해 대기 중인 요청을 가지고 있는 상태에서 대상이 TCP RST 또는 TCP FIN과의 연결을 종료했습니다. 대상의 연결 유지 기간이 로드 밸런서의 유휴 제한 시간 값보다 짧은지 확인합니다.

• 대상 응답이 잘못된 형식이거나 유효하지 않은 HTTP를 포함하고 있습니다.

• 전체 응답 헤더의 대상 응답 헤더가 32K를 초과했습니다.

• 등록 취소된 대상에 의해 처리 중인 요청에 대해 경과된 등록 취소 지연 시간 오래 걸리는 작업이 완료될 수 있도록 지연 기간을 늘립니다.

• 대상이 Lambda 함수이고 응답 본문이 1MB를 초과합니다.

• 대상이 구성된 제한 시간에 도달하기 전에 응답하지 않은 Lambda 함수입니다.

• 대상이 오류를 반환하는 Lambda 함수이거나 Lambda 서비스에 의해 스로틀된 함수입니다.

• 로드 밸런서에서 대상에 연결할 때 SSL 핸드셰이크 오류가 발생했습니다.

자세한 내용은 AWS 지원 지식 센터의 Application Load Balancer HTTP 502 오류 문제 해결 방법을 참조하십시오.

HTTP 503: 서비스 사용 불가

로드 밸런서의 대상 그룹에 등록된 대상이 없습니다.

HTTP 504: 게이트웨이 제한 시간

가능한 원인:

• 연결 제한 시간이 만료(10초)되기 전에 로드 밸런서가 대상에 대한 연결을 설정하지 못했습니다.

• 로드 밸런서가 대상에 대한 연결을 설정했지만, 유휴 제한 시간이 끝나기 전에 대상이 응답을 하지 않았습니다.

• 서브넷의 네트워크 ACL이 휘발성 포트(1024-65535)에서 대상에서 로드 밸런서 노드로의 트래픽을 허용하지 않았습니다.

• 대상이 개체 몸체보다 큰 콘텐츠 길이 헤더를 반환합니다. 로드 밸런서가 놓친 바이트를 기다리는 도중 시간이 초과되었습니다.

• 대상이 Lambda 함수이고 Lambda 서비스는 연결 제한 시간이 만료되기 전에 응답하지 않았습니다.

• 로드 밸런서가 대상에 연결할 때 SSL 핸드셰이크 제한 시간 초과 (10초) 가 발생했습니다.

HTTP 505: 버전이 지원되지 않습니다.

로드 밸런서가 예상치 못한 HTTP 버전 요청을 받았습니다. 예를 들어, 로드 밸런서가 HTTP/1 연결을 설정했지만 HTTP/2 요청을 받았습니다.

HTTP 507: 스토리지 부족

리디렉션 URL이 너무 깁니다.

HTTP 561: 권한 없음

사용자를 인증하도록 리스너 규칙을 구성했지만, 사용자를 인증할 때 IdP가 오류 코드를 반환했습니다. 액세스 로그에 관련 오류 원인 코드가 있는지 확인하십시오.

대상이 HTTP 오류 코드를 생성

로드 밸런서가 HTTP 오류를 포함하여 대상에서 클라이언트로 유효한 HTTP 응답을 전달합니다. 대상이 생성한 HTTP 오류 코드는 HTTPCode_Target_4XX_Count and HTTPCode_Target_5XX_Count 지표에 기록이 됩니다.

AWS Certificate Manager 인증서를 사용할 수 없습니다.

Application Load Balancer와 함께 HTTPS 리스너를 사용하기로 결정하는 경우 인증서를 AWS Certificate Manager 발급하기 전에 도메인 소유권을 검증해야 합니다. 설치 중에 이 단계를 빠뜨렸다면 인증서는 Pending Validation 상태로 유지되며 유효성이 확인될 때까지 사용할 수 없습니다.

• 이메일 검증을 사용하는 경우 AWS Certificate Manager 사용 설명서의 이메일 검증을 참조하세요.

• DNS 검증을 사용하는 경우AWS Certificate Manager 사용 설명서의 DNS 검증을 참조하십시오.

여러 줄의 헤더는 지원되지 않습니다.

Application Load Balancer는message/http 미디어 유형 헤더를 비롯한 여러 줄 헤더를 지원하지 않습니다. 여러 줄의 헤더가 제공되면 Application Load Balancer는 ":" 콜론 문자를 추가한 다음 대상에 전달합니다.