외부 HTTP(S) 부하 분산 개요

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

이 문서에서는 Google Cloud 외부 HTTP(S) 부하 분산을 구성하기 위해 알아야 하는 개념을 소개합니다.

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

작업 모드

외부 HTTP(S) 부하 분산은 다음과 같은 모드로 구성할 수 있습니다.

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

이 부하 분산기는 프리미엄 등급에서 전역이지만 표준 등급에서 사실상 리전별로 구성될 수 있습니다.

프리미엄 네트워크 서비스 등급에서는 부하 분산기가 멀티 리전 부하 분산을 제공하여 트래픽을 용량이 있는 가장 가까운 정상 백엔드로 전달하고 사용자에게 가능한 가까운 곳에서 HTTP(S) 트래픽을 종료합니다.

표준 네트워크 서비스 등급에서는 부하 분산이 리전별로 처리됩니다.

 전체 기능 목록은 부하 분산 기능 페이지를 참조하세요.
리전 외부 HTTP(S) 부하 분산기

이 부하 분산기에는 기존 전역 외부 HTTP(S) 부하 분산기(기본)의 다양한 기능과 함께 고급 트래픽 관리 기능이 포함되어 있습니다.

한 위치정보에서만 콘텐츠를 제공하려는 경우(예: 규정 준수 규제를 충족하기 위해) 또는 표준 네트워크 서비스 등급이 필요한 경우 이 부하 분산기를 사용합니다.

전체 목록은 부하 분산 기능을 참조하세요.

모드 식별

Cloud 콘솔

  1. Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
    부하 분산으로 이동
  2. 부하 분산기 탭에 부하 분산기 유형, 프로토콜, 리전이 표시됩니다. 리전이 비어 있으면 부하 분산기는 전역입니다. 다음 표에는 부하 분산기의 모드를 식별하는 방법이 요약되어 있습니다.
    부하 분산기 모드 부하 분산 유형 리전 네트워크 계층
    전역 외부 HTTP(S) 부하 분산기 HTTP(S) 프리미엄
    전역 외부 HTTP(S) 부하 분산기(기본) HTTP(S)(기본) 스탠더드 또는 프리미엄
    리전 외부 HTTP(S) 부하 분산기 HTTP(S) 리전 지정 표준

gcloud

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

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

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

    부하 분산기 모드 부하 분산 스키마 전달 규칙 네트워크 계층
    전역 외부 HTTP(S) 부하 분산기 EXTERNAL_MANAGED 전역 프리미엄
    전역 외부 HTTP(S) 부하 분산기(기본) 외부 전역 스탠더드 또는 프리미엄
    리전 외부 HTTP(S) 부하 분산기 EXTERNAL_MANAGED 리전 지정 표준

아키텍처

HTTP(S) 부하 분산 배포에 필요한 리소스는 다음과 같습니다.

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

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

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

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

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

  • 백엔드 서비스는 정상 백엔드에 요청을 배포합니다. 전역 외부 HTTP(S) 부하 분산기는 백엔드 버킷도 지원합니다.

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

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

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

전역

이 다이어그램은 전역 외부 HTTP(S) 부하 분산기 배포의 구성요소를 보여줍니다. 이 아키텍처는 고급 트래픽 관리 기능이 있는 전역 외부 HTTP(S) 부하 분산기와 프리미엄 등급의 전역 외부 HTTP(S) 부하 분산기 (기본)에 모두 적용됩니다.

전역 외부 HTTP(S) 부하 분산기 구성요소
전역 외부 HTTP(S) 부하 분산기 구성요소

리전

이 다이어그램은 리전 외부 HTTP(S) 부하 분산기 배포의 구성요소를 보여줍니다.

리전 외부 HTTP(S) 부하 분산기 구성요소
리전 외부 HTTP(S) 부하 분산기 구성요소

프록시 전용 서브넷

프록시 전용 서브넷은 리전 외부 HTTP(S) 부하 분산기에만 필요합니다.

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

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

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

전달 규칙 및 주소

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

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

  • HTTP 부하 분산기의 전달 규칙은 TCP 포트 80과 8080만 참조할 수 있습니다.
  • HTTPS 부하 분산기의 전달 규칙은 TCP 포트 443만 참조할 수 있습니다.

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

부하 분산기 모드 네트워크 서비스 등급 전달 규칙, IP 주소, 부하 분산 스킴 인터넷에서 부하 분산기 프런트엔드로 라우팅
전역 외부 HTTP(S) 부하 분산기 프리미엄 등급

전역 외부 전달 규칙

전역 외부 IP 주소

부하 분산 스킴:
EXTERNAL_MANAGED

 요청이 인터넷에서 클라이언트와 가장 가까운 GFE로 라우팅됩니다.
전역 외부 HTTP(S) 부하 분산기(기본) 프리미엄 등급

전역 외부 전달 규칙

전역 외부 IP 주소

부하 분산 스키마:
EXTERNAL

 요청이 인터넷에서 클라이언트와 가장 가까운 GFE로 라우팅됩니다.
표준 등급

리전 외부 전달 규칙

리전 외부 IP 주소

부하 분산 스키마:
EXTERNAL

 요청이 부하 분산기의 리전에 있는 GFE로 라우팅됩니다.
