내부 패스 스루 네트워크 부하 분산기 문제 해결

이 가이드에서는 Google Cloud 내부 패스 스루 네트워크 부하 분산기의 구성 문제를 해결하는 방법을 설명합니다. 문제를 조사하기 전에 다음 페이지를 숙지하시기 바랍니다.

네트워크 분석기의 일반적인 문제 해결

네트워크 분석기는 VPC 네트워크 구성을 자동으로 모니터링하고 최적화되지 않은 구성과 잘못된 구성을 모두 감지합니다. 네트워크 장애를 식별하고 근본 원인 정보를 제공하며 가능한 해결 방법을 제안합니다. 네트워크 분석기에서 자동으로 감지되는 여러 가지 잘못된 구성 시나리오에 대해 알아보려면 네트워크 분석기 문서의 부하 분산기 통계를 참조하세요.

네트워크 분석기는 Network Intelligence Center의 일부로 Google Cloud 콘솔에서 사용할 수 있습니다.

네트워크 분석기로 이동

백엔드에 호환되지 않는 분산 모드가 있음

부하 분산기를 만들 때 다음 오류가 표시될 수 있습니다.

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

이는 서로 다른 두 부하 분산기에서 동일한 백엔드를 사용하려고 하는데 백엔드에 호환 가능한 분산 모드가 없는 경우에 발생합니다.

자세한 내용은 다음을 참조하세요.

일반적인 연결 문제 해결

내부 패스 스루 네트워크 부하 분산기에 연결할 수 없는 경우 다음과 같은 일반적인 문제를 확인합니다.

방화벽 규칙 확인

백엔드 VM에 대한 상태 확인을 허용하도록 인그레스 허용 방화벽 규칙이 정의되어 있는지 확인합니다.
인그레스 허용 방화벽 규칙이 클라이언트에서 백엔드 VM으로 들어오는 트래픽을 허용하는지 확인합니다.
트래픽이 부하 분산기에서 사용 중인 포트의 백엔드 VM에 도달할 수 있도록 관련 방화벽 규칙이 있는지 확인합니다.
방화벽 규칙의 대상 태그를 사용하는 경우 부하 분산기의 백엔드 VM에 올바르게 태그가 지정되어 있는지 확인합니다.

내부 패스 스루 네트워크 부하 분산기에 필요한 방화벽 규칙을 구성하는 방법을 알아보려면 방화벽 규칙 구성을 참조하세요.

게스트 환경이 백엔드 VM에서 실행 중인지 확인

정상 백엔드 VM에 연결할 수 있지만 부하 분산기에는 연결할 수 없는 경우 VM의 게스트 환경(이전의 Windows 게스트 환경 또는 Linux 게스트 환경)이 실행되고 있지 않거나 메타데이터 서버(metadata.google.internal, 169.254.169.254)와 통신할 수 없는 것일 수 있습니다.

다음 사항을 확인하세요.

게스트 환경이 백엔드 VM에 설치되어 있고 실행 중인지 확인합니다.
백엔드 VM의 게스트 운영체제 내 방화벽 규칙(iptables 또는 Windows 방화벽)이 메타데이터 서버에 대한 액세스를 차단하지 않는지 확인합니다.

백엔드 VM이 부하 분산기로 전송된 패킷을 허용하는지 확인

각 백엔드 VM은 부하 분산기로 전송된 패킷을 허용하도록 구성되어야 합니다. 즉, 백엔드 VM에 전달되는 패킷의 대상 위치는 부하 분산기의 IP 주소입니다. 대부분의 경우 이 경로는 로컬 경로로 수행됩니다.

Google Cloud 이미지에서 생성된 VM의 경우 게스트 에이전트는 부하 분산기의 IP 주소에 대한 로컬 경로를 설치합니다. Container-Optimized OS를 기반으로 하는 Google Kubernetes Engine 인스턴스는 대신 iptables를 사용하여 이를 구현합니다.

Linux 백엔드 VM에서는 다음 명령어를 실행하여 로컬 경로가 있는지 확인할 수 있습니다. LOAD_BALANCER_IP를 부하 분산기의 IP 주소로 바꿉니다.

