외부 애플리케이션 부하 분산기 개요

이 문서에서는 외부 애플리케이션 부하 분산기를 구성하는 방법을 이해하는 데 필요한 개념을 소개합니다.

외부 애플리케이션 부하 분산기는 프록시 기반 레이어 7 부하 분산기로, 외부 IP 주소 하나로 서비스를 실행하고 서비스를 확장할 수 있습니다. 외부 애플리케이션 부하 분산기는 HTTP 및 HTTPS 트래픽을 Compute Engine, Google Kubernetes Engine(GKE), Cloud Storage 등의 다양한 Google Cloud Platform에서 호스팅되는 백엔드는 물론 인터넷 또는 하이브리드 연결을 통해 연결된 외부 백엔드에도 배포합니다. 자세한 내용은 애플리케이션 부하 분산기 개요: 사용 사례를 참조하세요.

작업 모드

외부 애플리케이션 부하 분산기는 다음 모드로 구성할 수 있습니다.

• 전역 외부 애플리케이션 부하 분산기. Google 프런트엔드(GFE)에서 관리형 서비스로 구현되는 전역 부하 분산기입니다. 이는 오픈소스 Envoy 프록시를 사용하여 트래픽 미러링, 가중치 기반 트래픽 분할, 요청/응답 기반 헤더 변환 등의 고급 트래픽 관리 기능을 지원합니다.
• 기존 애플리케이션 부하 분산기. 프리미엄 등급에서는 전역이지만 표준 등급에서는 리전으로 구성될 수 있는 기본 외부 애플리케이션 부하 분산기입니다. 이 부하 분산기는 Google 프런트엔드(GFE)에서 구현됩니다. GFE는 Google의 글로벌 네트워크 및 제어 영역을 사용하여 전 세계로 분산되고 함께 운영됩니다.
• 리전 외부 애플리케이션 부하 분산기. 오픈소스 Envoy 프록시에 관리형 서비스로 구현되는 리전별 부하 분산기입니다. 여기에는 트래픽 미러링, 가중치 기반 트래픽 분할, 요청/응답 기반 헤더 변환 등의 고급 트래픽 관리 기능이 포함됩니다.

모드 식별

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

아키텍처

외부 애플리케이션 부하 분산기 배포에는 다음 리소스가 필요합니다.

• 리전 외부 애플리케이션 부하 분산기에 한해 부하 분산기에서 백엔드로 연결을 전송하는 데 프록시 전용 서브넷이 사용됩니다.

• 외부 전달 규칙은 외부 IP 주소, 포트, 대상 HTTP(S) 프록시를 지정합니다. 클라이언트는 IP 주소와 포트를 사용하여 부하 분산기에 연결합니다.

• 대상 HTTP(S) 프록시는 클라이언트로부터 요청을 받습니다. HTTP(S) 프록시는 트래픽 라우팅을 결정하기 위해 URL 맵을 사용하여 요청을 평가합니다. 프록시는 SSL 인증서를 사용하여 통신을 인증할 수도 있습니다.

  • HTTPS 부하 분산의 경우 대상 HTTPS 프록시는 SSL 인증서를 사용하여 클라이언트에 ID를 증명합니다. 대상 HTTPS 프록시는 SSL 인증서의 문서화된 최대 개수를 지원합니다.

• HTTP(S) 프록시는 URL 맵을 사용하여 요청 경로, 쿠키 또는 헤더와 같은 HTTP 속성에 따라 라우팅을 결정합니다. 라우팅 결정에 따라 프록시는 클라이언트 요청을 특정 백엔드 서비스 또는 백엔드 버킷으로 전달합니다. URL 맵은 리디렉션을 클라이언트로 전송과 같은 추가 작업을 지정할 수 있습니다.

• 백엔드 서비스는 정상 backends에 요청을 배포합니다. 전역 외부 애플리케이션 부하 분산기는 백엔드 버킷도 지원합니다.

  • 하나 이상의 backends를 백엔드 서비스 또는 백엔드 버킷에 연결해야 합니다.

• 상태 점검에서 백엔드 준비 상태를 주기적으로 모니터링합니다. 이러면 요청을 처리할 수 없는 백엔드로 요청이 전송될 위험이 줄어듭니다.

• 백엔드가 상태 점검 프로브를 수락하는 방화벽 규칙입니다. 리전 외부 애플리케이션 부하 분산기에는 프록시 전용 서브넷의 트래픽이 백엔드에 도달하도록 허용하는 추가 방화벽 규칙이 필요합니다.

전역

이 다이어그램은 전역 외부 애플리케이션 부하 분산기 배포의 구성요소를 보여줍니다. 이 아키텍처는 전역 외부 애플리케이션 부하 분산기와 프리미엄 등급의 기본 애플리케이션 부하 분산기 모두에 적용됩니다.

리전

이 다이어그램은 리전 외부 애플리케이션 부하 분산기 배포의 구성요소를 보여줍니다.

프록시 전용 서브넷

프록시 전용 서브넷은 리전 외부 애플리케이션 부하 분산기에만 필요합니다.

프록시 전용 서브넷은 Google이 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 제공합니다. 리전 외부 애플리케이션 부하 분산기를 사용하는 VPC 네트워크의 각 리전에 하나의 프록시 전용 서브넷을 만들어야 합니다. 이 프록시 전용 서브넷의 --purpose 플래그는 REGIONAL_MANAGED_PROXY로 설정됩니다. 동일한 리전 및 VPC 네트워크의 모든 리전별 Envoy 기반 부하 분산기는 동일한 프록시 전용 서브넷의 Envoy 프록시 풀을 공유합니다. 그 밖에도 다음과 같습니다.

• 프록시 전용 서브넷은 백엔드가 아닌 오로지 Envoy 프록시에만 사용됩니다.
• 리전 및 VPC 네트워크에서 모든 리전 외부 애플리케이션 부하 분산기의 백엔드 VM 또는 엔드포인트는 프록시 전용 서브넷에서 연결을 수신합니다.
• 리전 외부 애플리케이션 부하 분산기의 IP 주소는 프록시 전용 서브넷에 있지 않습니다. 부하 분산기의 IP 주소는 아래에 설명된 외부 관리형 전달 규칙으로 정의됩니다.

이전에 --purpose=INTERNAL_HTTPS_LOAD_BALANCER를 사용하여 프록시 전용 서브넷을 만든 경우 VPC 네트워크와 동일한 리전에 다른 Envoy 기반 부하 분산기를 만들기 전에 REGIONAL_MANAGED_PROXY로 서브넷의 용도를 마이그레이션해야 합니다.

전달 규칙 및 IP 주소

전달 규칙은 IP 주소, 포트, 프로토콜별로 트래픽을 대상 프록시, URL 맵, 하나 이상의 백엔드 서비스로 구성된 부하 분산 구성으로 라우팅합니다.

IP 주소 사양. 각 전달 규칙은 애플리케이션의 DNS 레코드에 사용할 수 있는 단일 IP 주소를 제공합니다. DNS 기반 부하 분산은 필요 없습니다. 사용할 IP 주소를 지정하거나 Cloud Load Balancing에서 IP 주소를 할당하도록 할 수 있습니다.

포트 사양. 애플리케이션 부하 분산기의 각 전달 규칙은 1~65535 범위의 단일 포트를 참조할 수 있습니다. 여러 포트를 지원하려면 여러 개의 전달 규칙을 구성해야 합니다. IP 주소, 포트, 프로토콜의 전체 조합이 각 전달 규칙마다 고유하면 동일한 외부 IP 주소(VIP)를 사용하고 동일한 대상 HTTP(S) 프록시를 참조하도록 여러 전달 규칙을 구성할 수 있습니다. 이렇게 하면 공유 URL 맵이 있는 단일 부하 분산기를 여러 애플리케이션에 대한 프록시로 사용할 수 있습니다.

외부 애플리케이션 부하 분산기에서 사용하는 전달 규칙, IP 주소, 부하 분산 스키마의 유형은 부하 분산기 모드와 부하 분산기가 속한 네트워크 서비스 등급에 따라 다릅니다.

각 모드의 외부 애플리케이션 부하 분산기 전달 규칙에서 지원하는 프로토콜의 전체 목록은 부하 분산기 기능을 참조하세요.

전달 규칙 및 VPC 네트워크

이 섹션에서는 외부 애플리케이션 부하 분산기에서 사용하는 전달 규칙이 VPC 네트워크와 연결되는 방법을 설명합니다.

대상 프록시

대상 프록시는 클라이언트의 HTTP(S) 연결을 종료합니다. 하나 이상의 전달 규칙이 트래픽을 대상 프록시로 전달하고 대상 프록시가 URL 맵을 참조하여 트래픽을 백엔드로 라우팅하는 방법을 결정합니다.

요청 또는 응답 헤더 이름의 대소문자를 유지하기 위해 프록시에 의존하지 마세요. 예를 들어 Server: Apache/1.0 응답 헤더는 클라이언트에 server: Apache/1.0으로 나타날 수 있습니다.

다음 표에서는 각 모드의 외부 애플리케이션 부하 분산기에 필요한 대상 프록시 유형을 명시합니다.

대상 프록시에서 추가한 헤더 외에도 부하 분산기는 다음 방법으로 다른 HTTP 헤더를 조정합니다.

• 전역 외부 애플리케이션 부하 분산기의 경우 요청 및 응답 헤더가 항상 소문자로 변환됩니다. 예를 들어 Host는 host가 되고 Keep-ALIVE는 keep-alive가 됩니다.

  이에 대한 유일한 예외는 HTTP/1.1을 사용하는 전역 인터넷 NEG 백엔드를 사용하는 경우입니다. HTTP/1.1 헤더가 전역 인터넷 NEG로 처리되는 방법에 대한 자세한 내용은 인터넷 NEG 개요를 참조하세요.

• 기본 애플리케이션 부하 분산기의 경우 HTTP/1.1을 사용하는 경우를 제외하고 요청 및 응답 헤더가 소문자로 변환됩니다. HTTP/1.1에서는 헤더에 적절한 대소문자가 사용됩니다. 헤더의 키의 첫 번째 문자와 하이픈(-) 뒤에 오는 모든 문자는 HTTP/1.1 클라이언트와의 호환성을 유지하기 위해 대문자로 표기됩니다. 예를 들어 user-agent는 User-Agent로, content-encoding은 Content-Encoding으로 변경됩니다.

• 일부 헤더는 병합됩니다. 동일한 헤더 키의 인스턴스가 여러 개인 경우(예: Via) 부하 분산기는 단일 헤더 키의 단일 쉼표로 구분된 목록에 해당 값을 결합합니다. 값이 쉼표로 구분된 목록으로 표시될 수 있는 헤더만 병합됩니다. 다른 헤더(예: Set-Cookie)는 병합되지 않습니다.

호스트 헤더

부하 분산기가 HTTP 요청을 수행할 때 부하 분산기는 원래 요청의 호스트 헤더를 유지합니다.

