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]을 통한)일 수 있습니다. 이러한 백엔드는 부하 분산기와 동일한 리전에 있어야 합니다.
내부 HTTP(S) 부하 분산과 관련된 제한사항은 제한사항 섹션을 참조하세요.
Google Cloud 부하 분산기의 차이점에 대한 자세한 내용은 다음 문서를 참조하세요.
사용 사례
내부 HTTP(S) 부하 분산은 여러 사용 사례를 다룹니다. 이 섹션에서는 몇 가지 개략적인 예시를 설명합니다. 추가 예시는 트래픽 관리 사용 사례를 참조하세요.
3계층 웹 서비스
내부 HTTP(S) 부하 분산을 사용하여 기존의 3계층 웹 서비스를 지원할 수 있습니다. 다음 예시에서는 3가지 유형의 Google Cloud 부하 분산기를 사용하여 3계층을 확장하는 방법을 보여줍니다. 각 계층에서 부하 분산기 유형은 트래픽 유형에 따라 다릅니다.
웹 계층: 트래픽이 인터넷에서 들어오고 외부 HTTP(S) 부하 분산기를 사용하여 부하 분산됩니다.
애플리케이션 계층: 애플리케이션 계층은 리전별 내부 HTTP(S) 부하 분산기를 사용하여 확장됩니다.
데이터베이스 계층: 데이터베이스 계층은 내부 TCP/UDP 부하 분산기를 사용하여 확장됩니다.
다이어그램은 트래픽이 계층을 통해 이동하는 방식을 보여줍니다.
- 외부 HTTP(S) 부하 분산기는 인터넷 트래픽을 다양한 리전의 웹 프런트엔드 인스턴스 그룹 집합에 배포합니다.
- 이러한 프런트엔드는 HTTP(S) 트래픽을 일련의 리전별 내부 HTTP(S) 부하 분산기(이 개요의 대상)로 전송합니다.
- 내부 HTTP(S) 부하 분산기는 미들웨어 인스턴스 그룹으로 트래픽을 분산합니다.
- 이러한 미들웨어 인스턴스 그룹은 내부 TCP/UDP 부하 분산기로 트래픽을 전송하여 트래픽 부하를 데이터 스토리지 클러스터에 분산합니다.
경로 기반 라우팅을 사용한 부하 분산
한 가지 일반적인 사용 사례는 여러 서비스로 트래픽 부하를 분산하는 것입니다. 이 예시에서 내부 클라이언트는 /video 및 /images 경로를 포함한 동일한 기본 URL인 mygcpservice.internal을 사용하여 동영상 및 이미지 콘텐츠를 요청할 수 있습니다.
내부 HTTP(S) 부하 분산기의 URL 맵은 경로 /video에 대한 요청을 동영상 백엔드 서비스로 보내고 경로 /images에 대한 요청은 이미지 백엔드 서비스로 보내도록 지정합니다. 다음 예시에서 동영상 및 이미지 백엔드 서비스는 Compute Engine VM을 사용하여 제공되지만 GKE 포드를 사용하여 제공할 수도 있습니다.
내부 클라이언트가 부하 분산기의 내부 IP 주소로 요청을 보내면 부하 분산기는 이 로직에 따라 요청을 평가하고 올바른 백엔드 서비스로 보냅니다.
다음 다이어그램은 이 사용 사례를 보여줍니다.
기존 서비스 현대화하기
내부 HTTP(S) 부하 분산은 기존 애플리케이션을 현대화하는데 효과적인 도구입니다.
기존 애플리케이션의 한 가지 예시로는 쉽게 업데이트할 수 없는 대형 모놀리식 애플리케이션이 있습니다. 이 경우 기존 애플리케이션 앞에 내부 HTTP(S) 부하 분산기를 배포할 수 있습니다. 그런 다음 부하 분산기의 트래픽 제어 기능을 사용하여 트래픽 하위 집합을 기존 애플리케이션이 제공하는 기능을 대체하는 새로운 마이크로서비스로 전달할 수 있습니다.
시작하려면 기본적으로 모든 트래픽을 기존 애플리케이션에 라우팅하도록 부하 분산기의 URL 맵을 구성합니다. 이러면 기존 동작을 유지합니다. 대체 서비스가 개발되면 트래픽의 일부를 대체 서비스로 라우팅하도록 URL 맵을 업데이트합니다.
내부 클라이언트가 /video로 요청을 보낼 때 제공되는 일부 동영상 처리 기능이 기존 애플리케이션에 포함되어 있다고 가정해 보겠습니다.
이 동영상 서비스를 다음과 같이 별도의 마이크로서비스로 나눌 수 있습니다.
- 내부 HTTP(S) 부하 분산을 기존 애플리케이션 앞에 추가합니다.
- 대체 동영상 처리 마이크로서비스를 만듭니다.
- 경로
/video에 대한 모든 요청이 기존 애플리케이션이 아닌 새 마이크로서비스로 라우팅되도록 부하 분산기의 URL 맵을 업데이트합니다.
추가 대체 서비스를 개발하면 URL 맵을 계속 업데이트합니다. 시간이 지나면 기존 애플리케이션으로 라우팅되는 요청이 줄어듭니다. 결국 대체 서비스는 기존 애플리케이션에서 제공한 모든 기능에 적용됩니다. 이 시점에서 기존 애플리케이션을 폐기할 수 있습니다.
전역 액세스를 지원하는 3계층 웹 서비스
전역 액세스를 사용 설정하면 웹 계층 클라이언트 VM이 다른 리전에 있을 수 있습니다.
이 다중 계층 애플리케이션 예시는 다음 항목을 보여줍니다.
- HTTP(S) 부하 분산으로 트래픽을 부하 분산하는 전역적으로 사용 가능한 인터넷 연결 웹 계층
- 전역 웹 계층으로 액세스되는
us-east1리전에 있는 내부 백엔드의 부하 분산된 데이터베이스 us-east1에 있는 내부 부하 분산된 데이터베이스 계층에 액세스하는europe-west1리전의 웹 계층에 속하는 클라이언트 VM
하이브리드 연결을 사용한 부하 분산
Cloud Load Balancing은 온프레미스 데이터 센터, 하이브리드 연결을 사용하여 연결할 수 있는 기타 퍼블릭 클라우드 등 Google Cloud 이상으로 확장되는 엔드포인트에 대한 부하 분산 트래픽을 지원합니다.
다음 다이어그램은 내부 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) 부하 분산기는 다음과 같은 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 주소는 동일한 네트워크 및 리전의 모든 서브넷에서 가져올 수 있습니다. 다음 조건을 참고하세요.
- IP 주소는 백엔드 인스턴스 그룹과 동일한 서브넷에서 가져올 수 있지만 반드시 그럴 필요는 없습니다.
- IP 주소는
--purpose플래그가REGIONAL_MANAGED_PROXY로 설정된 예약된 프록시 전용 서브넷에서 가져오지 않아야 합니다. - 내부 IP 주소를 여러 전달 규칙과 공유하려면 IP 주소의
--purpose플래그를SHARED_LOADBALANCER_VIP로 설정합니다.
내부 HTTP(S) 부하 분산기에서 사용하는 전달 규칙마다 정확하게 TCP 포트 하나를 참조할 수 있습니다. HTTP 부하 분산기의 경우 포트 80 또는 8080 중 하나를 사용합니다. HTTPS 부하 분산기의 경우 포트 443을 사용합니다.
전달 규칙 및 전역 액세스
내부 HTTP(S) 부하 분산기의 전달 규칙은 전역 액세스가 사용 설정되어 있더라도 리전별로 적용됩니다. 전역 액세스를 사용 설정한 후에는 리전 내부 전달 규칙의 allowGlobalAccess 플래그가 true로 설정됩니다.
대상 프록시
리전 대상 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 프록시를 사용하는 내부 HTTP(S) 부하 분산기에는 부하 분산기 구성의 일부로 비공개 키와 SSL 인증서가 필요합니다. 이러한 부하 분산기는 자체 관리형 리전 Compute Engine SSL 인증서를 사용합니다.
SSL 인증서와 Google Cloud 프록시 부하 분산기에 대한 자세한 내용은 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) 부하 분산기에는 다음 방화벽 규칙이 필요합니다.
- Google의 중앙 상태 점검 범위에서 들어오는 트래픽을 허용하는 인그레스 허용 규칙
35.191.0.0/16130.211.0.0/22
- 프록시 전용 서브넷의 트래픽을 허용하는 인그레스 허용 규칙
클라이언트 액세스
기본적으로 클라이언트는 부하 분산기와 동일한 리전에 있어야 합니다. 클라이언트는 같은 네트워크 또는 VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크에 있을 수 있습니다. 모든 리전의 클라이언트가 부하 분산기에 액세스하도록 허용하려면 전역 액세스를 사용 설정하면 됩니다.
다음 표에는 클라이언트 액세스가 요약되어 있습니다.
| 중지된 전역 액세스 | 사용 설정된 전역 액세스 |
|---|---|
| 클라이언트는 부하 분산기와 동일한 리전에 있어야 합니다. 또한 부하 분산기와 동일한 VPC 네트워크에 있거나 VPC 네트워크 피어링을 사용하여 부하 분산기의 VPC 네트워크에 연결된 VPC 네트워크에 있어야 합니다. | 클라이언트는 어느 리전에나 있을 수 있습니다. 부하 분산기와 동일한 VPC 네트워크에 있거나 VPC 네트워크 피어링을 사용하여 부하 분산기의 VPC 네트워크에 연결된 VPC 네트워크에 있어야 합니다. |
| 온프레미스 클라이언트는 Cloud VPN 터널이나 VLAN 연결을 통해 부하 분산기에 액세스할 수 있습니다. 이러한 터널 또는 연결은 부하 분산기와 동일한 리전에 있어야 합니다. | 온프레미스 클라이언트는 Cloud VPN 터널이나 VLAN 연결을 통해 부하 분산기에 액세스할 수 있습니다. 이러한 터널 또는 연결은 어느 리전에나 있을 수 있습니다. |
공유 VPC 아키텍처
내부 HTTP(S) 부하 분산은 공유 VPC를 사용하는 네트워크를 지원합니다. 공유 VPC를 사용하는 조직은 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있으므로 리소스가 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다. 공유 VPC에 대해 잘 모른다면 공유 VPC 개요 문서를 참조하세요.
공유 VPC 네트워크 내에서 내부 HTTP(S) 부하 분산을 구성하는 방법에는 여러 가지가 있습니다. 배포 유형에 관계없이 부하 분산기의 모든 구성요소는 동일한 조직에 있어야 합니다.
| 서브넷 및 IP 주소 | 프런트엔드 구성요소 | 백엔드 구성요소 |
|---|---|---|
공유 VPC 호스트 프로젝트에서 필요한 네트워크 및 서브넷(프록시 전용 서브넷 포함)을 만듭니다. 부하 분산기의 내부 IP 주소는 호스트 프로젝트 또는 서비스 프로젝트에서 정의할 수 있지만 호스트 프로젝트에서 원하는 공유 VPC 네트워크의 서브넷을 사용해야 합니다. 주소 자체는 참조된 서브넷의 기본 IP 범위에서 가져옵니다. |
리전 외부 IP 주소, 전달 규칙, 대상 HTTP(S) 프록시, 연결된 URL 맵이 동일한 프로젝트에 정의되어야 합니다. 이 프로젝트는 호스트 프로젝트 또는 서비스 프로젝트일 수 있습니다. | 다음 중 하나를 실행하세요.
각 백엔드 서비스는 참조하는 백엔드와 동일한 프로젝트에서 정의되어야 합니다. 백엔드 서비스와 관련된 상태 점검은 백엔드 서비스와 동일한 프로젝트에서 정의되어야 합니다. |
공유 VPC 호스트 프로젝트에서 모든 부하 분산 구성요소와 백엔드를 만들 수 있지만 이 모델은 네트워크 관리와 서비스 개발 책임을 분리하지 않습니다.
클라이언트가 부하 분산기와 동일한 공유 VPC 네트워크 및 리전에 있는 경우 내부 HTTP(S) 부하 분산기에 액세스할 수 있습니다. 클라이언트는 호스트 프로젝트, 연결된 서비스 프로젝트 또는 연결된 네트워크에 있을 수 있습니다.
공유 VPC 환경의 서버리스 백엔드
서버리스 NEG 백엔드를 사용하는 내부 HTTP(S) 부하 분산기의 경우 지원 Cloud Run 서비스가 백엔드 서비스 및 서버리스 NEG와 동일한 서비스 프로젝트에 있어야 합니다. 부하 분산기의 프런트엔드 구성요소(전달 규칙, 대상 프록시, URL 맵)는 호스트 프로젝트, 백엔드 구성요소와 동일한 서비스 프로젝트 또는 동일한 공유 VPC 환경의 기타 서비스 프로젝트에서 만들 수 있습니다.
교차 프로젝트 서비스 참조
이 모델에서는 부하 분산기의 프런트엔드와 URL 맵이 호스트 또는 서비스 프로젝트에 있습니다. 부하 분산기의 백엔드 서비스와 백엔드는 공유 VPC 환경의 프로젝트에 분산될 수 있습니다. 교차 프로젝트 백엔드 서비스는 단일 URL 맵에서 참조될 수 있습니다. 이를 교차 프로젝트 서비스 참조라고 합니다.
교차 프로젝트 서비스 참조를 사용하면 조직에서 하나의 중앙 부하 분산기를 구성하고 여러 프로젝트에 분산된 수백 개의 서비스로 트래픽을 라우팅할 수 있습니다. 모든 트래픽 라우팅 규칙과 정책을 하나의 URL 맵에서 중앙 관리할 수 있습니다. 부하 분산기를 단일 호스트 이름 및 SSL 인증서 집합과 연결할 수도 있습니다. 따라서 애플리케이션을 배포하는 데 필요한 부하 분산기의 수를 최적화하고 관리 효율성, 운영 비용, 할당량 요구사항을 낮출 수 있습니다.
업무팀마다 서로 다른 프로젝트를 사용하면 조직 내 역할을 분리할 수 있습니다. 서비스 소유자는 서비스 프로젝트에서 서비스를 빌드하는 데 집중할 수 있으며, 네트워크팀은 다른 프로젝트에서 부하 분산기를 프로비저닝하고 유지관리할 수 있으며, 두 가지 모두 프로젝트 간 서비스 참조를 사용하여 연결할 수 있습니다.
서비스 소유자는 서비스 노출에 대한 자율성을 유지하고 부하 분산기를 통해 서비스에 액세스할 수 있는 사용자를 제어할 수 있습니다. 이를 위해서는 Compute 부하 분산기 서비스 사용자 역할(roles/compute.loadBalancerServiceUser)이라는 특수한 IAM 역할을 사용하면 됩니다.
교차 프로젝트 서비스 참조는 인스턴스 그룹, 서버리스 NEG, 기타 지원되는 백엔드 유형에서 사용할 수 있습니다. 서버리스 NEG를 사용하는 경우 부하 분산기의 프런트엔드를 만들려는 VPC 네트워크에 VM을 만들어야 합니다. VM을 만드는 방법을 알아보려면 Cloud Run으로 내부 HTTP(S) 부하 분산기 설정을 참조하세요.
예시 1: 다른 서비스 프로젝트의 부하 분산기 프런트엔드 및 백엔드
다음은 서비스 프로젝트 A에 부하 분산기의 프런트엔드 및 URL 맵이 생성되고 URL 맵이 서비스 프로젝트 B의 백엔드 서비스를 참조하는 배포의 예시입니다.
이 경우 서비스 프로젝트 A의 네트워크 관리자나 부하 분산기 관리자가 서비스 프로젝트 B의 백엔드 서비스에 액세스해야 합니다. 서비스 프로젝트 B 관리자는 서비스 프로젝트 B의 백엔드 서비스를 참조하려는 서비스 프로젝트 A의 부하 분산기 관리자에게 compute.loadBalancerServiceUser IAM 역할을 부여합니다.
예시 2: 호스트 프로젝트의 부하 분산기 프런트엔드 및 서비스 프로젝트의 백엔드
이 유형의 배포에서는 부하 분산기의 프런트엔드 및 URL 맵이 호스트 프로젝트에 생성되고 백엔드 서비스(및 백엔드)는 서비스 프로젝트에 생성됩니다.
이 경우 호스트 프로젝트의 네트워크 관리자나 부하 분산기 관리자가 서비스 프로젝트의 백엔드 서비스에 액세스해야 합니다. 서비스 프로젝트 관리자는 서비스 프로젝트의 백엔드 서비스를 참조하려는 호스트 프로젝트 A의 부하 분산기 관리자에게 compute.loadBalancerServiceUser IAM 역할을 부여합니다.
서비스 프로젝트의 모든 부하 분산기 구성요소 및 백엔드
이 모델에서는 모든 부하 분산기 구성요소와 백엔드가 서비스 프로젝트에 있습니다. 이 배포 모델은 모든 HTTP(S) 부하 분산기에서 지원됩니다.
부하 분산기는 호스트 프로젝트의 IP 주소와 서브넷을 사용합니다.
제한시간 및 재시도
내부 HTTP(S) 부하 분산에는 다음과 같은 제한 시간이 있습니다.구성 가능한 HTTP 백엔드 서비스 제한 시간: 부하 분산기가 백엔드에서 전체 HTTP 응답을 반환할 때까지 기다리는 시간입니다. 백엔드 서비스 제한 시간 기본값은 30초입니다. 허용되는 제한 시간 값의 전체 범위는 1~2,147,483,647초입니다.
예를 들어 500MB 파일을 다운로드하려는데 백엔드 서비스 제한 시간이 기본값인 30초인 경우 부하 분산기는 백엔드가 500MB 전체 파일을 30초 이내에 제공할 것으로 예상합니다. 백엔드 서비스 제한 시간이 짧게 구성되어서 백엔드가 전체 HTTP 응답을 보낼 정도로 충분히 길지 않을 가능성도 있습니다. 이 경우 부하 분산기에 HTTP 응답 헤더가 최소한 한 개 이상 있으면 부하 분산기가 전체 응답 헤더와 백엔드 서비스 제한 시간 내에 가능할 만큼 응답 본문을 반환합니다.
백엔드 서비스 제한 시간은 Envoy와 백엔드 간의 상호작용에서 요청의 첫 바이트부터 응답의 마지막 바이트까지 경과될 수 있는 최대 시간으로 설정해야 합니다. WebSocket을 사용하는 경우 백엔드 서비스 제한 시간은 유휴 또는 활성 WebSocket의 최대 기간으로 설정해야 합니다.
다음과 같은 상황에서는 이 제한 시간을 늘리는 것이 좋습니다.
- 백엔드에서 HTTP 응답을 반환하는 데 시간이 더 오래 걸릴 것으로 예상되는 경우
- 연결이 WebSocket으로 업그레이드된 경우
설정된 백엔드 서비스 제한 시간은 최선의 목표입니다. 기본 TCP 연결이 제한 시간 동안 계속 열려 있다는 보장은 없습니다.
백엔드 서비스 제한 시간을 원하는 값으로 설정할 수 있지만, 1일(86,400초) 이상의 값으로 설정하여도 부하 분산기가 TCP 연결을 해당 시간만큼 계속 유지한다는 보장은 없습니다. Google에서는 소프트웨어 업데이트 및 정기 유지보수를 위해 Envoy 프록시를 주기적으로 다시 시작하며 백엔드 서비스 제한 시간은 이를 재정의하지 않습니다. 백엔드 서비스 제한 시간을 길게 설정할수록 Google에서 Envoy 유지보수를 위한 TCP 연결을 종료할 가능성이 높습니다. 이러한 이벤트의 영향을 줄이기 위해 재시도 로직을 구현하는 것이 좋습니다.
백엔드 서비스 제한 시간은 HTTP 유휴(연결 유지) 제한 시간이 아닙니다. 느린 클라이언트(예: 연결 속도가 느린 브라우저)로 인해 백엔드의 입력과 출력(IO)이 차단될 수 있습니다. 이 대기 시간은 백엔드 서비스 제한 시간에 반영되지 않습니다.
백엔드 서비스 제한 시간을 구성하려면 다음 방법 중 하나를 사용하세요.
- Google Cloud 콘솔: 부하 분산기 백엔드 서비스의 제한 시간 필드를 수정합니다.
- Google Cloud CLI:
gcloud compute backend-services update명령어를 사용하여 백엔드 서비스 리소스의--timeout매개변수를 수정합니다. - API: 전역 또는 리전 백엔드 서비스 리소스의
timeoutSec매개변수를 수정합니다.
- 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 요청은 재시도되지 않습니다.
재시도한 요청은 최종 응답의 로그 항목 하나만 생성합니다.
자세한 내용은 내부 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를 통해 엔드 투 엔드 요청을 프록시해야 합니다. 방법은 다음과 같습니다.
- HTTPS 부하 분산기를 구성합니다.
- 부하 분산기에서 백엔드로의 프로토콜로 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 서비스로 트래픽을 보낼 수 있습니다. 이는 알려진 문제이며 향후 이 양식의 액세스가 차단됩니다.
다음 단계
- Compute Engine VM에서 실행되는 서비스에 부하 분산을 구성하려면 Compute Engine VM에 내부 HTTP(S) 부하 분산 설정을 참조하세요.
- 공유 VPC 설정에서 부하 분산을 구성하려면 공유 VPC에 내부 HTTP(S) 부하 분산 설정을 참조하세요.
- GKE 포드에서 실행되는 서비스에 부하 분산을 구성하려면 독립형 NEG를 사용한 컨테이너 기반 부하 분산 및 내부 HTTP(S) 부하 분산기를 독립형 NEG에 연결을 참조하세요.
- Private Service Connect로 내부 HTTP(S) 부하 분산을 구성하려면 소비자 HTTP(S) 서비스 제어로 Private Service Connect 구성을 참조하세요.
- 프록시 전용 서브넷 리소스를 관리하려면 프록시 전용 서브넷을 참조하세요.
- 내부 HTTP(S) 부하 분산에서 백엔드 하위 설정을 구성하려면 백엔드 하위 설정을 참조하세요.