Network Load Balancer 문제 해결

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

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

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

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

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

인스턴스에 연결된 보안 그룹은 반드시 상태 확인 포트와 상태 확인 프로토콜을 사용하여 로드 밸런서에서의 트래픽을 허용해야 합니다. 자세한 내용은 대상 보안 그룹 단원을 참조하십시오.

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

인스턴스의 서브넷 및 로드 밸런서의 서브넷과 연결된 네트워크 ACL은 로드 밸런서의 트래픽 및 상태 확인을 허용해야 합니다. 자세한 내용은 네트워크 ACL 단원을 참조하십시오.

요청이 대상으로 라우팅되지 않음

다음 사항을 확인합니다.

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

인스턴스와 연결된 보안 그룹이 리스너 포트에서 클라이언트 IP 주소(대상이 인스턴스 ID로 지정된 경우) 또는 로드 밸런서 노드(대상이 IP 주소로 지정된 경우)로부터의 트래픽을 허용해야 합니다. 자세한 내용은 대상 보안 그룹 단원을 참조하십시오.

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

VPC의 서브넷과 연결된 네트워크 ACL이 로드 밸런서 및 대상이 리스너 포트에서 양방향으로 통신하도록 허용해야 합니다. 자세한 내용은 네트워크 ACL 단원을 참조하십시오.

대상이 활성화되지 않은 가용 영역에 있음

가용 영역에 대상을 등록하지만 가용 영역은 활성화하지 않는 경우 이러한 등록된 대상은 로드 밸런서로부터 트래픽을 수신하지 않습니다.

인스턴스가 피어링된 VPC에 속해 있음

로드 밸런서와 피어링된 VPC에 인스턴스가 있는 경우, 인스턴스를 인스턴스 ID가 아닌 IP 주소로 로드 밸런서에 등록해야 합니다.

대상이 예상보다 많은 상태 확인 요청을 수신함

Network Load Balancer에 대한 상태 확인이 배포되고 합의 메커니즘을 사용하여 대상 상태를 확인합니다. 그러므로 대상은 HealthCheckIntervalSeconds 설정을 통해 구성된 수보다 많은 상태 확인을 수신합니다.

대상이 예상보다 적은 상태 확인 요청을 수신함

net.ipv4.tcp_tw_recycle이 활성화되었는지 여부를 확인합니다. 이 설정은 로드 밸런서에 문제를 야기하는 것으로 알려져 있습니다. net.ipv4.tcp_tw_reuse 설정이 더 안전한 대안입니다.

비정상 대상이 로드 밸런서로부터 요청을 수신

이는 등록된 모든 대상이 비정상일 때 발생합니다. 정상 상태의 대상이 한 개 이상 등록되어 있으면 Network Load Balancer는 정상 상태의 등록 대상으로만 요청을 라우팅합니다.

비정상 상태의 대상만 등록되어 있으면 Network Load Balancer는 모든 등록 대상에 요청을 라우팅합니다(오류 시 열림 모드라고 함). 모든 대상이 비정상이고 각 가용 영역에 요청을 보낼 정상 대상이 없는 경우 Network Load Balancer는 DNS에서 모든 IP 주소를 제거하는 대신 이 작업을 수행합니다.

호스트 헤더 불일치로 인해 대상이 HTTP 또는 HTTPS 상태 확인에 실패

상태 확인 요청의 HTTP 호스트 헤더에는 대상의 IP 주소 및 상태 확인 포트 대신 로드 밸런서 노드의 IP 주소 및 리스너 포트가 포함됩니다. 호스트 헤더별로 수신 요청을 매핑하는 경우 상태 확인이 HTTP 호스트 헤더와 일치하는지 확인해야 합니다. 또 다른 옵션은 다른 포트에 별도의 HTTP 서비스를 추가하고 대상 그룹이 상태 확인에 해당 포트를 대신 사용하도록 구성하는 것입니다. 또는 TCP 상태 확인을 사용할 수도 있습니다.

보안 그룹을 로드 밸런서와 연결할 수 없음

Network Load Balancer가 보안 그룹 없이 생성된 경우 생성 후에는 보안 그룹을 지원할 수 없습니다. 보안 그룹은 생성 중 로드 밸런서에 연결하거나 원래 보안 그룹으로 생성된 기존 로드 밸런서에만 연결할 수 있습니다.

모든 보안 그룹을 제거할 수 없음

Network Load Balancer가 보안 그룹과 함께 생성된 경우 항상 하나 이상의 보안 그룹이 연결되어 있어야 합니다. 로드 밸런서에서 모든 보안 그룹을 동시에 제거할 수는 없습니다.

TCP_ELB_Reset_Count 지표 증가