X-Forwarded-For 헤더

부하 분산기는 쉼표로 구분된 IP 주소 2개를 X-Forwarded-For 헤더에 다음 순서대로 추가합니다.

• 부하 분산기에 연결되는 클라이언트의 IP 주소
• 부하 분산기의 전달 규칙에 해당하는 IP 주소

수신 요청에 X-Forwarded-For 헤더가 없으면 이 두 IP 주소가 전체 헤더 값입니다.

X-Forwarded-For: <client-ip>,<load-balancer-ip>

요청에 X-Forwarded-For 헤더가 포함된 경우 부하 분산기는 <client-ip>,<load-balancer-ip> 앞에 제공된 값을 유지합니다.

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

부하 분산기의 백엔드에서 HTTP 리버스 프록시 소프트웨어를 실행하는 경우 소프트웨어에서 X-Forwarded-For 헤더 끝에 다음 IP 주소 중 하나 또는 둘 다를 추가할 수 있습니다.

• 백엔드에 연결된 Google 프런트엔드(GFE)의 IP 주소입니다. 이러한 IP 주소는 130.211.0.0/22 및 35.191.0.0/16 범위에 있습니다.

• 백엔드 시스템 자체의 IP 주소입니다.

따라서 부하 분산기의 백엔드 뒤에 업스트림 프로세스가 다음과 같은 형식의 X-Forwarded-For 헤더를 받을 수 있습니다.

<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>

URL 맵

URL 맵은 URL에 기반하여 요청을 적절한 백엔드 서비스로 라우팅하기 위한 일치 패턴을 정의합니다. 기본 서비스는 지정된 호스트 규칙 또는 경로 일치 규칙과 일치하지 않는 요청을 처리하도록 정의됩니다. 멀티 리전 부하 분산 예시와 같은 상황에서는 URL 규칙을 정의하지 않고 기본 서비스만 활용할 수도 있습니다. 요청 라우팅의 경우 URL 맵을 사용하면 URL 구성요소를 검사하여 요청을 서로 다른 백엔드 집합으로 전송하여 트래픽을 나눌 수 있습니다.

전역 외부 애플리케이션 부하 분산기 및 리전 외부 애플리케이션 부하 분산기와 함께 사용되는 URL 맵은 헤더 기반 트래픽 조정, 가중치 기반 트래픽 분할, 요청 미러링과 같은 여러 고급 트래픽 관리 기능을 지원합니다. 자세한 내용은 다음을 참조하세요.

• 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요
• 리전 외부 애플리케이션 부하 분산기의 트래픽 관리 개요

다음 표에서는 각 모드에서 외부 애플리케이션 부하 분산기에 필요한 URL 맵 유형을 명시합니다.

SSL 인증서

• Google Cloud는 대상 HTTPS 프록시에 비공개 키와 SSL 인증서를 할당하는 두 가지 구성 방법인 Compute Engine SSL 인증서와 Certificate Manager를 제공합니다. 각 구성에 대한 설명은 SSL 인증서 개요의 인증서 구성 방법을 참조하세요.

• Google Cloud는 자체 관리형과 Google 관리형이라는 두 가지 인증서 유형을 제공합니다. 각 유형에 대한 설명은 SSL 인증서 개요에서 인증서 유형을 참조하세요.

• 외부 애플리케이션 부하 분산기 유형(전역, 리전 또는 기본)에 따라 지원되는 구성 메서드 및 인증서 유형이 결정됩니다. 자세한 내용은 SSL 인증서 개요에서 인증서 및 Google Cloud 부하 분산기를 참조하세요.

상호 TLS

일반적으로 HTTPS 커뮤니케이션에서 인증은 클라이언트가 서버의 ID를 확인하는 방식의 단방향으로만 작동합니다. 부하 분산기가 연결하는 클라이언트의 ID를 인증해야 하는 애플리케이션의 경우 전역 외부 애플리케이션 부하 분산기 및 기본 애플리케이션 부하 분산기가 상호 TLS(mTLS)를 지원합니다.

mTLS에서 부하 분산기는 부하 분산기와의 TLS 핸드셰이크 중 클라이언트가 자체 인증을 위해 인증서를 전송하도록 요청합니다. 부하 분산기가 클라이언트 인증서의 신뢰 체인을 검증하는 데 사용하는 트러스트 저장소를 구성할 수 있습니다.

Google Cloud는 서버가 사용하는 인증서를 저장하는 인증서 관리자의 TrustConfig 리소스를 사용하여 클라이언트에서 제공한 인증서를 확인합니다. 프리미엄 네트워크 서비스 등급의 기본 외부 애플리케이션 부하 분산기 또는 전역 외부 애플리케이션 부하 분산기를 사용하는 경우 인증서 관리자를 사용하여 부하 분산기의 여러 인스턴스에서 SSL 인증서 또는 TrustConfig를 대규모로 프로비저닝하고 관리할 수 있습니다. 자세한 내용은 인증서 관리자 개요를 참조하세요.

mTLS에 관한 자세한 내용은 상호 TLS 인증을 참고하세요.

SSL 정책

SSL 정책은 클라이언트와 SSL을 협상할 때 Google Cloud 부하 분산기에서 사용하는 SSL 기능 집합을 지정합니다.

기본적으로 HTTPS 부하 분산은 우수한 보안과 광범위한 호환성을 제공하는 SSL 기능 집합을 사용합니다. 일부 애플리케이션은 HTTPS 또는 SSL 연결에 사용되는 SSL 버전 및 암호화를 보다 강력하게 제어해야 합니다. SSL 정책을 정의하여 부하 분산기가 클라이언트와 SSL을 협상할 때 사용하는 SSL 기능 집합을 지정할 수 있습니다. 또한 이 SSL 정책을 대상 HTTPS 프록시에 적용할 수 있습니다.

다음 표에서는 각 모드의 부하 분산기에 대한 SSL 정책 지원을 명시합니다.

백엔드 서비스 및 백엔드 버킷

백엔드 서비스는 부하 분산기에 구성 정보를 제공합니다. 부하 분산기는 백엔드 서비스의 정보를 사용하여 수신 트래픽을 하나 이상의 연결된 백엔드로 보냅니다. 백엔드 서비스와 Compute Engine 백엔드로 부하 분산기를 설정하는 방법을 보여주는 예시는 Compute Engine 백엔드로 외부 애플리케이션 부하 분산기 설정을 참조하세요.

백엔드 버킷은 들어오는 트래픽을 Cloud Storage 버킷으로 전달합니다. 외부 애플리케이션 부하 분산기에 버킷을 추가하는 방법의 예시는 백엔드 버킷으로 부하 분산기 설정을 참조하세요.

다음 표에서는 각 모드에서 외부 애플리케이션 부하 분산기가 지원하는 백엔드 기능을 명시합니다.

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

• 백엔드 서비스 개요
• Cloud Storage란 무엇인가요?

백엔드 및 VPC 네트워크

백엔드를 배치할 수 있는 위치에 대한 제한사항은 부하 분산기 유형에 따라 다릅니다.

백엔드를 배치할 수 있는 위치에 대한 제한사항은 부하 분산기 유형에 따라 다릅니다.

전역 외부 애플리케이션 부하 분산기 및 기본 애플리케이션 부하 분산기의 경우 인스턴스 그룹 백엔드의 모든 백엔드 인스턴스와 NEG 백엔드의 모든 백엔드 엔드포인트가 동일한 프로젝트에 있어야 합니다. 그러나 인스턴스 그룹 백엔드 또는 NEG는 해당 프로젝트에서 다른 VPC 네트워크를 사용할 수 있습니다. GFE가 해당 VPC 네트워크에서 백엔드와 직접 통신하므로 VPC 네트워크 피어링을 사용해서 다른 VPC 네트워크를 연결할 필요가 없습니다.

리전 외부 애플리케이션 부하 분산기의 경우 백엔드 유형에 따라 다릅니다.

• 인스턴스 그룹, 영역별 NEG, 하이브리드 연결 NEG의 경우 모든 백엔드는 백엔드 서비스와 동일한 프로젝트 및 리전에 있어야 합니다. 그러나 부하 분산기는 백엔드 서비스와 동일한 프로젝트에서 다른 VPC 네트워크를 사용하는 백엔드를 참조할 수 있습니다(이 기능은 미리보기에 있음). 부하 분산기의 VPC 네트워크와 백엔드 VPC 네트워크 간의 연결은 VPC 네트워크 피어링, Cloud VPN 터널, Cloud Interconnect VLAN 연결 또는 Network Connectivity Center 프레임워크를 사용하여 구성할 수 있습니다.

  백엔드 네트워크 정의

  • 영역별 NEG 및 하이브리드 NEG의 경우 NEG를 만들 때 VPC 네트워크를 명시적으로 지정합니다.
  • 관리형 인스턴스 그룹의 경우 VPC 네트워크가 인스턴스 템플릿에 정의됩니다.
  • 비관리형 인스턴스 그룹의 경우 인스턴스 그룹의 VPC 네트워크는 인스턴스 그룹에 추가된 첫 번째 VM에 대한 nic0 인터페이스의 VPC 네트워크와 일치하도록 설정됩니다.

  백엔드 네트워크 요구사항

  백엔드 네트워크는 다음 네트워크 요구사항 중 하나를 충족해야 합니다.

  • 백엔드의 VPC 네트워크는 전달 규칙의 VPC 네트워크와 정확하게 일치해야 합니다.

  • 백엔드의 VPC 네트워크는 VPC 네트워크 피어링을 사용하여 전달 규칙의 VPC 네트워크에 연결되어야 합니다. 전달 규칙의 VPC 네트워크에 있는 프록시 전용 서브넷과 백엔드 인스턴스 또는 엔드포인트에서 사용하는 서브넷 간의 통신을 허용하도록 서브넷 경로 교환을 구성해야 합니다.

  • 백엔드의 VPC 네트워크와 전달 규칙의 VPC 네트워크는 모두 동일한 Network Connectivity Center 허브에 있는 VPC 스포크여야 합니다. 가져오기 및 내보내기 필터는 전달 규칙의 VPC 네트워크에 있는 프록시 전용 서브넷과 백엔드 인스턴스 또는 엔드포인트에서 사용하는 서브넷 간의 통신을 허용해야 합니다.
  • 다른 모든 백엔드 유형의 경우 모든 백엔드가 동일한 VPC 네트워크와 리전에 있어야 합니다.

백엔드 및 네트워크 인터페이스

인스턴스 그룹 백엔드를 사용하는 경우 패킷이 항상 nic0에 전달됩니다. 패킷을 다른 NIC로 전송하려면 NEG 백엔드를 대신 사용합니다.

영역별 NEG 백엔드를 사용하는 경우 패킷은 NEG의 엔드포인트가 나타내는 네트워크 인터페이스로 전송됩니다. NEG 엔드포인트는 NEG의 명시적으로 정의된 VPC 네트워크와 동일한 VPC 네트워크에 있어야 합니다.

