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

Google Cloud 내부 HTTP(S) 부하 분산은 프록시 기반의 리전별 레이어 7 부하 분산기로 내부 IP 주소를 지원하는 서비스를 실행하고 확장할 수 있습니다.

내부 HTTP(S) 부하 분산은 HTTP 및 HTTPS 트래픽을 Compute Engine 및 Google Kubernetes Engine(GKE)에서 호스팅되는 백엔드에 배포합니다. 부하 분산기는 내부 IP 주소의 Virtual Private Cloud(VPC) 네트워크에서 선택한 리전에서만 액세스할 수 있습니다.

내부 HTTP(S) 부하 분산은 오픈소스 Envoy 프록시를 기반으로 하는 관리형 서비스입니다. 이를 통해 HTTP(S) 매개변수 기반의 풍부한 트래픽 제어 기능을 사용할 수 있습니다. 부하 분산기가 구성된 후에는 트래픽 요건에 맞게 Envoy 프록시를 자동으로 할당합니다.

대략적으로 내부 HTTP(S) 부하 분산기는 다음과 같이 구성됩니다.

  • 클라이언트가 트래픽을 전송하는 내부 IP 주소. 부하 분산기와 동일한 리전에 있는 클라이언트만이 IP 주소에 액세스할 수 있습니다. 내부 클라이언트 요청은 네트워크 및 리전 내부에서 유지됩니다.
  • 부하 분산기가 트래픽을 전달하는 하나 이상의 백엔드 서비스. 백엔드는 Compute Engine VM, Compute Engine VM 그룹(인스턴스 그룹을 통해) 또는 GKE 노드(네트워크 엔드포인트 그룹[NEG]을 통해)일 수 있습니다. 이러한 백엔드는 부하 분산기와 동일한 리전에 있어야 합니다.
레이어 7 기반 부하 분산을 사용하는 내부 서비스(확대하려면 클릭)
레이어 7 기반 부하 분산을 사용하는 내부 서비스(확대하려면 클릭)

내부 HTTP(S) 부하 분산과 관련된 제한사항은 제한사항 섹션을 참조하세요.

Google Cloud 부하 분산기의 차이점에 대한 자세한 내용은 다음 문서를 참조하세요.

사용 사례

내부 HTTP(S) 부하 분산은 여러 사용 사례를 다룹니다. 이 섹션에서는 몇 가지 개략적인 예시를 설명합니다. 추가 예시는 트래픽 관리 사용 사례를 참조하세요.

3계층 웹 서비스

내부 HTTP(S) 부하 분산을 사용하여 기존의 3계층 웹 서비스를 지원할 수 있습니다. 다음 예시에서는 3가지 유형의 Google Cloud 부하 분산기를 사용하여 3계층을 확장하는 방법을 보여줍니다. 각 계층에서 부하 분산기 유형은 트래픽 유형에 따라 다릅니다.

  • 웹 계층: 트래픽이 인터넷에서 들어오고 외부 HTTP(S) 부하 분산기를 사용하여 부하 분산됩니다.

  • 애플리케이션 계층: 애플리케이션 계층은 리전별 내부 HTTP(S) 부하 분산기를 사용하여 확장됩니다.

  • 데이터베이스 계층: 데이터베이스 계층은 내부 TCP/UDP 부하 분산기를 사용하여 확장됩니다.

다이어그램은 트래픽이 계층을 통해 이동하는 방식을 보여줍니다.

  1. 외부 HTTP(S) 부하 분산기는 인터넷 트래픽을 다양한 리전의 웹 프런트엔드 인스턴스 그룹 집합에 배포합니다.
  2. 이러한 프런트엔드는 HTTP(S) 트래픽을 일련의 리전별 내부 HTTP(S) 부하 분산기(이 개요의 대상)로 전송합니다.
  3. 내부 HTTP(S) 부하 분산기는 미들웨어 인스턴스 그룹으로 트래픽을 분산합니다.
  4. 이러한 미들웨어 인스턴스 그룹은 내부 TCP/UDP 부하 분산기로 트래픽을 전송하여 트래픽 부하를 데이터 스토리지 클러스터에 분산합니다.
