내부 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 기반 부하 분산을 사용하는 내부 서비스(확대하려면 클릭)

두 가지 추가 구성요소가 부하 분산 서비스를 제공하는데 사용됩니다.

  • URL 맵은 특정 백엔드 서비스에 매핑되는 트래픽 제어 규칙(HTTP 헤더 등 레이어 7 매개변수 기반)을 정의합니다. 부하 분산기는 트래픽을 백엔드 서비스로 라우팅하거나 추가 작업(예: 리디렉션)을 수행하기 위해 URL 맵에 대한 수신 요청을 평가합니다.
  • 상태 확인은 주기적으로 백엔드 상태를 확인하고 클라이언트 트래픽이 무응답 백엔드로 전송되는 위험을 줄입니다.

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

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

사용 사례

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

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

한 가지 일반적인 사용 사례는 여러 서비스로 트래픽 부하를 분산하는 것입니다. 이 예시에서 내부 클라이언트는 /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 맵을 계속 업데이트합니다. 시간이 지나면 기존 애플리케이션으로 라우팅되는 요청이 줄어듭니다. 결국 대체 서비스는 기존 애플리케이션에서 제공한 모든 기능에 적용됩니다. 이 시점에서 기존 애플리케이션을 폐기할 수 있습니다.

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 기반 라우팅(확대하려면 클릭)

액세스 예시

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

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

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

아키텍처 및 리소스

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

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

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

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

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

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

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

    • IP 주소는 백엔드 인스턴스 그룹과 동일한 서브넷에서 가져올 수 있지만 반드시 그럴 필요는 없습니다.
    • IP 주소는 --purpose 플래그가 INTERNAL_HTTPS_LOAD_BALANCER로 설정된 예약된 프록시 전용 서브넷에서 가져오지 않아야 합니다.
  • 리전 대상 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(S) 프록시는 리전 URL 맵을 사용하여 요청 경로, 쿠키 또는 헤더와 같은 HTTP 속성을 기반으로 라우팅을 결정합니다. 라우팅 결정에 따라 프록시는 클라이언트 요청을 특정 리전 백엔드 서비스로 전달합니다. URL 맵은 헤더 재작성, 클라이언트로 리디렉션 전송, 제한 시간 정책 구성(다른 정책 간) 등 추가 작업을 지정할 수 있습니다.

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

  • 하나 이상의 백엔드가 백엔드 서비스에 연결되어 있어야 합니다. 백엔드는 다음 구성의 인스턴스 그룹 또는 NEG일 수 있습니다.

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

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

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

SSL 인증서

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

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

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

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

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

방화벽 규칙

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

제한 시간 및 재시도

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

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

내부 HTTP(S) 부하 분산에는 두 가지 유형의 시간 제한이 있습니다.
  • 구성 가능한 HTTP 백엔드 서비스 제한 시간: 부하 분산기가 백엔드에서 전체 HTTP 응답을 반환할 때까지 기다리는 시간입니다. 백엔드 서비스 제한 시간 기본값은 30초입니다. 다음과 같은 상황에서는 이 제한 시간을 늘리는 것이 좋습니다.

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

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

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

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

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

부하 분산기는 백엔드 서비스 제한 시간이 발생하는 경우와 같은 특정 상황에서 실패한 GET 요청을 재시도합니다. 실패한 POST 요청은 다시 시도하지 않습니다. 재시도는 2회로 제한됩니다. 재시도한 요청은 최종 응답의 로그 항목을 하나만 생성합니다.

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

WebSocket 지원

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

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

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

WebSocket 연결의 제한 시간은 부하 분산기의 구성 가능한 백엔드 서비스 제한 시간에 따라 달라지며 기본값은 30초입니다. 이 제한 시간은 현재 사용 여부에 상관없이 WebSocket 연결에 적용됩니다. 백엔드 서비스 제한 시간과 구성 방법에 대한 자세한 내용은 제한 시간 및 재시도를 참조하세요.

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

트래픽 유형, 스키마, 범위

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

내부 HTTP(S) 부하 분산기의 범위는 전역이 아닌 리전이므로 클라이언트와 백엔드 VM 또는 엔드포인트는 모두 동일한 리전에 있어야 합니다.