백엔드 프로토콜

부하 분산기에 백엔드 서비스를 구성할 때는 백엔드 서비스가 백엔드와 통신하는 데 사용하는 프로토콜을 설정해야 합니다. HTTP, HTTPS 또는 HTTP/2를 선택할 수 있습니다. 부하 분산기는 지정된 프로토콜만 사용합니다. 지정된 프로토콜로 백엔드에 대한 연결을 협상할 수 없는 경우 부하 분산기는 다른 프로토콜 중 하나로 돌아가지 않습니다.

HTTP/2를 사용하는 경우 TLS를 사용해야 합니다. 암호화되지 않은 HTTP/2는 지원되지 않습니다.

지원되는 프로토콜의 전체 목록은 부하 분산 기능: 부하 분산기에서 백엔드까지의 프로토콜을 참조하세요.

WebSocket 지원

HTTP 또는 HTTPS를 백엔드에 대한 프로토콜로 사용하면 Google Cloud HTTP(S) 기반 부하 분산기는 기본적으로 WebSocket 프로토콜을 지원합니다. 부하 분산기에는 WebSocket 연결을 프록시하는 구성이 필요 없습니다.

WebSocket 프로토콜은 클라이언트와 부하 분산기 간의 전이중 통신 채널을 제공합니다. 자세한 내용은 RFC 6455를 참조하세요.

WebSocket 프로토콜은 다음과 같이 작동합니다.

1. 부하 분산기는 HTTP(S) 클라이언트에서 WebSocket Upgrade 요청을 인식합니다. 요청에는 다른 관련된 WebSocket 관련 요청 헤더로 이어지는 Connection: Upgrade, Upgrade: websocket 헤더가 포함됩니다.
2. 백엔드가 WebSocket Upgrade 응답을 보냅니다. 백엔드 인스턴스는 Connection: Upgrade, Upgrade: websocket 헤더, 기타 WebSocket 관련 응답 헤더를 사용하여 101 switching protocol 응답을 보냅니다.
3. 부하 분산기가 현재 연결 기간 동안 양방향 트래픽을 프록시합니다.

백엔드 인스턴스가 응답 코드 426 또는 502로 오류 응답을 반환하면 부하 분산기가 연결을 닫습니다.

WebSocket의 세션 어피니티는 다른 모든 요청과 동일하게 작동합니다. 자세한 내용은 세션 어피니티를 참조하세요.

Google Cloud 애플리케이션에서 gRPC 사용

gRPC는 원격 프로시저 호출을 위한 오픈소스 프레임워크이며 HTTP/2 표준을 기반으로 합니다. gRPC의 사용 사례는 다음과 같습니다.

• 지연 시간이 짧고 확장성이 높은 분산형 시스템
• 클라우드 서버와 통신하는 모바일 클라이언트 개발
• 정확하고 효율적이며 언어와 독립적이어야 하는 새로운 프로토콜 설계
• 확장, 인증, 로깅을 사용하는 계층형 디자인

Google Cloud 애플리케이션에서 gRPC를 사용하려면 HTTP/2를 통해 엔드 투 엔드 요청을 프록시해야 합니다. 방법은 다음과 같습니다.

1. HTTPS 부하 분산기를 구성합니다.
2. 부하 분산기에서 백엔드로의 프로토콜로 HTTP/2를 사용 설정합니다.

부하 분산기는 ALPN TLS 확장을 사용하여 SSL 핸드셰이크의 일부로 클라이언트와 HTTP/2를 협상합니다.

부하 분산기는 여전히 일부 클라이언트와 HTTPS를 협상하거나 부하 분산기와 백엔드 인스턴스 간에 HTTP/2를 사용하도록 구성된 부하 분산기에서 비보안 HTTP 요청을 수락할 수 있습니다. 이러한 HTTP 또는 HTTPS 요청은 부하 분산기에 의해 변환되어 요청을 HTTP/2를 통해 백엔드 인스턴스로 프록시합니다.

백엔드에서 TLS를 사용 설정해야 합니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.

Google Kubernetes Engine 인그레스에서 HTTP/2를 사용하거나 인그레스에서 gRPC 및 HTTP/2를 사용하여 외부 애플리케이션 부하 분산기를 구성하려면 인그레스를 사용한 부하 분산용 HTTP/2를 참조하세요.

HTTP/2를 사용하는 경우의 문제 해결에 대한 자세한 내용은 백엔드에 HTTP/2를 사용하여 문제 해결을 참조하세요.

HTTP/2 제한사항에 대한 자세한 내용은 HTTP/2 제한사항을 참조하세요.

상태 확인

각 백엔드 서비스는 부하 분산기에서 연결을 수신할 수 있도록 백엔드의 준비 상태를 주기적으로 모니터링하는 상태 점검을 지정합니다. 이러면 요청을 처리할 수 없는 백엔드로 요청이 전송될 위험이 줄어듭니다. 상태 점검은 애플리케이션 자체가 작동하는지 확인하지 않습니다.

상태 점검 프로브의 경우 상태 점검 프로브가 백엔드 인스턴스에 도달할 수 있도록 인그레스 허용 방화벽 규칙을 만들어야 합니다. 일반적으로 상태 점검 프로브는 Google의 중앙 집중식 상태 점검 메커니즘에서 시작됩니다.

하이브리드 NEG 백엔드를 사용하는 리전 외부 애플리케이션 부하 분산기는 대신 상태 점검이 프록시 전용 서브넷에서 시작되므로 이 규칙의 예외입니다. 자세한 내용은 하이브리드 NEG 개요를 참조하세요.

상태 점검 프로토콜

필수는 아니며 항상 가능하지는 않지만 프로토콜이 백엔드 서비스의 프로토콜과 일치하는 상태 점검을 사용하는 것이 좋습니다. 예를 들어 HTTP/2 상태 점검은 백엔드에 대한 HTTP/2 연결을 가장 정확하게 테스트합니다. 반면에 하이브리드 NEG 백엔드를 사용하는 리전 외부 애플리케이션 부하 분산기는 gRPC 상태 점검을 지원하지 않습니다. 지원되는 상태 점검 프로토콜 목록은 부하 분산 기능을 참조하세요.

다음 표에서는 각 모드의 외부 애플리케이션 부하 분산기에서 지원하는 상태 점검 범위를 명시합니다.

상태 점검에 대한 자세한 내용은 다음을 참조하세요.

• 상태 점검 개요
• 상태 점검 만들기

방화벽 규칙

부하 분산기에는 다음 방화벽 규칙이 필요합니다.

• 전역 외부 애플리케이션 부하 분산기에는 Google 프런트엔드(GFE)의 트래픽이 백엔드에 도달하도록 허용하는 인그레스 허용 규칙이 필요합니다.
  리전 외부 애플리케이션 부하 분산기의 경우 인그레스 허용 규칙에서 프록시 전용 서브넷의 트래픽이 백엔드에 도달하도록 허용합니다.
• 상태 점검 범위의 트래픽을 허용하는 인그레스 허용 규칙이 필요합니다. 상태 점검 프로브와 트래픽을 허용해야 하는 이유에 대한 자세한 내용은 프로브 IP 범위 및 방화벽 규칙을 참조하세요.

방화벽 규칙은 GFE 프록시가 아닌 VM 인스턴스 수준에서 구현됩니다. Google Cloud 방화벽 규칙을 사용하여 트래픽이 부하 분산기에 도달하는 것을 막을 수 없습니다. 전역 외부 애플리케이션 부하 분산기 및 기본 애플리케이션 부하 분산기의 경우 Google Cloud Armor를 사용하여 이를 수행할 수 있습니다.

이러한 방화벽 규칙의 포트를 다음과 같이 구성해야 합니다.

• 각 백엔드 서비스 상태 점검의 목적지 포트에 대한 트래픽을 허용합니다.

• 인스턴스 그룹 백엔드: 백엔드 서비스의 이름이 지정된 포트와 각 인스턴스 그룹의 이름이 지정된 포트에 연결된 포트 번호 간의 매핑에 따라 구성할 포트를 결정합니다. 동일한 백엔드 서비스에 할당된 인스턴스 그룹에서도 이 포트 번호가 다를 수 있습니다.

• GCE_VM_IP_PORT NEG 백엔드: 엔드포인트의 포트 번호에 대한 트래픽을 허용합니다.

다음 표에는 방화벽 규칙에 필요한 소스 IP 주소 범위가 요약되어 있습니다.

공유 VPC 아키텍처

외부 애플리케이션 부하 분산기는 공유 VPC를 사용하는 네트워크를 지원합니다. 공유 VPC를 사용하는 조직은 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있으므로 리소스가 해당 네트워크의 내부 IP 주소를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다. 공유 VPC에 대해 잘 모른다면 공유 VPC 개요를 참조하세요.

공유 VPC 네트워크 내에서 외부 애플리케이션 부하 분산기를 구성하는 여러 가지 방법이 있습니다. 배포 유형에 관계없이 부하 분산기의 모든 구성요소는 동일한 조직에 있어야 합니다.

공유 VPC 호스트 프로젝트에서 모든 부하 분산 구성요소와 백엔드를 만들 수 있지만 이러한 유형의 배포는 네트워크 관리와 서비스 개발 책임을 분리하지 않습니다.

서비스 프로젝트의 모든 부하 분산기 구성요소 및 백엔드

다음 아키텍처 다이어그램은 모든 부하 분산기 구성요소와 백엔드가 서비스 프로젝트에 있는 표준 공유 VPC 배포를 보여줍니다. 이 배포 유형은 모든 애플리케이션 부하 분산기에서 지원됩니다.

부하 분산기 구성요소와 백엔드는 동일한 VPC 네트워크를 사용해야 합니다.

공유 VPC 환경의 서버리스 백엔드

서버리스 NEG 백엔드를 사용하는 부하 분산기의 경우 백엔드 Cloud Run 또는 Cloud Run 함수 서비스가 서버리스 NEG와 동일한 프로젝트에 있어야 합니다.

또한 교차 프로젝트 서비스 참조를 지원하는 리전 외부 애플리케이션 부하 분산기의 경우 백엔드 서비스, 서버리스 NEG, Cloud Run 서비스가 항상 동일한 서비스 프로젝트에 있어야 합니다.

교차 프로젝트 서비스 참조

이 모델에서는 부하 분산기의 프런트엔드와 URL 맵이 호스트 또는 서비스 프로젝트에 있습니다. 부하 분산기의 백엔드 서비스와 백엔드는 공유 VPC 환경의 프로젝트에 분산될 수 있습니다. 교차 프로젝트 백엔드 서비스는 단일 URL 맵에서 참조될 수 있습니다. 이를 교차 프로젝트 서비스 참조라고 합니다.