sudo ip route list table local | grep LOAD_BALANCER_IP

백엔드 VM에서 서비스 IP 주소 및 포트 바인딩을 확인

내부 패스 스루 네트워크 부하 분산기로 전송된 패킷은 부하 분산기 자체의 대상 IP 주소와 함께 백엔드 VM에 도착합니다. 이 유형의 부하 분산기는 프록시가 아니며 예상되는 동작입니다.

백엔드 VM에서 실행되는 소프트웨어는 다음 작업을 수행해야 합니다.

부하 분산기의 IP 주소 또는 모든 IP 주소(0.0.0.0 또는 ::)에서 리슨(바인딩)
부하 분산기의 전달 규칙에 포함된 포트에서 리슨(바인딩)

이를 테스트하려면 SSH 또는 RDP를 사용하여 백엔드 VM에 연결합니다. 그런 다음 curl, telnet 또는 비슷한 도구를 사용하여 다음 테스트를 수행합니다.

백엔드 VM 자체의 내부 IP 주소(127.0.0.1 또는 localhost)를 사용하여 서비스에 연결을 시도합니다.
부하 분산기 전달 규칙의 IP 주소를 사용하여 서비스에 연결을 시도합니다.

클라이언트 VM이 부하 분산기와 동일한 리전에 있는지 확인

부하 분산기에 연결하는 클라이언트가 다른 리전에 있으면 전역 액세스가 사용 설정되어 있는지 확인합니다.

상태 확인 트래픽이 백엔드 VM에 도달할 수 있는지 확인

상태 확인 트래픽이 백엔드 VM에 도달하는지 확인하려면 상태 확인 로깅을 사용 설정하고 성공적인 로그 항목을 검색합니다.

백엔드의 '정상' 상태를 확인하여 부하 분산기 기능이 정상인지 확인할 수도 있습니다.

백엔드에 정상 인스턴스가 없으면 적절한 상태 확인이 구성되었고 백엔드의 각 VM이 구성된 상태 확인 포트에서 리슨하는지 확인하세요.

동일한 VPC 네트워크의 클라이언트에서 다음 명령어를 실행하여 백엔드 VM이 특정 TCP 포트에서 리슨하는지 확인합니다.

telnet SERVER_IP_ADDRESS PORT

다음을 바꿉니다.

SERVER_IP_ADDRESS: 백엔드 VM의 IP 주소
PORT: 상태 확인을 위해 구성한 포트. 기본적으로 상태 확인 포트는 80입니다.

또는 SSH를 사용하여 백엔드 VM을 연결하고 다음 명령어를 실행할 수 있습니다.

curl localhost:PORT

다시 PORT를 상태 확인을 위해 구성한 포트로 바꿉니다.

이 테스트를 수행하는 또 다른 방법은 다음 명령어를 실행하는 것입니다.

netstat -npal | grep LISTEN

출력에서 다음을 확인하세요.

<var>LB_IP_ADDRESS</var>:<var>PORT</var>
0.0.0.0:<var>PORT</var>
:::<var>PORT</var>

부하 분산기의 IP 주소에 응답하도록 라우팅이 올바르게 설정되었는지 여부는 확인하지 않습니다. 이는 비슷한 증상을 가진 별개의 문제입니다. 라우팅의 경우 백엔드 VM이 부하 분산기로 전송된 패킷을 허용하는지 확인에 설명된 대로 ip route list table local 명령어를 실행하고 부하 분산기의 IP 주소가 나열되는지 확인합니다.

성능 문제 해결

성능 문제가 발생하고 지연 시간이 증가한 경우 다음과 같은 일반적인 문제를 확인하세요.

서버 기능 확인

모든 백엔드 서버가 상태 확인에 응답하는 경우 서버에서 직접 발급할 때 클라이언트의 요청이 올바르게 작동하는지 확인합니다. 예를 들어 클라이언트가 부하 분산기를 통해 서버에 HTTP 요청을 보내고 응답이 없거나 응답이 정상보다 훨씬 느린 경우 동일한 HTTP 요청을 각 백엔드 서버에서 실행하고 동작을 관찰합니다.

