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

이 가이드에서는 외부 애플리케이션 부하 분산기의 구성 문제를 해결하는 방법을 설명합니다. 문제를 조사하기 전에 다음 페이지를 숙지하시기 바랍니다.

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

네트워크 분석기는 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.

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

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

일반적인 연결 문제 해결

설명할 수 없는 5XX 오류

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

statusDetails가 로그 문자열 response_sent_by_backend를 반환하는 경우 부하 분산기는 백엔드가 보낸 응답 코드만 릴레이합니다. 이 경우 백엔드의 HTTP 오류 응답 문제를 해결해야 합니다.

statusDetails가 로그 문자열 response_sent_by_backend와 일치하지 않는 HTTP 오류 응답의 경우:

전역 외부 애플리케이션 부하 분산기와 리전별 외부 애플리케이션 부하 분산기는 503(서비스를 사용할 수 없음) 및 504(게이트웨이 제한 시간)와 같은 유의미한 HTTP 응답 오류 코드를 생성합니다.
기본 애플리케이션 부하 분산기는 항상 HTTP 응답 오류 코드 502를 사용합니다.

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

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

상태 점검을 허용하도록 구성된 방화벽 규칙이 있는지 확인합니다. 방화벽 규칙이 없으면 부하 분산기 로그에는 일반적으로 failed_to_pick_backend와 일치하는 statusDetails가 있습니다. 이는 부하 분산기가 요청을 처리할 수 있는 정상적인 백엔드를 선택할 수 없음을 나타냅니다.
상태 점검 트래픽이 백엔드 VM에 도달하는지 확인합니다. 이렇게 하려면 상태 점검 로깅을 사용 설정하고 성공적인 로그 항목을 검색합니다.

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

백엔드에서 소프트웨어가 실행 중인지 확인합니다. 이렇게 하려면 5xx 응답이 부하 분산기에서 제공되는지 또는 백엔드에서 생성되는지 확인합니다. 다음 단계를 수행합니다.

Cloud Logging을 사용하여 부하 분산기의 로그를 확인합니다. 5xx 응답 코드만 검색하도록 쿼리를 만들 수 있습니다.

statusDetails 필드 값을 확인합니다.

statusDetails가 response_sent_by_backend와 같은 성공 메시지를 반환하면 이는 HTTP 502 응답을 제공하는 백엔드입니다. 백엔드에서 로그를 확인하고 백엔드에서 실행되는 서비스에 따라 추가로 문제를 해결합니다.
statusDetails가 실패 메시지를 반환하는 경우 5xx 응답과 관련된 몇 가지 일반적인 실패에 대해서는 다음 솔루션 목록을 참조하세요.

statusDetail 실패 메시지	잠재적 원인 및 해결책
`failed_to_connect_to_backend`	부하 분산기가 백엔드와의 연결을 설정할 수 없습니다. 즉, 백엔드에서 실행되는 서비스가 백엔드 서비스에 정의된 포트에서 수신되지 않을 수 있습니다. 권장사항: 제공 포트를 사용하도록 상태 점검 포트를 설정합니다. 즉, 백엔드가 실제 트래픽을 처리하기 전에 비정상으로 발견될 것입니다. 다음 명령어를 사용하여 백엔드 서비스의 이름이 지정된 포트에서 실행 중인 서비스가 있는지 확인합니다. $ netstat -tnl \| grep `PORT`
`failed_to_pick_backend`	부하 분산기가 백엔드를 선택할 수 없습니다. 즉, 모든 백엔드가 비정상일 수 있습니다. 상태 점검에 적합한 방화벽 규칙을 구성했는지 확인하세요.
`backend_connection_closed_before_data_sent_to_client`	응답이 클라이언트에 프록시되기 전에 백엔드가 예기치 않게 부하 분산기와의 연결을 닫았습니다. 이는 부하 분산기가 다른 항목으로 트래픽을 전송하는 경우 발생할 수 있습니다. 다른 항목은 부하 분산기의 제한 시간보다 짧은 TCP 제한 시간을 갖는 타사 부하 분산기일 수 있습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.
`backend_timeout`	백엔드가 응답하는 데 시간이 너무 오래 걸립니다. 백엔드 서비스 제한 시간이 너무 낮게 설정되어 있어서 지정된 서비스에 응답하지 못할 수 있습니다. 백엔드 서비스 제한 시간을 늘리거나 서비스가 응답하는 데 시간이 오래 걸리는 이유를 살펴보세요.

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

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

HTTP `408` 오류 해결

HTTP 트래픽의 경우 클라이언트가 요청 전송을 완료하는 데 걸리는 최대 시간은 백엔드 서비스 제한 시간과 동일합니다. HTTP에 jsonPayload.statusDetail client_timed_out이 포함된 408 응답이 표시되면 이는 클라이언트의 요청이 프록시되거나 백엔드의 응답이 프록시되어 있는 동안에 진행이 부족하다는 의미입니다. 성능 문제가 있는 클라이언트로 인해 문제가 발생하면 백엔드 서비스 제한 시간을 늘려 이 문제를 해결할 수 있습니다.

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

