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

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

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

작업 모드

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

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

• 리전 내부 애플리케이션 부하 분산기. 오픈소스 Envoy 프록시를 기반으로 하는 관리형 서비스로 구현되는 리전 부하 분산기입니다. 리전 모드에서는 백엔드가 단일 Google Cloud 리전에 있어야 합니다. 클라이언트는 전달 규칙에서 전역 액세스의 사용 중지 또는 사용 설정 여부에 따라 해당 리전으로 제한될 수도 있고, 모든 리전에 있을 수도 있습니다. 이 부하 분산기에서 HTTP 또는 HTTPS 매개변수 기반의 풍부한 트래픽 제어 기능을 사용할 수 있습니다. 부하 분산기가 구성된 후에는 필요한 트래픽에 맞게 Envoy 프록시를 자동으로 할당합니다.

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

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

모드 식별

콘솔

1. Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.

   부하 분산으로 이동

2. 부하 분산기 탭에서 부하 분산기 유형, 프로토콜, 리전을 참조할 수 있습니다. 리전이 비어 있으면 부하 분산기가 교차 리전 모드입니다. 다음 표에는 부하 분산기의 모드를 식별하는 방법이 요약되어 있습니다.

   부하 분산기 모드	부하 분산기 유형	액세스 유형	지역
   리전 간 내부 애플리케이션 부하 분산기	애플리케이션	내부
   리전 내부 애플리케이션 부하 분산기	애플리케이션	내부	리전 지정

gcloud

1. 부하 분산기 모드를 확인하려면 다음 명령어를 실행합니다.

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

   명령어 출력에서 부하 분산 스킴, 리전, 네트워크 등급을 확인합니다. 다음 표에는 부하 분산기의 모드를 식별하는 방법이 요약되어 있습니다.

   부하 분산기 모드	부하 분산 스키마	전달 규칙
   교차 리전 내부 애플리케이션 부하 분산기	INTERNAL_MANAGED	전역
   리전 내부 애플리케이션 부하 분산기	INTERNAL_MANAGED	리전

중요: 부하 분산기를 만든 후에는 모드를 수정할 수 없습니다. 대신 부하 분산기를 삭제하고 새 부하 분산기를 만들어야 합니다.

아키텍처 및 리소스

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

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

이 다이어그램은 동일한 VPC 네트워크에 있는 프리미엄 등급의 교차 리전 내부 애플리케이션 부하 분산기 배포 구성요소를 보여줍니다. 각 전역 전달 규칙에서 클라이언트가 연결하는 데 사용하는 리전 IP 주소를 사용합니다.

교차 리전 내부 애플리케이션 부하 분산기 구성요소(확대하려면 클릭)

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

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

리전 내부 애플리케이션 부하 분산기 구성요소(확대하려면 클릭)

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

프록시 전용 서브넷

위의 다이어그램에서 프록시 전용 서브넷은 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 또는 HTTPS 프록시를 참조하도록 여러 전달 규칙을 구성할 수 있습니다. 이렇게 하면 공유 URL 맵이 있는 단일 부하 분산기를 여러 애플리케이션에 대한 프록시로 사용할 수 있습니다.

내부 애플리케이션 부하 분산기에 사용되는 전달 규칙, IP 주소, 부하 분산 스키마의 유형은 부하 분산기 모드에 따라 달라집니다.

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

전달 규칙 및 VPC 네트워크

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

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

대상 프록시

대상 HTTP 또는 HTTPS 프록시는 클라이언트의 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를 보여줍니다.

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

SSL 인증서

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

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

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

URL 맵

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

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

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

백엔드 서비스

백엔드 서비스는 Compute Engine 인스턴스 그룹 또는 네트워크 엔드포인트 그룹(NEG)와 같은 백엔드로 요청을 전달할 수 있도록 부하 분산기에 구성 정보를 제공합니다. 백엔드 서비스에 대한 자세한 내용은 백엔드 서비스 개요를 참조하세요.

백엔드 서비스 범위

다음 표에서는 내부 애플리케이션 부하 분산기에 사용되는 백엔드 서비스 리소스와 범위를 보여줍니다.

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

백엔드 프로토콜

애플리케이션 부하 분산기의 백엔드 서비스는 백엔드로 요청을 보내기 위해 다음 프로토콜 중 하나를 사용해야 합니다.

• HTTP: HTTP/1.1 사용하지만 TLS를 사용 안 함
• HTTPS: HTTP/1.1 및 TLS 사용
• HTTP/2: HTTP/2 및 TLS 사용(암호화가 없는 HTTP/2는 지원되지 않음)
• H2C: TCP를 통해 HTTP/2 사용. TLS는 필요하지 않습니다. H2C는 기본 애플리케이션 부하 분산기에서 지원되지 않습니다.

