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

이 문서에서는 내부 애플리케이션 부하 분산기를 구성하기 위해 이해해야 하는 개념을 소개합니다.

Google Cloud 내부 애플리케이션 부하 분산기는 프록시 기반의 레이어 7 부하 분산기로 단일 내부 IP 주소를 기반으로 서비스를 실행하고 확장할 수 있습니다. 내부 애플리케이션 부하 분산기는 Compute Engine, Google Kubernetes Engine(GKE), Cloud Run과 같은 다양한 Google Cloud Platform에서 호스팅되는 백엔드에 HTTP 및 HTTPS 트래픽을 분산합니다. 자세한 내용은 사용 사례를 참조하세요.

작업 모드

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

• 리전 간 내부 애플리케이션 부하 분산기. 오픈소스 Envoy 프록시를 기반으로 하는 관리형 서비스로 구현되는 멀티 리전 부하 분산기입니다. 리전 간 모드를 사용하면 트래픽을 가장 가까운 백엔드로 전달하는 트래픽 관리를 포함하여 트래픽을 전역으로 분산된 백엔드 서비스에 부하 분산할 수 있습니다. 또한 이 부하 분산기는 고가용성을 제공합니다. 백엔드를 여러 리전에 배치하면 단일 리전에서 발생하는 오류를 방지하는 데 도움이 됩니다. 한 리전의 백엔드가 다운되면 트래픽을 다른 리전으로 장애 조치할 수 있습니다.

• 리전별 내부 애플리케이션 부하 분산기. 오픈소스 Envoy 프록시를 기반으로 하는 관리형 서비스로 구현되는 리전별 부하 분산기입니다. 리전 모드에서는 모든 클라이언트와 백엔드가 지정된 리전에 있어 리전 규정 준수가 필요할 때 유용합니다. 이 부하 분산기에서 HTTP(S) 매개변수 기반의 풍부한 트래픽 제어 기능을 사용할 수 있습니다. 부하 분산기가 구성된 후에는 필요한 트래픽에 맞게 Envoy 프록시를 자동으로 할당합니다.

  다음 표에서는 리전 모드와 리전 간 모드 간의 중요한 차이점을 설명합니다.

  기능	리전 간 내부 애플리케이션 부하 분산기	리전 내부 애플리케이션 부하 분산기
  부하 분산기의 가상 IP 주소(VIP)	특정 Google Cloud 리전의 서브넷에서 할당됩니다. 여러 리전의 VIP 주소는 동일한 전역 백엔드 서비스를 공유할 수 있습니다. DNS 라우팅 정책을 사용하여 클라이언트 요청을 가장 가까운 VIP 주소로 라우팅하면 DNS 기반 글로벌 부하 분산을 구성할 수 있습니다.	특정 Google Cloud 리전의 서브넷에서 할당됩니다.
  클라이언트 액세스	항상 전역에서 액세스할 수 있습니다. VPC의 모든 Google Cloud 리전에 있는 클라이언트가 부하 분산기로 트래픽을 전송할 수 있습니다.	기본적으로 전역에서 액세스할 수 없습니다. 필요한 경우 전역 액세스를 사용 설정할 수 있습니다.
  부하 분산된 백엔드	전역 백엔드. 부하 분산기는 모든 리전의 백엔드로 트래픽을 전송할 수 있습니다.	리전 백엔드. 부하 분산기는 부하 분산기의 프록시와 동일한 리전에 있는 백엔드로만 트래픽을 전송할 수 있습니다.
  고가용성 및 장애 조치	동일한 리전 또는 다른 리전의 정상 백엔드로 자동 장애 조치합니다.	동일한 리전의 정상 백엔드로 자동 장애 조치합니다.

모드 식별

아키텍처 및 리소스

다음 다이어그램은 각 모드에서 내부 애플리케이션 부하 분산기에 필요한 Google Cloud 리소스를 보여줍니다.

각 내부 애플리케이션 부하 분산기는 다음 Google Cloud 구성 리소스를 사용합니다.

프록시 전용 서브넷

위의 다이어그램에서 프록시 전용 서브넷은 Google이 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 제공합니다. 내부 애플리케이션 부하 분산기를 사용하는 VPC 네트워크의 각 리전에 프록시 전용 서브넷을 만들어야 합니다.

다음 표에서는 리전 모드와 리전 간 모드에서 프록시 전용 서브넷 차이점을 설명합니다.