백엔드에서 인식하는 패킷의 소스 IP 주소는 부하 분산기의 외부 IP 주소가 아닙니다. 외부 애플리케이션 부하 분산기와 같은 프록시 기반 부하 분산기는 TCP 연결 2개를 사용하여 트래픽을 클라이언트에서 백엔드로 전송합니다.

원래 클라이언트에서 부하 분산기(GFE 또는 프록시 전용 서브넷)로의 연결 1
부하 분산기(GFE 또는 프록시 전용 서브넷)에서 백엔드 VM 또는 엔드포인트로의 연결 2

각 연결의 소스 및 대상 IP 주소는 사용하는 외부 애플리케이션 부하 분산기의 유형에 따라 다릅니다. 자세한 내용은 클라이언트 패킷의 소스 IP 주소를 참조하세요.

Cloud Storage 버킷에서 객체를 볼 때 권한 오류 발생

부하 분산을 통해 객체를 제공하려면 Cloud Storage 객체에 공개 액세스가 가능해야 합니다. 공개적으로 읽을 수 있도록 제공 중인 객체의 권한을 업데이트하세요.

URL이 예상되는 Cloud Storage 객체를 제공하지 않음

제공해야 하는 Cloud Storage 객체는 사용자가 요청한 URL 맵과 URL을 바탕으로 결정됩니다. 요청 경로가 URL 맵의 백엔드 버킷에 매핑되면 Cloud Storage 객체는 URL 맵이 지정하는 Cloud Storage 버킷에 전체 요청 경로를 추가하여 결정됩니다.