리전 외부 HTTP(S) 부하 분산기 표준 등급

리전 외부 전달 규칙

리전 외부 IP 주소

부하 분산 스키마:
EXTERNAL_MANAGED

 요청이 부하 분산기와 동일한 리전의 Envoy 프록시로 라우팅됩니다.

각 모드의 HTTP(S) 부하 분산 전달 규칙에서 지원하는 프로토콜의 전체 목록은 부하 분산기 기능을 참조하세요.

대상 프록시

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

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

다음 표에서는 각 모드에서 HTTP(S) 부하 분산에 필요한 대상 프록시 유형을 명시합니다.

부하 분산기 모드 대상 프록시 유형 프록시가 추가된 헤더 커스텀 헤더 지원 Cloud Trace 지원
전역 외부 HTTP(S) 부하 분산기 전역 HTTP,
전역 HTTPS		 프록시는 HTTP 요청/응답 헤더를 다음과 같이 설정합니다.
  • Via: 1.1 google(요청 및 응답)
  • X-Forwarded-Proto: [http | https](요청만)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(요청만)
    Cloud Trace의 매개변수를 포함합니다.
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (X-Forwarded-For 헤더 참조)(요청만)
백엔드 서비스 또는 백엔드 버킷에 구성됨

Cloud CDN에서 지원되지 않음
전역 외부 HTTP(S) 부하 분산기(기본) 전역 HTTP,
전역 HTTPS		 프록시는 HTTP 요청/응답 헤더를 다음과 같이 설정합니다.
  • Via: 1.1 google(요청 및 응답)
  • X-Forwarded-Proto: [http | https](요청만)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(요청만)
    Cloud Trace의 매개변수를 포함합니다.
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (X-Forwarded-For 헤더 참조)(요청만)
백엔드 서비스 또는 백엔드 버킷에 구성됨
리전 외부 HTTP(S) 부하 분산기 리전 HTTP,
리전 HTTPS
  • X-Forwarded-Proto: [http | https](요청만)
  • Via: 1.1 google(요청 및 응답)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (X-Forwarded-For 헤더 참조)(요청만)

호스트 헤더

부하 분산기가 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 구성요소를 검사하여 요청을 서로 다른 백엔드 집합으로 전송하여 트래픽을 나눌 수 있습니다.

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

다음 표에서는 각 모드의 HTTP(S) 부하 분산에 필요한 URL 맵 유형을 명시합니다.

부하 분산기 모드 URL 맵 유형
전역 외부 HTTP(S) 부하 분산기 전역
전역 외부 HTTP(S) 부하 분산기(기본) 전역(지원되는 기능의 하위 집합만 포함)
리전 외부 HTTP(S) 부하 분산기 리전

SSL 인증서

대상 HTTPS 프록시를 사용하는 외부 HTTP(S) 부하 분산기에는 부하 분산기 구성의 일부로 비공개 키와 SSL 인증서가 필요합니다.

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

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

  • 외부 HTTP(S) 부하 분산기 모드에 따라 지원되는 구성 메서드 및 인증서 유형이 결정됩니다. 자세한 내용은 SSL 인증서 개요에서 인증서 및 Google Cloud 부하 분산기를 참조하세요.

SSL 정책

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

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

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

부하 분산기 모드 지원되는 SSL 정책
전역 외부 HTTP(S) 부하 분산기
전역 외부 HTTP(S) 부하 분산기(기본)
리전 외부 HTTP(S) 부하 분산기

백엔드 서비스 및 버킷

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

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

다음 표에서는 각 모드에서 HTTP(S) 부하 분산이 지원하는 백엔드 기능을 명시합니다.


부하 분산기 모드 		백엔드 서비스의 백엔드 지원 백엔드 버킷 지원 Google Cloud Armor 지원 Cloud CDN 지원 IAP 지원
인스턴스 그룹 영역별 NEG 인터넷 NEG 서버리스 NEG 하이브리드 NEG Private Service Connect NEG
전역 외부 HTTP(S) 부하 분산기
전역 외부 HTTP(S) 부하 분산기(기본)
프리미엄 등급 사용 시
리전 외부 HTTP(S) 부하 분산기

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

백엔드 및 VPC 네트워크

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

  • 전역 외부 HTTP(S) 부하 분산기와 전역 외부 HTTP(S) 부하 분산기(기본)의 경우 모든 백엔드가 동일한 프로젝트에 있어야 하지만 서로 다른 VPC 네트워크에 있을 수 있습니다. GFE 프록시 시스템은 해당 VPC 네트워크의 백엔드와 직접 통신하므로 VPC 네트워크 피어링을 사용하여 다른 VPC 네트워크를 연결할 필요가 없습니다.
  • 리전 외부 HTTP(S) 부하 분산기의 경우 모든 백엔드가 같은 VPC 네트워크와 리전에 있어야 합니다.

백엔드 프로토콜

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

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

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

WebSocket 지원

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

WebSocket 프로토콜은 클라이언트와 서버 간의 전이중 통신 채널을 제공합니다. HTTP(S) 요청이 채널을 시작합니다. 프로토콜에 대한 자세한 내용은 RFC 6455를 참조하세요.

