내부 애플리케이션 부하 분산기 관련 문제 해결

이 가이드에서는 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.

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

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

• 인스턴스 그룹에 대한 제한 및 지침
• 부하 분산기의 분산 모드 변경

부하 분산된 트래픽에 원래 클라이언트의 소스 주소가 없음

이는 정상적인 동작입니다. 내부 애플리케이션 부하 분산기는 HTTP(S) 리버스 프록시(게이트웨이)로 작동합니다. 클라이언트 프로그램이 INTERNAL_MANAGED 전달 규칙의 IP 주소에 대한 연결을 열면 프록시에서 연결이 종료됩니다. 프록시는 해당 연결을 통해 도달하는 요청을 처리합니다. 프록시는 각 요청에서 URL 맵 및 기타 요인에 따라 요청을 수신할 백엔드를 선택합니다. 그런 다음 선택된 백엔드로 요청을 보냅니다. 결과적으로 백엔드 관점에서 볼 때 수신 패킷의 소스는 해당 리전의 프록시 전용 서브넷의 IP 주소입니다.

부하 분산기에서 요청을 거부함

프록시는 각 요청에서 부하 분산기 URL 맵의 경로 일치자에 따라 요청을 수신할 백엔드를 선택합니다. URL 맵에 요청에 대해 정의된 경로 일치자가 없으면 백엔드 서비스를 선택할 수 없으므로 HTTP 404(찾을 수 없음) 응답 코드를 반환합니다.

부하 분산기가 백엔드에 연결하지 않음

백엔드 서버를 보호하는 방화벽은 내부 HTTP(S) 부하 분산기 리전에 할당된 프록시 전용 서브넷 범위의 프록시에서 들어오는 인그레스 트래픽을 허용하도록 구성되어야 합니다.

프록시는 백엔드 서비스의 구성에 지정된 연결 설정을 사용하여 백엔드에 연결합니다. 이러한 값이 백엔드에서 실행되는 서버의 구성과 일치하지 않으면 프록시는 요청을 백엔드로 전달할 수 없습니다.

상태 점검 프로브가 백엔드에 도달할 수 없음

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

클라이언트가 부하 분산기에 연결할 수 없음

프록시는 전달 규칙에 구성된 부하 분산기의 IP 주소 및 포트(예: 10.1.2.3:80)로 들어오는 연결과 전달 규칙에 지정된 프로토콜(HTTP 또는 HTTPS)과 관련된 연결을 리슨합니다. 클라이언트가 연결할 수 없는 경우 올바른 주소, 포트, 프로토콜을 사용하고 있는지 확인하세요.

방화벽이 클라이언트 인스턴스와 부하 분산 IP 주소 사이의 트래픽을 차단하지 않는지 확인합니다.

클라이언트가 부하 분산기와 동일한 리전에 있는지 확인합니다. 내부 HTTP(S) 부하 분산은 리전 제품이므로 모든 클라이언트와 백엔드가 부하 분산기 리소스와 동일한 리전에 있어야 합니다.

공유 VPC에 대한 조직 정책 제한사항

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

부하 분산기가 영역에 트래픽을 균등하게 분산하지 않음

영역 간 내부 애플리케이션 부하 분산기 트래픽의 불균형을 확인할 수 있습니다. 이 문제는 특히 백엔드 용량의 사용률이 낮을 경우(10% 미만) 발생할 수 있습니다.

이러한 동작은 트래픽이 한 영역의 일부 서버로만 전달되기 때문에 전체 지연 시간에 영향을 줄 수 있습니다.

여러 영역의 트래픽 분산을 균등화하기 위해 다음과 같이 구성을 변경할 수 있습니다.

• max-rate-per-instance 대상 용량이 낮은 RATE 분산 모드를 사용합니다.
• 부하 분산 알고리즘이 LEAST_REQUEST인 LocalityLbPolicy 백엔드 트래픽 정책을 사용합니다.

설명할 수 없는 5xx 오류

부하 분산기 프록시와 백엔드 간의 통신 문제로 인해 발생한 오류 조건의 경우 부하 분산기는 HTTP 상태 코드(5xx)를 생성하고 클라이언트에 해당 상태 코드를 반환합니다. 부하 분산기가 모든 HTTP 5xx 오류를 생성하지는 않습니다. 예를 들어 백엔드가 HTTP 5xx 응답을 부하 분산기로 전송하면 부하 분산기에서 해당 응답을 클라이언트에 릴레이합니다. HTTP 5xx 응답이 백엔드에서 릴레이되었는지 또는 부하 분산기 프록시에서 생성되었는지 확인하려면 부하 분산기 로그의 proxyStatus 필드를 참조하세요.

백엔드 서비스 추가 또는 삭제와 같은 내부 애플리케이션 부하 분산기의 구성이 변경되면 사용자에게 HTTP 상태 코드 503이 잠시 표시될 수 있습니다. 이러한 구성 변경사항은 전역으로 Envoy에 전파되지만 proxyStatus 필드가 connection_refused 로그 문자열과 일치하는 로그 항목이 표시됩니다.

부하 분산기 구성을 완료한 후 HTTP 5xx 상태 코드가 몇 분 이상 지속되면 다음 단계를 수행하여 HTTP 5xx 응답 문제를 해결합니다.

1. 상태 점검을 허용하도록 구성된 방화벽 규칙이 있는지 확인합니다. 방화벽 규칙이 없으면 부하 분산기 로그에는 일반적으로 destination_unavailable과 일치하는 proxyStatus가 있습니다. 이는 부하 분산기가 백엔드를 사용할 수 없다고 간주함을 나타냅니다.

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

   새 부하 분산기의 경우 성공 상태 점검 로그 항목 누락이 상태 점검 트래픽이 백엔드에 도달하지 않는다는 의미는 아닙니다. 즉, 백엔드의 초기 상태가 아직 UNHEALTHY에서 다른 상태로 변경되지 않았을 수 있습니다. 상태 점검 프로버가 백엔드에서 HTTP 200 OK 응답을 수신한 후에만 성공 상태 점검 로그 항목이 표시됩니다.

3. 백엔드 인스턴스에서 실행 중인 HTTP 서버 소프트웨어의 연결 유지 구성 매개변수가 부하 분산기의 연결 유지 제한 시간보다 짧지 않은지 확인합니다. 값은 10분(600초)으로 고정되어 있으며 구성될 수 없습니다.

   부하 분산기는 HTTP 요청을 전송하는 동안 또는 전체 HTTP 응답이 수신되기 전에 예기치 않게 백엔드에 대한 연결이 닫히면 HTTP 5xx 상태 코드를 생성합니다. 이는 백엔드 인스턴스에서 실행 중인 웹 서버 소프트웨어의 연결 유지 구성 매개변수가 부하 분산기의 고정 연결 유지 제한 시간보다 작기 때문입니다. 각 백엔드에서 HTTP 서버 소프트웨어의 연결 유지 제한 시간 구성이 10분보다 약간 높게 설정되어 있는지 확인합니다(권장 값: 620초).

제한사항

다른Google Cloud 네트워킹 기능과 함께 내부 애플리케이션 부하 분산기를 사용하는 데 문제가 있다면 현재 호환성 제한사항을 참조하세요.