다중 계층 앱의 내부 계층을 위한 레이어 7 기반 라우팅(확대하려면 클릭)
다중 계층 앱의 내부 계층을 위한 레이어 7 기반 라우팅(확대하려면 클릭)

경로 기반 라우팅을 사용한 부하 분산

한 가지 일반적인 사용 사례는 여러 서비스로 트래픽 부하를 분산하는 것입니다. 이 예시에서 내부 클라이언트는 /video/images 경로를 포함한 동일한 기본 URL인 mygcpservice.internal을 사용하여 동영상 및 이미지 콘텐츠를 요청할 수 있습니다.

내부 HTTP(S) 부하 분산기의 URL 맵은 경로 /video에 대한 요청을 동영상 백엔드 서비스로 보내고 경로 /images에 대한 요청은 이미지 백엔드 서비스로 보내도록 지정합니다. 다음 예시에서 동영상 및 이미지 백엔드 서비스는 Compute Engine VM을 사용하여 제공되지만 GKE Pod를 사용하여 제공할 수도 있습니다.

내부 클라이언트가 부하 분산기의 내부 IP 주소로 요청을 보내면 부하 분산기는 이 로직에 따라 요청을 평가하고 올바른 백엔드 서비스로 보냅니다.

다음 다이어그램은 이 사용 사례를 보여줍니다.

레이어 7 기반 부하 분산을 사용하는 내부(마이크로) 서비스(확대하려면 클릭)
레이어 7 기반 부하 분산을 사용하는 내부(마이크로) 서비스

기존 서비스 현대화하기

내부 HTTP(S) 부하 분산은 기존 애플리케이션을 현대화하는데 효과적인 도구입니다.

기존 애플리케이션의 한 가지 예시로는 쉽게 업데이트할 수 없는 대형 모놀리식 애플리케이션이 있습니다. 이 경우 기존 애플리케이션 앞에 내부 HTTP(S) 부하 분산기를 배포할 수 있습니다. 그런 다음 부하 분산기의 트래픽 제어 기능을 사용하여 트래픽 하위 집합을 기존 애플리케이션이 제공하는 기능을 대체하는 새로운 마이크로서비스로 전달할 수 있습니다.

시작하려면 기본적으로 모든 트래픽을 기존 애플리케이션에 라우팅하도록 부하 분산기의 URL 맵을 구성합니다. 이러면 기존 동작을 유지합니다. 대체 서비스가 개발되면 트래픽의 일부를 대체 서비스로 라우팅하도록 URL 맵을 업데이트합니다.

내부 클라이언트가 /video로 요청을 보낼 때 제공되는 일부 동영상 처리 기능이 기존 애플리케이션에 포함되어 있다고 가정해 보겠습니다. 이 동영상 서비스를 다음과 같이 별도의 마이크로서비스로 나눌 수 있습니다.

  1. 내부 HTTP(S) 부하 분산을 기존 애플리케이션 앞에 추가합니다.
  2. 대체 동영상 처리 마이크로서비스를 만듭니다.
  3. 경로 /video에 대한 모든 요청이 기존 애플리케이션이 아닌 새 마이크로서비스로 라우팅되도록 부하 분산기의 URL 맵을 업데이트합니다.

추가 대체 서비스를 개발하면 URL 맵을 계속 업데이트합니다. 시간이 지나면 기존 애플리케이션으로 라우팅되는 요청이 줄어듭니다. 결국 대체 서비스는 기존 애플리케이션에서 제공한 모든 기능에 적용됩니다. 이 시점에서 기존 애플리케이션을 폐기할 수 있습니다.

아키텍처 및 리소스

다음 다이어그램은 내부 HTTP(S) 부하 분산기에 필요한 Google Cloud 리소스를 보여줍니다.

내부 HTTP(S) 부하 분산 구성요소(확대하려면 클릭)
내부 HTTP(S) 부하 분산 구성요소

각 내부 HTTP(S) 부하 분산기는 다음과 같은 Google Cloud 구성 리소스를 사용합니다.

프록시 전용 서브넷