부하 분산기는 백엔드와 통신을 위해 지정하는 백엔드 서비스 프로토콜만 사용합니다. 지정된 백엔드 서비스 프로토콜을 사용하여 백엔드와 통신할 수 없더라도 부하 분산기는 다른 프로토콜로 대체하지 않습니다.

백엔드 서비스 프로토콜은 부하 분산기와 통신을 위해 클라이언트에 사용되는 프로토콜과 일치할 필요가 없습니다. 예를 들어 클라이언트가 HTTP/2를 사용하여 부하 분산기로 요청을 보낼 수 있지만 부하 분산기는 HTTP/1.1(HTTP 또는 HTTPS)을 사용하여 통신할 수 있습니다.

백엔드

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

부하 분산기 모드	백엔드 서비스의 백엔드 지원^1						백엔드 버킷 지원	Cloud Armor 지원	Cloud CDN 지원	IAP 지원	Service Extensions 지원
	인스턴스 그룹^2	영역별 NEG^3	인터넷 NEG	서버리스 NEG	하이브리드 NEG	Private Service Connect NEG
교차 리전 내부 애플리케이션 부하 분산기				Cloud Run
리전 내부 애플리케이션 부하 분산기				Cloud Run

¹ 백엔드 서비스의 모든 백엔드는 같은 유형이어야 합니다. 즉, 모두 인스턴스 그룹이거나 모두 같은 유형의 NEG여야 합니다. 이 규칙에 대한 예외는 하이브리드 아키텍처를 지원하기 위해 GCE_VM_IP_PORT 영역별 NEG와 하이브리드 NEG를 모두 동일한 백엔드 서비스에서 사용할 수 있는 경우입니다.

² 같은 백엔드 서비스에서 영역별 비관리, 영역별 관리형, 리전별 관리형 인스턴스 그룹을 조합할 수 있습니다. 백엔드가 둘 이상의 백엔드 서비스에 속하는 관리형 인스턴스 그룹에 자동 확장을 사용할 때는 여러 신호를 사용하도록 인스턴스 그룹의 자동 확장 정책을 구성합니다.

³ 영역별 NEG는 GCE_VM_IP_PORT 엔드포인트를 사용해야 합니다.

백엔드 및 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에 전달됩니다. nic0이 아닌 인터페이스(vNIC 또는 Dynamic Network Interface)로 패킷을 전송하려면 대신 NEG 백엔드를 사용합니다.

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

백엔드 하위 설정

프리뷰

이 제품 또는 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 제품 및 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

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

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

상태 확인

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

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

상태 확인 프로토콜

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

다음 표에서는 내부 애플리케이션 부하 분산기에서 지원하는 상태 확인 범위를 보여줍니다.

부하 분산기 모드	상태 확인 유형
리전 간 내부 애플리케이션 부하 분산기	healthChecks
리전 내부 애플리케이션 부하 분산기	regionHealthChecks

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

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

방화벽 규칙

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

• Google의 중앙 상태 확인 범위에서 들어오는 트래픽을 허용하는 인그레스 허용 규칙. 특정 상태 확인 프로브 IP 주소 범위와 트래픽을 허용해야 하는 이유에 대한 자세한 내용은 프로브 IP 범위 및 방화벽 규칙을 참조하세요.
• 프록시 전용 서브넷의 트래픽을 허용하는 인그레스 허용 규칙

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

• 하이브리드 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 연결을 통해 부하 분산기에 액세스할 수 있습니다. 이러한 터널 또는 연결은 어느 리전에나 있을 수 있습니다.

GKE 지원

GKE는 다음 방식으로 내부 애플리케이션 부하 분산기를 사용합니다.

• GKE Gateway Controller를 사용하여 생성된 내부 게이트웨이는 내부 애플리케이션 부하 분산기의 모든 모드를 사용할 수 있습니다. 부하 분산기의 모드를 제어하려면 GatewayClass를 선택합니다. GKE Gateway Controller는 항상 GCE_VM_IP_PORT 영역별 NEG 백엔드를 사용합니다.

• GKE Ingress Controller를 사용하여 생성된 내부 인그레스는 항상 리전 내부 애플리케이션 부하 분산기입니다. GKE Ingress Controller는 항상 GCE_VM_IP_PORT 영역별 NEG 백엔드를 사용합니다.

• GKE 서비스로 생성 및 관리되는 GCE_VM_IP_PORT 영역별 NEG를 애플리케이션 부하 분산기 또는 프록시 네트워크 부하 분산기의 백엔드로 사용할 수 있습니다. 자세한 내용은 표준 영역별 NEG를 통한 컨테이너 기반 부하 분산을 참조하세요.