부하 분산기 모드	프록시 전용 서브넷 --purpose 플래그의 값
리전 간 내부 애플리케이션 부하 분산기	GLOBAL_MANAGED_PROXY 리전별 및 리전 간 부하 분산기는 동일한 서브넷을 공유할 수 없습니다. 리전 간 Envoy 기반 부하 분산기에서는 부하 분산기가 구성된 각 리전에 프록시 전용 서브넷이 있어야 합니다. 동일한 리전 및 네트워크의 리전 간 부하 분산기 프록시는 동일한 프록시 전용 서브넷을 공유합니다.
리전 내부 애플리케이션 부하 분산기	REGIONAL_MANAGED_PROXY 리전별 및 리전 간 부하 분산기는 동일한 서브넷을 공유할 수 없습니다. 리전 및 VPC 네트워크의 모든 리전 Envoy 기반 부하 분산기는 동일한 프록시 전용 서브넷을 공유합니다.

그 밖에도 다음과 같습니다.

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

전달 규칙 및 IP 주소

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

IP 주소 사양. 각 전달 규칙은 애플리케이션의 DNS 레코드에 사용할 수 있는 단일 리전 IP 주소를 참조합니다. 사용할 수 있는 고정 IP 주소를 예약하거나 Cloud Load Balancing에서 IP 주소를 하나 할당하도록 할 수 있습니다. 고정 IP 주소를 예약하는 것이 좋습니다. 그렇지 않으면 전달 규칙을 삭제하고 새 규칙을 만들 때마다 DNS 레코드를 새로 할당된 임시 IP 주소로 업데이트해야 합니다.

클라이언트는 IP 주소와 포트를 사용하여 부하 분산기의 Envoy 프록시에 연결합니다. 전달 규칙의 IP 주소는 부하 분산기의 IP 주소입니다(가상 IP 주소 또는 VIP라고도 함). 부하 분산기에 연결하는 클라이언트는 HTTP 버전 1.1 이상을 사용해야 합니다. 지원되는 전체 프로토콜 목록은 부하 분산기 기능을 참조하세요.

전달 규칙에 연결된 내부 IP 주소는 백엔드와 동일한 네트워크 및 리전의 모든 서브넷에서 가져올 수 있습니다.

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

다음 표에서는 리전 모드와 리전 간 모드에서 전달 규칙 차이점을 보여줍니다.

부하 분산기 모드	전달 규칙, IP 주소, 프록시 전용 서브넷 --purpose	클라이언트에서 부하 분산기의 프런트엔드로 라우팅
리전 간 내부 애플리케이션 부하 분산기	전역 전달 규칙 리전별 IP 주소 부하 분산 스키마 INTERNAL_MANAGED 프록시 전용 서브넷: --purpose GLOBAL_MANAGED_PROXY IP 주소 --purpose: SHARED_LOADBALANCER_VIP	VPC 내 모든 리전의 클라이언트가 부하 분산기에 액세스할 수 있도록 기본적으로 전역 액세스가 사용 설정됩니다. 백엔드는 여러 리전에 있을 수 있습니다.
리전 내부 애플리케이션 부하 분산기	리전 전달 규칙 리전 IP 주소 부하 분산 스키마 INTERNAL_MANAGED 프록시 전용 서브넷: --purpose REGIONAL_MANAGED_PROXY IP 주소 --purpose: SHARED_LOADBALANCER_VIP	VPC의 모든 리전의 클라이언트가 부하 분산기에 액세스하도록 허용하려면 전역 액세스를 사용 설정하면 됩니다. 또한 백엔드는 부하 분산기와 동일한 리전에 있어야 합니다.

전달 규칙 및 VPC 네트워크

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

부하 분산기 모드	VPC 네트워크 연결
리전 간 내부 애플리케이션 부하 분산기 리전 내부 애플리케이션 부하 분산기	리전 내부 IPv4 주소는 항상 VPC 네트워크 내에 존재합니다. 전달 규칙을 만들 때는 내부 IP 주소를 가져올 서브넷을 지정해야 합니다. 이 서브넷은 프록시 전용 서브넷이 생성된 동일한 리전 및 VPC 네트워크에 있어야 합니다. 따라서 묵시적 네트워크 연결이 존재합니다.

대상 프록시

대상 HTTP(S) 프록시는 클라이언트의 HTTP(S) 연결을 종료합니다. HTTP(S) 프록시는 URL 맵을 참조하여 트래픽을 백엔드로 라우팅하는 방법을 결정합니다. 대상 HTTPS 프록시는 SSL 인증서를 사용하여 클라이언트에 자신을 인증합니다.

