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

내부 HTTP(S) 부하 분산은 프록시 기반의 리전별 Layer 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]을 통한)일 수 있습니다. 이러한 백엔드는 부하 분산기와 동일한 리전에 있어야 합니다.
Layer 7 기반 부하 분산을 사용하는 내부 서비스(확대하려면 클릭)
Layer 7 기반 부하 분산을 사용하는 내부 서비스(확대하려면 클릭)

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

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

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

사용 사례

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

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

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

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

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

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

Layer 7 기반 부하 분산을 사용하는 내부(마이크로) 서비스(확대하려면 클릭)
Layer 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 부하 분산기로 트래픽을 전송하여 트래픽 부하를 데이터 스토리지 클러스터에 분산합니다.
다중 계층 앱의 내부 계층을 위한 Layer 7 기반 라우팅(확대하려면 클릭)
다중 계층 앱의 내부 계층을 위한 Layer 7 기반 라우팅(확대하려면 클릭)

액세스 예시

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

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

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

아키텍처 및 리소스

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

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

다음 리소스는 내부 HTTP(S) 부하 분산기를 정의합니다.

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

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

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

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

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

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

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

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

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

  • 프록시 전용 서브넷은 IP 주소가 부하 분산기 프록시에서 백엔드로 가는 트래픽의 소스입니다. 내부 HTTP(S) 부하 분산기를 사용하는 VPC 네트워크의 각 리전에 하나의 프록시 전용 서브넷을 만들어야 합니다. Google에서 이 서브넷을 관리하며 해당 리전의 모든 내부 HTTP(S) 부하 분산기가 공유합니다. 이 서브넷을 사용하여 백엔드를 호스팅할 수 없습니다.

  • 백엔드가 프록시 전용 서브넷의 연결을 수락하는 방화벽입니다. 자세한 내용은 방화벽 규칙 구성의 예시를 참조하세요.

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

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

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

제한사항

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

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

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

  • 공유 VPC 호스트 프로젝트에서 내부 HTTP(S) 부하 분산기를 만드는 경우:

    • 클라이언트 VM은 호스트 프로젝트 또는 모든 연결된 서비스 프로젝트에 있을 수 있습니다. 클라이언트 VM은 동일한 공유 VPC 네트워크 및 부하 분산기와 동일한 리전을 사용해야 합니다.
    • 모든 부하 분산기의 구성요소와 백엔드는 호스트 프로젝트에 있어야 합니다. 이러면 부하 분산기가 공유 VPC 네트워크를 사용할 때 내부 HTTP(S) 부하 분산기 구성요소가 서비스 프로젝트에 있을 수 없기 때문에 다른 Google Cloud 부하 분산과 다릅니다.
    • 공유 VPC 네트워크 내의 호스트 프로젝트는 프록시 전용 서브넷(용도=INTERNAL_HTTPS_LOAD_BALANCER)을 소유하고 생성합니다.
  • WebSocket 프로토콜은 지원되지 않습니다.

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

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

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

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

다음 단계