공유 VPC 아키텍처

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

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

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

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

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

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

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

공유 VPC 네트워크의 내부 애플리케이션 부하 분산기(확대하려면 클릭)

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

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

교차 프로젝트 서비스 참조

교차 프로젝트 서비스 참조는 부하 분산기의 프런트엔드와 URL 맵이 하나의 프로젝트에 포함되고 부하 분산기의 백엔드 서비스와 백엔드가 다른 프로젝트에 포함되는 배포 모델입니다.

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

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

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

내부 애플리케이션 부하 분산기의 경우 교차 프로젝트 서비스 참조만 공유 VPC 환경 내에서 지원됩니다.

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

교차 프로젝트 서비스 참조를 위한 사용 참고사항

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

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

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

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

다른 서비스 프로젝트의 부하 분산기 프런트엔드 및 백엔드(확대하려면 클릭).

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

다음은 호스트 프로젝트에 부하 분산기의 프런트엔드 및 URL 맵이 생성되고 백엔드 서비스(및 백엔드)가 서비스 프로젝트에 생성되는 공유 VPC 배포의 예시입니다.

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

호스트 프로젝트의 부하 분산기 프런트엔드 및 URL 맵(확대하려면 클릭).

제한 시간 및 재시도

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

제한 시간 유형 및 설명	기본값	커스텀 값 지원
		리전 간	리전
백엔드 서비스 제한 시간 요청 및 응답 제한 시간. 부하 분산기가 요청의 첫 번째 바이트를 백엔드로 보내는 시점과 백엔드가 HTTP 응답의 마지막 바이트를 부하 분산기로 반환하는 시점 사이에 허용되는 최대 시간을 나타냅니다. 백엔드가 이 제한 시간 내에 전체 HTTP 응답을 부하 분산기에 반환하지 않았으면 남은 응답 데이터가 삭제됩니다.	백엔드 서비스의 서버리스 NEG: 60분 백엔드 서비스의 다른 모든 백엔드 유형: 30초 =
클라이언트 HTTP 연결 유지 제한 시간 클라이언트와 부하 분산기의 관리형 Envoy 프록시 사이의 TCP 연결이 유휴 상태로 유지될 수 있는 최대 시간입니다. 여러 HTTP 요청에 같은 TCP 연결이 사용될 수 있습니다.	610초
백엔드 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 연결이 종료될 가능성이 높습니다.

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

콘솔

부하 분산기의 백엔드 서비스의 제한 시간 필드를 수정합니다.

gcloud

gcloud compute backend-services update 명령어를 사용하여 백엔드 서비스 리소스의 --timeout 파라미터를 수정합니다.

API

regionBackendServices 리소스의 timeoutSec 파라미터를 수정합니다.

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

클라이언트 HTTP 연결 유지 제한 시간은 (다운스트림) 클라이언트와 Envoy 프록시 사이에 TCP 연결이 유휴 상태가 될 수 있는 최대 시간을 나타냅니다. 기본 클라이언트 HTTP 연결 유지 제한 시간 값은 610초입니다. 제한 시간은 5~1200초 사이의 값으로 구성할 수 있습니다.

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

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

클라이언트 HTTP 연결 유지 제한 시간이 만료되면 GFE 또는 Envoy 프록시에서 TCP FIN을 클라이언트로 보내 연결을 정상적으로 종료합니다.

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

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

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

백엔드 연결 유지 제한 시간은 10분(600초)으로 고정되며 변경할 수 없습니다. 따라서 부하 분산기가 최소 10분 이상 연결을 유휴 상태로 유지할 수 있습니다. 이 기간이 경과하면 부하 분산기에서 언제든지 종료 패킷을 백엔드에 보낼 수 있습니다.

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

백엔드 HTTP 연결 유지 제한 시간이 만료되면 GFE 또는 Envoy 프록시에서 TCP FIN을 백엔드 VM으로 보내 연결을 정상적으로 종료합니다.

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

웹 서버 소프트웨어	매개변수	기본 설정	권장 설정
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

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

세션 어피니티

애플리케이션 부하 분산기 백엔드 서비스에 구성된 세션 어피니티는 정상 백엔드 인스턴스나 엔드포인트의 수가 일정하게 유지되고 이전에 선택한 백엔드 인스턴스나 엔드포인트의 용량이 부족한 경우 특정 클라이언트의 요청을 같은 백엔드로 전송하려고 합니다. 분산 모드 대상 용량은 백엔드 용량이 충분해지는 시기를 결정합니다.