부하 분산기가 HTTP(S) 클라이언트의 WebSocket Upgrade 요청을 인식하고 백엔드 인스턴스가 성공적인 Upgrade 응답을 반환하면 부하 분산기는 현재 연결 기간 동안 양방향 트래픽을 프록시합니다. 백엔드 인스턴스가 성공적인 Upgrade 응답을 반환하지 않으면 부하 분산기가 연결을 닫습니다.

WebSocket 연결의 제한 시간은 부하 분산기의 구성 가능한 백엔드 서비스 제한 시간에 따라 달라지며 기본값은 30초입니다. 이 제한 시간은 현재 사용 여부에 상관없이 WebSocket 연결에 적용됩니다.

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(S) 부하 분산기를 구성하려면 인그레스를 사용한 부하 분산용 HTTP/2를 참조하세요.

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

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

상태 점검

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

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

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

상태 점검 프로토콜

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

다음 표에서는 각 모드의 HTTP(S) 부하 분산에서 지원하는 상태 점검 범위를 명시합니다.

부하 분산기 모드 상태 점검 유형
전역 외부 HTTP(S) 부하 분산기 전역
전역 외부 HTTP(S) 부하 분산기(기본) 전역
리전 외부 HTTP(S) 부하 분산기 리전

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

방화벽 규칙

HTTP(S) 부하 분산에는 다음과 같은 방화벽 규칙이 필요합니다.

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

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

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

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

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

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

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