교차 프로젝트 서비스 참조를 사용하면 조직에서 중앙 부하 분산기 하나를 구성하고 여러 프로젝트에 분산된 수백 개의 서비스로 트래픽을 라우팅할 수 있습니다. 모든 트래픽 라우팅 규칙과 정책을 하나의 URL 맵에서 중앙 관리할 수 있습니다. 부하 분산기를 단일 호스트 이름 및 SSL 인증서 집합과 연결할 수도 있습니다. 따라서 애플리케이션을 배포하는 데 필요한 부하 분산기 수를 최적화하고 관리 소요, 운영 비용, 할당량 요구사항을 낮출 수 있습니다.

업무팀마다 서로 다른 프로젝트를 사용하면 조직 내 역할을 분리할 수 있습니다. 서비스 소유자는 서비스 프로젝트에서 서비스를 빌드하는 데 집중할 수 있으며, 네트워크팀은 다른 프로젝트에서 부하 분산기를 프로비저닝하고 유지관리할 수 있으며, 두 가지 모두 프로젝트 간 서비스 참조를 사용하여 연결할 수 있습니다.

서비스 소유자는 서비스 노출에 대한 자율성을 유지하고 부하 분산기를 통해 서비스에 액세스할 수 있는 사용자를 제어할 수 있습니다. 이를 위해서는 Compute 부하 분산기 서비스 사용자 역할(roles/compute.loadBalancerServiceUser)이라는 특수 IAM 역할을 사용하면 됩니다.

교차 프로젝트 서비스 참조 유무에 관계없이 리전 외부 애플리케이션 부하 분산기의 공유 VPC를 구성하는 방법은 공유 VPC로 리전 외부 애플리케이션 부하 분산기 설정을 참조하세요.

교차 프로젝트 서비스 참조의 알려진 제한사항

• 교차 프로젝트 서비스 참조는 인스턴스 그룹, 서버리스 NEG, 기타 지원되는 대부분의 백엔드 유형에 사용할 수 있습니다. 단, 다음과 같은 제한사항이 적용됩니다.

  • 전역 외부 애플리케이션 부하 분산기를 사용하면 백엔드 서비스에 다음 백엔드가 있는 경우 교차 프로젝트 백엔드 서비스를 참조할 수 없습니다.

    • 백엔드 버킷
    • App Engine의 서버리스 NEG
  • 리전 외부 애플리케이션 부하 분산기를 사용하면 백엔드 서비스에 리전별 인터넷 NEG 백엔드가 있는 경우 교차 프로젝트 백엔드 서비스를 참조할 수 없습니다.
• 기본 애플리케이션 부하 분산기에는 교차 프로젝트 서비스 참조가 지원되지 않습니다.
• Google Cloud는 여러 프로젝트에서 동일한 이름을 사용하는 리소스(예: 백엔드 서비스)를 구별하지 않습니다. 따라서 프로젝트 간 서비스 참조를 사용하는 경우 조직 내 프로젝트 전체에서 고유한 백엔드 서비스 이름을 사용하는 것이 좋습니다.

예시 1: 다른 서비스 프로젝트의 부하 분산기 프런트엔드 및 백엔드

다음은 서비스 프로젝트 A에 부하 분산기의 프런트엔드 및 URL 맵이 생성되고 URL 맵이 서비스 프로젝트 B의 백엔드 서비스를 참조하는 배포의 예시입니다.

이 경우 서비스 프로젝트 A의 네트워크 관리자나 부하 분산기 관리자가 서비스 프로젝트 B의 백엔드 서비스에 액세스해야 합니다. 서비스 프로젝트 B 관리자는 서비스 프로젝트 B의 백엔드 서비스를 참조하려는 서비스 프로젝트 A의 부하 분산기 관리자에게 compute.loadBalancerServiceUser IAM 역할을 부여합니다.

예시 2: 호스트 프로젝트의 부하 분산기 프런트엔드 및 서비스 프로젝트의 백엔드

이 유형의 배포에서는 부하 분산기의 프런트엔드 및 URL 맵이 호스트 프로젝트에 생성되고 백엔드 서비스(및 백엔드)는 서비스 프로젝트에 생성됩니다.

이 경우 호스트 프로젝트의 네트워크 관리자나 부하 분산기 관리자가 서비스 프로젝트의 백엔드 서비스에 액세스해야 합니다. 서비스 프로젝트 관리자는 서비스 프로젝트의 백엔드 서비스를 참조하려는 호스트 프로젝트 A의 부하 분산기 관리자에게 compute.loadBalancerServiceUser IAM 역할을 부여합니다.

연결 작동 방식

전역 외부 애플리케이션 부하 분산기 연결

전역 외부 애플리케이션 부하 분산기는 Google 프런트엔드(GFE)라고 하는 여러 프록시에 의해 구현됩니다. 단일 프록시는 없습니다. 프리미엄 등급에서는 동일한 전역 외부 IP 주소가 다양한 접속 지점에서 공지되며 클라이언트 요청은 클라이언트에서 가장 가까운 GFE로 전달됩니다.

클라이언트 위치에 따라 여러 GFE에서 백엔드에 대한 HTTP(S) 연결을 시작할 수 있습니다. GFE에서 전송된 패킷에는 상태 점검 프로버에서 사용하는 동일한 범위(35.191.0.0/16 및 130.211.0.0/22)의 소스 IP 주소가 포함됩니다.

백엔드 서비스 구성에 따라 각 GFE에서 백엔드에 연결하는 데 사용하는 프로토콜은 HTTP, HTTPS 또는 HTTP/2일 수 있습니다. HTTP 또는 HTTPS 연결에서 사용되는 HTTP 버전은 HTTP 1.1입니다.

HTTP 연결 유지는 HTTP 1.1 사양에서 지정된 대로 기본적으로 사용 설정됩니다. HTTP 연결 유지는 동일한 TCP 세션을 효율적으로 사용하려고 하지만 보장되지는 않습니다. GFE는 클라이언트 HTTP 연결 유지 제한 시간 610초와 기본 백엔드 연결 유지 제한 시간 값 600초를 사용합니다. 클라이언트 HTTP 연결 유지 제한 시간을 업데이트할 수 있지만 백엔드 연결 유지 제한 시간 값은 고정되어 있습니다. 백엔드 서비스 제한 시간을 설정하여 요청/응답 제한 시간을 구성할 수 있습니다. 밀접하게 관련되어 있지만 HTTP 연결 유지와 TCP 유휴 상태 제한 시간은 동일하지 않습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.

트래픽이 고르게 분산되도록 부하 분산기에서 Connection: close 헤더가 포함된 응답을 완료한 후 FIN ACK 패킷을 전송하여 TCP 연결을 완전히 닫거나 응답을 완료한 후 HTTP/2 GOAWAY 프레임을 실행할 수 있습니다. 이 동작은 활성 요청 또는 응답을 방해하지 않습니다.

HTTP 연결과 TCP 세션의 수는 연결하는 GFE 수, GFE에 연결하는 클라이언트 수, 백엔드에 대한 프로토콜, 백엔드가 배포된 위치에 따라 달라집니다.

자세한 내용은 솔루션 가이드 전역 부하 분산을 사용한 애플리케이션 용량 최적화의 외부 애플리케이션 부하 분산기의 작동 방식을 참조하세요.

리전 외부 애플리케이션 부하 분산기 연결

리전 외부 애플리케이션 부하 분산기는 Envoy 프록시에 구현된 관리형 서비스입니다. 리전 외부 애플리케이션 부하 분산기는 프록시 전용 서브넷이라는 공유 서브넷을 사용하여 Google에서 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 프로비저닝합니다. 이 프록시 전용 서브넷의 --purpose 플래그는 REGIONAL_MANAGED_PROXY로 설정됩니다. 특정 네트워크와 리전의 모든 리전 Envoy 기반 부하 분산기가 이 서브넷을 공유합니다.

클라이언트는 부하 분산기의 IP 주소와 포트를 사용하여 부하 분산기에 연결합니다. 클라이언트와 동일한 리전에 있는 프록시 전용 서브넷으로 클라이언트 요청이 전달됩니다. 부하 분산기에서 클라이언트 요청을 종료한 후 프록시 전용 서브넷에서 백엔드로 새 연결을 엽니다. 따라서 부하 분산기에서 전송된 패킷에는 프록시 전용 서브넷의 소스 IP 주소가 포함됩니다.

백엔드 서비스 구성에 따라 Envoy 프록시에서 백엔드에 연결하는 데 사용하는 프로토콜은 HTTP, HTTPS 또는 HTTP/2일 수 있습니다. HTTP 또는 HTTPS이면 HTTP 버전은 HTTP 1.1입니다. HTTP 연결 유지는 HTTP 1.1 사양에서 지정된 대로 기본적으로 사용 설정됩니다. Envoy 프록시는 클라이언트 HTTP 연결 유지 제한 시간과 백엔드 연결 유지 제한 시간을 기본 값인 각각 600초로 설정합니다. 클라이언트 HTTP 연결 유지 제한 시간을 업데이트할 수 있지만 백엔드 연결 유지 제한 시간 값은 고정되어 있습니다. 백엔드 서비스 제한 시간을 설정하여 요청/응답 제한 시간을 구성할 수 있습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.

부하 분산기와의 클라이언트 통신

• 클라이언트는 HTTP 1.1 또는 HTTP/2 프로토콜을 사용하여 부하 분산기와 통신할 수 있습니다.
• HTTPS를 사용하면 최신 클라이언트는 HTTP/2로 기본 설정됩니다. 이는 HTTPS 부하 분산기가 아니라 클라이언트에서 제어됩니다.
• 부하 분산기에서 구성을 변경하여 HTTP/2를 사용 중지할 수는 없습니다. 하지만 일부 클라이언트는 HTTP/2 대신 HTTP 1.1을 사용하도록 구성할 수 있습니다. 예를 들어 curl과 함께 --http1.1 매개변수를 사용합니다.
• 외부 애플리케이션 부하 분산기는 HTTP/1.1 100 Continue 응답을 지원합니다.

각 모드의 외부 애플리케이션 부하 분산기 전달 규칙에서 지원하는 프로토콜의 전체 목록은 부하 분산기 기능을 참조하세요.

클라이언트 패킷의 소스 IP 주소

백엔드에서 인식하는 패킷의 소스 IP 주소는 부하 분산기의 Google Cloud 외부 IP 주소가 아닙니다. 다시 말해 TCP 연결이 두 개 있습니다.

• 원래 클라이언트에서 부하 분산기(GFE)로의 연결 1:

  • 소스 IP 주소: 원래 클라이언트(또는 클라이언트가 NAT 또는 전달 프록시 뒤에 있는 경우 외부 IP 주소)입니다.
  • 대상 IP 주소: 부하 분산기의 IP 주소입니다.

• 부하 분산기(GFE)에서 백엔드 VM 또는 엔드포인트로의 연결 2:

  • 소스 IP 주소: IP 주소는 방화벽 규칙에 지정된 범위 중 하나입니다.

  • 대상 IP 주소: VPC 네트워크의 백엔드 VM 또는 컨테이너의 내부 IP 주소입니다.