부하 분산기는 원래 클라이언트 요청의 호스트 헤더를 보존합니다. 또한 부하 분산기는 두 IP 주소를 X-Forwarded-For 헤더에 추가합니다.

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

수신 요청에 X-Forwarded-For 헤더가 없으면 이 두 IP 주소가 전체 헤더 값입니다. 요청에 X-Forwarded-For 헤더가 있으면 부하 분산기로 가는 동안 프록시에서 기록한 IP 주소와 같은 기타 정보가 두 IP 주소보다 먼저 보존됩니다. 부하 분산기는 이 헤더의 마지막 두 IP 주소 앞에 있는 IP 주소를 확인하지 않습니다.

프록시를 백엔드 서버로 실행할 경우 이 프록시는 일반적으로 X-Forwarded-For 헤더에 더 많은 정보를 추가하므로 소프트웨어에서 이를 고려해야 합니다. 부하 분산기의 프록시 설정된 요청은 프록시 전용 서브넷의 IP 주소에서 가져오며 백엔드 인스턴스의 프록시는 이 주소와 백엔드 인스턴스의 자체 IP 주소를 기록할 수 있습니다.

애플리케이션이 처리해야 하는 트래픽 유형에 따라 대상 HTTP 프록시 또는 대상 HTTPS 프록시로 부하 분산기를 구성할 수 있습니다.

다음 표에서는 각 모드에서 내부 애플리케이션 부하 분산기에 필요한 대상 프록시 API를 보여줍니다.

대상 프록시	리전 간 내부 애플리케이션 부하 분산기	리전 내부 애플리케이션 부하 분산기
HTTP	전역 targetHttpProxies	regionTargetHttpProxies
HTTPS	전역 targetHttpsProxies	regionTargetHttpsProxies

SSL 인증서

대상 HTTPS 프록시를 사용하는 내부 애플리케이션 부하 분산기에는 부하 분산기 구성의 일부로 비공개 키와 SSL 인증서가 필요합니다.

다음 표에서는 각 모드의 내부 애플리케이션 부하 분산기에 필요한 SSL 인증서 유형을 명시합니다.

부하 분산기 모드	SSL 인증서 유형
리전 내부 애플리케이션 부하 분산기	Compute Engine 리전 SSL 인증서 인증서 관리자 리전별 자체 관리형 인증서 및 Google 관리형 인증서. 인증서 관리자에서 지원되는 Google 관리형 인증서 유형은 다음과 같습니다. 프로젝트별 DNS 승인을 사용하는 리전별 Google 관리형 인증서. 자세한 내용은 리전별 Google 관리형 인증서 배포를 참조하세요. 비공개 Certificate Authority Service를 사용하는 리전별 Google 관리형 인증서. 자세한 내용은 CA 서비스를 사용하여 리전별 Google 관리형 인증서 배포를 참조하세요. 부하 분산기 승인을 사용하는 Google 관리 인증서는 지원되지 않습니다.
리전 간 내부 애플리케이션 부하 분산기	인증서 관리자 자체 관리형 인증서 및 Google 관리형 인증서. 인증서 관리자에서 지원되는 Google 관리형 인증서 유형은 다음과 같습니다. 공개 DNS로 DNS 승인. 자세한 내용은 DNS 승인을 사용하여 Google 관리 인증서 만들기를 참조하세요. 비공개 Certificate Authority Service 자세한 내용은 CA 서비스 인스턴스에서 발급한 Google 관리형 인증서 만들기를 참조하세요. 부하 분산기 승인을 사용하는 Google 관리 인증서는 지원되지 않습니다. Compute Engine SSL 인증서는 지원되지 않습니다.

URL 맵

대상 HTTP(S) 프록시는 URL 맵을 사용하여 요청 경로, 쿠키, 헤더 등의 HTTP 속성을 기반으로 라우팅을 결정합니다. 라우팅 결정에 따라 프록시는 클라이언트 요청을 특정 백엔드 서비스로 전달합니다. URL 맵은 헤더 재작성, 클라이언트로 리디렉션 전송, 제한 시간 정책 구성(다른 정책 간) 등 추가 작업을 지정할 수 있습니다.

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

부하 분산기 모드	URL 맵 유형
리전 간 내부 애플리케이션 부하 분산기	전역 URL 맵
리전 내부 애플리케이션 부하 분산기	리전 URL 맵

