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

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

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

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

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

  • 클라이언트가 트래픽을 전송하는 내부 IP 주소. 부하 분산기와 동일한 리전에 있는 클라이언트만이 IP 주소에 액세스할 수 있습니다. 내부 클라이언트 요청은 네트워크 및 리전 내부에서 유지됩니다.
  • 부하 분산기가 트래픽을 전달하는 하나 이상의 백엔드 서비스입니다. 백엔드는 Compute Engine VM, Compute Engine VM 그룹(인스턴스 그룹을 통한), Cloud Run 애플리케이션 또는 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 맵을 계속 업데이트합니다. 시간이 지나면 기존 애플리케이션으로 라우팅되는 요청이 줄어듭니다. 결국 대체 서비스는 기존 애플리케이션에서 제공한 모든 기능에 적용됩니다. 이 시점에서 기존 애플리케이션을 폐기할 수 있습니다.

하이브리드 연결을 사용한 부하 분산

Cloud Load Balancing은 온프레미스 데이터 센터, 하이브리드 연결을 사용하여 연결할 수 있는 기타 퍼블릭 클라우드 등 Google Cloud 이상으로 확장되는 엔드포인트에 대한 부하 분산 트래픽을 지원합니다.

다음 다이어그램은 내부 HTTP(S) 부하 분산기가 있는 하이브리드 배포를 보여줍니다.

내부 HTTP(S) 부하 분산과의 하이브리드 연결(확대하려면 클릭)
내부 HTTP(S) 부하 분산과의 하이브리드 연결(확대하려면 클릭)

Private Service Connect

내부 HTTP(S) 부하 분산을 사용하여 지원되는 리전 Google API 및 서비스에 요청을 전송할 수 있습니다. 자세한 내용은 Private Service Connect를 사용하여 소비자 HTTP(S) 서비스 제어로 Google API에 액세스를 참조하세요.

GKE 애플리케이션을 위한 부하 분산

GKE에서 애플리케이션을 빌드할 때는 GKE 사용자를 대신해서 Google Cloud 부하 분산기를 배포하는 기본 제공되는 GKE 인그레스 컨트롤러를 사용하는 것이 좋습니다. 수명 주기가 GKE에 의해 완전히 자동화되고 제어된다는 점을 제외하면 이 페이지에 설명된 독립형 부하 분산 아키텍처와 동일합니다.

관련 GKE 문서:

아키텍처 및 리소스

다음 다이어그램은 내부 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 플래그가 REGIONAL_MANAGED_PROXY로 설정된 예약된 프록시 전용 서브넷에서 가져오지 않아야 합니다.

내부 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 인증서

전송 계층 보안(TLS)은 네트워크 통신을 보호하기 위해 SSL 인증서에 사용되는 암호화 프로토콜입니다.

Google Cloud는 SSL 인증서를 사용하여 클라이언트에서 부하 분산기로 개인정보 보호 및 보안을 제공합니다. HTTPS 기반 부하 분산을 사용할 경우 대상 HTTPS 프록시에 SSL 인증서를 한 개 이상 설치해야 합니다.

SSL 인증서에 대한 자세한 내용은 다음을 참조하세요.

URL 맵

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

백엔드 서비스

리전별 백엔드 서비스는 정상적인 백엔드(Compute Engine VM을 포함하는 인스턴스 그룹, GKE 컨테이너를 포함하는 NEG, 지원되는 Google API 및 서비스를 가리키는 Private Service Connect NEG)에 요청을 배포합니다.

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

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

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

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

백엔드 및 VPC 네트워크

모든 백엔드는 같은 VPC 네트워크와 리전에 있어야 합니다. VPC 네트워크 피어링을 사용하여 연결된 경우에도 다른 VPC 네트워크에 백엔드를 배치할 수 없습니다. 피어링된 VPC 네트워크의 클라이언트 시스템이 부하 분산기에 액세스하는 방법에 대한 자세한 내용은 내부 HTTP(S) 부하 분산 및 연결된 네트워크를 참조하세요.

백엔드 하위 설정

백엔드 하위 설정은 각 프록시 인스턴스에 백엔드 하위 집합을 할당하여 성능 및 확장성을 개선하는 선택적 기능입니다.

기본적으로 백엔드 하위 설정은 사용 중지되어 있습니다. 이 기능을 사용 설정하는 방법에 대한 자세한 내용은 내부 HTTP(S) 부하 분산기의 백엔드 하위 설정을 참조하세요.

상태 확인

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

방화벽 규칙

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

공유 VPC 아키텍처

내부 HTTP(S) 부하 분산은 공유 VPC를 사용하는 네트워크를 지원합니다. 공유 VPC를 사용하면 네트워크 관리자와 서비스 개발자 간의 책임을 명확하게 구분할 수 있습니다. 개발팀은 서비스 프로젝트에 서비스를 빌드하는 데 집중할 수 있으며 네트워크 인프라팀은 부하 분산을 프로비저닝하고 관리할 수 있습니다. 또한 네트워크 관리자는 내부 IP 주소를 안전하고 효율적으로 관리할 수 있습니다. 공유 VPC에 대해 잘 모른다면 공유 VPC 개요 문서를 참조하세요.

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