• 원래 클라이언트에서 부하 분산기(프록시 전용 서브넷)로의 연결 1:

  • 소스 IP 주소: 원래 클라이언트(또는 클라이언트가 NAT 또는 전달 프록시 뒤에 있는 경우 외부 IP 주소)입니다.
  • 대상 IP 주소: 부하 분산기의 IP 주소입니다.

• 부하 분산기(프록시 전용 서브넷)에서 백엔드 VM 또는 엔드포인트로의 연결 2:

  • 소스 IP 주소: 동일한 리전 및 네트워크에 부하 분산기로 배포된 모든 Envoy 기반 부하 분산기에서 공유되는 프록시 전용 서브넷의 IP 주소입니다.

  • 대상 IP 주소: VPC 네트워크의 백엔드 VM 또는 컨테이너의 내부 IP 주소입니다.

특수 라우팅 경로

Google Cloud는 VPC 네트워크에 정의되지 않은 특수 경로를 사용하여 다음 유형의 트래픽에 대한 패킷을 라우팅합니다.

• 상태 점검의 경우 분산 Envoy 상태 점검을 제외합니다. 자세한 내용은 상태 점검 경로를 참조하세요.

• 전역 외부 애플리케이션 부하 분산기 및 기존 애플리케이션 부하 분산기의 GFE와 백엔드 사이. 자세한 내용은 Google 프런트엔드와 백엔드 사이의 경로를 참조하세요.

Google Cloud는 프록시 전용 서브넷의 서브넷 경로를 사용하여 다음과 같은 유형의 트래픽에 대한 패킷을 라우팅합니다.

• 분산형 Envoy 상태 점검을 사용하는 경우.

리전 외부 애플리케이션 부하 분산기에서는 Google Cloud가 오픈소스 Envoy 프록시를 사용하여 부하 분산기에 대한 클라이언트 요청을 종료합니다. 부하 분산기가 TCP 세션을 종료하고 리전의 프록시 전용 서브넷에서 백엔드로 새 TCP 세션을 엽니다. VPC 네트워크 내에 정의된 경로가 Envoy 프록시와 백엔드의 상호 통신을 지원합니다.

열린 포트

GFE에는 동일한 아키텍처에서 실행되는 다른 Google 서비스를 지원하는 열린 포트가 여러 개 있습니다. 포트 스캔을 실행하면 GFE에서 실행되는 다른 Google 서비스에 대한 다른 열린 포트가 표시될 수 있습니다.

다음과 같은 이유로 GFE 기반 부하 분산기의 IP 주소에 포트 스캔을 실행하는 것은 감사 측면에서 유용하지 않습니다.

• 포트 스캔(예: nmap 사용)에서는 일반적으로 TCP SYN 프로브를 수행할 때 응답 패킷이나 TCP RST 패킷을 예상하지 않습니다. GFE는 전달 규칙을 구성한 포트에만 SYN 프로브에 대한 응답으로 SYN-ACK 패킷을 전송합니다. GFE는 부하 분산기의 IP 주소 및 이 전달 규칙에 구성된 목적지 포트로 전송된 패킷에 대한 응답으로만 패킷을 백엔드로 전송합니다. 다른 IP 주소나 포트로 전송되는 패킷은 백엔드로 전송되지 않습니다.

  GFE는 Google Cloud Armor와 같은 보안 기능을 구현합니다. GFE는 Google Cloud Armor 표준을 사용하여 볼륨 및 프로토콜 기반 DDoS 공격과 SYN 플러드로부터 상시 보호 기능을 제공합니다. Google Cloud Armor를 명시적으로 구성하지 않은 경우에도 이 보호 기능을 사용할 수 있습니다. 보안 정책을 구성하거나 Managed Protection 플러스에 등록한 경우에만 요금이 청구됩니다.

• 부하 분산기의 IP 주소로 전송되는 패킷은 Google Fleet의 모든 GFE가 응답할 수 있습니다. 하지만 부하 분산기 IP 주소와 목적지 포트 조합을 스캔하면 TCP 연결당 GFE 1개만 조사됩니다. 부하 분산기의 IP 주소는 단일 기기 또는 시스템에 할당되지 않습니다. 따라서 GFE 기반 부하 분산기의 IP 주소를 스캔해도 Google Fleet에 있는 모든 GFE가 스캔되지 않습니다.

이러한 점을 고려하여 백엔드 인스턴스의 보안을 감사하는 효과적인 방법을 몇 가지 소개합니다.

• 보안 감사자는 부하 분산기 구성의 전달 규칙 구성을 검사해야 합니다. 전달 규칙에서는 부하 분산기가 패킷을 수락하여 백엔드로 전달하는 대상 포트를 정의합니다. GFE 기반 부하 분산기의 경우 외부 전달 규칙마다 하나의 대상 TCP 포트만 참조할 수 있습니다. TCP 포트 443을 사용하는 부하 분산기에서는 연결이 QUIC(HTTP/3)로 업그레이드되면 UDP 포트 443이 사용됩니다.

• 보안 감사자는 백엔드 VM에 적용 가능한 방화벽 규칙 구성을 검사해야 합니다. 설정한 방화벽 규칙은 GFE에서 백엔드 VM으로 들어오는 트래픽을 차단하지만 GFE로 들어오는 트래픽은 차단하지 않습니다. 권장사항은 방화벽 규칙 섹션을 참조하세요.

TLS 종료

다음 표에는 각 모드의 외부 애플리케이션 부하 분산기가 TLS 종료를 처리하는 방법이 요약되어 있습니다.

제한시간 및 재시도

백엔드 서비스 제한 시간

구성 가능한 백엔드 서비스 제한 시간은 부하 분산기에서 백엔드가 HTTP 요청을 처리하고 해당 HTTP 응답을 반환할 때까지 기다리는 최대 시간을 나타냅니다. 서버리스 NEG를 제외하고 백엔드 서비스 제한 시간의 기본값은 30초입니다.

예를 들어 500MB 파일을 다운로드하려는데 백엔드 서비스 제한 시간이 90초라면 부하 분산기는 백엔드가 500MB 파일 전체를 90초 이내에 전송할 것으로 예상합니다. 백엔드가 전체 HTTP 응답을 보내지 못할 정도로 짧게 백엔드 서비스 제한 시간을 구성할 수 있습니다. 이 경우 부하 분산기에 백엔드로부터의 HTTP 응답 헤더가 최소한 한 개 이상 있으면 부하 분산기가 전체 응답 헤더와 백엔드 서비스 제한 시간 내에 가능할 만큼 응답 본문을 반환합니다.

백엔드 서비스 제한 시간을 백엔드가 HTTP 응답을 처리하는 데 필요한 가장 긴 시간으로 설정해야 합니다. 백엔드에서 실행 중인 소프트웨어가 HTTP 요청을 처리하고 전체 응답을 반환하는 데 더 많은 시간이 필요한 경우 백엔드 서비스 제한 시간을 늘려야 합니다. 예를 들어 jsonPayload.statusDetail client_timed_out으로 HTTP 408 응답이 표시되면 제한 시간을 늘려야 합니다.

백엔드 서비스 제한 시간은 1~2,147,483,647초 사이의 값을 허용하지만 큰 값은 실용적인 구성 옵션이 아닙니다. 또한 Google Cloud는 기본 TCP 연결이 백엔드 서비스 제한 시간 값의 전체 기간 동안 열린 상태로 유지됨을 보장하지 않습니다. 전역 및 기존 애플리케이션 부하 분산기의 경우 GFE는 효과적인 최대 백엔드 서비스 제한 시간으로 86,400초(1일)를 적용합니다. 클라이언트 시스템은 TCP 연결을 사용하여 장시간 열어 두는 대신 재시도 로직을 구현해야 합니다.

백엔드 서비스 제한 시간을 구성하려면 다음 방법 중 하나를 사용하세요.

• Google Cloud 콘솔: 부하 분산기 백엔드 서비스의 제한 시간 필드를 수정합니다.
• Google Cloud CLI: gcloud compute backend-services update 명령어를 사용하여 백엔드 서비스 리소스의 --timeout 매개변수를 수정합니다.
• API: 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 경우 전역 backendServices 리소스에 대해 timeoutSec 매개변수를 수정합니다.
• API: 리전 외부 애플리케이션 부하 분산기의 경우 regionBackendServices 리소스의 timeoutSec 매개변수를 수정합니다.

리전 외부 애플리케이션 부하 분산기는 URL 맵의 구성된 routeActions.timeout 매개변수를 사용하고 백엔드 서비스 제한 시간을 무시합니다. routeActions.timeout이 구성되지 않으면 백엔드 서비스 제한 시간 값이 사용됩니다. routeActions.timeout이 제공되면 백엔드 서비스 제한 시간이 무시되고 대신 routeActions.timeout 값이 요청 및 응답 제한 시간으로 사용됩니다.

클라이언트 HTTP 연결 유지 제한 시간

클라이언트 HTTP 연결 유지 제한 시간은 (다운스트림) 클라이언트와 다음 유형의 프록시 중 하나 사이에 TCP 연결이 유휴 상태가 될 수 있는 최대 시간을 나타냅니다.

• 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기: 첫 번째 레이어 Google 프런트엔드
• 리전 외부 애플리케이션 부하 분산기: Envoy 프록시

HTTP 연결 유지 제한 시간은 기본 TCP 연결의 TCP 유휴 상태 제한 시간을 나타냅니다. 클라이언트 HTTP 연결 유지 제한 시간은 WebSocket에 적용되지 않습니다.

• 전역 외부 애플리케이션 부하 분산기의 기본값은 610초입니다. 클라이언트 HTTP 연결 유지 제한 시간을 5~1,200초 사이의 값으로 구성할 수 있습니다.
• 기본 애플리케이션 부하 분산기의 경우 클라이언트 HTTP 연결 유지 제한 시간이 610초로 고정됩니다.
• 리전 외부 애플리케이션 부하 분산기의 경우 클라이언트 HTTP 연결 유지 제한 시간이 600초로 고정됩니다.

연결 유지 제한 시간 매개변수를 구성하려면 다음 방법 중 하나를 사용하세요.

• Google Cloud 콘솔: 부하 분산기 프런트엔드 구성의 HTTP 연결 유지 제한 시간 필드를 수정합니다.
• Google Cloud CLI: gcloud compute target-http-proxies update 명령어 또는 gcloud compute target-https-proxies update 명령어를 사용하여 대상 HTTP 프록시 또는 대상 HTTPS 프록시 리소스의 --http-keep-alive-timeout-sec 매개변수를 수정합니다.
• API: targetHttpProxies 리소스 또는 targetHttpsProxies 리소스의 httpKeepAliveTimeoutSec 매개변수를 수정합니다.