백엔드 서비스

백엔드 서비스는 정상적인 백엔드(Compute Engine VM이 포함된 인스턴스 그룹, Cloud Run 또는 GKE 컨테이너가 포함된 NEG)에 요청을 배포합니다.

백엔드 서비스는 HTTP, HTTPS 또는 HTTP/2 프로토콜을 지원합니다. HTTP/2는 TLS에서만 지원됩니다. 클라이언트와 백엔드는 동일한 요청 프로토콜을 사용할 필요가 없습니다. 예를 들어 클라이언트는 HTTP/2를 사용하여 부하 분산기에 요청을 전송할 수 있으며 부하 분산기는 HTTP/1.1을 사용하여 이러한 요청을 백엔드에 전달할 수 있습니다.

다음 표에서는 각 모드에서 내부 애플리케이션 부하 분산기에 필요한 백엔드 서비스 유형을 명시합니다.

부하 분산기 모드	백엔드 서비스 유형
리전 간 내부 애플리케이션 부하 분산기	전역 backendServices
리전 내부 애플리케이션 부하 분산기	리전 backendServices

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

부하 분산기 모드	백엔드 서비스의 백엔드 지원						백엔드 버킷 지원	Google Cloud Armor 지원	Cloud CDN 지원	IAP 지원	서비스 확장 프로그램 지원
	인스턴스 그룹	영역별 NEG	인터넷 NEG	서버리스 NEG	하이브리드 NEG	Private Service Connect NEG
리전 간 내부 애플리케이션 부하 분산기		2		Cloud Run
리전 내부 애플리케이션 부하 분산기		1		Cloud Run

자세한 내용은 백엔드 서비스 개요를 참조하세요.

백엔드 및 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 네트워크에 있어야 합니다.

백엔드 하위 설정

백엔드 하위 설정은 리전별 내부 애플리케이션 부하 분산기가 지원하는 선택적 기능으로, 각 프록시 인스턴스에 백엔드 하위 집합을 할당하여 성능과 확장성을 개선합니다.

기본적으로 백엔드 하위 설정은 사용 중지되어 있습니다. 이 기능을 사용 설정하는 방법은 내부 애플리케이션 부하 분산기의 백엔드 하위 설정을 참조하세요.

상태 점검

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

상태 점검 프로브가 성공하려면 상태 점검 프로브가 백엔드 인스턴스에 도달할 수 있도록 인그레스 허용 방화벽 규칙을 만들어야 합니다. 일반적으로 상태 점검 프로브는 Google의 중앙 집중식 상태 점검 메커니즘에서 시작됩니다. 하지만 하이브리드 NEG의 경우 상태 점검은 프록시 전용 서브넷에서 시작됩니다. 자세한 내용은 하이브리드 NEG 개요에서 분산형 Envoy 상태 점검을 참조하세요.

상태 점검 프로토콜

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

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

부하 분산기 모드	상태 점검 유형
리전 간 내부 애플리케이션 부하 분산기	전역
리전 내부 애플리케이션 부하 분산기	리전

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

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

방화벽 규칙

내부 애플리케이션 부하 분산기에는 다음 방화벽 규칙이 필요합니다.

• Google의 중앙 상태 점검 범위에서 들어오는 트래픽을 허용하는 인그레스 허용 규칙
  • 35.191.0.0/16
  • 130.211.0.0/22

  백엔드로 들어오는 IPv6 트래픽:

  • 2600:2d00:1:b029::/64
• 프록시 전용 서브넷의 트래픽을 허용하는 인그레스 허용 규칙

이러한 범위에 대한 방화벽 규칙 요구사항에는 몇 가지 예외가 있습니다.

• 하이브리드 NEG에는 Google의 상태 점검 프로브 범위를 허용 목록에 추가할 필요가 없습니다. 하지만 단일 백엔드 서비스에서 하이브리드 및 영역 NEG 조합을 사용하는 경우 영역 NEG에 대한 Google 상태 점검 프로브 범위를 허용 목록에 추가해야 합니다.
• 리전 인터넷 NEG의 경우 상태 점검은 선택사항입니다. 리전 인터넷 NEG를 사용하는 부하 분산기의 트래픽은 프록시 전용 서브넷에서 시작되며 수동 또는 자동 할당된 NAT IP 주소로 NAT 변환됩니다(Cloud NAT 사용). 이 트래픽에는 상태 점검 프로브와 부하 분산기에서 백엔드로의 사용자 요청이 포함됩니다. 자세한 내용은 리전 NEG: 이그레스 Cloud NAT 사용을 참조하세요.