서브넷 및 IP 주소 전달 규칙 대상 프록시 및 URL 맵 백엔드 구성요소
공유 VPC 호스트 프로젝트에서 필요한 네트워크, 서브넷(프록시 전용 서브넷 포함) 및 내부 IP 주소를 만듭니다. 전달 규칙은 호스트 프로젝트 또는 서비스 프로젝트에서 정의할 수 있습니다. 대상 프록시와 URL 맵은 전달 규칙과 동일한 프로젝트에서 정의되어야 합니다.

백엔드 서비스 및 백엔드는 필요한 만큼의 서비스 프로젝트에서 생성할 수 있습니다. 단일 URL 맵은 서로 다른 프로젝트의 백엔드 서비스를 참조할 수 있습니다. 이러한 유형의 배포를 프로젝트 간 서비스 참조라고 합니다. 이 사용 사례는 미리보기에 있습니다.

단일 서비스 프로젝트에서 모든 부하 분산기 구성요소와 해당 백엔드를 만들 수도 있습니다.

각 백엔드 서비스는 참조하는 백엔드 인스턴스와 동일한 프로젝트에서 정의되어야 합니다. 이 인스턴스는 백엔드 서비스에 백엔드로 연결된 인스턴스 그룹에 있어야 합니다. 백엔드 서비스와 관련된 상태 확인은 백엔드 서비스와 동일한 프로젝트에서 정의되어야 합니다.

호스트 프로젝트에서 필요한 네트워크, 서브넷 및 IP 주소를 만듭니다. 그런 다음 부하 분산기 구성요소에 대해 다음 중 하나를 수행할 수 있습니다.

이러한 모든 배포 모델에서 클라이언트는 부하 분산기와 동일한 공유 VPC 네트워크 및 리전에 있으면 부하 분산기에 액세스할 수 있습니다. 클라이언트는 호스트 프로젝트, 연결된 서비스 프로젝트 또는 연결된 네트워크에 있을 수 있습니다.

교차 프로젝트 서비스 참조

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

교차 프로젝트 서비스 참조는 중앙에서 관리되는 부하 분산기를 통해 서비스가 노출됨에 따라 서비스 개발자와 관리자에게 자율성을 제공합니다. 서비스 프로젝트 관리자는 compute.loadBalancerServiceUser IAM 역할을 사용하여 프로젝트의 백엔드 서비스에 대한 액세스 권한을 부여합니다.

프로젝트 간 서비스 참조 유무에 관계없이 내부 HTTP(S) 부하 분산기에 대해 공유 VPC를 구성하는 방법은 공유 VPC로 내부 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) 부하 분산기에서 지원됩니다.

부하 분산기는 호스트 프로젝트의 IP 주소와 서브넷을 사용합니다.

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

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

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

이 모델 구성은 독립형 VPC 네트워크에서 부하 분산기 구성과 동일합니다.

제한시간 및 재시도

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

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

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

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

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

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

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

    자세한 내용은 백엔드 서비스 설정을 참조하세요.

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

  • HTTP 연결 유지 제한 시간: 값이 10분(600초)으로 고정됩니다. 백엔드 서비스를 수정하는 방법으로 이 값을 구성할 수 없습니다. 백엔드가 사용하는 웹 서버 소프트웨어는 백엔드가 연결을 조기에 닫지 않도록 연결 유지 제한시간을 600초보다 길게 설정해야 합니다. 이 제한 시간은 WebSocket에는 적용되지 않습니다. 다음 표는 일반적인 웹 서버 소프트웨어의 연결 유지 제한 시간을 수정할 때 필요한 변경사항을 보여줍니다.
    웹 서버 소프트웨어 매개변수 기본 설정 권장 설정
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
  • 스트림 유휴 시간 제한: 값이 5분(300초)으로 고정됩니다. 이 값은 구성할 수 없습니다. HTTP 스트림은 활동이 없으면 5분 후에 유휴 상태가 됩니다.

재시도

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

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

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

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

gRPC 지원

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

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

Google Cloud 애플리케이션에서 gRPC를 사용하려면 HTTP/2를 통해 엔드 투 엔드 요청을 프록시해야 합니다. 방법은 다음과 같습니다.

  1. HTTPS 부하 분산기를 구성합니다.
  2. 부하 분산기에서 백엔드로의 프로토콜로 HTTP/2를 사용 설정합니다.

부하 분산기는 ALPN TLS 확장을 사용하여 SSL 핸드셰이크의 일부로 클라이언트와 HTTP/2를 협상합니다.

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

백엔드에서 TLS를 사용 설정해야 합니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.

TLS 지원

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

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

제한사항

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

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

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

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

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

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

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

  • 공유 VPC 환경에서 Cloud Run과 함께 내부 HTTP(S) 부하 분산을 사용하는 경우 서비스 프로젝트의 독립형 VPC 네트워크는 동일한 공유 VPC 환경 내의 다른 서비스 프로젝트에 배포된 다른 Cloud Run 서비스로 트래픽을 보낼 수 있습니다. 이는 알려진 문제이며 향후 이 양식의 액세스가 차단됩니다.

다음 단계