부하 분산기의 클라이언트 HTTP 연결 유지 제한 시간은 다운스트림 클라이언트 또는 프록시에서 사용하는 HTTP 연결 유지(TCP 유휴 상태) 제한 시간보다 커야 합니다. 다운스트림 클라이언트의 HTTP 연결 유지(TCP 유휴 상태) 제한 시간이 부하 분산기의 클라이언트 HTTP 연결 유지 제한 시간보다 길면 경합 상태가 발생할 수 있습니다. 다운스트림 클라이언트의 관점에서 설정된 TCP 연결은 부하 분산기에서 허용하는 것보다 유휴 상태를 더 오랫동안 허용됩니다. 즉, 부하 분산기가 TCP 연결이 종료된 것으로 간주하면 다운스트림 클라이언트는 패킷을 전송할 수 있습니다. 이 경우 부하 분산기는 TCP 재설정(RST) 패킷으로 응답합니다.

백엔드 HTTP 연결 유지 제한 시간

외부 애플리케이션 부하 분산기는 2개 이상의 TCP 연결을 사용하는 프록시입니다.

• 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 경우 (다운스트림) 클라이언트와 첫 번째 레이어 GFE 사이에 첫 번째 TCP 연결이 존재합니다. 첫 번째 레이어 GFE가 두 번째 레이어 GFE에 연결하면 두 번째 레이어 GFE에서 백엔드에 대한 두 번째 TCP 연결을 엽니다.

• 리전 외부 애플리케이션 부하 분산기의 경우 (다운스트림) 클라이언트와 Envoy 프록시 사이에 첫 번째 TCP 연결이 존재합니다. 그러면 Envoy 프록시가 백엔드에 대한 두 번째 TCP 연결을 엽니다.

각 요청 후 부하 분산기의 보조 TCP 연결이 닫히지 않을 수 있습니다. 개방형 상태로 유지하여 여러 HTTP 요청 및 응답을 처리할 수 있습니다. 백엔드 HTTP 연결 유지 제한 시간 제한은 TCP 부하 분산기와 백엔드 간의 TCP 유휴 상태 제한 시간을 정의합니다. 백엔드 HTTP 연결 유지 제한 시간은 WebSocket에 적용되지 않습니다.

백엔드 연결 유지 제한 시간은 10분(600초)으로 고정되며 변경할 수 없습니다. 부하 분산기의 백엔드 연결 유지 제한 시간은 백엔드에서 실행되는 소프트웨어에서 사용하는 연결 유지 제한 시간보다 짧아야 합니다. 이렇게 하면 백엔드의 운영체제가 TCP 재설정(RST)으로 TCP 연결을 종료할 가능성이 있는 경합 상태가 방지됩니다. 부하 분산기의 백엔드 연결 유지 제한 시간을 구성할 수 없으므로 HTTP 연결 유지(TCP 유휴 상태) 제한 시간 값이 600초를 초과하도록 백엔드 소프트웨어를 구성해야 합니다.

다음 표에서는 일반적인 웹 서버 소프트웨어의 연결 유지 제한 시간 값을 수정할 때 필요한 변경사항을 보여줍니다.

QUIC 세션 유휴 제한 시간

QUIC 세션 유휴 제한 시간은 클라이언트와 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 GFE 사이에 QUIC 세션이 유휴 상태일 수 있는 최대 시간을 나타냅니다.

QUIC 세션 유휴 제한 시간 값은 클라이언트 유휴 제한 시간 또는 GFE 유휴 제한 시간(300초)의 최솟값으로 정의됩니다. GFE 유휴 제한 시간은 300초로 고정되어 있습니다. 클라이언트 유휴 제한 시간을 구성할 수 있습니다.

재시도

재시도 로직 지원은 외부 애플리케이션 부하 분산기의 모드에 따라 다릅니다.

WebSocket 프로토콜은 GKE 인그레스를 사용하여 지원됩니다.

잘못된 요청 및 응답 처리

부하 분산기는 여러 가지 이유로 클라이언트 요청과 백엔드 응답이 각각 백엔드 또는 클라이언트에 도달하지 못하도록 차단합니다. 이러한 이유로는 HTTP/1.1 준수를 위한 이유도 있고 예기치 않은 데이터가 백엔드로 또는 백엔드에서 전달되는 것을 방지하기 위한 이유도 있습니다. 사용 중지할 수 있는 검사가 없습니다.

부하 분산기는 HTTP/1.1 규정 준수를 위해 다음 요청과 같은 경우 차단을 수행합니다.

• 요청의 첫 번째 줄을 파싱할 수 없습니다.
• 헤더에 콜론(:) 구분 기호가 없습니다.
• 헤더 또는 첫 번째 줄에 잘못된 문자가 있습니다.
• 콘텐츠 길이가 유효한 숫자가 아니거나 콘텐츠 길이 헤더가 여러 개입니다.
• 전송 인코딩 키가 여러 개 있거나 인식할 수 없는 전송 인코딩 값이 존재합니다.
• 분할되지 않은 본문이 있으며 콘텐츠 길이가 지정되지 않았습니다.
• 본문 단위를 파싱할 수 없습니다. 이는 일부 데이터가 백엔드에 도달하는 유일한 경우입니다. 부하 분산기는 파싱할 수 없는 청크를 수신하면 클라이언트 및 백엔드와의 연결을 닫습니다.

요청 처리

다음 중 하나라도 해당하면 부하 분산기가 요청을 차단합니다.

• 요청 헤더와 요청 URL의 총 크기가 외부 애플리케이션 부하 분산기의 최대 요청 헤더 크기 한도를 초과합니다.
• 요청 메서드가 본문을 허용하지 않지만 요청에 본문이 존재합니다.
• 요청에 Upgrade 헤더가 포함되어 있고 WebSocket 연결을 사용 설정하기 위해 Upgrade 헤더가 사용되지 않습니다.
• HTTP 버전을 알 수 없습니다.

응답 처리

다음 중 하나라도 해당하면 부하 분산기가 백엔드의 응답을 차단합니다.

• 응답 헤더의 총 크기가 외부 애플리케이션 부하 분산기의 최대 응답 헤더 크기 한도를 초과합니다.
• HTTP 버전을 알 수 없습니다.

요청과 응답을 모두 처리할 때 부하 분산기는 HTTP/1.1에서 홉별 헤더를 삭제하거나 덮어쓰기한 후 대상에 전달할 수 있습니다.

트래픽 분산

백엔드 인스턴스 그룹 또는 NEG를 백엔드 서비스에 추가할 때 백엔드 로드 및 대상 용량을 측정하는 방법을 정의하는 분산 모드를 지정합니다. 외부 애플리케이션 부하 분산기는 다음과 같은 두 가지 분산 모드를 지원합니다.

• 인스턴스 그룹 또는 NEG의 경우 RATE는 초당 최대 대상 요청(쿼리) 수(RPS, QPS)입니다. 모든 최대 백엔드가 용량에 도달하거나 용량을 초과할 경우 대상 최대 RPS/QPS를 초과할 수 있습니다.

• UTILIZATION은 인스턴스 그룹에 있는 VM의 백엔드 사용률입니다.

백엔드 간에 트래픽이 분산되는 방식은 부하 분산기의 모드에 따라 다릅니다.

전역 외부 애플리케이션 부하 분산기

Google 프런트엔드(GFE)가 요청을 백엔드 인스턴스로 전송하기 전에 GFE는 요청을 수신할 수 있는 백엔드 인스턴스를 예측합니다. 이 용량 예측은 요청이 도착하는 시점이 아니라 사전에 수행됩니다. GFE는 사용 가능한 용량에 대한 주기적인 정보를 받고 그에 따라 들어오는 요청을 분산합니다.

용량의 의미는 부분적으로 분산 모드에 따라 다릅니다. RATE 모드에서는 비교적 간단합니다. GFE는 초당 할당할 수 있는 요청 수를 정확하게 결정합니다. UTILIZATION 기반 부하 분산은 좀 더 복잡합니다. 부하 분산기는 인스턴스의 현재 사용률을 확인한 후 각 인스턴스에서 처리할 수 있는 쿼리 부하를 추정합니다. 이 예상치는 인스턴스 사용률 및 트래픽 패턴이 변경되는 것처럼 시간이 경과하면 변경됩니다.

용량 예측과 사전 할당 등 두 가지 요인 모두 인스턴스 간 분포에 영향을 미칩니다. 따라서 Cloud Load Balancing은 두 인스턴스 간에 요청을 정확하게 50:50으로 분산하는 간단한 라운드 로빈 부하 분산기와 다르게 동작합니다. 대신 Google Cloud 부하 분산은 각 요청에 대한 백엔드 인스턴스 선택을 최적화하려고 합니다.

전역 외부 애플리케이션 부하 분산기의 경우 부하 분산은 2계층입니다. 분산 모드에 따라 각 백엔드(인스턴스 그룹 또는 NEG)로 전송되어야 할 트래픽의 가중치 또는 비율이 결정됩니다. 그런 다음 부하 분산 정책(LocalityLbPolicy)에 따라 그룹 내 인스턴스 또는 엔드포인트에 트래픽이 분산되는 방식이 결정됩니다. 자세한 내용은 부하 분산 지역 정책(백엔드 서비스 API 문서)을 참조하세요.

기본 애플리케이션 부하 분산기의 경우 가장 선호하는 백엔드(인스턴스 그룹 또는 NEG)를 선택하기 위해 분산 모드가 사용됩니다. 그러면 트래픽은 백엔드 내에서 인스턴스 또는 엔드포인트 간에 라운드 로빈 방식으로 분산됩니다.

요청 분산 방법

GFE 기반 외부 애플리케이션 부하 분산기는 다음 프로세스를 사용하여 수신 요청을 분산합니다.

1. 클라이언트에서 첫 번째 레이어 GFE까지. 에지 라우터는 Google 네트워크 경계에 있는 전달 규칙의 외부 IP 주소를 공지합니다. 각 공지는 레이어 3/4 부하 분산 시스템(Maglev)에 대한 다음 홉을 나열합니다. Maglev 시스템은 트래픽을 첫 번째 레이어 Google 프런트엔드(GFE)로 라우팅합니다.
   • 프리미엄 등급을 사용하는 경우 Google은 전 세계 모든 접속 지점에서 부하 분산기의 IP 주소를 공지합니다. 각 부하 분산기 IP 주소는 전역 애니캐스트입니다.
   • 표준 등급을 사용하는 경우 Google은 전달 규칙의 리전과 연결된 접속 지점에서 부하 분산기의 IP 주소를 공지합니다. 부하 분산기에서 리전 외부 IP 주소를 사용합니다. 표준 등급 전달 규칙을 사용하면 부하 분산기의 전달 규칙과 동일한 리전에 있는 인스턴스 그룹 및 영역 NEG 백엔드로 제한됩니다.