클라이언트 액세스

클라이언트는 같은 네트워크 또는 VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크에 있을 수 있습니다.

리전 간 내부 애플리케이션 부하 분산기의 경우 전역 액세스가 기본적으로 사용 설정됩니다. VPC의 모든 리전의 클라이언트가 부하 분산기에 액세스할 수 있습니다.

리전 내부 애플리케이션 부하 분산기의 경우 클라이언트가 기본적으로 부하 분산기와 동일한 리전에 있어야 합니다. VPC에서 모든 리전의 클라이언트가 부하 분산기에 액세스하도록 허용하려면 전역 액세스를 사용 설정하면 됩니다.

다음 표에는 리전별 내부 애플리케이션 부하 분산기의 클라이언트 액세스가 요약되어 있습니다.

중지된 전역 액세스	사용 설정된 전역 액세스
클라이언트는 부하 분산기와 동일한 리전에 있어야 합니다. 또한 부하 분산기와 동일한 VPC 네트워크에 있거나 VPC 네트워크 피어링을 사용하여 부하 분산기의 VPC 네트워크에 연결된 VPC 네트워크에 있어야 합니다.	클라이언트는 어느 리전에나 있을 수 있습니다. 부하 분산기와 동일한 VPC 네트워크에 있거나 VPC 네트워크 피어링을 사용하여 부하 분산기의 VPC 네트워크에 연결된 VPC 네트워크에 있어야 합니다.
온프레미스 클라이언트는 Cloud VPN 터널이나 VLAN 연결을 통해 부하 분산기에 액세스할 수 있습니다. 이러한 터널 또는 연결은 부하 분산기와 동일한 리전에 있어야 합니다.	온프레미스 클라이언트는 Cloud VPN 터널이나 VLAN 연결을 통해 부하 분산기에 액세스할 수 있습니다. 이러한 터널 또는 연결은 어느 리전에나 있을 수 있습니다.

공유 VPC 아키텍처

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

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

서브넷 및 IP 주소	프런트엔드 구성요소	백엔드 구성요소
공유 VPC 호스트 프로젝트에서 필요한 네트워크 및 서브넷(프록시 전용 서브넷 포함)을 만듭니다. 부하 분산기의 내부 IP 주소는 호스트 프로젝트 또는 서비스 프로젝트에서 정의할 수 있지만 호스트 프로젝트에서 원하는 공유 VPC 네트워크의 서브넷을 사용해야 합니다. 주소 자체는 참조된 서브넷의 기본 IP 범위에서 가져옵니다.	리전 내부 IP 주소, 전달 규칙, 대상 HTTP(S) 프록시, 연결된 URL 맵이 동일한 프로젝트에 정의되어야 합니다. 이 프로젝트는 호스트 프로젝트 또는 서비스 프로젝트일 수 있습니다.	다음 중 하나를 실행하세요. 프런트엔드 구성요소와 동일한 서비스 프로젝트에서 백엔드 서비스와 backends(인스턴스 그룹, 서버리스 NEG 또는 기타 지원되는 백엔드 유형)를 만듭니다. 백엔드 서비스와 백엔드(인스턴스 그룹, 서버리스 NEG, 기타 지원되는 백엔드 유형)를 필요한 만큼 많은 서비스 프로젝트에 만듭니다. 단일 URL 맵은 서로 다른 프로젝트의 백엔드 서비스를 참조할 수 있습니다. 이러한 유형의 배포를 프로젝트 간 서비스 참조라고 합니다. 각 백엔드 서비스는 참조하는 백엔드와 동일한 프로젝트에서 정의되어야 합니다. 백엔드 서비스와 관련된 상태 점검은 백엔드 서비스와 동일한 프로젝트에서 정의되어야 합니다.

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

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

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

부하 분산기는 호스트 프로젝트의 IP 주소와 서브넷을 사용합니다. 클라이언트가 부하 분산기와 동일한 공유 VPC 네트워크 및 리전에 있는 경우 내부 애플리케이션 부하 분산기에 액세스할 수 있습니다. 클라이언트는 호스트 프로젝트, 연결된 서비스 프로젝트 또는 연결된 네트워크에 있을 수 있습니다.

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