예를 들어 /static/*을 gs://[EXAMPLE_BUCKET]에 매핑하면 https://<GCLB IP or Host>/static/path/to/content.jpg에 대한 요청은 gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg를 제공하려고 시도합니다. 객체가 존재하지 않으면 객체 대신 다음과 같은 오류 메시지가 나타납니다.


NoSuchKey
The specified key does not exist.

압축이 작동하지 않음

외부 애플리케이션 부하 분산기는 응답 자체를 압축하거나 압축 해제하지 않지만 gzip 또는 DEFLATE와 같은 도구를 사용하여 압축된 백엔드 서비스에서 생성된 응답을 제공할 수 있습니다.

부하 분산기에서 제공하는 응답이 압축되지 않았지만 압축되어야 하는 경우, 인스턴스에서 실행 중인 웹 서버 소프트웨어가 응답을 압축하도록 구성되어 있는지 확인하세요. 기본적으로 일부 웹 서버 소프트웨어는 요청이 프록시에 의해 전달되었음을 나타내는 Via 헤더가 포함된 요청에 대해 압축을 자동으로 사용 중지합니다. 외부 애플리케이션 부하 분산기는 프록시이므로 HTTP 사양에 따라 각 요청에 Via 헤더를 추가합니다. 압축을 사용 설정하려면 요청에 Via 헤더가 포함되었더라도 응답을 압축하도록 웹 서버의 기본 구성을 우선 적용해야 할 수 있습니다.

외부 애플리케이션 부하 분산기를 통해 프록시 처리된 압축 응답을 제공하도록 nginx 백엔드를 구성하려면 다음 안내를 따르세요.

gzip_proxied 지시문을 적절하게 설정합니다(예: any).
gzip_vary 지시문을 on으로 설정합니다.

외부 애플리케이션 부하 분산기를 통해 프록시 처리된 압축 응답을 제공하도록 Apache 백엔드를 구성하려면 다음 안내를 따르세요.

DEFLATE 필터 사용합니다.
mod_headers 모듈을 사용하여 응답 헤더에 Vary Accept-Encoding을 추가합니다.

비정상 백엔드 문제 해결

백엔드의 HTTP/2 문제 해결

백엔드 인스턴스가 정상이고 HTTP/2 프로토콜을 지원하는지 확인합니다. 이를 확인하려면 HTTP/2를 사용하여 백엔드 인스턴스에 대한 연결을 테스트합니다. VM이 HTTP/2 사양과 호환되는 암호화 모음을 사용하는지 확인하세요. 예를 들어 특정 TLS 1.2 암호화 제품군은 HTTP/2에서 허용되지 않습니다. TLS 1.2 Cipher Suite Black List를 참조하세요.

VM이 HTTP/2 프로토콜을 사용하는지 확인한 후 방화벽 설정이 상태 검사기와 부하 분산기가 통과하도록 허용하는지 확인하세요.

방화벽 설정에 문제가 없으면 부하 분산기가 VM의 올바른 포트와 통신하도록 구성되었는지 확인합니다.

외부 백엔드 및 인터넷 NEG 문제 해결

문제를 조사하기 전에 다음 페이지를 숙지하시기 바랍니다.

트래픽이 엔드포인트에 도달하지 않음

서비스를 구성한 후 다음과 같은 경우에 외부 애플리케이션 부하 분산기를 통해 새 엔드포인트에 연결할 수 있습니다.

엔드포인트가 인터넷 NEG에 연결되어 있습니다.
연결된 FQDN이 성공적으로 확인된 DNS일 수 있습니다(FQDN 엔드포인트 유형을 사용하는 경우).
인터넷을 통해 엔드포인트에 액세스할 수 있습니다.

트래픽이 엔드포인트에 도달할 수 없어 502 오류 코드가 발생하면 dig 또는 nslookup과 같은 도구를 사용하여 _cloud-eoips.googleusercontent.com DNS TXT 레코드를 쿼리합니다. CIDR(ip4: 다음)을 기록하고 방화벽이나 클라우드 액세스 제어 목록(ACL)에서 허용하는 범위인지 확인합니다.

외부 백엔드를 구성한 후 외부 백엔드에 대한 요청이 5xx 오류와 함께 실패

로깅을 확인합니다.
외부 백엔드에 대해 올바른 IP:Port 또는 FQDN:Port로 네트워크 엔드포인트 그룹이 구성되었는지 확인합니다.
FQDN을 사용하는 경우 Google Public DNS를 통해 확인할 수 있는지 확인합니다. 해당 단계에 따라 웹 인터페이스를 직접 사용하여 Google Public DNS를 통해 FQDN이 확인되는지 확인할 수 있습니다.
외부 IP에서만 부하 분산기에 액세스하고 원본 웹 서버에 호스트 이름이 필요한 경우 커스텀 요청 헤더를 구성하여 백엔드에 유효한 HTTP 호스트 헤더를 전송해야 합니다.
INTERNET_FQDN_PORT 외부 백엔드 엔드포인트로 구성된 HTTPS 또는 HTTP2(백엔드 서비스의 protocol 필드에 설정됨)로 백엔드와 통신하는 경우 원본이 유효한 TLS(SSL) 인증서를 제공하고 구성된 FQDN이 SAN의 인증서 목록에 있는 SAN(제목 대체 이름)과 일치하는지 확인합니다. 유효한 인증서는 공개 인증 기관에서 서명된 인증서로 정의되며, 만료되지 않은 인증서입니다.
INTERNET_FQDN_PORT 외부 백엔드 엔드포인트를 사용하는 경우 자체 서명된 인증서는 부하 분산기에서 허용되지 않으며 거부됩니다.
INTERNET_IP_PORT 유형의 엔드포인트로 HTTPS 또는 HTTP/2를 사용할 때는 SSL 인증서 검증/SAN 확인이 수행되지 않습니다. 따라서 자체 서명된 인증서를 사용할 수 있습니다. SSL을 사용할 때는 INTERNET_FQDN_PORT 엔드포인트를 사용하여 서버 인증서 및 SAN을 검증할 수 있는지 확인하는 것이 좋습니다.

외부 백엔드의 응답이 Cloud CDN에 캐시되지 않음

다음을 확인하세요.

enableCDN을 true로 설정하여 외부 백엔드를 가리키는 NEG가 포함된 백엔드 서비스에서 Cloud CDN을 사용 설정했는지 확인합니다.
외부 백엔드에서 제공하는 응답이 Cloud CDN 캐싱 요구사항을 충족하는지 확인합니다. 예를 들어 원본에서 Cache-Control: public, max-age=3600 응답 헤더를 전송하는지 확인합니다.

서버리스 NEG 문제 해결

문제를 조사하기 전에 다음 페이지를 숙지하시기 바랍니다.

404 오류로 요청 실패

기본 서버리스 리소스(예: App Engine, Cloud Functions 또는 Cloud Run 서비스)가 계속 실행 중인지 확인합니다. 서버리스 리소스가 삭제되었지만 서버리스 NEG가 여전히 존재하는 경우 외부 애플리케이션 부하 분산기는 계속해서 존재하지 않는 서비스로 요청을 라우팅하려고 시도합니다. 그러면 404 응답이 발생합니다.

일반적으로 외부 애플리케이션 부하 분산기는 기본 서버리스 리소스가 예상대로 작동하는지 감지할 수 없습니다. 즉, 한 리전의 서비스가 오류를 반환하더라도 해당 리전의 전체 Cloud Run, Cloud Functions 또는 App Engine 인프라가 정상적으로 작동하면 외부 애플리케이션 부하 분산기가 자동으로 트래픽을 다른 리전으로 전달하지 않습니다. 외부 HTTP(S) 부하 분산기로 사용자 트래픽을 라우팅하기 전에 새로운 버전의 서비스를 철저히 테스트해야 합니다.

URL 마스크 불일치 처리

사용자 요청 URL에 구성된 URL 마스크를 적용해도 서비스 이름이 나오지 않거나 존재하지 않는 서비스 이름이 나오는 경우 사용 중인 서버리스 컴퓨팅 플랫폼에 따라 부하 분산기가 이러한 불일치를 다르게 처리할 수 있습니다.

Cloud Run: URL 마스크가 일치하지 않는 경우 부하 분산기가 HTTP 오류 404(찾을 수 없음)를 반환합니다.

Cloud Functions: URL 마스크가 일치하지 않는 경우 부하 분산기가 HTTP 오류 404(찾을 수 없음)를 반환합니다.

App Engine: URL 마스크가 일치하지 않는 경우 App Engine은 dispatch.yaml 및 App Engine의 기본 라우팅 로직을 사용하여 요청을 전송할 서비스를 결정합니다.