2. 첫 번째 레이어 GFE에서 두 번째 레이어 GFE로. 첫 번째 레이어 GFE에서 필요한 경우 TLS를 종료한 후 이 프로세스에 따라 두 번째 레이어 GFE로 트래픽을 라우팅합니다.
   • 첫 번째 레이어 GFE는 URL 맵을 파싱하고 백엔드 서비스 또는 백엔드 버킷을 선택합니다.
   • 인터넷 NEG가 있는 백엔드 서비스의 경우 첫 번째 레이어 GFE가 첫 번째 레이어 GFE와 같은 위치에 있는 두 번째 레이어 외부 전달 게이트웨이를 선택합니다. 전달 게이트웨이가 인터넷 NEG 엔드포인트로 요청을 전송합니다. 그러면 인터넷 NEG의 요청 배포 프로세스가 완료됩니다.
   • 서버리스 NEG, Private Service Connect(PSC) NEG, 백엔드 버킷이 있는 백엔드 서비스의 경우 첫 번째 레이어 GFE는 NEG 또는 버킷의 리전과 일치하는 리전에서 두 번째 레이어 GFE를 선택합니다. 멀티 리전 Cloud Storage 버킷의 경우 첫 번째 레이어 GFE는 첫 번째 레이어 GFE(네트워크 왕복 시간으로 정의됨)에 가장 가까운 리전에서 두 번째 레이어 GFE를 선택합니다.
   • 인스턴스 그룹이 있는 백엔드 서비스, GCE_VM_IP_PORT 엔드포인트가 있는 영역 NEG, 하이브리드 NEG의 경우 Google의 용량 관리 시스템은 첫 번째 레이어 GFE에 각 백엔드의 사용 및 구성된 용량을 알립니다. 백엔드에 구성된 용량은 분산 모드, 분산 모드의 대상 용량 및 용량 확장 처리로 정의됩니다.
     • 표준 등급: 첫 번째 레이어 GFE가 백엔드가 포함된 리전에서 두 번째 레이어 GFE를 선택합니다.
     • 프리미엄 등급: 첫 번째 레이어 GFE는 적용 가능한 리전 집합에서 두 번째 레이어 GFE를 선택합니다. 적용 가능한 리전은 백엔드가 구성된 모든 리전이며 용량이 0인 백엔드가 구성된 리전은 제외됩니다. 첫 번째 레이어 GFE는 해당 리전에서 가장 가까운 두 번째 레이어 GFE를 선택합니다(네트워크 왕복 시간으로 정의됨). 백엔드가 두 개 이상의 리전에 구성된 경우 첫 번째 선택 리전이 가득 차면 첫 번째 레이어 GFE가 다른 적용 가능한 리전으로 요청을 스필링할 수 있습니다. 첫 번째 선택 리전의 모든 백엔드가 용량에 도달하면 다른 리전으로 스필오버할 수 있습니다.
3. 두 번째 레이어 GFE가 백엔드를 선택합니다. 두 번째 레이어 GFE는 리전의 영역에 있습니다. 다음 프로세스를 사용하여 백엔드를 선택합니다.
   • 서버리스 NEG, Private Service Connect NEG, 백엔드 버킷이 있는 백엔드 서비스의 경우 두 번째 레이어 GFE가 요청을 Google의 프로덕션 시스템으로 전달합니다. 그러면 백엔드의 요청 배포 프로세스가 완료됩니다.

   • 인스턴스 그룹이 있는 백엔드 서비스, GCE_VM_IP_PORT 엔드포인트가 있는 영역 NEG, 하이브리드 NEG의 경우 Google의 상태 점검 프로브 시스템은 두 번째 레이어 GFE에 백엔드 인스턴스 또는 엔드포인트의 상태 점검 상태를 알립니다

     프리미엄 등급만 해당: 두 번째 레이어 GFE의 해당 리전에 정상 백엔드 인스턴스나 엔드포인트가 없는 경우 백엔드가 구성된 다른 적용 가능한 리전의 다른 두 번째 레이어 GFE에 요청을 보낼 수 있습니다. 서로 다른 리전의 두 번째 레이어 GFE 간에 스필오버를 수행하면 가능한 모든 리전 간 조합이 소진되지 않습니다. 특정 리전의 백엔드에서 트래픽을 보내야 하는 경우 상태 점검에 실패하도록 백엔드를 구성하는 대신 백엔드의 용량 확장 처리를 0으로 설정하여 첫 번째 레이어 GFE가 이전 단계에서 해당 리전을 제외하도록 해야 합니다.

   그런 다음 두 번째 레이어 GFE가 다음 단계에 설명된 대로 해당 리전 내의 영역에 있는 백엔드 인스턴스 또는 엔드포인트로 요청을 전달합니다.

4. 두 번째 레이어 GFE에서 영역을 선택합니다. 기본적으로 두 번째 레이어 GFE는 WATERFALL_BY_REGION 알고리즘을 사용합니다. 여기서 각 두 번째 레이어 GFE는 두 번째 레이어 GFE가 포함된 영역과 동일한 영역에 있는 백엔드 인스턴스 또는 엔드포인트를 선택하는 것을 선호합니다. WATERFALL_BY_REGION은 영역 간 트래픽을 최소화하므로 요청 비율이 낮기 때문에 각 두 번째 레이어 GFE가 두 번째 레이어 GFE 자체와 동일한 영역에 있는 백엔드에만 요청을 보낼 수 있습니다.

   전역 외부 애플리케이션 부하 분산기의 경우에만 serviceLbPolicy를 사용하여 다음 대체 알고리즘 중 하나를 사용하도록 두 번째 레이어 GFE를 구성할 수 있습니다.

   • SPRAY_TO_REGION: 두 번째 레이어 GFE는 두 번째 레이어 GFE와 동일한 영역에서 백엔드 인스턴스 또는 엔드포인트를 선택하는 것을 선호하지 않습니다. 두 번째 레이어 GFE가 리전의 모든 영역에 있는 모든 백엔드 인스턴스 또는 엔드포인트에 트래픽을 분산하려고 시도합니다. 이렇게 하면 영역 간 트래픽 증가하는 대신 부하가 보다 고르게 분산될 수 있습니다.
   • WATERFALL_BY_ZONE: 두 번째 레이어 GFE가 두 번째 레이어 GFE와 동일한 영역에서 백엔드 인스턴스 또는 엔드포인트를 선택하는 것이 좋습니다. 두 번째 레이어 GFE는 현재 영역의 모든 백엔드가 구성된 용량에 도달한 후에만 다른 영역의 백엔드로 요청을 전달합니다.
5. 두 번째 레이어 GFE가 영역 내에서 인스턴스 또는 엔드포인트를 선택합니다. 기본적으로 두 번째 레이어 GFE가 라운드 로빈 방식으로 요청을 백엔드로 분산합니다. 전역 외부 애플리케이션 부하 분산기의 경우에만 부하 분산 지역 정책(localityLbPolicy)을 사용하여 이를 변경할 수 있습니다. 부하 분산 지역 정책은 이전 단계에서 설명한 선택한 영역 내의 백엔드에만 적용됩니다.

리전 외부 애플리케이션 부하 분산기

리전 외부 애플리케이션 부하 분산기의 경우 트래픽 분산은 부하 분산 모드 및 부하 분산 지역 정책을 기반으로 합니다.

분산 모드에 따라 각 그룹(인스턴스 그룹 또는 NEG)으로 전송되어야 할 트래픽의 가중치 및 비율이 결정됩니다. 부하 분산 지역 정책(LocalityLbPolicy)에 따라 그룹 내 백엔드의 부하 분산 방식이 결정됩니다.

백엔드 서비스가 트래픽을 수신하면 백엔드의 분산 모드에 따라 백엔드(인스턴스 그룹 또는 NEG)로 트래픽을 전달합니다. 백엔드가 선택되면 부하 분산 지역 정책에 따라 해당 백엔드 그룹의 인스턴스 또는 엔드포인트 간에 트래픽이 분산됩니다.

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

• 분산 모드
• 부하 분산 지역 정책(리전 백엔드 서비스 API 문서)

세션 어피니티

세션 어피니티는 백엔드가 정상이고 구성된 분산 모드에 따라 용량이 있는 경우 특정 클라이언트의 요청을 동일한 백엔드로 전송하려고 합니다.

세션 어피니티를 사용하는 경우 UTILIZATION보다는 RATE 분산 모드를 사용하는 것이 좋습니다. 세션 어피니티는 분산 모드를 초당 요청 수(RPS)로 설정할 경우 가장 잘 작동합니다.

외부 애플리케이션 부하 분산기는 다음 유형의 세션 어피니티를 제공합니다.

• 없음. 부하 분산기에 세션 어피니티가 설정되지 않았습니다.
• 클라이언트 IP 어피니티
• 생성된 쿠키 어피니티
• 헤더 필드 어피니티
• HTTP 쿠키 어피니티
• 스테이트풀(Stateful) 세션 쿠키 어피니티

다음 표에는 각 모드의 외부 애플리케이션 부하 분산기에서 지원되는 세션 어피니티 옵션이 요약되어 있습니다.

고가용성 및 장애 조치

외부 애플리케이션 부하 분산기의 고가용성 및 장애 조치는 부하 분산기 수준에서 구성할 수 있습니다. 이는 백업이 필요한 모든 리전에서 백업 리전 외부 애플리케이션 부하 분산기를 만들어 처리합니다.

다음 표에서는 각 모드의 장애 조치 동작을 설명합니다.

HTTP/2 지원

HTTP/2는 HTTP/1 프로토콜의 주 버전입니다. HTTP/2는 클라이언트와 외부 애플리케이션 부하 분산기 간의 연결 및 부하 분산기와 해당 백엔드 간의 연결에 지원됩니다.

부하 분산기는 자동으로 ALPN TLS 확장을 사용하여 TLS 핸드셰이크의 일부로 클라이언트와 HTTP/2를 협상합니다. 부하 분산기가 HTTPS를 사용하도록 구성되어 있어도 최신 클라이언트는 HTTP/2로 기본 설정됩니다. 이는 부하 분산기가 아니라 클라이언트 측에서 제어됩니다.

클라이언트가 HTTP/2를 지원하지 않고 부하 분산기가 부하 분산기와 백엔드 인스턴스 간에 HTTP/2를 사용하도록 구성된 경우에도 부하 분산기는 여전히 HTTPS 연결을 협상하거나 안전하지 않은 HTTP 요청을 수락할 수 있습니다. 그런 다음 부하 분산기에서 이러한 HTTPS 또는 HTTP 요청을 변환하여 HTTP/2를 통해 해당 요청을 백엔드 인스턴스에 대해 프록시 처리합니다.

HTTP/2를 사용하려면 백엔드에서 TLS를 사용 설정해야 합니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.

HTTP/2 최대 동시 스트림

HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS 설정은 동종 앱에서 시작한 엔드포인트가 허용하는 최대 스트림 수를 설명합니다. HTTP/2 클라이언트에서 Google Cloud 부하 분산기로 공지하는 값은 부하 분산기가 클라이언트로 스트림을 시작하지 않으므로 실질적으로 의미가 없습니다.

부하 분산기가 HTTP/2를 사용하여 VM에서 실행 중인 서버와 통신하는 경우 부하 분산기는 서버에서 공지한 SETTINGS_MAX_CONCURRENT_STREAMS 값을 준수합니다. 값 0이 공지되면 부하 분산기가 요청을 서버에 전달할 수 없으므로 오류가 발생할 수 있습니다.