서버리스 NEG 백엔드를 사용하는 내부 애플리케이션 부하 분산기의 경우 지원 Cloud Run 서비스가 백엔드 서비스 및 서버리스 NEG와 동일한 서비스 프로젝트에 있어야 합니다. 부하 분산기의 프런트엔드 구성요소(전달 규칙, 대상 프록시, URL 맵)는 호스트 프로젝트, 백엔드 구성요소와 동일한 서비스 프로젝트 또는 동일한 공유 VPC 환경의 기타 서비스 프로젝트에서 만들 수 있습니다.

교차 프로젝트 서비스 참조

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

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

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

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

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

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

• 백엔드 서비스에 리전 인터넷 NEG 백엔드가 있는 경우 프로젝트 간 백엔드 서비스를 참조할 수 없습니다. 다른 모든 백엔드 유형은 지원됩니다.
• Google Cloud는 여러 프로젝트에서 동일한 이름을 사용하는 리소스(예: 백엔드 서비스)를 구분하지 않습니다. 따라서 프로젝트 간 서비스 참조를 사용하는 경우 조직 내 프로젝트 전체에서 고유한 백엔드 서비스 이름을 사용하는 것이 좋습니다.

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

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

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

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

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

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

제한시간 및 재시도

내부 애플리케이션 부하 분산기는 다음 유형의 제한 시간을 지원합니다.

제한 시간 유형 및 설명	기본값	커스텀 값 지원
		백엔드 서비스 제한 시간 요청 및 응답 제한 시간. 부하 분산기가 HTTP 요청의 첫 번째 바이트를 백엔드로 보낸 후 백엔드가 HTTP 응답의 마지막 바이트를 반환할 때까지 경과할 수 있는 최대 시간을 나타냅니다. 요청 또는 응답 제한 시간 내에 전체 HTTP 응답이 부하 분산기로 반환되지 않으면 나머지 응답 데이터가 삭제됩니다.	백엔드 서비스의 서버리스 NEG: 60분 백엔드 서비스의 다른 모든 백엔드 유형: 30초 =
클라이언트 HTTP 연결 유지 제한 시간 클라이언트와 부하 분산기의 관리형 Envoy 프록시 간의 TCP 연결이 유휴 상태일 수 있는 최대 시간입니다. 여러 HTTP 요청에 같은 TCP 연결이 사용될 수 있습니다.	10분(600초)
백엔드 HTTP 연결 유지 제한 시간 부하 분산기의 관리형 Envoy 프록시와 백엔드 간의 TCP 연결이 유휴 상태일 수 있는 최대 시간입니다. 여러 HTTP 요청에 같은 TCP 연결이 사용될 수 있습니다.	10분(600초)

백엔드 서비스 제한 시간

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

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

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

백엔드 서비스 제한 시간은 1~2,147,483,647초 사이의 값을 허용하지만 큰 값은 실용적인 구성 옵션이 아닙니다. 또한 Google Cloud는 기본 TCP 연결이 백엔드 서비스 제한 시간 값의 전체 기간 동안 열린 상태로 유지됨을 보장하지 않습니다. 클라이언트 시스템은 TCP 연결을 사용하여 장시간 열어 두는 대신 재시도 로직을 구현해야 합니다.

내부 애플리케이션 부하 분산기에 사용되는 WebSocket 연결의 경우 활성 WebSocket 연결이 백엔드 서비스 제한 시간을 따르지 않습니다. 유휴 WebSocket 연결은 백엔드 서비스 제한 시간 후 닫힙니다.

Google Cloud는 주기적으로 Envoy 소프트웨어 작업을 다시 시작하거나 제공 수를 변경합니다. 백엔드 서비스 제한 시간 값이 길수록 Envoy 태스크가 다시 시작하거나 대체를 통해 TCP 연결이 종료될 가능성이 높습니다.

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

• Google Cloud 콘솔: 부하 분산기 백엔드 서비스의 제한 시간 필드를 수정합니다.
• Google Cloud CLI: gcloud compute backend-services update 명령어를 사용하여 백엔드 서비스 리소스의 --timeout 매개변수를 수정합니다.
• API: regionBackendServices 리소스의 timeoutSec 매개변수를 수정합니다.

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

클라이언트 HTTP 연결 유지 제한 시간은 (다운스트림) 클라이언트와 Envoy 프록시 사이에 TCP 연결이 유휴 상태가 될 수 있는 최대 시간을 나타냅니다. 클라이언트 HTTP 연결 유지 제한 시간 값은 600초로 고정됩니다.