부하 분산기 모드 상태 점검 소스 범위 요청 소스 범위
전역 외부 HTTP(S) 부하 분산기
  • 35.191.0.0/16
  • 130.211.0.0/22
 GFE 트래픽의 소스는 백엔드 유형에 따라 달라집니다.
  • 인스턴스 그룹, 영역별 NEG(GCE_VM_IP_PORT), 하이브리드 연결 NEG(NON_GCP_PRIVATE_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16
  • SERVERLESS NEG 및 백엔드 버킷: Google의 프로덕션 네트워크에서 패킷 라우팅을 처리합니다.
전역 외부 HTTP(S) 부하 분산기(기본)
  • 35.191.0.0/16
  • 130.211.0.0/22
 GFE 트래픽의 소스는 백엔드 유형에 따라 달라집니다.
  • 인스턴스 그룹, 영역별 NEG(GCE_VM_IP_PORT), 하이브리드 연결 NEG(NON_GCP_PRIVATE_IP_PORT):
    • 35.191.0.0/16
    • 130.211.0.0/22
  • 인터넷 NEG(INTERNET_FQDN_PORT 및 INTERNET_IP_PORT):
    • 34.96.0.0/20
    • 34.127.192.0/18
  • SERVERLESS NEG 및 백엔드 버킷: Google의 프로덕션 네트워크에서 패킷 라우팅을 처리합니다.
리전 외부 HTTP(S) 부하 분산기
  • 35.191.0.0/16
  • 130.211.0.0/22

현재 하이브리드 NEG의 상태 점검 프로브는 Google의 중앙 집중식 상태 점검 메커니즘에서 시작됩니다. Google 상태 점검 범위에서 시작된 트래픽이 하이브리드 엔드포인트에 도달하도록 허용할 수 없고 상태 점검 프로브를 비공개 IP 주소에서 시작하게 하려면 분산 Envoy 상태 점검의 허용 목록에 프로젝트가 들어가도록 Google 계정 담당자에게 요청하세요. 		구성할 프록시 전용 서브넷입니다.

공유 VPC 아키텍처

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

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

부하 분산기 프런트엔드 구성요소 백엔드 구성요소
전역 외부 HTTP(S) 부하 분산기
전역 외부 HTTP(S) 부하 분산기(기본)		 전역 외부 IP 주소, 전달 규칙, 대상 HTTP(S) 프록시, 연결된 URL 맵은 백엔드와 동일한 서비스 프로젝트에 정의되어야 합니다. 전역 백엔드 서비스는 백엔드(인스턴스 그룹 또는 NEG)와 동일한 서비스 프로젝트에 정의되어야 합니다. 백엔드 서비스와 관련된 상태 점검은 백엔드 서비스와 동일한 프로젝트에서 정의되어야 합니다.
리전 외부 HTTP(S) 부하 분산기

공유 VPC 호스트 프로젝트에서 필요한 네트워크 및 프록시 전용 서브넷을 만듭니다.

리전 외부 IP 주소, 전달 규칙, 대상 HTTP(S) 프록시, 연결된 URL 맵이 동일한 프로젝트에 정의되어야 합니다. 이 프로젝트는 호스트 프로젝트 또는 서비스 프로젝트일 수 있습니다.

 다음 중 하나를 실행하세요.
  • 프런트엔드 구성요소와 동일한 서비스 프로젝트에서 백엔드 서비스와 백엔드(인스턴스 그룹, 서버리스 NEG 또는 기타 지원되는 백엔드 유형)를 만듭니다.
  • 백엔드 서비스와 백엔드 (인스턴스 그룹, 서버리스 NEG, 기타 지원되는 백엔드 유형)를 필요한 만큼 많은 서비스 프로젝트에 만듭니다. 단일 URL 맵은 서로 다른 프로젝트의 백엔드 서비스를 참조할 수 있습니다. 이러한 유형의 배포를 프로젝트 간 서비스 참조라고 합니다.

각 백엔드 서비스는 참조하는 백엔드와 동일한 프로젝트에서 정의되어야 합니다. 백엔드 서비스와 관련된 상태 점검은 백엔드 서비스와 동일한 프로젝트에서 정의되어야 합니다.

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

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

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

또한 프로젝트 간 서비스 참조를 지원하는 리전별 외부 HTTP(S) 부하 분산기의 경우 백엔드 서비스, 서버리스 NEG, Cloud Run 서비스가 항상 동일한 서비스 프로젝트에 있어야 합니다.

교차 프로젝트 서비스 참조

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

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

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

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

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

교차 프로젝트 서비스 참조는 인스턴스 그룹, 서버리스 NEG, 기타 지원되는 백엔드 유형에서 사용할 수 있습니다. 서버리스 NEG를 사용하는 경우 부하 분산기의 프런트엔드를 만들려는 VPC 네트워크에 VM을 만들어야 합니다. VM을 만드는 방법을 알아보려면 Cloud Run으로 리전 외부 HTTP(S) 부하 분산기 설정을 참조하세요.

전역 외부 HTTP(S) 부하 분산기 및 전역 외부 HTTP(S) 부하 분산기(기본)에서는 교차 프로젝트 서비스 참조가 지원되지 않습니다.

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

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

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

서비스 프로젝트의 부하 분산기 프런트엔드 및 URL 맵
다른 서비스 프로젝트의 부하 분산기 프런트엔드 및 백엔드

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

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

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

호스트 프로젝트의 부하 분산기 프런트엔드 및 URL 맵
호스트 프로젝트의 부하 분산기 프런트엔드 및 URL 맵

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

이 모델에서는 모든 부하 분산기 구성요소와 백엔드가 서비스 프로젝트에 있습니다. 이 배포 모델은 모든 HTTP(S) 부하 분산기에서 지원됩니다.

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

공유 VPC 네트워크의 리전 외부 HTTP(S) 부하 분산기
공유 VPC 네트워크의 리전 외부 HTTP(S) 부하 분산기

HTTP(S) 부하 분산에서 연결 작동 방식

전역 외부 HTTP(S) 부하 분산기 연결

전역 외부 HTTP(S) 부하 분산기는 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는 연결 유지 제한 시간 600초를 사용하며 이 제한 시간을 구성할 수 없습니다. 하지만 백엔드 서비스 제한 시간을 설정하여 요청/응답 제한 시간을 구성할 수 있습니다. 밀접하게 관련되어 있지만 HTTP 연결 유지와 TCP 유휴 제한 시간은 동일하지 않습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.

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

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

리전 외부 HTTP(S) 부하 분산기 연결

리전 외부 HTTP(S) 부하 분산기는 Envoy 프록시에 구현된 관리형 서비스입니다. 리전 외부 HTTP(S) 부하 분산기는 프록시 전용 서브넷이라는 공유 서브넷을 사용하여 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 프록시는 연결 유지 제한 시간 600초를 사용하며 이 제한 시간을 구성할 수 없습니다. 하지만 백엔드 서비스 제한 시간을 설정하여 요청/응답 제한 시간을 구성할 수 있습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.

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

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

각 모드의 HTTP(S) 부하 분산 전달 규칙에서 지원하는 프로토콜의 전체 목록은 부하 분산기 기능을 참조하세요.

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

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

전역 외부 HTTP(S) 부하 분산기:

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

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

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

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

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

리전 외부 HTTP(S) 부하 분산기:

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

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

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

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

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

반환 경로

전역 외부 HTTP(S) 부하 분산기의 경우 Google Cloud는 상태 점검을 위해 VPC 네트워크에 정의되지 않은 특수 경로를 사용합니다. 자세한 내용은 부하 분산기 반환 경로를 참조하세요.

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

열린 포트

이 섹션은 GFE를 사용하여 구현된 전역 외부 HTTP(S) 부하 분산기에만 적용됩니다.

GFE에는 동일한 아키텍처에서 실행되는 다른 Google 서비스를 지원하는 열린 포트가 여러 개 있습니다. GFE에서 열려 있을 가능성이 있는 일부 포트 목록을 보려면 전달 규칙: 포트 사양을 참조하세요. GFE에서 실행되는 다른 Google 서비스에 다른 열린 포트가 있을 수 있습니다.

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

  • 포트 스캔(예: nmap 사용)에서는 일반적으로 TCP SYN 프로브를 수행할 때 응답 패킷이나 TCP RST 패킷을 예상하지 않습니다. GFE는 부하 분산기가 프리미엄 등급 IP 주소를 사용하는 경우에 전달 규칙을 구성한 포트와 포트 80 및 443에만 SYN 프로브에 대한 응답으로 SYN-ACK 패킷을 전송합니다. GFE는 부하 분산기의 IP 주소 및 이 전달 규칙에 구성된 대상 포트로 전송된 패킷에 대한 응답으로만 패킷을 백엔드로 전송합니다. 다른 부하 분산기의 IP 주소나 전달 규칙에 구성되지 않은 포트의 부하 분산기 IP 주소로 전송된 패킷은 부하 분산기의 백엔드로 패킷이 전송되지 않습니다. GFE는 Google Cloud Armor와 같은 보안 기능을 구현합니다. Google Cloud Armor 구성이 없더라도 Google 인프라와 GFE에서 DDoS 공격 및 SYN 플러드에 대한 심층 방어를 제공합니다.

  • 부하 분산기의 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 종료

다음 표에는 외부 HTTP(S) 부하 분산기가 각 모드에서 TLS 종료를 처리하는 방법이 요약되어 있습니다.

부하 분산기 모드 TLS 종료
전역 외부 HTTP(S) 부하 분산기 전 세계 어디에나 있을 수 있는 GFE에서 TLS가 종료됩니다.
전역 외부 HTTP(S) 부하 분산기(기본) 전 세계 어디에나 있을 수 있는 GFE에서 TLS가 종료됩니다.
리전 외부 HTTP(S) 부하 분산기 TLS는 사용자가 선택한 리전의 프록시 전용 서브넷에 있는 Envoy 프록시에서 종료됩니다. TLS가 종료되는 리전을 지리적으로 제어해야 하는 경우 이 부하 분산기 모드를 사용합니다.

제한시간 및 재시도

외부 HTTP(S) 부하 분산에는 다음과 같은 제한 시간이 있습니다.

  • 구성 가능한 HTTP 백엔드 서비스 제한 시간: 부하 분산기가 백엔드에서 전체 HTTP 응답을 반환할 때까지 기다리는 시간입니다. 백엔드 서비스 제한 시간 기본값은 30초입니다. 허용되는 제한 시간 값의 전체 범위는 1~2,147,483,647초입니다.

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

    백엔드 서비스 제한 시간은 프록시(GFE 또는 관리형 Envoy)와 백엔드 간의 상호작용에서 요청의 첫 바이트부터 응답의 마지막 바이트까지 경과될 수 있는 최대 시간으로 설정해야 합니다. WebSocket을 사용하는 경우 백엔드 서비스 제한 시간은 유휴 또는 활성 WebSocket의 최대 기간으로 설정해야 합니다.

    다음과 같은 상황에서는 이 제한 시간을 늘리는 것이 좋습니다.

    • 백엔드에서 HTTP 응답을 반환하는 데 시간이 더 오래 걸릴 것으로 예상되는 경우
    • jsonPayload.statusDetail client_timed_out인 HTTP 408 응답이 표시됩니다.
    • 연결이 WebSocket으로 업그레이드된 경우

    설정된 백엔드 서비스 제한 시간은 최선의 목표입니다. 기본 TCP 연결이 제한 시간 동안 계속 열려 있다는 보장은 없습니다.

    백엔드 서비스 제한 시간을 원하는 값으로 설정할 수 있지만, 1일(86,400초) 이상의 값으로 설정하여도 부하 분산기가 TCP 연결을 해당 시간만큼 계속 유지한다는 보장은 없습니다. Google은 소프트웨어 업데이트 및 정기 유지보수를 위해 GFE 및 Envoy 소프트웨어 작업을 주기적으로 다시 시작하며, 백엔드 서비스 제한 시간은 이를 재정의하지 않습니다. 백엔드 서비스 제한 시간을 길게 설정할수록 Google에서 유지보수를 위한 TCP 연결을 종료할 가능성이 높습니다. 이러한 이벤트의 영향을 줄이기 위해 재시도 로직을 구현하는 것이 좋습니다.

    백엔드 서비스 제한 시간은 HTTP 유휴(연결 유지) 제한 시간이 아닙니다. 느린 클라이언트(예: 연결 속도가 느린 브라우저)로 인해 백엔드의 입력과 출력(IO)이 차단될 수 있습니다. 이 대기 시간은 백엔드 서비스 제한 시간에 반영되지 않습니다.

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

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

    리전 외부 HTTP(S) 부하 분산기에서는 URL 맵의 routeActions.timeout 매개변수가 백엔드 서비스 제한 시간을 재정의할 수 있습니다. 백엔드 서비스 제한 시간이 routeActions.timeout의 기본값으로 사용됩니다.

  • 백엔드 버킷을 전역 외부 HTTP(S) 부하 분산기 및 전역 외부 HTTP(S) 부하 분산기(기본)와 함께 사용하는 경우 두 가지 제한 시간이 적용됩니다.
    • 유휴 제한 시간은 6분으로 고정됩니다. 즉, 백엔드 버킷 HTTP 스트림은 6분 동안 활동이 없으면 유휴 상태로 간주됩니다.
    • 부하 분산기와 Cloud Storage에서 사용한 전체 응답 처리 시간을 포함하는 또 다른 제한 시간이 적용됩니다. 이 제한 시간은 24시간으로 고정됩니다.
  • HTTP 연결 유지 제한 시간: 값이 10분(600초)으로 고정됩니다. 백엔드 서비스를 수정하는 방법으로 이 값을 구성할 수 없습니다. 백엔드가 사용하는 웹 서버 소프트웨어는 백엔드가 연결을 조기에 닫지 않도록 연결 유지 제한시간을 600초보다 길게 설정해야 합니다. 이 제한 시간은 WebSocket에는 적용되지 않습니다. 다음 표는 일반적인 웹 서버 소프트웨어의 연결 유지 제한 시간을 수정할 때 필요한 변경사항을 보여줍니다.
    웹 서버 소프트웨어 매개변수 기본 설정 권장 설정
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

재시도

재시도 로직에 대한 HTTP(S) 부하 분산 지원은 외부 HTTP(S) 부하 분산기의 모드에 따라 다릅니다.

부하 분산기 모드 재시도 로직
전역 외부 HTTP(S) 부하 분산기

URL 맵에서 재시도 정책을 사용하여 구성할 수 있습니다. 기본 재시도 횟수(numRetries)는 1입니다. 재시도 정책을 사용하여 구성할 수 있는 최대 재시도 횟수는 25입니다. 각 시도의 기본 제한 시간(perTryTimeout)은 30초이며 구성 가능한 최대 perTryTimeout은 24시간입니다.

재시도 정책이 없으면 HTTP 본문이 없는 실패한 요청(예: GET 요청)은 HTTP 502, 503 또는 504 응답(retryConditions=["gateway-error"])이 한 번만 재시도됩니다. HTTP POST 요청은 재시도되지 않습니다.

재시도한 요청은 최종 응답의 로그 항목을 하나만 생성합니다.
전역 외부 HTTP(S) 부하 분산기(기본)

연결 재시도에 대한 재시도 정책을 변경할 수 없습니다.

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

HTTP GET 요청은 백엔드의 80% 이상이 정상인 경우 항상 재시도됩니다. 그룹에 백엔드 인스턴스가 하나만 있는데 이 백엔드 인스턴스에 연결하지 못할 경우 비정상 백엔드 인스턴스의 비율이 100%이므로 GFE에서 요청을 재시도하지 않습니다.

부하 분산기는 백엔드 서비스 제한 시간이 발생하는 경우와 같은 특정 상황에서 실패한 GET 요청을 재시도합니다. 요청 재시도는 25회로 제한됩니다. 재시도한 요청은 최종 응답의 로그 항목을 하나만 생성합니다. 자세한 내용은 HTTP(S) 부하 분산 로깅 및 모니터링을 참조하세요.

요청이 실패하면 부하 분산기가 HTTP 502 응답을 생성합니다.
리전 외부 HTTP(S) 부하 분산기

URL 맵에서 재시도 정책을 사용하여 구성할 수 있습니다. 기본 재시도 횟수(numRetries)는 1입니다. 재시도 정책을 사용하여 구성할 수 있는 최대 재시도 횟수는 25입니다. 각 시도의 기본 제한 시간(perTryTimeout)은 30초이며 구성 가능한 최대 perTryTimeout은 24시간입니다.

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

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

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

잘못된 요청 및 응답 처리

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

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

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

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

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

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

  • 응답 헤더의 총 크기가 외부 HTTP(S) 부하 분산의 최대 응답 헤더 크기 한도를 초과합니다.
  • HTTP 버전을 알 수 없습니다.

트래픽 분산

백엔드 인스턴스 그룹 또는 NEG를 백엔드 서비스에 추가할 때 백엔드 로드 및 대상 용량을 측정하는 방법을 정의하는 분산 모드를 지정합니다. 외부 HTTP(S) 부하 분산은 두 가지 분산 모드를 지원합니다.

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

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

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

전역 외부 HTTP(S) 부하 분산기

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

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

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

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

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

리전 외부 HTTP(S) 부하 분산기

리전 외부 HTTP(S) 부하 분산기의 경우 트래픽 분산은 부하 분산 모드 및 부하 분산 지역 정책을 기반으로 합니다.

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

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

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

요청 분산 방법

트래픽이 리전별로 분산되는지 아니면 전역으로 배포되는지 여부는 사용 중인 부하 분산기 모드 및 네트워크 서비스 등급에 따라 다릅니다.

프리미엄 등급:

  • Google에서는 전 세계 모든 접속 지점에서 부하 분산기의 IP 주소를 공지합니다. 각 부하 분산기 IP 주소는 전역 Anycast입니다.
  • 여러 리전에서 백엔드로 백엔드 서비스를 구성하면 Google 프런트엔드(GFE)는 사용자에게 가장 가까운 리전의 정상 백엔드 인스턴스 그룹 또는 NEG로 요청을 전달하려고 시도합니다. 프로세스 세부정보는 이 페이지에 설명되어 있습니다.

표준 등급:

  • Google이 전달 규칙의 리전과 연결된 접속 지점에서 부하 분산기 IP 주소를 공지합니다. 부하 분산기에서 리전 외부 IP 주소를 사용합니다.

  • 전달 규칙과 동일한 리전에서 백엔드를 구성할 수 있습니다. 여기에서 설명한 프로세스가 계속 적용되지만 부하 분산기에서 해당 리전 한 곳의 정상 백엔드로만 요청을 전달합니다.

요청 분배 프로세스:

분산 모드와 선택한 대상에 따라 각 영역별 GCE_VM_IP_PORT NEG, 영역 인스턴스 그룹 또는 리전 인스턴스 그룹 영역의 관점에서 백엔드의 가득 찬 상태가 정의됩니다. 영역 내 분배는 전역 외부 HTTP(S) 부하 분산기(기본)의 일관된 해싱으로 수행되며 전역 외부 HTTP(S) 부하 분산기 및 리전 외부 HTTP(S) 부하 분산기의 부하 분산 지역 정책을 사용하여 구성 가능합니다.

GFE 기반 전역 외부 HTTP(S) 부하 분산기는 다음 프로세스를 사용하여 수신 요청을 분산합니다.

  1. 전달 규칙의 외부 IP 주소는 Google 네트워크 경계의 에지 라우터에서 공지됩니다. 각 공지는 레이어 3/4 부하 분산 시스템(Maglev)에 대한 다음 홉을 나열합니다.
  2. Maglev 시스템은 트래픽을 첫 번째 레이어 Google 프런트엔드(GFE)로 라우팅합니다. 첫 번째 레이어 GFE에서 필요한 경우 TLS를 종료한 후 이 프로세스에 따라 두 번째 레이어 GFE로 트래픽을 라우팅합니다.
    1. URL 맵에서 백엔드 서비스를 선택합니다.
    2. 백엔드 서비스가 인스턴스 그룹 또는 GCE_VM_IP_PORT NEG 백엔드를 사용하는 경우 첫 번째 레이어 GFE는 인스턴스 그룹 또는 NEG가 포함된 리전이나 그 근처에 있는 두 번째 레이어 GFE를 선호합니다.
    3. 하이브리드 NEG, 서버리스 NEG, 인터넷 NEG가 있는 백엔드 버킷 및 백엔드 서비스의 경우 첫 번째 레이어 GFE는 리전 하위 집합의 두 번째 레이어 GFE를 선택하여 두 GFE 간의 왕복 시간이 최소화됩니다.

      두 번째 레이어 GFE 환경설정은 보장되는 것은 아니며 Google의 네트워크 조건 및 유지보수에 따라 동적으로 변경될 수 있습니다.

      두 번째 레이어 GFE는 상태 점검 상태와 실제 백엔드 용량 사용량을 인식합니다.

  3. 두 번째 레이어 GFE가 해당 리전의 영역에 있는 백엔드로 요청을 전달합니다.
  4. 프리미엄 등급의 경우 두 번째 레이어 GFE가 다른 리전의 영역에 있는 백엔드로 요청을 보내는 경우가 있습니다. 이러한 동작을 스필오버라고 합니다.

    5. 스필오버에는 다음 두 가지 원칙이 적용됩니다.

    • 두 번째 레이어 GFE에 알려진 모든 백엔드가 용량에 도달하거나 비정상이면 스필오버가 가능합니다.
    • 두 번째 레이어 GFE에는 다른 리전의 영역에서 사용 가능한 정상 백엔드에 대한 정보가 포함됩니다.

    두 번째 레이어 GFE는 일반적으로 백엔드 위치의 하위 집합에 대응하도록 구성됩니다.

    스필오버 동작으로 가능한 모든 Google Cloud 영역이 소진되지 않습니다. 특정 영역 또는 전체 리전의 백엔드로 트래픽을 전달하지 않으려면 용량 확장 처리를 0으로 설정해야 합니다. 상태 점검이 실패하도록 백엔드를 구성해도 두 번째 레이어 GFE가 다른 리전의 영역에 있는 백엔드로 스필오버된다고 보장할 수 없습니다.

  5. 요청을 백엔드로 분산할 때 GFE는 영역 수준에서 운영됩니다.

    초당 요청 수가 적은 경우 두 번째 레이어 GFE가 다른 영역보다 리전의 한 영역을 선호하는 경우가 있습니다. 이 선호 사항은 정상이며 예상할 수 있습니다. 부하 분산기가 초당 더 많은 요청을 받기 전에는 리전의 영역 간 분산이 일정하지 않습니다.

세션 어피니티

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

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

HTTP(S) 부하 분산은 다음과 같은 유형의 세션 어피니티를 제공합니다.

다음 표에는 각 HTTP(S) 부하 분산 모드에 대해 지원되는 세션 어피니티 옵션이 요약되어 있습니다.

부하 분산기 모드 세션 어피니티 옵션
  없음 클라이언트 IP 생성된 쿠키 헤더 필드 HTTP 쿠키
전역 외부 HTTP(S) 부하 분산기
전역 외부 HTTP(S) 부하 분산기(기본)
리전 외부 HTTP(S) 부하 분산기

HTTP/2 지원

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 및 Google QUIC 지원

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

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

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

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

다음 표에서는 각 모드의 HTTP(S) 부하 분산에 대한 HTTP/3 지원을 지정합니다.

부하 분산기 모드 HTTP/3 지원
전역 외부 HTTP(S) 부하 분산기(항상 프리미엄 등급)
프리미엄 등급의 전역 외부 HTTP(S) 부하 분산기(기본)
표준 등급의 전역 외부 HTTP(S) 부하 분산기(기본)
리전 외부 HTTP(S) 부하 분산기(항상 표준 등급)

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이 외부 HTTP(S) 부하 분산기의 targetHttpsProxy 리소스에서 ENABLE로 구성되면 부하 분산기의 응답에 다음 alt-svc 헤더 값이 포함됩니다.

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

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 구성

quicOverride를 ENABLE로 설정하여 부하 분산기에 대해 HTTP/3 지원을 명시적으로 사용 설정할 수 있습니다.

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

HTTP(S) 부하 분산은 다음 표와 같이 HTTP/3를 구성하는 세 가지 방법을 제공합니다.

quicOverride 값 동작
NONE

HTTP/3에 대한 지원은 클라이언트에 공지됩니다.

ENABLE

HTTP/3 및 Google QUIC 지원은 클라이언트에 공지됩니다. HTTP/3은 더 높은 우선순위로 공지됩니다. 두 프로토콜을 모두 지원하는 클라이언트는 Google QUIC보다 HTTP/3을 사용해야 합니다.

참고: TLS 0-RTT(TLS 조기 데이터라고도 함)는 클라이언트에서 Google QUIC를 협상할 때 암시적으로 지원되지만 HTTP/3가 사용되는 경우 지원되지 않습니다.

DISABLE 클라이언트에 HTTP/3 및 Google QUIC 공지를 명시적으로 사용 중지합니다.

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

콘솔: HTTPS

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

    부하 분산으로 이동

  2. 수정할 부하 분산기를 선택합니다.

  3. 프런트엔드 구성을 클릭합니다.

  4. 수정할 프런트엔드 IP 주소와 포트를 선택합니다. HTTP/3 구성을 수정하려면 IP 주소 및 포트가 HTTPS(포트 443)여야 합니다.

HTTP/3 사용 설정

  1. QUIC 협상 드롭다운을 선택합니다.
  2. 이 프런트엔드에 HTTP/3을 명시적으로 사용 설정하려면 사용 설정을 선택합니다.
  3. IPv4 및 IPv6을 나타내는 여러 프런트엔드 규칙이 있는 경우 각 규칙에 HTTP/3을 사용 설정해야 합니다.

HTTP/3 사용 중지

  1. QUIC 협상 드롭다운을 선택합니다.
  2. 이 프런트엔드에 대해 HTTP/3을 명시적으로 사용 중지하려면 사용 중지를 선택합니다.
  3. IPv4 및 IPv6을 나타내는 여러 프런트엔드 규칙이 있는 경우 각 규칙에 대해 HTTP/3을 사용 중지해야 합니다.

gcloud: HTTPS

이 명령어를 실행하기 전에 각 인증서에 SSL 인증서 리소스를 만들어야 합니다.

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

QUIC_SETTING를 다음 중 하나로 바꿉니다.

  • NONE (기본값): Google이 HTTP/3을 공지할 시기를 제어합니다.

    현재 NONE을 선택하면 HTTP/3이 클라이언트에 공지되지만 Google QUIC는 공지되지 않습니다.

    Google Cloud 콘솔에서는 이 옵션을 자동(기본값)이라고 합니다.

  • ENABLE: 클라이언트에 HTTP/3 및 Google QUIC 공지합니다.

  • DISABLE: 클라이언트에 HTTP/3 또는 Google QUIC를 공지하지 않습니다.

API: HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

QUIC_SETTING를 다음 중 하나로 바꿉니다.

  • NONE (기본값): Google이 HTTP/3을 공지할 시기를 제어합니다.

    현재 NONE을 선택하면 HTTP/3이 클라이언트에 공지되지만 Google QUIC는 공지되지 않습니다.

    Google Cloud 콘솔에서는 이 옵션을 자동(기본값)이라고 합니다.

  • ENABLE: 클라이언트에 HTTP/3 및 Google QUIC 공지합니다.

  • DISABLE: 클라이언트에 HTTP/3 또는 Google QUIC를 공지하지 않습니다.

제한사항

  • HTTPS 부하 분산기는 클라이언트 인증서 기반 인증(상호 TLS 인증이라고도 함)을 지원하지 않습니다.
  • HTTPS 부하 분산기는 SSL 연결을 종료할 때 close_notify 폐쇄 알림을 전송하지 않습니다. 즉, 부하 분산기는 SSL 종료를 수행하는 대신 TCP 연결을 종료합니다.
  • HTTPS 부하 분산기는 인증서의 일반 이름(CN) 속성 또는 주체 대체 이름(SAN) 속성에서 도메인에 소문자만 지원합니다. 도메인에 대문자가 포함된 인증서는 대상 프록시에서 기본 인증서로 설정된 경우에만 반환됩니다.
  • HTTPS 부하 분산기는 백엔드에 연결할 때 인터넷 NEG 백엔드가 있는 부하 분산기를 제외하고 서버 이름 표시(SNI) 확장 프로그램을 사용하지 않습니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.
  • 공유 VPC 환경에서 Cloud Run과 함께 리전 외부 HTTP(S) 부하 분산기를 사용하는 경우 서비스 프로젝트의 독립형 VPC 네트워크는 동일한 공유 VPC 환경 내의 다른 서비스 프로젝트에 배포된 다른 Cloud Run 서비스로 트래픽을 보낼 수 있습니다. 이는 알려진 문제이며 향후 이 양식의 액세스가 차단됩니다.
  • Google Cloud Armor를 사용한 WAF용 reCAPTCHA Enterprise는 전역 외부 HTTP(S) 부하 분산기(기본)에서만 지원됩니다. 고급 트래픽 관리 기능이 있는 전역 외부 HTTP(S) 부하 분산기에서는 지원되지 않습니다.

다음 단계