HTTP/2 제한사항

• 부하 분산기와 인스턴스 사이의 HTTP/2에는 HTTP(S)보다 인스턴스에 훨씬 더 많은 TCP 연결이 필요할 수 있습니다. HTTP(S)와의 연결 수를 줄이는 최적화 방법인 연결 풀링은 현재 HTTP/2에서 사용할 수 없습니다. 따라서 백엔드 연결이 더 자주 수행되기 때문에 백엔드 지연 시간이 길어질 수 있습니다.
• 부하 분산기와 백엔드 간의 HTTP/2는 HTTP/2 연결의 단일 스트림(RFC 8441)을 통한 WebSocket 프로토콜 실행을 지원하지 않습니다.
• 부하 분산기와 백엔드 간의 HTTP/2는 서버 푸시를 지원하지 않습니다.
• gRPC 오류율과 요청 볼륨은 Google Cloud API 또는 Google Cloud 콘솔에 표시되지 않습니다. gRPC 엔드포인트가 오류를 반환하면 부하 분산기 로그 및 모니터링 데이터에 OK 200 HTTP 응답 코드가 보고됩니다.

HTTP/3 지원

HTTP/3은 차세대 인터넷 프로토콜입니다. 원본 Google QUIC 프로토콜에서 개발한 프로토콜인 IETF QUIC를 기반으로 합니다. HTTP/3은 외부 애플리케이션 부하 분산기, Cloud CDN, 클라이언트 사이에서 지원됩니다.

구체적으로는 다음과 같습니다.

• IETF QUIC는 TCP와 유사한 정체 제어 및 안정성을 제공하고 보안 및 향상된 성능을 위해 TLS 1.3을 사용하는 전송 계층 프로토콜입니다.
• HTTP/3은 IETF QUIC를 기반으로 빌드된 애플리케이션 레이어이며 다중화, 정체 제어, 손실 감지, 재전송을 처리하기 위해 QUIC를 사용합니다.
• HTTP/3을 이용하면 클라이언트 연결 초기화 시간을 줄이고 다중화 스트림의 대기 행렬 막힘을 제거할 수 있으며 클라이언트 IP 주소 변경 시 연결 이전을 지원합니다.
• HTTP/3은 부하 분산기와 백엔드가 아니라, 클라이언트와 부하 분산기 간의 연결에 지원됩니다.
• HTTP/3 연결은 BBR 정체 제어 알고리즘을 사용합니다.

부하 분산기에서 HTTP/3은 웹페이지 로드 시간을 개선하고, 동영상 재버퍼링을 줄이고, 지연 시간이 긴 연결의 처리량을 개선할 수 있습니다.

다음 표에서는 각 모드의 외부 애플리케이션 부하 분산기에 대한 HTTP/3 지원을 명시합니다.

HTTP/3 협상 방식

HTTP/3이 사용 설정되면 부하 분산기가 이 지원을 클라이언트에 공지하여 HTTP/3을 지원하는 클라이언트가 HTTPS 부하 분산기로 HTTP/3 연결을 설정하려고 시도할 수 있습니다.

• 올바르게 구현된 클라이언트는 HTTP/3 연결을 설정할 수 없다면 언제나 HTTPS 또는 HTTP/2로 대체합니다.
• HTTP/3을 지원하는 클라이언트는 HTTP/3 지원의 캐시된 사전 지식을 활용하여 향후 불필요한 왕복 횟수를 줄입니다.
• 이러한 대체 기능 덕분에 부하 분산기에서 HTTP/3을 사용 설정하거나 사용 중지해도 부하 분산기가 클라이언트에 연결하는 기능에 방해가 되지 않습니다.

지원은 Alt-Svc HTTP 응답 헤더에 공지됩니다. HTTP/3이 사용 설정되었으면 부하 분산기의 응답에 다음 alt-svc 헤더 값이 포함됩니다.

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

HTTP/3이 명시적으로 DISABLE로 설정된 경우 응답에 alt-svc 응답 헤더가 포함되지 않습니다.

HTTPS 부하 분산기에서 HTTP/3을 사용 설정하면 상황에 따라 클라이언트가 HTTP/3을 협상하는 대신 HTTPS 또는 HTTP/2로 대체할 수 있습니다. 여기에는 다음과 같은 내용이 포함되어 있습니다.

• 클라이언트가 HTTPS 부하 분산기가 지원하는 HTTP/3 버전과 호환되지 않는 HTTP/3 버전을 지원하는 경우
• 부하 분산기가 UDP 트래픽이 차단되거나 비율 제한에 도달하여 HTTP/3이 작동하지 않는 것을 감지하는 경우
• 클라이언트는 HTTP/3을 전혀 지원하지 않으므로 HTTP/3 연결 협상을 시도하지 않습니다.

연결이 HTTPS 또는 HTTP/2로 대체되더라도 이를 부하 분산기의 장애로 간주하지 않습니다.

HTTP/3을 사용 설정하기 전에 앞에서 설명한 동작을 워크로드가 수용할 수 있는지 확인합니다.

HTTP/3 구성

NONE(기본값) 및 ENABLE 모두 부하 분산기에 대해 HTTP/3 지원을 사용 설정합니다.

HTTP/3이 사용 설정되었으면 부하 분산기가 클라이언트에 이를 공지하며, 이를 지원하는 클라이언트가 HTTP/3 버전과 부하 분산기를 협상할 수 있습니다. HTTP/3를 지원하지 않는 클라이언트는 HTTP/3 연결을 협상하지 않습니다. 손상된 클라이언트 구현을 식별하지 않는 한 HTTP/3을 명시적으로 중지할 필요가 없습니다.

외부 애플리케이션 부하 분산기는 다음 표와 같이 HTTP/3을 구성하는 세 가지 방법을 제공합니다.

HTTP/3을 명시적으로 사용 설정(또는 사용 중지)하려면 다음 단계를 따르세요.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

제한사항

• HTTPS 부하 분산기는 SSL 연결을 종료할 때 close_notify 폐쇄 알림을 전송하지 않습니다. 즉, 부하 분산기는 SSL 종료를 수행하는 대신 TCP 연결을 종료합니다.
• HTTPS 부하 분산기는 인증서의 일반 이름(CN) 속성 또는 주체 대체 이름(SAN) 속성에서 도메인에 소문자만 지원합니다. 도메인에 대문자가 포함된 인증서는 대상 프록시에서 기본 인증서로 설정된 경우에만 반환됩니다.
• HTTPS 부하 분산기는 백엔드에 연결할 때 인터넷 NEG 백엔드가 있는 부하 분산기를 제외하고 서버 이름 표시(SNI) 확장 프로그램을 사용하지 않습니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.
• 공유 VPC 환경에서 Cloud Run과 함께 리전 외부 애플리케이션 부하 분산기를 사용하는 경우 서비스 프로젝트의 독립형 VPC 네트워크는 동일한 공유 VPC 환경 내의 다른 서비스 프로젝트에 배포된 다른 Cloud Run 서비스로 트래픽을 보낼 수 있습니다. 이는 알려진 문제이며 향후 이 양식의 액세스가 차단됩니다.
• Google Cloud는 기본 TCP 연결이 백엔드 서비스 제한 시간의 전체 기간 동안 열린 상태로 유지될 수 있는지를 보장하지 않습니다. 클라이언트 시스템은 TCP 연결을 사용하여 장시간 열어 두는 대신 재시도 로직을 구현해야 합니다.
• Google Cloud 콘솔을 사용하여 프리미엄 등급에서 리전 외부 애플리케이션 부하 분산기를 만들 수 없습니다. 또한 Google Cloud 콘솔에서는 이러한 부하 분산기에 표준 등급을 지원하는 리전만 사용할 수 있습니다. 대신 gcloud CLI 또는 API를 사용합니다. 대신 gcloud CLI 또는 API를 사용합니다.
• Cloud CDN을 사용하면 캐시 무효화를 요청하여 캐시에서 객체나 객체 조합을 무시하도록 할 수 있습니다. 기본적으로 공유 VPC 프로젝트 간 서비스 참조가 포함된 전역 외부 애플리케이션 부하 분산기를 사용하는 경우, 서비스 프로젝트 관리자에게는 캐시 무효화를 요청하는 데 필요한 권한이 없습니다. 이는 캐시 무효화가 프런트엔드 프로젝트(즉, 부하 분산기의 전달 규칙, 대상 프록시, URL 맵을 포함하는 프로젝트)에서 구성되기 때문입니다. 따라서 프런트엔드 프로젝트에서 부하 분산기 관련 리소스를 구성하는 IAM 역할(예: Compute 네트워크 관리자 역할)이 있는 주 구성원만 캐시 무효화를 수행할 수 있습니다. 개별 프로젝트에서 백엔드 서비스 프로비저닝을 제어하는 서비스 관리자는 프런트엔드 프로젝트의 부하 분산기 관리자와 협력하여 프로젝트 간 서비스의 캐시 무효화를 수행해야 합니다.

다음 단계

• 전역 외부 애플리케이션 부하 분산기를 배포하는 방법은 Compute Engine 백엔드로 외부 애플리케이션 부하 분산기 설정을 참조하세요.
• 리전 외부 애플리케이션 부하 분산기를 배포하는 방법은 Compute Engine 백엔드가 있는 리전 외부 애플리케이션 부하 분산기 설정을 참조하세요.
• 기본 애플리케이션 부하 분산기의 기존 사용자인 경우 전역 외부 애플리케이션 부하 분산기를 사용하여 새 배포를 계획할 때 전역 외부 애플리케이션 부하 분산기로의 마이그레이션 계획을 검토하세요.
• Terraform으로 외부 애플리케이션 부하 분산기 설정을 자동화하는 방법은 외부 애플리케이션 부하 분산기를 위한 Terraform 모듈 예시를 참조하세요.
• 전역 외부 애플리케이션 부하 분산기에서 사용할 수 있는 고급 트래픽 관리 기능을 구성하는 방법은 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참고하세요.
• 리전 외부 애플리케이션 부하 분산기에서 사용할 수 있는 고급 트래픽 관리 기능을 구성하는 방법은 리전 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참고하세요.
• Google PoP 위치를 찾으려면 GFE 위치를 참조하세요.
• 용량 관리에 대한 자세한 내용은 부하 분산을 통한 용량 관리 튜토리얼 및 전역 부하 분산을 사용한 애플리케이션 용량 최적화를 참조하세요.
• 웹사이트 제공에 대한 자세한 내용은 웹사이트 제공을 참조하세요.
• 인증서 관리자를 사용하여 SSL 인증서를 프로비저닝하고 관리하는 방법은 인증서 관리자 개요를 참조하세요.
• 부하 분산 데이터 경로에 커스텀 로직을 삽입하려면 서비스 확장 프로그램 콜아웃을 구성합니다.