HTTP 연결 유지 제한 시간은 TCP 유휴 상태 제한 시간이라고도 합니다.

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

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

내부 애플리케이션 부하 분산기는 (다운스트림) 클라이언트와 Envoy 프록시 사이에 첫 번째 TCP 연결을 사용하고 Envoy 프록시와 백엔드 사이에 두 번째 TCP 연결을 사용하는 프록시입니다.

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

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

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

웹 서버 소프트웨어	매개변수	기본 설정	권장 설정
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

재시도

재시도를 구성하려면 URL 맵에서 재시도 정책을 사용합니다. 기본 재시도 횟수(numRetries)는 1입니다. 구성 가능한 최대 perTryTimeout은 24시간입니다.

재시도 정책이 없으면 HTTP 본문이 없는 실패한 요청(예: GET 요청)은 502, 503, 또는 504 응답이 한 번만 재시도됩니다.

HTTP POST 요청은 재시도되지 않습니다.

재시도한 요청은 최종 응답의 로그 항목 하나만 생성합니다.

자세한 내용은 내부 애플리케이션 부하 분산기 로깅 및 모니터링을 참조하세요.

연결된 네트워크 액세스

클라이언트는 다음을 사용하여 연결된 네트워크에서 VPC 네트워크의 내부 애플리케이션 부하 분산기에 액세스할 수 있습니다.

• VPC 네트워크 피어링
• Cloud VPN 및 Cloud Interconnect

자세한 예시는 내부 애플리케이션 부하 분산기 및 연결된 네트워크를 참조하세요.

장애 조치

백엔드가 비정상이 되면 트래픽은 자동으로 정상 백엔드로 리디렉션됩니다.

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

부하 분산기 모드	장애 조치 동작	모든 백엔드가 비정상일 때 동작
리전 간 내부 애플리케이션 부하 분산기	동일한 리전 또는 다른 리전의 정상 백엔드로 자동 장애 조치합니다. 트래픽은 트래픽 분산 구성에 따라 여러 리전에 걸쳐 있는 정상 백엔드 간에 분산됩니다.	HTTP 503 반환
리전 내부 애플리케이션 부하 분산기	동일한 리전의 정상 백엔드로 자동 장애 조치합니다. Envoy 프록시는 구성된 트래픽 분산을 기준으로 리전의 정상 백엔드로 트래픽을 전송합니다.	HTTP 503 반환

고가용성 및 리전 간 장애 조치

리전별 내부 애플리케이션 부하 분산기의 경우

고가용성을 확보하려면 애플리케이션의 트래픽을 가장 잘 지원하는 리전에 개별 리전 내부 애플리케이션 부하 분산기를 여러 개를 배포하세요. 그런 다음 Cloud DNS 위치정보 라우팅 정책을 사용하여 리전 서비스 중단 시 부하 분산기가 응답하는지 감지합니다. 위치정보 정책은 클라이언트 요청의 출처에 기반하여 사용 가능한 다음으로 가장 가까운 리전으로 트래픽을 라우팅합니다. 내부 애플리케이션 부하 분산기의 경우 기본적으로 상태 점검을 사용할 수 있습니다.

리전 간 내부 애플리케이션 부하 분산기의 경우

여러 리전에서 리전 간 내부 애플리케이션 부하 분산기를 설정하면 다음과 같은 이점을 얻을 수 있습니다.

1. 한 리전의 리전 간 내부 애플리케이션 부하 분산기가 실패하면 DNS 라우팅 정책이 다른 리전의 리전 간 내부 애플리케이션 부하 분산기로 트래픽을 라우팅합니다.

   고가용성 배포 예시에서는 다음을 보여줍니다.

   • VPC 네트워크의 RegionA 및 RegionB 리전에 프런트엔드 가상 IP 주소(VIP)가 있는 리전 간 내부 애플리케이션 부하 분산기. 클라이언트는 RegionA 리전에 있습니다.
   • 두 리전의 프런트엔드 VIP를 사용하여 부하 분산기를 액세스 가능하도록 만들고, DNS 라우팅 정책을 사용하여 클라이언트에 최적의 VIP를 반환할 수 있습니다. 클라이언트가 지리적으로 가장 가까운 VIP를 사용하도록 하려면 위치정보 라우팅 정책을 사용합니다.
   • DNS 라우팅 정책은 리전 중단 시 VIP가 응답하지 않는지 여부를 감지하고 그 다음으로 적합한 VIP를 클라이언트에 반환하여 리전이 중단되어도 애플리케이션을 계속 가동합니다.

   