공유 VPC 아키텍처

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

  • 호스트 프로젝트를 지정하고 하나 이상의 다른 서비스 프로젝트를 호스트 프로젝트에 연결합니다.
  • 호스트 프로젝트 관리자는 하나 이상의 공유 VPC 네트워크 및 서브넷을 만들고 이를 서비스 프로젝트와 공유합니다.
  • 서비스 프로젝트의 운영 가능 리소스는 공유 VPC 네트워크의 서브넷을 사용할 수 있습니다.

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

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

이 모델에서는 부하 분산기와 백엔드 인스턴스를 서비스 프로젝트에 배포합니다. 그런 다음 공유 VPC 네트워크를 사용하도록 부하 분산기와 백엔드 인스턴스를 구성합니다.

이 배포 모델은 공유 VPC 네트워크 배포 모델의 일반적인 사용 사례인 네트워크 관리와 서비스 개발 간의 책임 분할과 매우 유사합니다. 네트워크 관리자는 내부 IP 공간을 안전하고 효율적으로 할당할 수 있으며 네트워크 관리자와 서비스 개발자 간의 책임을 명확하게 구분할 수 있습니다.

공유 VPC 네트워크에서 내부 HTTP(S) 부하 분산
공유 VPC 네트워크에서 내부 HTTP(S) 부하 분산

호스트 프로젝트

호스트 프로젝트 관리자:

  • 호스트 프로젝트에서 공유 VPC 네트워크를 설정합니다.
  • 공유 VPC 네트워크에서 서브넷을 프로비저닝합니다.
  • 공유 VPC 네트워크에서 방화벽 규칙을 구성합니다.

서비스 프로젝트

  • 서비스 프로젝트 관리자는 서비스 프로젝트에서 부하 분산기(전달 규칙, 대상 HTTP(S) 프록시, URL 맵, 백엔드 서비스) 및 백엔드 인스턴스를 만듭니다.
  • 이러한 부하 분산 리소스 및 백엔드 인스턴스는 공유 VPC 호스트 프로젝트의 공유 네트워크 및 서브넷을 참조합니다.

이 패턴을 사용하면 서비스 개발자가 자체 서비스 프로젝트에서 부하 분산 서비스를 만들 수 있습니다. 또한 서비스 개발팀은 부하 분산기의 구성을 업데이트하고 호스트 프로젝트의 관리자의 도움 없이 백엔드 인스턴스를 변경할 수 있습니다.

클라이언트가 부하 분산기와 동일한 공유 VPC 네트워크에 있는 경우 호스트 프로젝트 또는 서비스 프로젝트에도 있을 수 있습니다. 이러한 클라이언트는 부하 분산기의 비공개 IP 주소를 사용하여 부하 분산된 서비스에 액세스할 수 있습니다.

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

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

이 네트워크 배포 모델을 사용하면 네트워크, 부하 분산기, 백엔드가 모두 호스트 프로젝트에 있게 됩니다. 이 설정은 작동은 하지만 네트워크 관리와 서비스 개발 책임을 분리하지 않으므로 일반적인 공유 VPC 배포에 적합하지 않습니다.

호스트 프로젝트에서 부하 분산기와 백엔드를 계속 실행해야 하는 경우 내부 HTTP(S) 부하 분산 설정의 단계를 따르세요.

제한사항

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

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

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

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

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

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

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

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

  • 각 VPC 네트워크 내에 있는 각 내부 관리형 전달 규칙에는 고유의 IP 주소가 있어야 합니다. 자세한 내용은 공통 IP 주소를 사용하는 여러 전달 규칙을 참조하세요.

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

  • 라우팅 어플라이언스와 같은 중간 라우터 VM을 통해 내부 HTTP(S) 부하 분산기에 요청을 전송하는 경우 라우팅 어플라이언스가 다음을 수행하도록 구성해야 합니다.

    1. 요청 패킷을 내부 HTTP(S) 부하 분산기로 전송하기 전에 소스 네트워크 주소 변환 (SNAT)을 수행하도록 라우터 VM(라우팅 어플라이언스)을 구성합니다.
    2. 내부 HTTP(s) 부하 분산기에서 보낸 응답 패킷을 전송할 때 대상 네트워크 주소 변환(DNAT)을 수행하도록 라우터 VM을 구성합니다.

다음 단계