위의 다이어그램에서 프록시 전용 서브넷은 Google이 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 제공합니다. 내부 HTTP 부하 분산기를 사용하는 VPC 네트워크의 각 리전에 하나의 프록시 전용 서브넷을 만들어야 합니다. 리전 및 VPC 네트워크의 모든 내부 HTTP(S) 부하 분산기는 리전 및 VPC 네트워크의 모든 내부 HTTP 부하 분산기가 Envoy 프록시 풀을 공유하므로 동일한 프록시 전용 서브넷을 공유합니다. 그 밖에도 다음과 같습니다.

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

전달 규칙 및 IP 주소

내부 관리형 전달 규칙은 내부 IP 주소, 포트, 리전 대상 HTTP(S) 프록시를 지정합니다. 클라이언트는 IP 주소와 포트를 사용하여 부하 분산기의 Envoy 프록시에 연결합니다. 전달 규칙의 IP 주소는 부하 분산기의 IP 주소입니다(가상 IP 주소 또는 VIP라고도 함).

내부 HTTP(S) 부하 분산기에 연결하는 클라이언트는 HTTP 버전 1.1 이상을 사용해야 합니다. 지원되는 전체 프로토콜 목록은 부하 분산기 기능을 참조하세요.

전달 규칙에 연결된 내부 IP 주소는 --purpose 플래그가 PRIVATE으로 설정된 동일한 네트워크 및 리전의 모든 서브넷에서 가져올 수 있습니다. 다음 사항을 참고하세요.

  • IP 주소는 백엔드 인스턴스 그룹과 동일한 서브넷에서 가져올 수 있지만 반드시 그럴 필요는 없습니다.
  • IP 주소는 --purpose 플래그가 INTERNAL_HTTPS_LOAD_BALANCER로 설정된 예약된 프록시 전용 서브넷에서 가져오지 않아야 합니다.

내부 HTTP(S) 부하 분산기에서 사용하는 전달 규칙마다 정확하게 TCP 포트 하나를 참조할 수 있습니다. HTTP 부하 분산기의 경우 포트 80 또는 8080 중 하나를 사용합니다. HTTPS 부하 분산기의 경우 포트 443을 사용합니다.

대상 프록시

리전 대상 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 주소를 기록할 수 있습니다.

SSL 인증서

HTTPS 기반 부하 분산을 사용할 경우 대상 HTTPS 프록시에 SSL 인증서를 한 개 이상 설치해야 합니다.

이러한 인증서는 대상 HTTPS 프록시에서 부하 분산기와 클라이언트 간의 통신을 보호하는 데 사용됩니다.

SSL 인증서 한도 및 할당량에 대한 자세한 내용은 부하 분산 할당량 페이지의 SSL 인증서를 참조하세요.

최고 수준의 보안을 위해 HTTPS 부하 분산기 배포에 엔드 투 엔드 암호화를 사용하세요. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.

Google에서 사용자 트래픽을 암호화하는 방법에 대한 일반적인 내용은 Google Cloud의 전송 중인 데이터 암호화 백서를 참조하세요.

URL 맵

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

백엔드 서비스

리전별 백엔드 서비스는 정상적인 백엔드(Compute Engine VM을 포함하는 인스턴스 그룹 또는 GKE 컨테이너를 포함하는 NEG)에 요청을 배포합니다.

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

하나 이상의 백엔드가 백엔드 서비스에 연결되어 있어야 합니다. 내부 HTTP(S) 부하 분산기의 범위는 전역이 아닌 리전이므로 클라이언트와 백엔드 VM 또는 엔드포인트는 모두 동일한 리전에 있어야 합니다. 백엔드는 다음 구성의 인스턴스 그룹 또는 NEG일 수 있습니다.

  • 관리형 인스턴스 그룹(영역 또는 리전)
  • 비관리형 인스턴스 그룹(영역)
  • 네트워크 엔드포인트 그룹(영역)

인스턴스 그룹과 NEG는 동일한 백엔드 서비스에서 사용할 수 없습니다.

상태 확인

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

방화벽 규칙

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

제한 시간 및 재시도