2. 특정 리전의 백엔드가 다운되면 리전 간 내부 애플리케이션 부하 분산기 트래픽이 다른 리전의 백엔드로 원활하게 장애 조치됩니다.

   리전 간 장애 조치 배포 예시에서는 다음을 보여줍니다.

   • VPC 네트워크의 RegionA 리전에 프런트엔드 VIP 주소가 있는 리전 간 내부 애플리케이션 부하 분산기. 또한 클라이언트도 RegionA 리전에 있습니다.
   • RegionA 및 RegionB Google Cloud 리전의 백엔드를 참조하는 전역 백엔드 서비스.
   • RegionA 리전의 백엔드가 다운되면 트래픽이 RegionB 리전으로 장애 조치됩니다.

   

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의 세션 어피니티는 다른 모든 요청과 동일하게 작동합니다. 자세한 내용은 세션 어피니티를 참조하세요.

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를 사용 설정해야 합니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.

TLS 지원

기본적으로 HTTPS 대상 프록시는 클라이언트 SSL 요청을 종료할 때 TLS 1.0, 1.1, 1.2, 1.3만 허용합니다.

HTTPS를 백엔드 서비스 프로토콜로 사용하는 내부 애플리케이션 부하 분산기는 TLS 1.0, 1.1, 1.2, 1.3을 백엔드로 협상할 수 있습니다.

제한사항

• 리전의 한 영역에 있는 클라이언트의 요청이 클라이언트와 동일한 영역에 있는 백엔드로 전송된다는 보장은 없습니다. 세션 어피니티는 영역 간 통신을 감소시키지 않습니다.

• 내부 애플리케이션 부하 분산기는 다음 기능과 호환되지 않습니다.

  • Cloud CDN
  • Cloud Storage 버킷
  • Google 관리형 SSL 인증서

• 내부 애플리케이션 부하 분산기는 TLS를 통해서만 HTTP/2를 지원합니다.

• 내부 애플리케이션 부하 분산기에 연결하는 클라이언트는 HTTP 버전 1.1 이상을 사용해야 합니다. HTTP 1.0은 지원되지 않습니다.

• 프록시 전용 서브넷에 IP 주소가 부족해도 Google Cloud에서 경고를 표시하지 않습니다.

• 내부 애플리케이션 부하 분산기에서 사용하는 내부 전달 규칙에는 포트가 정확히 하나만 있어야 합니다.

• 내부 애플리케이션 부하 분산기는 Cloud Trace를 지원하지 않습니다.

• 공유 VPC 환경에서 Cloud Run과 함께 내부 애플리케이션 부하 분산기를 사용하는 경우 서비스 프로젝트의 독립형 VPC 네트워크는 동일한 공유 VPC 환경 내의 다른 서비스 프로젝트에 배포된 다른 모든 Cloud Run 서비스로 트래픽을 전송할 수 있습니다. 이는 알려진 문제이며 향후 이 양식의 액세스가 차단됩니다.

• Google Cloud는 기본 TCP 연결이 백엔드 서비스 제한 시간의 전체 기간 동안 열린 상태로 유지될 수 있는지를 보장하지 않습니다. 클라이언트 시스템은 TCP 연결을 사용하여 장시간 열어 두는 대신 재시도 로직을 구현해야 합니다.

다음 단계

• 공유 VPC 설정에서 부하 분산을 구성하려면 공유 VPC의 내부 애플리케이션 부하 분산기 설정을 참조하세요.
• GKE 포드에서 실행되는 서비스에 대한 부하 분산을 구성하려면 GKE 게이트웨이 배포, 독립형 NEG를 사용한 컨테이너 기반 부하 분산 및 독립형 NEG에 내부 애플리케이션 부하 분산기 연결 섹션을 참조하세요.
• Private Service Connect를 사용하여 리전 내부 애플리케이션 부하 분산기를 구성하려면 소비자 HTTP(S) 서비스 제어로 Private Service Connect 구성을 참조하세요.
• 프록시 전용 서브넷 리소스를 관리하려면 프록시 전용 서브넷을 참조하세요.
• 리전 내부 애플리케이션 부하 분산기에서 백엔드 하위 설정을 구성하려면 백엔드 하위 설정을 참조하세요.
• 부하 분산 데이터 경로에 커스텀 로직을 삽입하려면 서비스 확장 프로그램 콜아웃을 구성합니다.