기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Network Load Balancer 문제 해결
다음 정보는 Network Load Balancer와 관련된 문제를 해결하는 데 도움이 될 수 있습니다.
등록된 대상은 서비스되지 않고 있습니다.
대상이 InService
상태로 들어가는 데 예상보다 시간이 오래 걸릴 경우 상태 확인에 실패할 수 있습니다. 한번이라도 상태 확인을 통과할 때까지 대상이 서비스되지 않습니다. 자세한 내용은 Network Load Balancers 대상 그룹의 상태 확인 단원을 참조하십시오.
인스턴스가 상태 확인에 실패하고 있는지 확인한 다음, 다음을 점검합니다.
요청이 대상으로 라우팅되지 않음
다음 사항을 확인합니다.
- 보안 그룹이 트래픽을 허용하지 않음
-
인스턴스와 연결된 보안 그룹이 리스너 포트에서 클라이언트 IP 주소(대상이 인스턴스 ID로 지정된 경우) 또는 로드 밸런서 노드(대상이 IP 주소로 지정된 경우)로부터의 트래픽을 허용해야 합니다. 자세한 내용은 대상 보안 그룹 단원을 참조하십시오.
- 네트워크 액세스 제어 목록(ACL)은 트래픽을 허용하지 않습니다.
-
의 서브넷과 ACLs 연결된 네트워크는 로드 밸런서와 대상이 리스너 포트에서 양방향으로 통신할 수 있도록 허용VPC해야 합니다. 자세한 내용은 네트워크 ACL 단원을 참조하십시오.
- 대상이 활성화되지 않은 가용 영역에 있음
-
가용 영역에 대상을 등록하지만 가용 영역은 활성화하지 않는 경우 이러한 등록된 대상은 로드 밸런서로부터 트래픽을 수신하지 않습니다.
- 인스턴스가 피어링된 VPC
-
에 로드 밸런서와 피어링된 인스턴스가 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 대해를 전송합니다.
TCP_ELB_Reset_Count
지표가 증가하기 직전 또는 증가하면서 UnhealthyHostCount
지표가 급증하는 경우 대상이 실패하기 시작했지만 비정상으로 표시되지 않았기 때문에 TCP RST 패킷이 전송되었을 가능성이 높습니다. 대상이 비정상으로 표시되지 TCP_ELB_Reset_Count
않고가 지속적으로 증가하는 경우 만료된 VPC 흐름에 대한 데이터를 보내는 클라이언트의 흐름 로그를 확인할 수 있습니다.
대상에서 로드 밸런서로의 요청에서 연결 시간이 초과됨
대상 그룹에서 클라이언트 IP 보존이 활성화되어 있는지 확인합니다. 클라이언트 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 엔드포인트 서비스와 연결된 경우 각 고유한 대상(IP 주소 및 포트)에 대해 분당 55,000개의 동시 연결 또는 약 55,000개의 연결을 지원합니다. 연결 건수가 이보다 더 많을 경우, 포트 할당 오류가 발생할 가능성이 증가합니다. 포트 할당 오류는 PortAllocationErrorCount
지표를 사용하여 추적할 수 있습니다. 포트 할당 오류를 해결하려면 대상 그룹에 더 많은 대상을 추가하세요. 자세한 내용은 Network Load Balancer의 CloudWatch 지표 단원을 참조하십시오.
간헐적 TCP 연결 설정 실패 또는 TCP 연결 설정 지연
클라이언트 IP 주소 보존이 활성화된 경우 클라이언트는 동일한 소스 임시 포트를 사용하여 다른 대상 IP 주소에 연결할 수 있습니다. 이러한 대상 IP 주소는 교차 영역 로드 밸런싱이 활성화된 경우 동일한 로드 밸런서(다른 가용 영역에 있음) 또는 등록된 동일한 대상 IP 주소 및 포트를 사용하는 다른 Network Load Balancer에서 가져올 수 있습니다. 이 경우 이러한 연결이 동일한 대상 IP 주소 및 포트로 라우팅되면 동일한 클라이언트 IP 주소 및 포트에서 오기 때문에 대상에 중복된 연결이 표시됩니다. 이로 인해 이러한 연결 중 하나를 설정할 때 연결 오류와 지연이 발생합니다. 이는 클라이언트 앞에 있는 NAT 디바이스와 여러 Network Load Balancer IP 주소에 동시에 연결할 때 동일한 소스 IP 주소 및 소스 포트가 할당될 때 자주 발생합니다.
클라이언트 또는 NAT 디바이스에서 할당한 소스 임시 포트 수를 늘리거나 로드 밸런서의 대상 수를 늘려 이러한 유형의 연결 오류를 줄일 수 있습니다. 클라이언트는 이러한 연결 실패 후 다시 연결할 때 사용되는 소스 포트를 변경하는 것이 좋습니다. 이러한 유형의 연결 오류를 방지하기 위해 단일 Network Load Balancer를 사용하는 경우 교차 영역 로드 밸런싱 비활성화를 고려하거나 여러 Network Load Balancer를 사용하는 경우 여러 대상 그룹에 등록된 동일한 대상 IP 주소 및 포트를 사용하지 않는 것을 고려할 수 있습니다. 또는 클라이언트 IP 보존 비활성화를 고려할 수 있습니다. 클라이언트 IP가 필요한 경우 프록시 프로토콜 v2를 사용하여 해당 IP를 검색할 수 있습니다. 프록시 프로토콜 v2에 대한 자세한 내용은 섹션을 참조하세요프록시 프로토콜.
로드 밸런서가 프로비저닝되고 있을 때 발생할 수 있는 오류
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되고 AZs 결과에 활성화된 세 개의 모든 IP 주소를 제공합니다.
리소스 맵을 사용하여 비정상 대상 문제 해결
Network Load Balancer 대상이 상태 확인에 실패하는 경우 리소스 맵을 사용하여 비정상 대상을 찾고 실패 원인 코드에 따라 조치를 취할 수 있습니다. 자세한 내용은 Network Load Balancer 리소스 맵 보기 단원을 참조하십시오.
리소스 맵은 개요 및 비정상 대상 맵의 두 가지 보기를 제공합니다. 개요는 기본적으로 선택되며 로드 밸런서의 모든 리소스를 표시합니다. 비정상 대상 맵 보기를 선택하면 Network Load Balancer와 연결된 각 대상 그룹의 비정상 대상만 표시됩니다.
참고
리소스 맵 내의 모든 해당 리소스에 대한 상태 확인 요약 및 오류 메시지를 보려면 리소스 세부 정보 표시를 활성화해야 합니다. 활성화되지 않은 경우 각 리소스를 선택하여 세부 정보를 확인해야 합니다.
대상 그룹 열에는 각 대상 그룹의 정상 및 비정상 대상에 대한 요약이 표시됩니다. 이 정보는 모든 대상이 상태 확인에 실패하는지 아니면 특정 대상만 실패하는지를 확인하는 데 도움이 될 수 있습니다. 대상 그룹의 모든 대상이 상태 확인에 실패하는 경우 대상 그룹의 상태 확인 설정을 확인합니다. 대상 그룹의 이름을 선택하여 새 탭에서 세부 정보 페이지를 엽니다.
대상 열에는 TargetID와 각 대상의 현재 상태 확인 상태가 표시됩니다. 대상이 비정상 상태인 경우 상태 확인 실패 사유 코드가 표시됩니다. 단일 대상이 상태 검사에 실패하면 대상에 충분한 리소스가 있는지 확인합니다. 대상의 ID를 선택하여 새 탭에서 세부 정보 페이지를 엽니다.
내보내기를 선택하면 Network Load Balancer 리소스 맵의 현재 보기를 로 내보낼 수 있는 옵션이 제공됩니다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에서 제공하는 프로토콜을 지원하는지 확인합니다.
-