백엔드 서비스 제한 시간은 HTTP(S) 트래픽에 대한 요청/응답 제한 시간입니다. 이 값은 백엔드가 요청에 대한 응답을 모두 반환할 때까지 부하 분산기가 대기하는 시간입니다.

예를 들어 백엔드 서비스 제한 시간이 기본값인 30초인 경우 백엔드가 요청에 응답할 수 있는 시간은 30초입니다. 백엔드가 부하 분산기에 응답 헤더를 전송하기 전에 연결을 닫거나 시간이 초과되면 부하 분산기가 HTTP GET 요청을 다시 시도합니다. 백엔드가 응답 헤더를 전송하거나 백엔드로 전송된 요청이 HTTP GET 요청이 아닌 경우 부하 분산기는 재시도하지 않습니다. 백엔드가 전혀 응답하지 않으면 부하 분산기가 클라이언트에 HTTP 5xx 응답을 반환합니다. 이러한 부하 분산기의 경우 백엔드가 요청에 응답하는 시간을 늘리거나 줄이려면 제한 시간 값을 변경합니다.

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

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

    • 백엔드에서 HTTP 응답을 반환하는 데 시간이 더 오래 걸릴 것으로 예상되는 경우
    • 연결이 WebSocket으로 업그레이드된 경우

부하 분산기를 통해 전송된 WebSocket 트래픽의 경우 백엔드 서비스 제한 시간은 유휴 상태 여부에 상관없이 WebSocket 연결이 열린 상태로 유지될 수 있는 최대 시간으로 해석됩니다. 자세한 내용은 백엔드 서비스 설정을 참조하세요.

  • TCP 세션 제한 시간: 값이 10분(600초)으로 고정됩니다. 이 세션 제한 시간은 연결 유지 또는 유휴 제한 시간이라고도 하며 백엔드 서비스를 수정하는 방법으로 값을 구성할 수 없습니다. 백엔드에서 사용하는 웹 서버 소프트웨어는 백엔드가 연결을 조기에 닫지 않도록 연결 유지 제한 시간을 600초보다 길게 설정해야 합니다. 이 제한 시간은 WebSocket에는 적용되지 않습니다.

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