서버 자체에서 요청이 전송될 때 개별 백엔드 서버가 올바르게 동작하지 않는 경우 서버 애플리케이션 스택이 제대로 작동하지 않는다고 결론을 내릴 수 있습니다. 애플리케이션 자체에 대한 추가 문제 해결에 집중할 수 있습니다. 모든 서버가 올바르게 동작하는 경우 다음 단계는 클라이언트 측과 네트워크를 살펴보는 것입니다.

네트워크 연결 및 지연 시간 확인

모든 백엔드 서버가 요청에 올바르게 응답하는 경우 네트워크 지연 시간을 확인합니다. 클라이언트 VM에서 다음과 같이 각 서버에 일정한 핑 명령어를 실행합니다.

ping SERVER_IP_ADDRESS

이 테스트는 기본 제공되는 네트워크 지연 시간과 네트워크의 패킷 삭제 여부를 보여줍니다. 경우에 따라 방화벽 규칙이 ICMP 트래픽을 차단할 수도 있습니다. 이 경우 이 테스트는 결과를 생성하지 못합니다. 방화벽 규칙 관리자에게 이 경우에 해당하는지 여부를 확인하세요.

ping 명령어로 지연 시간이 정상보다 상당히 긴 것으로 표시되거나 패킷 손실이 심한 것으로 표시되는 경우 Google Cloud 지원 케이스를 열어 자세히 조사합니다.

문제가 있는 클라이언트-서버 조합 식별

네트워크 ping 테스트에서 지연 시간이 짧고 패킷 손실이 없는 것으로 나타나는 경우 다음 단계는 문제가 있는 결과를 생성하는 특정 클라이언트-서버 조합(있는 경우)을 식별하는 것입니다. 이렇게 하려면 문제가 있는 동작(예: 긴 지연 시간 또는 응답 없음)을 재현하는 동시에 서버 수가 1에 도달할 때까지 백엔드 서버 수를 절반으로 줄이면 됩니다.

문제가 있는 클라이언트-서버 조합을 하나 이상 식별하는 경우 트래픽 캡처 및 분석을 수행하세요.

문제가 있는 클라이언트-서버 조합이 식별되지 않으면 성능 테스트로 건너뜁니다.

트래픽 캡처 및 분석 수행

문제가 있는 특정 클라이언트-서버 조합을 식별하는 경우 패킷 캡처를 사용하여 통신에서 지연 또는 중단을 야기하는 부분을 정확히 찾아낼 수 있습니다. 다음과 같이 tcpdump를 사용하여 패킷 캡처를 수행할 수 있습니다.

서버에 tcpdump를 설치합니다.
서버에서 tcpdump 캡처를 시작합니다.
클라이언트에서 다음과 같은 샘플 요청을 실행합니다.
```
curl URL
```
tcpdump 출력을 분석하여 문제를 식별합니다.

성능 테스트 수행

문제가 있는 클라이언트-서버 조합을 식별하지 않고 모든 클라이언트와 서버의 집계 성능이 예상보다 낮은 경우 다음 테스트를 고려합니다.

부하 분산이 없는 클라이언트 및 서버 한 개
부하 분산이 있는 클라이언트 및 서버 한 개

결과: 테스트 [1] 과 [2]의 결과 조합은 부하 분산기가 문제의 원인인지 여부를 식별합니다.
부하 분산이 있는 하나의 클라이언트 및 여러 서버

결과: 한 서버의 성능 한도를 식별합니다.
부하 분산이 있는 여러 클라이언트 및 서버 한 개

결과: 한 서버의 성능 한도를 식별합니다.
부하 분산이 없는 여러 클라이언트 및 여러 서버

결과: 네트워크의 성능 한도를 식별합니다.

여러 클라이언트 및 서버로 부하 테스트를 실행하면 클라이언트 또는 서버 리소스(CPU, 메모리, I/O)에 병목 현상이 발생하고 집계 결과가 줄어들 수 있습니다. 각 클라이언트와 서버가 올바르게 동작하더라도 집계 결과가 저하될 수 있습니다.