다음 표에서는 다양한 애플리케이션 부하 분산기에서 지원되는 다양한 유형의 세션 어피니티 옵션을 간략히 설명합니다. 다음 섹션인 세션 어피니티 유형에서는 각 세션 어피니티 유형을 자세히 설명합니다.

표: 지원되는 세션 어피니티 설정

제품

세션 어피니티 옵션

리전 간 내부 애플리케이션 부하 분산기 리전별 내부 애플리케이션 부하 분산기

없음(NONE) 클라이언트 IP(CLIENT_IP) 생성된 쿠키(GENERATED_COOKIE) 헤더 필드(HEADER_FIELD) HTTP 쿠키(HTTP_COOKIE) 스테이트풀(Stateful) 쿠키 기반 어피니티(STRONG_COOKIE_AFFINITY) 또한 다음을 참고하세요 부하 분산 지역 정책(localityLbPolicy)의 유효한 기본값은 세션 어피니티 설정에 따라 변경됩니다. 세션 어피니티가 구성되지 않은 경우, 즉 세션 어피니티가 기본값 NONE으로 유지되는 경우 localityLbPolicy의 기본값은 ROUND_ROBIN입니다. 세션 어피니티가 NONE 이외의 값으로 설정된 경우 localityLbPolicy의 기본값은 MAGLEV입니다. 내부 애플리케이션 부하 분산기에서 가중치가 적용된 트래픽 분할을 사용하는 경우 세션 어피니티를 구성하지 마세요. 구성하면 가중치가 적용된 트래픽 분할 구성이 우선 적용됩니다.

세션 어피니티를 구성할 때 다음 사항에 유의하세요.

• 인증 또는 보안 목적으로 세션 어피니티를 사용하지 않습니다. 스테이트풀(Stateful) 쿠키 기반 세션 어피니티를 제외한 세션 어피니티는 제공 및 정상 백엔드 수가 변경될 때마다 중단될 수 있습니다. 자세한 내용은 세션 어피니티 손실을 참조하세요.

• --session-affinity 및 --subsetting-policy 플래그의 기본값은 모두 NONE이며 한 번에 하나만 다른 값으로 설정할 수 있습니다.

세션 어피니티 유형

내부 애플리케이션 부하 분산기의 세션 어피니티는 다음 카테고리 중 하나로 분류할 수 있습니다.

