기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Network Load Balancer 문제 해결

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

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

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

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

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

다음 사항을 확인합니다.

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

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 주소가 동일하기 때문에 연결 시간이 초과됩니다.

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

대상을 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 지표를 사용하여 추적할 수 있습니다. 포트 할당 오류를 해결하려면 대상 그룹에 더 많은 대상을 추가하세요. 자세한 내용은 Network Load Balancer에 대한 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에 세 개의 가용 영역이 활성화되어 있고 모든 가용 영역에 하나 이상의 정상 등록된 대상 인스턴스가 있다고 가정해 보겠습니다.

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

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

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

대상 그룹 열에는 각 대상 그룹의 정상 및 비정상 대상에 대한 요약 정보가 표시됩니다. 이 정보는 모든 대상이 상태 확인에 실패하는지 아니면 특정 대상만 실패하는지를 확인하는 데 도움이 될 수 있습니다. 대상 그룹의 모든 대상이 상태 확인에 실패하는 경우 대상 그룹의 상태 확인 설정을 확인합니다. 대상 그룹의 이름을 선택하여 새 탭에서 세부 정보 페이지를 엽니다.

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

내보내기를 선택하면 Network Load Balancer 리소스 맵의 현재 보기를 PDF로 내보낼 수 있는 옵션이 제공됩니다.

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