공유 VPC 문제 해결

공유 VPC를 사용 중이며 특정 서브넷에 새 내부 패스 스루 네트워크 부하 분산기를 만들 수 없는 경우 조직 정책이 원인일 수 있습니다. 조직 정책에서 허용되는 서브넷 목록에 서브넷을 추가하거나 조직 관리자에게 문의하세요. 자세한 내용은 constraints/compute.restrictSharedVpcSubnetworks 제약조건을 참조하세요.

장애 조치 문제 해결

내부 패스 스루 네트워크 부하 분산기의 장애 조치를 구성한 경우 발생할 수 있는 문제는 다음 섹션에서 설명합니다.

연결

하나 이상의 장애 조치 백엔드를 지정했는지 확인합니다.
장애 조치 정책 설정을 확인합니다.
- 장애 조치율
- 모든 백엔드 VM이 비정상적인 경우 트래픽 차단
- 장애 조치 시 연결 드레이닝 사용 중지

관리형 인스턴스 그룹 및 장애 조치 관련 문제

증상: 활성 풀이 기본 백엔드와 장애 복구 백엔드를 오락가락하며 바꿉니다.
가능한 이유: 관리형 인스턴스 그룹을 자동 확장 및 장애 조치와 함께 사용하면 활성 풀이 기본 백엔드와 장애 조치 백엔드 간에 장애 조치 및 장애 복구를 반복할 수 있습니다. 이 설정이 도움이 되는 배포도 있으므로 Google Cloud는 관리형 인스턴스 그룹에 장애 조치를 구성하지 못하게 하지 않습니다.

장애 조치 그룹의 연결 드레이닝 제한 사용 중지

백엔드 서비스가 프로토콜 TCP로 설정된 경우에만 연결 드레이닝을 사용 중지합니다.

연결 드레이닝이 사용 중지된 상태에서 UDP를 사용하여 백엔드 서비스를 만드는 경우 다음 오류 메시지가 표시됩니다.

gcloud compute backend-services create my-failover-bs \
    --global-health-checks \
    --load-balancing-scheme=internal \
    --health-checks=my-tcp-health-check \
    --region=us-central1 \
    --no-connection-drain-on-failover \
    --drop-traffic-if-unhealthy \
    --failover-ratio=0.5 \
    --protocol=UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

트래픽이 예기치 않은 백엔드 VM으로 전송됨

클라이언트 VM이 부하 분산기의 백엔드 VM을 겸하는 경우 부하 분산기 전달 규칙의 IP 주소로 전송된 연결에 항상 백엔드 VM 자체에서 응답하는 것이 정상적인 동작입니다. 자세한 내용은 단일 클라이언트에서 연결 테스트 및 부하 분산된 VM에서 요청 전송을 참조하세요.

클라이언트 VM이 부하 분산기의 백엔드 VM이 아닌 경우:

단일 클라이언트 요청의 경우 단일 클라이언트에서 연결 테스트를 참조하여 이 방법의 제한사항을 이해합니다.
인그레스가 방화벽 규칙이 상태 확인을 허용하도록 구성했는지 확인합니다.
장애 조치 구성의 경우 활성 풀의 구성원이 작동하는 방식과 Google Cloud가 장애 조치 및 장애 복구를 수행하는 시기를 이해해야 합니다. 부하 분산기의 구성을 검사하세요.
- Google Cloud 콘솔을 사용하여 각 백엔드 인스턴스 그룹에서 정상 백엔드 VM 수를 확인합니다. Google Cloud 콘솔에는 활성 풀에 있는 VM도 표시됩니다.
- 부하 분산기의 장애 조치율이 적절하게 설정되어 있는지 확인합니다. 예를 들어 기본 VM이 10개이고 장애 조치율이 0.2로 설정되어 있으면 정상 상태인 기본 VM이 2개 미만(10 × 0.2 = 2)일 때 Google Cloud가 장애 조치를 수행한다는 의미입니다. 장애 조치율 0.0은 특별한 의미가 있습니다. Google Cloud는 정상 상태인 기본 VM이 없을 때 장애 조치를 수행합니다.