웹 서버 소프트웨어 매개변수 기본 설정 권장 설정
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
  • 해당 값이 백엔드 서비스 제한 시간과 동일한 유휴 상태 제한 시간입니다. 이 기간 동안 활동이 없으면 HTTP 스트림 및 웹소켓 연결이 유휴 상태가 됩니다.
  • 부하 분산기는 백엔드 서비스 제한 시간이 발생하는 경우와 같은 특정 상황에서 실패한 GET 요청을 재시도합니다. 실패한 POST 요청은 다시 시도하지 않습니다. 재시도는 2회로 제한됩니다. 재시도한 요청은 최종 응답의 로그 항목을 하나만 생성합니다.

    자세한 내용은 내부 HTTP(S) 부하 분산 로깅 및 모니터링을 참조하세요.

    연결된 네트워크 액세스

    다음을 사용하여 연결된 네트워크에서 VPC 네트워크의 내부 HTTP(S) 부하 분산기에 액세스할 수 있습니다.

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

    자세한 예시는 내부 HTTP(S) 부하 분산 및 연결된 네트워크를 참조하세요.

    장애 조치

    백엔드가 비정상이 되면 트래픽은 자동으로 동일한 리전에 있는 정상 백엔드로 리디렉션됩니다. 모든 백엔드가 비정상이면 부하 분산기가 HTTP 503 Service Unavailable 응답을 반환합니다.

    WebSocket 지원

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

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

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

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

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

    공유 VPC 아키텍처

    내부 HTTP(S) 부하 분산은 공유 VPC를 사용하는 네트워크를 지원합니다. 공유 VPC에 대해 잘 모른다면 공유 VPC 개요 문서를 참조하세요.

    내부 HTTP(S) 부하 분산과 관련하여 공유 VPC 네트워크 내에서 부하 분산을 구성하는 방법에는 두 가지가 있습니다. 서비스 프로젝트 또는 호스트 프로젝트에서 부하 분산기와 백엔드 인스턴스를 만들 수 있습니다.

    서비스 프로젝트의 부하 분산기 및 백엔드

    이 모델에서는 부하 분산기와 백엔드가 서비스 프로젝트에 있으며 공유 VPC 네트워크 서브넷의 IP 주소를 사용합니다.

    이 배포 모델은 일반적인 공유 VPC 사용 사례와 매우 유사합니다.

    • 네트워크 관리와 서비스 개발 간의 책임을 분할하면 네트워크 관리자와 서비스 개발자 간의 책임이 명확하게 구분되어 유지됩니다.
    • 네트워크 관리자가 내부 IP 주소를 안전하고 효율적으로 관리할 수 있습니다.
    공유 VPC 네트워크에서 내부 HTTP(S) 부하 분산
    공유 VPC 네트워크에서 내부 HTTP(S) 부하 분산

    호스트 프로젝트

    호스트 프로젝트에서 다음을 수행합니다.

    서비스 프로젝트

    • 서비스 프로젝트의 소유자, 편집자 또는 보다 세분화된 역할(예: Compute 관리자)은 백엔드 인스턴스를 만듭니다.
    • 서비스 프로젝트의 소유자, 편집자 또는 보다 세분화된 역할(예: 네트워크 관리자 또는 부하 분산기 관리자)은 부하 분산기 구성요소(전달 규칙, 대상 HTTP(S) 프록시, URL 맵, 백엔드 서비스, 상태 확인)를 만듭니다.
    • 이러한 부하 분산 리소스와 백엔드 인스턴스는 호스트 프로젝트의 공유 VPC 네트워크와 서브넷을 참조합니다.

    클라이언트가 부하 분산기와 동일한 공유 VPC 네트워크 및 리전에 있으면 부하 분산기에 액세스할 수 있습니다. 클라이언트는 서비스 프로젝트나 호스트 프로젝트에 있을 수 있습니다.

    공유 VPC 네트워크에 내부 HTTP(S) 부하 분산기를 구성하는 방법은 공유 VPC로 내부 HTTP(S) 부하 분산 설정을 참조하세요.

    호스트 프로젝트의 부하 분산기 및 백엔드

    이 모델에서는 공유 VPC 네트워크, 부하 분산기 구성요소, 백엔드 모두 호스트 프로젝트에 있습니다. 이 모델에서는 네트워크 관리 및 서비스 개발 책임을 구분하지 않습니다.

    이 모델 구성은 독립형 VPC 네트워크에서 부하 분산기 구성과 동일합니다. 내부 HTTP(S) 부하 분산 설정의 단계를 수행합니다.

    TLS 지원

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

    HTTPS를 백엔드 서비스 프로토콜로 사용하는 내부 HTTP(S) 부하 분산기는 TLS 1.0, 1.1, 1.2, 1.3을 백엔드로 협상할 수 있습니다.

    제한사항

    • 내부 HTTP(S) 부하 분산은 리전 수준에서 작동합니다.

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

    • 내부 HTTP(S) 부하 분산은 다음 기능과 호환되지 않습니다.

    • 공유 VPC 호스트 또는 서비스 프로젝트에서 내부 HTTP(S) 부하 분산기를 만들 때 다음 사항을 고려하세요.

      • 모든 부하 분산 구성요소와 백엔드가 모두 호스트 프로젝트에 있거나 모두 서비스 프로젝트에 있어야 합니다. 예를 들어 한 프로젝트에 부하 분산기의 전달 규칙을 배포하고 다른 프로젝트에 백엔드 인스턴스를 만들 수 없습니다.

      • 클라이언트는 호스트 프로젝트, 연결된 서비스 프로젝트 또는 연결된 네트워크에 있을 수 있습니다. 클라이언트는 동일한 공유 VPC 네트워크를 사용해야 하며 부하 분산기와 동일한 리전에 있어야 합니다.

    • 내부 HTTP(S) 부하 분산기는 TLS를 통해서만 HTTP/2를 지원합니다.

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

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

    • 내부 HTTP(S) 부하 분산기에서 사용하는 내부 전달 규칙에는 포트가 정확히 하나만 있어야 합니다.

    • 내부 HTTP(S) 부하 분산은 Cloud Trace를 지원하지 않습니다.

    다음 단계