클라이언트가 Network Load Balancer를 통해 보내는 각 TCP 요청에 대해 해당 연결의 상태가 추적됩니다. 유휴 제한 시간보다 오래 클라이언트 또는 대상에 의한 연결을 통해 데이터가 전송되지 않으면 연결이 닫힙니다. 유휴 제한 시간이 지난 후 클라이언트 또는 대상에서 데이터를 보내면 연결이 더 이상 유효하지 않음을 나타내는 TCP RST 패킷이 수신됩니다. 또한, 대상이 비정상 상태이면 비정상 대상이 로드 밸런서의 페일 오픈을 트리거하지 않는 한 로드 밸런서가 대상과 관련된 클라이언트 연결에서 수신된 패킷에 대해 TCP RST를 보냅니다.

UnhealthyHostCount 메트릭이 증가하기 직전에 또는 증가함과 동시에 TCP_ELB_Reset_Count 지표가 급증하는 것이 보이는 것은 대상이 실패하기 시작했지만 비정상으로 표시되지 않았기 때문에 TCP RST 패킷이 전송되는 것일 수 있습니다. 대상이 비정상적으로 표시되지 않았지만 TCP_ELB_Reset_Count에서 지속적인 증가가 보이는 경우, VPC 흐름 로그에서 만료된 흐름에 데이터를 전송하는 클라이언트가 있는지 확인할 수 있습니다.

대상에서 로드 밸런서로의 요청에서 연결 시간이 초과됨

대상 그룹에서 클라이언트 IP 보존이 활성화되어 있는지 확인합니다. 헤어피닝이라고도 하는 NAT 루프백은 클라이언트 IP 보존이 활성화된 경우 지원되지 않습니다. 인스턴스가 등록된 로드 밸런서의 클라이언트이고 클라이언트 IP 보존이 활성화된 경우 요청이 다른 인스턴스로 라우팅된 경우에만 연결이 성공합니다. 요청이 전송된 동일한 인스턴스로 라우팅되는 경우 소스 및 목적지 IP 주소가 동일하기 때문에 연결 시간이 초과됩니다.

인스턴스가 자신이 등록된 로드 밸런서로 요청을 전송해야 하는 경우 다음 중 하나를 수행합니다.

• 클라이언트 IP 보존을 사용하지 않도록 설정합니다.

• 통신해야 하는 컨테이너가 다른 컨테이너 인스턴스에 있는지 확인합니다.

대상을 Network Load Balancer로 이동할 때 성능이 저하됨

Classic Load Balancer와 Application Load Balancer는 모두 연결 멀티플렉싱을 사용하지만 Network Load Balancer는 그렇지 않습니다. 그러므로 대상이 Network Load Balancer를 기반으로 더 많은 TCP 연결을 수신할 수 있습니다. 대상이 수신할 수 있는 연결 요청 볼륨을 처리할 준비가 되었는지 확인하십시오.

연결 시 포트 할당 오류가 발생했습니다. AWS PrivateLink

Network Load Balancer가 VPC 엔드포인트 서비스에 연결된 경우 Network Load Balancer는 각각의 고유 대상(IP 주소 및 포트)에 대해 55,000건의 동시 연결 또는 분당 약 55,000건의 연결을 지원합니다. 연결 건수가 이보다 더 많을 경우, 포트 할당 오류가 발생할 가능성이 증가합니다. 포트 할당 오류는 PortAllocationErrorCount 지표를 사용하여 추적할 수 있습니다. 포트 할당 오류를 해결하려면 대상 그룹에 더 많은 대상을 추가하세요. 자세한 정보는 CloudWatch 네트워크 로드 밸런서의 지표을 참조하세요.

클라이언트 IP 보존 사용 시 간헐적인 연결 실패

클라이언트 IP 보존을 사용하도록 설정한 경우 대상에서 관찰된 소켓 재사용과 관련된 TCP/IP 연결 제한이 발생할 수 있습니다. 이러한 연결 제한은 여러 로드 밸런서 노드에 동시에 연결할 때 클라이언트 또는 클라이언트 앞에 있는 NAT 디바이스가 동일한 소스 IP 주소와 소스 포트를 사용하는 경우에 발생할 수 있습니다. 로드 밸런서가 이러한 연결을 동일한 대상으로 라우팅하는 경우 이 연결은 동일한 소스 소켓에서 온 것처럼 대상에 나타나므로 연결 오류가 발생합니다. 이러한 경우(연결이 실패하면) 클라이언트가 다시 시도하거나 (연결이 중단되면) 다시 연결할 수 있습니다. 소스 휘발성 포트 수를 늘리거나 로드 밸런서에 대한 대상 수를 늘려 이러한 유형의 연결 오류를 줄일 수 있습니다. 클라이언트 IP 보존 혹은 교차 영역 로드 밸런싱을 비활성화하여 이러한 유형의 연결 오류를 방지할 수 있습니다.