기존 연결이 장애 조치 또는 장애 복구 중에 종료됨

백엔드 서비스의 장애 조치 정책을 수정합니다. 장애 조치 시 연결 드레이닝이 사용 설정되었는지 확인합니다.

다음 홉으로 부하 분산기 사용 문제 해결

커스텀 정적 경로의 다음 홉으로 내부 패스 스루 네트워크 부하 분산기를 설정하면 다음과 같은 문제가 발생할 수 있습니다.

연결 문제

다음 홉이 내부 패스 스루 네트워크 부하 분산기에 대한 전달 규칙인 경로의 대상 범위에서 IP 주소를 핑할 수 없으면 경로가 생성된 시간에 따라 이 유형의 다음 홉을 사용하는 경로가 ICMP 트래픽을 처리할 수 없는지 확인합니다. 경로가 2021년 5월 15일 이전에 생성된 경우 2021년 8월 16일까지만 TCP 및 UDP 트래픽을 처리합니다. 2021년 8월 16일부터는 모든 경로가 경로 생성 시간에 관계없이 모든 프로토콜 트래픽(TCP, UDP, ICMP)을 자동으로 전달합니다. 그때까지 기다리지 않으려면 새 경로를 만들고 기존 경로를 삭제하여 핑 기능을 지금 사용 설정할 수 있습니다.
내부 패스 스루 네트워크 부하 분산기를 커스텀 정적 경로의 다음 홉으로 사용하는 경우 부하 분산기의 내부 백엔드 서비스에 구성된 프로토콜이나 부하 분산기의 내부 전달 규칙에 구성된 포트에 관계없이 모든 트래픽은 부하 분산기의 정상적인 백엔드 VM으로 전달됩니다.
커스텀 정적 경로의 다음 홉을 통해 백엔드 VM에 전달되어야 하는 트래픽 소스를 올바르게 식별하는 인그레스 허용 방화벽 규칙을 만들었는지 확인합니다. 백엔드 VM에 도달하는 패킷은 커스텀 정적 경로를 통해 전달되는 경우에도 소스 IP 주소를 보존합니다.

목적지 범위 값이 잘못됨

커스텀 정적 경로의 목적지 범위는 VPC 네트워크의 어느 서브넷 경로보다도 구체적일 수 없습니다. 커스텀 정적 경로를 만들 때 다음 오류 메시지가 표시되는 경우:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

서브넷 경로와 정확히 일치하거나 더 구체적인(마스크가 더 긴) 목적지를 사용하여 커스텀 정적 경로를 만들 수 없습니다. 자세한 내용은 적용 여부 및 순서를 참조하세요.
패킷이 예상치 못한 목적지로 이동하는 경우 VPC 네트워크에서 목적지가 더 구체적인 다른 경로를 삭제합니다. Google Cloud 경로 선택을 이해하려면 라우팅 순서를 검토하세요.

로깅 문제 해결

내부 패스 스루 네트워크 부하 분산기의 로깅을 구성하면 다음 문제가 발생할 수 있습니다.

샘플링된 패킷이 RTT를 캡처하는 데 부족하면 바이트 값과 같은 RTT 측정이 일부 로그에서 누락될 수 있습니다. 소량 연결에서 발생할 가능성이 높습니다.
RTT 값은 TCP 흐름에서만 사용할 수 있습니다.
필부 패킷은 페이로드 없이 전송됩니다. 헤더 전용 패킷이 샘플링되면 바이트 값은 0입니다.

다음 단계

내부 패스 스루 네트워크 부하 분산기의 Logging 및 Monitoring 구성에 대한 자세한 내용은 내부 패스 스루 네트워크 부하 분산기의 Logging 및 Monitoring을 참조하세요.
VPC 네트워크에 연결된 피어 네트워크에서 내부 패스 스루 네트워크 부하 분산기에 액세스하는 방법은 내부 패스 스루 네트워크 부하 분산기 및 연결된 네트워크를 참조하세요.