• 해시 기반 세션 어피니티(NONE, CLIENT_IP)
• HTTP 헤더 기반 세션 어피니티(HEADER_FIELD)
• 쿠키 기반 세션 어피니티(GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

해시 기반 세션 어피니티

해시 기반 세션 어피니티의 경우 부하 분산기는 일관된 해싱 알고리즘을 사용하여 적격한 백엔드를 선택합니다. 세션 어피니티 설정은 해시를 계산하는 데 사용되는 IP 헤더의 필드를 결정합니다.

해시 기반 세션 어피니티는 다음 유형 중 하나일 수 있습니다.

• 없음
• 클라이언트 IP 어피니티

없음

세션 어피니티를 NONE으로 설정한다고 해서 세션 어피니티가 없다는 의미는 아닙니다. 명시적으로 구성된 세션 어피니티 옵션이 없다는 의미입니다.

해싱은 항상 백엔드를 선택하기 위해 수행됩니다. 세션 어피니티 설정이 NONE이면 부하 분산기에서 5튜플 해시를 사용하여 백엔드를 선택합니다. 5튜플 해시는 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 목적지 포트로 구성되어 있습니다.

세션 어피니티 기본값은 NONE입니다.

클라이언트 IP 어피니티

클라이언트 IP 세션 어피니티(CLIENT_IP)는 패킷의 소스 및 대상 IP 주소에서 생성된 2튜플 해시입니다. 클라이언트 IP 어피니티는 백엔드가 정상이고 용량이 충분한 경우 같은 클라이언트 IP 주소의 모든 요청을 같은 백엔드로 전달합니다.

클라이언트 IP 어피니티를 사용할 때는 다음 사항에 유의하세요.

• 패킷 대상 IP 주소는 패킷이 부하 분산기로 직접 전송되는 경우에만 부하 분산기 전달 규칙 IP 주소와 동일합니다.
• 패킷이 Google Cloud 부하 분산기에 전송되기 전에 중간 NAT 또는 프록시 시스템에서 처리되는 경우에는 패킷 소스 IP 주소가 원래 클라이언트와 연결된 IP 주소와 일치하지 않을 수 있습니다. 여러 클라이언트에서 같은 유효 소스 IP 주소를 공유하는 경우 일부 백엔드 VM은 다른 VM보다 더 많은 연결이나 요청을 수신할 수 있습니다.

HTTP 헤더 기반 세션 어피니티

헤더 필드 어피니티(HEADER_FIELD)를 사용하면 요청이 백엔드 서비스의 consistentHash.httpHeaderName 필드에 있는 HTTP 헤더 값에 따라 백엔드로 라우팅됩니다. 사용 가능한 모든 백엔드에 요청을 분산하려면 각 클라이언트가 서로 다른 HTTP 헤더 값을 사용해야 합니다.

헤더 필드 어피니티는 다음 조건이 충족되는 경우에 지원됩니다.

• 부하 분산 지역 정책이 RING_HASH 또는 MAGLEV입니다.
• 백엔드 서비스의 consistentHash가 HTTP 헤더의 이름(httpHeaderName)을 지정합니다.

쿠키 기반 세션 어피니티

쿠키 기반 세션 어피니티는 다음 유형 중 하나일 수 있습니다.

• 생성된 쿠키 어피니티
• HTTP 쿠키 어피니티
• 스테이트풀(Stateful) 쿠키 기반 세션 어피니티

생성된 쿠키 어피니티

생성된 쿠키 기반 어피니티(GENERATED_COOKIE)를 사용하면 부하 분산기에서 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다.

생성된 쿠키의 이름은 부하 분산기 유형에 따라 다릅니다.

제품	쿠키 이름
교차 리전 내부 애플리케이션 부하 분산기	GCILB
리전 내부 애플리케이션 부하 분산기	GCILB

생성된 쿠키의 경로 속성은 항상 슬래시(/)이므로 다른 백엔드 서비스도 생성된 쿠키 어피니티를 사용하는 경우 같은 URL 맵의 모든 백엔드 서비스에 적용됩니다.

affinityCookieTtlSec 백엔드 서비스 매개변수를 사용하여 쿠키 TTL(수명) 값을 0~1,209,600초(포함)로 구성할 수 있습니다. affinityCookieTtlSec이 지정되지 않으면 기본 TTL 값은 0입니다.

클라이언트가 HTTP 요청의 Cookie 요청 헤더에 생성된 세션 어피니티 쿠키를 포함하면 세션 어피니티 쿠키가 유효한 경우 부하 분산기가 이러한 요청을 동일한 백엔드 인스턴스 또는 엔드포인트로 전달합니다. 쿠키 값을 특정 백엔드 인스턴스나 엔드포인트를 참조하는 색인에 매핑하고 생성된 쿠키 세션 어피니티 요구사항이 충족되는지 확인하면 이 작업이 수행됩니다.

생성된 쿠키 어피니티를 사용하려면 다음과 같은 균형 조정 모드와 localityLbPolicy 설정을 구성합니다.

• 백엔드 인스턴스 그룹의 경우 RATE 분산 모드를 사용합니다.
• 백엔드 서비스의 localityLbPolicy에는 RING_HASH 또는 MAGLEV를 사용합니다. localityLbPolicy를 명시적으로 설정하지 않으면 부하 분산기는 MAGLEV를 암시적 기본값으로 사용합니다.

자세한 내용은 세션 어피니티 손실을 참조하세요.

HTTP 쿠키 어피니티

HTTP 쿠키 기반 어피니티(HTTP_COOKIE)를 사용하면 부하 분산기에서 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다. 쿠키의 이름, 경로, TTL(수명)을 지정합니다.

모든 애플리케이션 부하 분산기는 HTTP 쿠키 기반 어피니티를 지원합니다.

다음 백엔드 서비스 파라미터와 유효한 값을 사용하여 초, 1초 미만의 값(나노초) 또는 초와 1초 미만의 값(나노초) 모두를 사용하여 쿠키의 TTL 값을 구성할 수 있습니다.

• consistentHash.httpCookie.ttl.seconds는 0과 315576000000 사이의 값(양 끝값 포함)으로 설정할 수 있습니다.
• consistentHash.httpCookie.ttl.nanos는 0과 999999999 사이의 값(양 끝값 포함)으로 설정할 수 있습니다. 단위가 나노초이므로 999999999는 .999999999초를 의미합니다.

consistentHash.httpCookie.ttl.seconds 및 consistentHash.httpCookie.ttl.nanos가 모두 지정되지 않으면 affinityCookieTtlSec 백엔드 서비스 파라미터 값이 대신 사용됩니다. affinityCookieTtlSec이 지정되지 않으면 기본 TTL 값은 0입니다.

클라이언트가 HTTP 요청의 Cookie 요청 헤더에 HTTP 세션 어피니티 쿠키를 포함하면 세션 어피니티 쿠키가 유효한 경우 부하 분산기가 이러한 요청을 동일한 백엔드 인스턴스 또는 엔드포인트로 전달합니다. 쿠키 값을 특정 백엔드 인스턴스나 엔드포인트를 참조하는 색인에 매핑하고 생성된 쿠키 세션 어피니티 요구사항이 충족되는지 확인하면 이 작업이 수행됩니다.

HTTP 쿠키 어피니티를 사용하려면 다음과 같은 균형 조정 모드 및 localityLbPolicy 설정을 구성합니다.

• 백엔드 인스턴스 그룹의 경우 RATE 분산 모드를 사용합니다.
• 백엔드 서비스의 localityLbPolicy에는 RING_HASH 또는 MAGLEV를 사용합니다. localityLbPolicy를 명시적으로 설정하지 않으면 부하 분산기는 MAGLEV를 암시적 기본값으로 사용합니다.

자세한 내용은 세션 어피니티 손실을 참조하세요.

스테이트풀(Stateful) 쿠키 기반 세션 어피니티

스테이트풀(Stateful) 쿠키 기반 어피니티(STRONG_COOKIE_AFFINITY)를 사용하면 부하 분산기에서 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다. 쿠키의 이름, 경로, TTL(수명)을 지정합니다.

기본 애플리케이션 부하 분산기를 제외한 모든 애플리케이션 부하 분산기는 스테이트풀(Stateful) 쿠키 기반 어피니티를 지원합니다.

초, 1초 미만의 값(나노초) 또는 초와 1초 미만의 값(나노초) 모두를 사용하여 쿠키의 TTL 값을 구성할 수 있습니다. strongSessionAffinityCookie.ttl로 표시되는 기간은 2주(1,209,600초)를 초과하는 값으로 설정할 수 없습니다.

쿠키의 값은 선택된 인스턴스 또는 엔드포인트를 값 자체에 인코딩하여 선택된 백엔드 인스턴스 또는 엔드포인트를 식별합니다. 쿠키가 유효한 한 클라이언트가 후속 HTTP 요청의 Cookie 요청 헤더에 세션 어피니티 쿠키를 포함하면 부하 분산기는 이러한 요청을 선택한 백엔드 인스턴스 또는 엔드포인트로 전달합니다.

다른 세션 어피니티 방법과의 차이점:

• 스테이트풀(Stateful) 쿠키 기반 어피니티에는 분산 모드 또는 부하 분산 지역 정책(localityLbPolicy)에 관한 특정한 요구사항이 없습니다.

• 자동 확장이 관리형 인스턴스 그룹에 새 인스턴스를 추가할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.

• 선택한 인스턴스가 삭제되지 않는 한 자동 확장이 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.

• 선택한 인스턴스가 삭제되지 않는 한 자동 복구가 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.

자세한 내용은 세션 어피니티 손실을 참조하세요.

쿠키 기반 어피니티 TTL 0의 의미

생성된 쿠키 어피니티, HTTP 쿠키 어피니티, 스테이트풀(Stateful) 쿠키 기반 어피니티와 같은 모든 쿠키 기반 세션 어피니티에는 TTL 속성이 있습니다.

TTL이 0초이면 부하 분산기가 쿠키에 Expires 속성을 할당하지 않습니다. 이 경우 클라이언트는 쿠키를 세션 쿠키로 취급합니다. 세션 정의는 클라이언트에 따라 다릅니다.

• 웹브라우저와 같은 일부 클라이언트는 전체 탐색 세션 동안 쿠키를 유지합니다. 즉, 애플리케이션이 닫힐 때까지 여러 요청에 걸쳐 쿠키가 유지됩니다.

• 세션을 단일 HTTP 요청으로 취급하여 쿠키를 즉시 삭제하는 클라이언트도 있습니다.

세션 어피니티 상실

모든 세션 어피니티 옵션에는 다음이 필요합니다.

• 선택한 백엔드 인스턴스나 엔드포인트는 백엔드로 구성된 상태를 유지해야 합니다. 다음 이벤트 중 하나가 발생하면 세션 어피니티가 중단될 수 있습니다.
  • 선택한 인스턴스를 인스턴스 그룹에서 삭제합니다.
  • 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 선택한 인스턴스가 관리형 인스턴스 그룹에서 삭제됩니다.
  • 선택한 엔드포인트를 NEG에서 삭제합니다.
  • 선택한 인스턴스나 엔드포인트가 포함된 인스턴스 그룹 또는 NEG를 백엔드 서비스에서 삭제합니다.
• 선택한 백엔드 인스턴스나 엔드포인트가 정상 상태로 유지되어야 합니다. 선택한 인스턴스나 엔드포인트가 상태 점검에 실패하면 세션 어피니티가 손상될 수 있습니다.

스테이트풀(Stateful) 쿠키 기반 세션 어피니티를 제외한 모든 세션 어피니티 옵션에는 다음과 같은 추가 요구사항이 있습니다.

• 선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG가 대상 용량에서 정의된 대로 가득 차서는 안 됩니다. 리전 관리형 인스턴스 그룹의 경우 선택한 인스턴스가 포함된 인스턴스 그룹의 영역 구성요소가 가득 차서는 안 됩니다. 인스턴스 그룹 또는 NEG가 가득 차고 다른 인스턴스 그룹 또는 NEG는 가득 차지 않은 경우 세션 어피니티가 손상될 수 있습니다. UTILIZATION 분산 모드를 사용할 때는 가득 찬 상태가 예측 불가능한 방식으로 변경될 수 있으므로 RATE 또는 CONNECTION 분산 모드를 사용하여 세션 어피니티가 손상될 수 있는 상황을 최소화해야 합니다.

• 구성된 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 구성된 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.

  • 새 인스턴스나 엔드포인트를 추가합니다.

    • 백엔드 서비스의 기존 인스턴스 그룹에 인스턴스를 추가합니다.
    • 관리형 인스턴스 그룹 자동 확장으로 인해 백엔드 서비스의 관리형 인스턴스 그룹에 인스턴스가 추가됩니다.
    • 백엔드 서비스의 기존 NEG에 엔드포인트를 추가합니다.
    • 백엔드 서비스에 비어 있지 않은 백엔드 인스턴스 그룹 또는 NEG를 추가합니다.

  • 선택한 인스턴스 또는 엔드포인트뿐만 아니라 모든 인스턴스 또는 엔드포인트 삭제:

    • 인스턴스 그룹 백엔드에서 인스턴스를 삭제합니다.
    • 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 관리형 인스턴스 그룹 백엔드에서 인스턴스가 삭제됩니다.
    • NEG 백엔드에서 엔드포인트를 삭제합니다.
    • 백엔드 서비스에서 비어 있지 않은 기존 백엔드 인스턴스 그룹이나 NEG를 삭제합니다.

• 정상 백엔드 인스턴스나 엔드포인트의 총개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 정상적인 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.

  • 인스턴스 또는 엔드포인트가 상태 점검을 통과하여 비정상 상태에서 정상 상태로 전환됩니다.
  • 인스턴스 또는 엔드포인트가 상태 점검에 실패하여 정상 상태에서 비정상 상태 또는 시간 초과로 전환됩니다.

장애 조치

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

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

부하 분산기 모드	장애 조치 동작	모든 백엔드가 비정상일 때 동작
교차 리전 내부 애플리케이션 부하 분산기	동일한 리전 또는 다른 리전의 정상 백엔드로 자동 장애 조치합니다. 트래픽은 트래픽 분산 구성에 따라 여러 리전에 걸쳐 있는 정상 백엔드 간에 분산됩니다.	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 또는 HTTPS 클라이언트의 WebSocket Upgrade 요청을 인식합니다. 요청에는 다른 관련된 WebSocket 관련 요청 헤더로 이어지는 Connection: Upgrade, Upgrade: websocket 헤더가 포함됩니다.
2. 백엔드가 WebSocket Upgrade 응답을 보냅니다. 백엔드 인스턴스는 Connection: Upgrade 및 Upgrade: websocket 헤더, 기타 WebSocket 관련 응답 헤더를 사용하여 101 switching protocol 응답을 보냅니다.
3. 부하 분산기가 현재 연결 기간 동안 양방향 트래픽을 프록시합니다.

백엔드 인스턴스에서 상태 코드 426 또는 502를 반환하면 부하 분산기가 연결을 닫습니다.

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

HTTP/2 지원

HTTP/2는 HTTP/1 프로토콜의 주요 버전입니다. HTTP/2 지원에는 두 가지 모드가 있습니다.

• TLS 기반 HTTP/2
• TCP 기반 일반 텍스트 HTTP/2

TLS 기반 HTTP/2

TLS 기반 HTTP/2는 클라이언트와 외부 애플리케이션 부하 분산기 사이의 연결과 부하 분산기 및 백엔드 사이의 연결에 지원됩니다.

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

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

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

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

TCP 기반 일반 텍스트 HTTP/2(H2C)

H2C라고도 부르는 TCP 기반 일반 텍스트 HTTP/2에서는 TLS 없이 HTTP/2를 사용할 수 있습니다. H2C는 다음 연결에 모두 지원됩니다.

• 클라이언트와 부하 분산기 사이의 연결. 특별한 구성이 필요하지 않습니다.

• 부하 분산기와 백엔드 사이의 연결.

  부하 분산기와 백엔드 사이의 연결을 위해 H2C를 구성하려면 백엔드 서비스 프로토콜을 H2C로 설정합니다.

GKE Gateway Controller와 Cloud Service Mesh를 사용하여 만든 부하 분산기에도 H2C 지원이 제공됩니다.

H2C는 기본 애플리케이션 부하 분산기에서 지원되지 않습니다.

gRPC 지원

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

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

Google Cloud 애플리케이션에서 gRPC를 사용하려면 HTTP/2를 통해 엔드 투 엔드 요청을 프록시해야 합니다. 이렇게 하려면 다음 구성 중 하나를 사용해서 애플리케이션 부하 분산기를 만듭니다.

• 암호화되지 않은 엔드 투 엔드 트래픽의 경우(TLS 미사용): HTTP 부하 분산기를 만듭니다(대상 HTTP 프록시로 구성됨). 또한 백엔드 서비스 프로토콜을 H2C로 설정하여 부하 분산기와 백엔드 사이의 암호화되지 않은 연결에 HTTP/2를 사용하도록 부하 분산기를 구성합니다.

• 암호화된 엔드 투 엔드 트래픽의 경우(TLS 사용): HTTPS 부하 분산기를 만듭니다(대상 HTTPS 프록시 및 SSL 인증서로 구성됨). 부하 분산기는 ALPN TLS 확장을 사용하여 SSL 핸드셰이크의 일부로 클라이언트와 HTTP/2를 협상합니다.

  또한 백엔드가 TLS 트래픽을 처리할 수 있는지 확인하고 백엔드 서비스 프로토콜을 HTTP2로 설정하여 부하 분산기와 백엔드 사이의 암호화된 연결에 HTTP/2를 사용하도록 부하 분산기를 구성해야 합니다.

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

TLS 지원

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

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

상호 TLS 지원

상호 TLS(mTLS)는 클라이언트와 서버 간의 상호 인증을 위한 업계 표준 프로토콜입니다. mTLS는 클라이언트와 서버에서 신뢰할 수 있는 인증 기관(CA)에서 발급한 유효한 인증서를 갖고 있는지 확인하여 서로 인증하도록 보장합니다. 서버만 인증되는 표준 TLS와 달리 mTLS는 클라이언트와 서버 모두 인증서를 제공해야 하며, 양측의 ID가 확인된 후에만 통신이 설정됩니다.

애플리케이션 부하 분산기는 모두 mTLS를 지원합니다. mTLS에서 부하 분산기는 부하 분산기와의 TLS 핸드셰이크 중 클라이언트가 자체 인증을 위해 인증서를 전송하도록 요청합니다. 그런 후 부하 분산기가 클라이언트 인증서의 트러스트 체인을 검증하는 데 사용할 수 있는 인증서 관리자 트러스트 저장소를 구성할 수 있습니다.

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

제한사항

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

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

  • Cloud CDN
  • Compute Engine Google 관리형 SSL 인증서(인증서 관리자 Google 관리형 인증서가 지원됨)

• 내부 애플리케이션 부하 분산기에서 인증서 관리자 인증서를 사용하려면 API 또는 gcloud CLI를 사용해야 합니다.Google Cloud 콘솔은 인증서 관리자 인증서를 지원하지 않습니다.

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

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

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

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

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

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

• 내부 애플리케이션 부하 분산기는 Cloud Functions 1세대 및 App Engine을 지원하지 않습니다. 자세한 내용은 서버리스 NEG 개요: 지원되는 부하 분산기를 참조하세요.

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

다음 단계

• 공유 VPC 설정에서 부하 분산을 구성하려면 공유 VPC의 내부 애플리케이션 부하 분산기 설정을 참조하세요.

• GKE 포드에서 실행되는 서비스에 대한 부하 분산을 구성하려면 GKE 게이트웨이 배포, 독립형 NEG를 사용한 컨테이너 기반 부하 분산 및 독립형 NEG에 내부 애플리케이션 부하 분산기 연결 섹션을 참조하세요.

• 프록시 전용 서브넷 리소스를 관리하려면 Envoy 기반 부하 분산기용 프록시 전용 서브넷을 참조하세요.

• 리전 내부 애플리케이션 부하 분산기에서 백엔드 하위 설정을 구성하려면 백엔드 하위 설정을 참조하세요.

• Private Service Connect로 리전 내부 애플리케이션 부하 분산기를 구성하려면 백엔드를 통해 리전 Google API에 액세스를 참조하세요.

• 부하 분산 데이터 경로에 커스텀 로직을 삽입하려면 Cloud Load Balancing 확장 프로그램을 구성합니다.