또한 클라이언트 IP 보존을 사용하도록 설정한 경우 Network Load Balancer에 연결하는 클라이언트가 로드 밸런서를 기반으로 대상에도 연결되어 있으면 연결이 실패할 수 있습니다. 이 문제를 해결하려면 영향을 받는 대상 그룹에서 클라이언트 IP 보존을 비활성화할 수 있습니다. 또는, 클라이언트가 Network Load Balancer에만 연결하거나 대상에만 연결하도록 하고 둘 다에는 연결하지 않도록 합니다.

TCP 연결 지연

교차 영역 로드 밸런싱과 클라이언트 IP 보존이 모두 활성화된 경우, 동일한 로드 밸런서의 다른 IP에 연결하는 클라이언트가 동일한 대상으로 라우팅될 수 있습니다. 클라이언트가 이러한 두 연결 모두에 대해 동일한 소스 포트를 사용하는 경우, 대상은 중복 연결인 것으로 보이는 데이터를 수신하여 새 연결을 설정할 때 연결 오류와 TCP 지연이 발생할 수 있습니다. 교차 영역 로드 밸런싱을 비활성화하면 이러한 유형의 연결 오류를 방지할 수 있습니다. 자세한 정보는 교차 영역 로드 밸런싱을 참조하세요.

로드 밸런서가 프로비저닝되고 있을 때 발생할 수 있는 오류

프로비저닝될 때 Network Load Balancer가 실패할 수 있는 이유 중 하나는 이미 할당되었거나 다른 곳에 할당된 IP 주소(예: EC2 인스턴스의 보조 IP 주소로 할당됨)를 사용하는 경우입니다. 이 IP 주소는 로드 밸런서가 설정되지 않도록 하며 상태는 failed입니다. 연결된 IP 주소의 할당을 해제하고 생성 프로세스를 다시 시도하면 이 문제를 해결할 수 있습니다.

DNS 이름 확인에 포함된 IP 주소가 활성화된 가용 영역보다 적음

가용 영역에 하나 이상의 정상 호스트가 있는 경우 Network Load Balancer가 활성화된 가용 영역당 하나의 IP 주소를 제공하는 것이 가장 좋습니다. 특정 가용 영역에 정상 호스트가 없고 영역 간 로드 밸런싱이 비활성화된 경우 해당 AZ와 관련된 Network Load Balancer IP 주소가 DNS에서 제거됩니다.

예를 들어 Network Load Balancer Balancer에 세 개의 가용 영역이 활성화되어 있고 모든 가용 영역에 하나 이상의 정상 등록된 대상 인스턴스가 있다고 가정해 보겠습니다.

• 가용 영역 A에 등록된 대상 인스턴스가 비정상 상태가 되면 Network Load Balancer 가용 영역 A의 해당 IP 주소가 DNS에서 제거됩니다.

• 활성화된 가용 영역 중 두 개 영역에 정상 등록된 대상 인스턴스가 없는 경우 Network Load Balancer 밸런서의 해당 두 IP 주소가 DNS에서 제거됩니다.

• 활성화된 모든 가용 영역에 정상 등록된 대상 인스턴스가 없는 경우 오류 시 열림 모드가 활성화되고 DNS는 세 개의 활성화된 AZ의 모든 IP 주소를 결과에 제공합니다.

리소스 맵을 사용하여 비정상 대상 문제 해결

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

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

참고

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

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

Targets 열에는 TargetId와 각 대상의 현재 상태 점검 상태가 표시됩니다. 대상이 비정상인 경우 상태 점검 실패 사유 코드가 표시됩니다. 단일 대상이 상태 점검에 실패하는 경우 대상에 충분한 리소스가 있는지 확인하십시오. 대상의 ID를 선택하여 새 탭에서 해당 세부 정보 페이지를 엽니다.

내보내기를 선택하면 네트워크 로드 밸런서 리소스 맵의 현재 보기를 PDF로 내보낼 수 있습니다.

인스턴스의 상태 확인이 실패했는지 확인한 다음 실패 이유 코드를 기반으로 다음 문제를 확인하십시오.

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

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

  • 대상에 Network Load Balancer의 연결을 수락할 수 있는 충분한 용량이 있는지 확인합니다.

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

• 비정상: FailedHealthChecks

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

    TLS 리스너를 사용하는 경우

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

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

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

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

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

  • 대상이 하나 이상의 일치하는 암호와 TLS 핸드셰이크를 설정하기 위해 Network Load Balancer에서 제공하는 프로토콜을 지원하는지 확인합니다.