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

이 문서에서는 Google Cloud 외부 HTTP(S) 부하 분산을 구성하기 위해 알아야 하는 개념을 소개합니다.

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

사용 사례

외부 HTTP(S) 부하 분산기는 많은 사용 사례를 다룹니다. 이 섹션에서는 몇 가지 개략적인 예시를 제공합니다.

여러 백엔드 유형을 사용하는 부하 분산

외부 HTTP(S) 부하 분산은 다음과 같은 백엔드 유형을 지원합니다.

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

외부 HTTP(S) 부하 분산기의 URL 맵은 다음을 지정합니다.

  • 경로 /api에 대한 요청은 VM 인스턴스 그룹 또는 영역별 NEG 백엔드가 있는 백엔드 서비스로 이동합니다.
  • 경로 /images에 대한 요청은 Cloud Storage 백엔드가 있는 백엔드 버킷으로 이동합니다.
  • 경로 /video에 대한 요청은 Google Cloud 외부의 온프레미스에 있는 외부 엔드포인트를 포함하는 인터넷 NEG를 가리키는 백엔드 서비스로 이동합니다.

클라이언트가 부하 분산기의 외부 IPv4 또는 IPv6 주소로 요청을 전송하면 부하 분산기는 URL 맵에 따라 요청을 평가하고 올바른 서비스로 전송합니다.

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

커스텀 원본이 포함된 부하 분산 다이어그램(확대하려면 클릭)
커스텀 원본이 포함된 부하 분산 다이어그램(확대하려면 클릭)

각 백엔드 서비스에서 선택적으로 Cloud CDN 및 Google Cloud Armor를 사용 설정할 수 있습니다. Cloud CDN과 함께 Google Cloud Armor를 사용하는 경우 보안 정책은 동적 콘텐츠, 캐시 부적중 또는 CDN 원본 서버를 대상으로 지정된 기타 요청에 대해서만 적용됩니다. 다운스트림 Google Cloud Armor 보안 정책으로 인해 해당 요청이 CDN 원본 서버에 도달하지 못하더라도 캐시 적중은 제공됩니다.

백엔드 버킷에서는 Cloud CDN이 지원되지만 Google Cloud Armor는 지원되지 않습니다.

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

리전 간 부하 분산

리전 간 부하 분산의 표현

프리미엄 등급에서 외부 HTTP(S) 부하 분산기를 구성하면 전역 외부 IP 주소를 사용하고 사용자의 요청을 근접성에 따라 가장 가까운 백엔드 인스턴스 그룹 또는 NEG로 지능적으로 라우팅할 수 있습니다. 예를 들어 북미, 유럽, 아시아에서 인스턴스 그룹을 설정하고 부하 분산기의 백엔드 서비스에 연결하면 전 세계의 사용자 요청이 자동으로 사용자와 가장 가까운 VM으로 전송됩니다. 여기서 VM은 상태 확인을 통과하고 용량(분산 모드로 정의됨)이 충분한 것으로 가정합니다. 가장 가까운 VM이 모두 비정상이거나 가장 가까운 인스턴스 그룹 용량은 충분하지만 다른 인스턴스 그룹 용량이 부족하면 부하 분산기는 자동으로 요청을 용량이 충분한 다음으로 가장 가까운 리전으로 보냅니다.


콘텐츠 기반 부하 분산

콘텐츠 기반 부하 분산의 표현

HTTP(S) 부하 분산은 URL 맵을 사용하여 요청된 호스트 이름, 요청 경로 또는 둘 다에 따라 백엔드 서비스를 선택하는 콘텐츠 기반 부하 분산을 지원합니다. 예를 들어 인스턴스 그룹 또는 NEG 집합을 사용하여 동영상 콘텐츠를 처리하고 다른 집합을 사용하여 모든 항목을 처리할 수 있습니다.

HTTP(S) 부하 분산을 Cloud Storage 버킷과 함께 사용할 수도 있습니다. 부하 분산기를 설정한 후 여기에 Cloud Storage 버킷을 추가할 수 있습니다.


통합 부하 분산기 만들기

콘텐츠 기반 및 리전 간 부하 분산의 표현

여러 리전에 백엔드 인스턴스 그룹 또는 NEG가 포함된 각각의 백엔드 서비스 여러 개를 사용하여 콘텐츠 기반 및 리전 간 부하 분산을 모두 제공하도록 프리미엄 등급에서 외부 HTTP(S) 부하 분산기를 구성할 수 있습니다. 사용 사례를 결합 및 확장하여 필요에 맞게 외부 HTTP(S) 부하 분산기를 구성할 수 있습니다.


구성 예시

테스트를 위해 지금 바로 부하 분산기를 빌드하려면 단순 외부 HTTP 부하 분산기 설정 또는 단순 외부 HTTPS 부하 분산기 설정을 참조하세요.

콘텐츠 기반 및 리전 간 부하 분산을 사용하는 좀 더 복잡한 예시는 HTTPS 부하 분산기 만들기를 참조하세요.

HTTP(S) 부하 분산에서 연결 작동 방식

외부 HTTP(S) 부하 분산은 Google 프런트엔드(GFE)라고 하는 여러 프록시에 의해 구현됩니다. 단일 프록시는 없습니다. 프리미엄 등급에서는 동일한 전역 외부 IP 주소가 다양한 접속 지점에서 공지되며 트래픽은 클라이언트에서 가장 가까운 GFE로 전달됩니다.

클라이언트 위치에 따라 여러 GFE에서 백엔드에 대한 HTTP(S) 연결을 시작할 수 있습니다. GFE에서 전송된 패킷에는 상태 확인 프로버에서 사용하는 동일한 범위(35.191.0.0/16130.211.0.0/22)의 소스 IP 주소가 포함됩니다.

백엔드 서비스 구성에 따라 각 GFE에서 백엔드에 연결하는 데 사용하는 프로토콜은 HTTP, HTTPS 또는 HTTP/2일 수 있습니다. HTTP 또는 HTTPS이면 HTTP 버전은 HTTP 1.1입니다. HTTP 연결 유지는 HTTP 1.1 사양에서 지정된 대로 기본적으로 사용 설정됩니다. GFE는 연결 유지 제한 시간 600초를 사용하며 이 제한 시간을 구성할 수 없습니다. 하지만 백엔드 서비스 제한 시간을 설정하여 요청/응답 제한 시간을 구성할 수 있습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.

HTTP 연결 유지는 동일한 TCP 세션을 효율적으로 사용하려고 하지만 보장되지는 않습니다. 밀접하게 관련되어 있지만 HTTP 연결 유지와 TCP 유휴 제한 시간은 동일하지 않습니다.

HTTP 연결과 TCP 세션의 수는 연결하는 GFE 수, GFE에 연결하는 클라이언트 수, 백엔드에 대한 프로토콜, 백엔드가 배포된 위치에 따라 달라집니다.

자세한 내용은 솔루션 가이드 '전역 부하 분산을 사용한 애플리케이션 용량 최적화'의 HTTP(S) 부하 분산 작동 방식을 참조하세요.

아키텍처 및 리소스

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

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

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

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

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

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

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

  • 백엔드 서비스 또는 백엔드 버킷은 정상 백엔드에 요청을 배포합니다.

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

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

    인스턴스 그룹과 NEG가 동일한 백엔드 서비스에 있을 수 없습니다.

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

  • 백엔드가 상태 확인 프로브를 수락하는 방화벽입니다.

소스 IP 주소

각 백엔드 가상 머신(VM) 인스턴스 또는 컨테이너에서 확인되는 패킷의 소스 IP 주소는 다음 범위의 IP 주소입니다.

  • 35.191.0.0/16
  • 130.211.0.0/22

실제 부하 분산 트래픽의 소스 IP 주소는 상태 확인 프로브 IP 범위와 같습니다.

백엔드에서 확인되는 트래픽의 소스 IP 주소는 부하 분산기의 Google Cloud 외부 IP 주소가 아닙니다. 다시 말해 HTTP, SSL 또는 TCP 세션이 두 개 있습니다.

  • 원래 클라이언트에서 부하 분산기(GFE)로 이동하는 세션 1:

    • 원본 IP 주소: 원래 클라이언트 또는 클라이언트가 NAT 뒤에 있는 경우 외부 IP 주소입니다.
    • 대상 IP 주소: 부하 분산기의 IP 주소입니다.
  • 부하 분산기(GFE)에서 백엔드 VM 또는 컨테이너로 이동하는 세션 2:

    • 소스 IP 주소: IP 주소는 35.191.0.0/16 또는 130.211.0.0/22 범위 중 하나입니다.

      실제 소스 주소는 예측할 수 없습니다.

    • 대상 IP 주소: Virtual Private Cloud(VPC) 네트워크의 백엔드 VM 또는 컨테이너의 내부 IP 주소입니다.

부하 분산기와의 클라이언트 통신

  • 클라이언트는 HTTP 1.1 또는 HTTP/2 프로토콜을 사용하여 부하 분산기와 통신할 수 있습니다.
  • HTTPS를 사용하면 최신 클라이언트는 HTTP/2로 기본 설정됩니다. 이는 HTTPS 부하 분산기가 아니라 클라이언트에서 제어됩니다.
  • 부하 분산기에서 구성을 변경하여 HTTP/2를 사용 중지할 수는 없습니다. 하지만 일부 클라이언트는 HTTP/2 대신 HTTP 1.1을 사용하도록 구성할 수 있습니다. 예를 들어 curl과 함께 --http1.1 매개변수를 사용합니다.
  • HTTPS 부하 분산기는 클라이언트 인증서 기반 인증(상호 TLS 인증이라고도 함)을 지원하지 않습니다.

열린 포트

외부 HTTP(S) 부하 분산기는 역방향 프록시 부하 분산기입니다. 부하 분산기는 수신 연결을 종료한 후 부하 분산기에서 백엔드로 새 연결을 엽니다. 역방향 프록시 기능은 Google 프런트엔드(GFE)에서 제공합니다.

설정한 방화벽 규칙은 GFE에서 백엔드로 들어오는 트래픽을 차단하지만 GFE로 들어오는 트래픽은 차단하지 않습니다.

외부 HTTP(S) 부하 분산기에는 동일한 아키텍처에서 실행되는 다른 Google 서비스를 지원하는 열린 포트가 여러 개 있습니다. Google Cloud 외부 HTTP(S) 부하 분산기의 외부 IP 주소에 대해 보안 또는 포트 검사를 실행하면 추가 포트가 열려 있는 것처럼 보입니다.

이는 외부 HTTP(S) 부하 분산기에 영향을 주지 않습니다. 외부 HTTP(S) 부하 분산기의 정의에 사용되는 외부 전달 규칙은 TCP 포트 80, 8080, 443만 참조할 수 있습니다. 다른 TCP 대상 포트를 사용하는 트래픽은 부하 분산기의 백엔드로 전달되지 않습니다.

구성요소

다음은 외부 HTTP(S) 부하 분산기의 구성요소입니다.

전달 규칙 및 주소

전달 규칙은 IP 주소, 포트, 프로토콜별로 트래픽을 대상 프록시, URL 맵, 하나 이상의 백엔드 서비스로 구성된 부하 분산 구성으로 라우팅합니다.

각 전달 규칙은 애플리케이션의 DNS 레코드에 사용할 수 있는 단일 IP 주소를 제공합니다. DNS 기반 부하 분산은 필요 없습니다. 사용할 IP 주소를 지정하거나 Cloud Load Balancing에서 IP 주소를 할당하도록 할 수 있습니다.

  • HTTP 부하 분산기의 전달 규칙은 TCP 포트 80과 8080만 참조할 수 있습니다.
  • HTTPS 부하 분산기의 전달 규칙은 TCP 포트 443만 참조할 수 있습니다.

외부 HTTP(S) 부하 분산기에 필요한 전달 규칙의 유형은 부하 분산기가 속한 네트워크 서비스 등급에 따라 다릅니다.

  • 프리미엄 등급의 외부 HTTP(S) 부하 분산기는 전역 외부 전달 규칙을 사용합니다.
  • 스탠더드 등급의 외부 HTTP(S) 부하 분산기는 리전 외부 전달 규칙을 사용합니다.

대상 프록시

대상 프록시는 클라이언트의 HTTP(S) 연결을 종료합니다. 하나 이상의 전달 규칙이 트래픽을 대상 프록시로 전달하고 대상 프록시가 URL 맵을 참조하여 트래픽을 백엔드로 라우팅하는 방법을 결정합니다.

프록시는 HTTP 요청/응답 헤더를 다음과 같이 설정합니다.

  • Via: 1.1 google(요청 및 응답)
  • X-Forwarded-Proto: [http | https](요청만)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(요청만)
    Cloud Trace의 매개변수를 포함합니다.

기본 헤더가 사용자 요구를 충족하지 않는 경우 커스텀 요청 헤더를 만들 수 있습니다. 이 기능에 대한 자세한 내용은 사용자 정의 요청 헤더 만들기를 참조하세요.

요청 또는 응답 헤더 이름의 대소문자를 유지하기 위해 프록시에 의존하지 마세요. 예를 들어 Server: Apache/1.0 응답 헤더는 클라이언트에 server: Apache/1.0으로 나타날 수 있습니다.

호스트 헤더

부하 분산기가 HTTP 요청을 수행할 때 부하 분산기는 원래 요청의 호스트 헤더를 유지합니다.

X-Forwarded-For 헤더

부하 분산기가 2개의 IP 주소를 X-Forwarded-For 헤더에 추가합니다.

  • 부하 분산기에 연결되는 클라이언트의 IP 주소

  • 부하 분산기의 IP 주소

수신 요청에 X-Forwarded-For 헤더가 없으면 이 두 IP 주소는 전체 헤더 값입니다. 요청에 X-Forwarded-For 헤더가 있으면 부하 분산기로 가는 동안 프록시에서 기록한 IP 주소와 같은 기타 정보가 두 IP 주소보다 먼저 보존됩니다. 부하 분산기는 이 헤더의 마지막 두 IP 주소 앞에 있는 IP 주소를 확인하지 않습니다.

백엔드 인스턴스에서 프록시를 실행할 경우 이 프록시는 일반적으로 X-Forwarded-For 헤더에 더 많은 정보를 추가하므로 소프트웨어에서 이를 고려해야 합니다. 부하 분산기의 프록시 설정된 요청은 130.211.0.0/22 또는 35.191.0.0/16 범위의 IP 주소에서 전송되며 백엔드 인스턴스의 프록시는 이 주소와 백엔드 인스턴스의 자체 IP 주소를 기록할 수 있습니다.

URL 맵

URL 맵은 URL에 기반하여 요청을 적절한 백엔드 서비스로 라우팅하기 위한 일치 패턴을 정의합니다. 기본 서비스는 지정된 호스트 규칙 또는 경로 일치 규칙과 일치하지 않는 요청을 처리하도록 정의됩니다. 리전 간 부하 분산 예시와 같은 상황에서는 URL 규칙을 정의하지 않고 기본 서비스만 활용할 수도 있습니다. 콘텐츠에 기반하여 트래픽을 라우팅하는 경우 URL 맵을 사용하면 URL 구성요소를 검사하여 요청을 서로 다른 백엔드 집합으로 보내 트래픽을 나눌 수 있습니다.

SSL 인증서

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

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

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

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

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

SSL 정책

SSL 정책을 사용하면 HTTPS 부하 분산기가 HTTPS 클라이언트와 협상하는 SSL 기능을 제어할 수 있습니다.

기본적으로 HTTPS 부하 분산은 우수한 보안과 광범위한 호환성을 제공하는 SSL 기능 집합을 사용합니다. 일부 애플리케이션은 HTTPS 또는 SSL 연결에 사용되는 SSL 버전 및 암호화를 보다 강력하게 제어해야 합니다. 부하 분산기가 협상하는 SSL의 기능을 제어하는 SSL 정책을 정의하고 SSL 정책을 대상 HTTPS 프록시와 연결할 수 있습니다.

TLS가 종료되는 위치에 대한 지리적 제어

클라이언트와 부하 분산기 간의 지연을 최소화하기 위해 HTTPS 부하 분산기는 전역으로 분산된 위치에서 TLS를 종료합니다. TLS가 종료되는 위치를 지리적으로 제어해야 하는 경우 Google Cloud 네트워크 부하 분산을 대신 사용하고, 요구사항에 적합한 리전에 있는 백엔드에서 TLS를 종료해야 합니다.

백엔드 서비스

백엔드 서비스는 부하 분산기에 구성 정보를 제공합니다. 외부 HTTP(S) 부하 분산기에는 백엔드 서비스가 하나 이상 있어야 하며 여러 백엔드 서비스가 있을 수 있습니다.

부하 분산기는 백엔드 서비스의 정보를 사용하여 수신 트래픽을 하나 이상의 연결된 백엔드로 보냅니다.

백엔드 서비스의 백엔드는 인스턴스 그룹 또는 네트워크 엔드 포인트 그룹(NEG)일 수 있지만 이 둘의 조합일 수는 없습니다. 백엔드 인스턴스 그룹 또는 NEG를 추가할 때 요청 분산 방법과 대상 용량을 정의하는 분산 모드를 지정합니다. 자세한 내용은 로드 분산 알고리즘을 참조하세요.

HTTP(S) 부하 분산은 사용자가 백엔드 서비스의 인스턴스 그룹에 대한 자동 확장을 수행할 수 있도록 하는 Cloud Load Balancing 자동 확장 처리를 지원합니다. 자세한 내용은 HTTP(S) 부하 분산 제공 용량을 기준으로 확장을 참조하세요.

백엔드 서비스에서 연결 드레이닝을 사용 설정하면 트래픽을 제공하는 인스턴스가 종료되거나 수동으로 삭제되거나 자동 확장 처리를 통해 삭제되는 경우 사용자에 대한 방해를 최소화할 수 있습니다. 자세한 내용은 연결 드레이닝 사용 설정을 참조하세요.

외부 HTTP(S) 부하 분산기와 연관된 백엔드 서비스에 대한 변경 사항은 즉시 적용되지 않습니다. 변경사항이 네트워크 전체에 전파되려면 몇 분이 걸릴 수 있습니다.

다른 네트워크 서비스 등급의 부하 분산기 동작

HTTP(S) 부하 분산은 프리미엄 네트워크 서비스 등급이 사용되는 전역 서비스입니다. 한 리전에 2개 이상의 백엔드 서비스가 존재할 수 있고, 백엔드 서비스를 2개 이상의 리전에서 생성할 수 있으며, 이러한 서비스는 모두 동일한 전역 부하 분산기에서 처리됩니다. 트래픽은 다음과 같이 백엔드 서비스에 할당됩니다.

  1. 사용자 요청이 수신되면 부하 분산 서비스가 소스 IP 주소에서 요청의 대략적인 출처를 확인합니다.
  2. 부하 분산 서비스는 백엔드 서비스가 소유한 인스턴스의 위치, 전체 용량, 현재 총 사용량을 인식합니다.
  3. 사용자에게 가장 가까운 인스턴스에 이용 가능한 용량이 있으면 요청은 가장 가까운 인스턴스 집합으로 전달됩니다.
  4. 한 리전에 수신되는 요청은 해당 리전의 이용 가능한 모든 백엔드 서비스와 인스턴스에 균등하게 분산됩니다. 하지만 부하가 아주 적은 경우에는 분산이 균등하지 않게 나타날 수 있습니다.
  5. 지정한 리전에 이용 가능한 용량이 있는 정상 인스턴스가 없는 경우, 부하 분산기는 이용 가능한 용량이 있는 그 다음으로 가까운 리전으로 요청을 전송합니다.

스탠더드 네트워크 서비스 등급 사용 시 HTTP(S) 부하 분산은 리전 서비스입니다. 백엔드 인스턴스 그룹 또는 NEG는 모두 부하 분산기의 외부 IP 주소와 전달 규칙에서 사용하는 리전에 있어야 합니다.

상태 확인

각 백엔드 서비스는 사용 가능한 각 인스턴스에 대해 수행되는 상태 확인도 지정합니다. 상태 확인 프로브가 제대로 작동하려면 130.211.0.0/2235.191.0.0/16의 트래픽이 인스턴스에 도달하도록 허용하는 방화벽 규칙을 만들어야 합니다.

상태 확인에 대한 자세한 내용은 상태 확인 만들기를 참조하세요.

백엔드 프로토콜

외부 HTTP(S) 부하 분산기에 백엔드 서비스를 구성할 때 백엔드 서비스가 백엔드와 통신하는 데 사용할 프로토콜을 설정합니다. HTTP, HTTPS 또는 HTTP/2를 선택할 수 있습니다. 부하 분산기는 지정된 프로토콜만 사용합니다. 지정된 프로토콜로 백엔드에 대한 연결을 협상할 수 없는 경우 부하 분산기는 다른 프로토콜 중 하나로 돌아가지 않습니다.

HTTP/2를 사용하는 경우 TLS를 사용해야 합니다. 암호화되지 않은 HTTP/2는 지원되지 않습니다.

필수는 아니지만 프로토콜이 백엔드 서비스의 프로토콜과 일치하는 상태 확인을 사용하는 것이 좋습니다. 예를 들어 HTTP/2 상태 확인은 백엔드에 대한 HTTP/2 연결을 가장 정확하게 테스트합니다.

Google Cloud 애플리케이션에서 gRPC 사용

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

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

Google Cloud 애플리케이션에서 gRPC를 사용하려면 HTTP/2를 통해 엔드 투 엔드 요청을 프록시해야 합니다. 외부 HTTP(S) 부하 분산기를 사용하여 이렇게 하려면 다음 안내를 따르세요.

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

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

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

Google Kubernetes Engine 인그레스에서 HTTP/2를 사용하거나 인그레스에서 gRPC 및 HTTP/2를 사용하여 외부 HTTP(S) 부하 분산기를 구성하려면 인그레스를 사용한 부하 분산용 HTTP/2를 참조하세요.

HTTP/2를 사용하는 경우의 문제해결에 대한 자세한 내용은 백엔드에 HTTP/2를 사용하여 문제해결을 참조하세요.

HTTP/2 제한사항에 대한 자세한 내용은 HTTP/2 제한사항을 참조하세요.

백엔드 버킷

백엔드 버킷은 들어오는 트래픽을 Cloud Storage 버킷으로 전달합니다.

다음 다이어그램과 같이 부하 분산기에서 /static 경로의 트래픽을 스토리지 버킷으로 전송하고 다른 모든 요청은 다른 백엔드로 전송하도록 할 수 있습니다.

HTTP(S) 부하 분산을 사용하여 다양한 백엔드 유형에 트래픽 분산(확대하려면 클릭)
HTTP(S) 부하 분산을 사용하여 다양한 백엔드 유형에 트래픽 분산(확대하려면 클릭)

기존 부하 분산기에 버킷을 추가하는 방법의 예시는 백엔드 버킷으로 부하 분산기 설정을 참조하세요.

방화벽 규칙

백엔드 인스턴스는 부하 분산기 GFE/상태 확인 범위에서의 연결을 허용해야 합니다. 즉, 130.211.0.0/2235.191.0.0/16의 트래픽이 백엔드 인스턴스 또는 엔드포인트에 도달하도록 허용하는 방화벽 규칙을 만들어야합니다. 이러한 IP 주소 범위는 상태 확인 패킷과 백엔드로 전송되는 모든 부하 분산 패킷의 소스로 사용됩니다.

이 방화벽 규칙에 대해 구성하는 포트는 백엔드 인스턴스 또는 엔드포인트에 대한 트래픽을 허용해야 합니다.

  • 각 전달 규칙에서 사용하는 포트를 허용해야 합니다.
  • 각 백엔드 서비스에 구성된 각 상태 확인에 사용하는 포트를 허용해야 합니다.

방화벽 규칙은 Google 프런트엔드(GFE) 프록시가 아닌 VM 인스턴스 수준에서 구현됩니다. Google Cloud 방화벽 규칙을 사용하여 트래픽이 부하 분산기에 도달하는 것을 막을 수 없습니다.

상태 확인 프로브와 130.211.0.0/2235.191.0.0/16의 트래픽을 허용해야 하는 이유에 대한 자세한 내용은 프로브 IP 범위 및 방화벽 규칙을 참조하세요.

반환 경로

Google Cloud는 상태 확인을 위해 VPC 네트워크에 정의되지 않은 특수 경로를 사용합니다. 자세한 내용은 부하 분산기 반환 경로를 참조하세요.

부하 분산 알고리즘

백엔드 인스턴스 그룹 또는 NEG를 백엔드 서비스에 추가할 때 백엔드 로드 및 대상 용량을 측정하는 방법을 정의하는 분산 모드를 지정합니다. 외부 HTTP(S) 부하 분산은 두 가지 분산 모드를 지원합니다.

  • 인스턴스 그룹 또는 NEG의 경우 RATE는 초당 최대 대상 요청(쿼리) 수(RPS, QPS)입니다. 모든 최대 백엔드가 용량에 도달하거나 용량을 초과할 경우 대상 최대 RPS/QPS를 초과할 수 있습니다.

  • UTILIZATION은 인스턴스 그룹에 있는 VM의 백엔드 사용률입니다.

Google 프런트엔드(GFE)가 요청을 백엔드 인스턴스로 전송하기 전에 GFE는 요청을 수신할 수 있는 백엔드 인스턴스를 예측합니다. 이 용량 예측은 요청이 도착하는 시점이 아니라 사전에 수행됩니다. GFE는 사용 가능한 용량에 대한 주기적인 정보를 받고 그에 따라 들어오는 요청을 분산합니다.

용량의 의미는 부분적으로 분산 모드에 따라 다릅니다. RATE 모드에서는 비교적 간단합니다. GFE는 초당 할당할 수 있는 요청 수를 정확하게 결정합니다. UTILIZATION 기반 부하 분산은 좀 더 복잡합니다. 부하 분산기는 인스턴스의 현재 사용률을 확인한 후 각 인스턴스에서 처리할 수 있는 쿼리 부하를 추정합니다. 이 예상치는 인스턴스 사용률 및 트래픽 패턴이 변경되는 것처럼 시간이 경과하면 변경됩니다.

용량 예측과 사전 할당 등 두 가지 요인 모두 인스턴스 간 분포에 영향을 미칩니다. 따라서 Cloud Load Balancing은 두 인스턴스 간에 요청을 정확하게 50:50으로 분산하는 간단한 라운드 로빈 부하 분산기와 다르게 동작합니다. 대신 Google Cloud 부하 분산은 각 요청에 대한 백엔드 인스턴스 선택을 최적화하려고 합니다.

자세한 내용은 트래픽 분산을 참조하세요.

분산 모드에 대한 자세한 내용은 분산 모드를 참조하세요.

네트워크 서비스 등급

외부 HTTP(S) 부하 분산기가 프리미엄 등급인 경우 사용자에게 가장 가까운 리전의 백엔드에 사용 가능한 용량이 있으면 부하 분산기로 전송된 요청은 해당 리전의 백엔드 인스턴스 그룹 또는 NEG로 전달됩니다. 사용 가능한 용량은 부하 분산기의 분산 모드에서 구성됩니다.

외부 HTTP(S) 부하 분산기가 스탠더드 등급인 경우 백엔드 인스턴스 그룹 또는 NEG는 모두 부하 분산기의 외부 IP 주소와 전달 규칙에서 사용하는 리전에 있어야 합니다.

리전과 영역

리전이 선택된 후

  • 리전 내 여러 영역에 백엔드를 구성하면 외부 HTTP(S) 부하 분산기가 백엔드 인스턴스 용량과 세션 어피니티에 따라 가능한 한 영역 전체에서 요청을 분산하려고 합니다.

  • 영역 내에서 외부 HTTP(S) 부하 분산기는 사용 가능한 용량과 세션 어피니티에 따라 부하 분산 알고리즘을 사용하여 요청을 분산하려고 합니다.

세션 어피니티

세션 어피니티는 백엔드가 정상이고 구성된 분산 모드에 따라 용량이 있는 경우 특정 클라이언트의 요청을 동일한 백엔드로 전송하려고 합니다.

Google Cloud HTTP(S) 부하 분산은 다음과 같이 세 가지 유형의 세션 어피니티를 제공합니다.

  • 없음. 부하 분산기에 세션 어피니티가 설정되지 않았습니다.
  • 클라이언트 IP 어피니티는 동일한 클라이언트 IP 주소의 요청을 동일한 백엔드로 전송합니다.
  • 생성된 쿠키 어피니티는 첫 번째 요청 시 클라이언트 쿠키를 설정한 다음 해당 쿠키가 포함된 요청을 동일한 백엔드로 전송합니다.

세션 어피니티를 사용하는 경우 UTILIZATION보다는 RATE 분산 모드를 사용하는 것이 좋습니다. 세션 어피니티는 분산 모드를 초당 요청 수(RPS)로 설정할 경우 가장 잘 작동합니다.

WebSocket 프록시 지원

HTTP/2가 아닌 HTTP 또는 HTTPS를 백엔드의 프로토콜로 사용하는 경우 HTTPS 부하 분산은 WebSocket 프로토콜을 기본적으로 지원합니다.

WebSocket 프로토콜을 사용하여 클라이언트와 통신하는 백엔드는 확장성과 가용성을 위한 프런트엔드로 외부 HTTP(S) 부하 분산기를 사용할 수 있습니다. 부하 분산기는 추가 구성 없이도 WebSocket 연결을 프록시할 수 있습니다.

RFC 6455에서 정의하는 WebSocket 프로토콜은 클라이언트와 서버 간의 전이중 통신 채널을 제공합니다. 채널은 HTTP(S) 요청으로 시작됩니다.

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

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

HTTP(S) 부하 분산기에 클라이언트 IP 또는 생성된 쿠키 세션 어피니티를 구성하면 인스턴스가 상태 확인을 계속 통과하고 용량이 있는 한 클라이언트의 모든 WebSocket 연결이 동일한 백엔드 인스턴스로 전송됩니다.

WebSocket 프로토콜은 인그레스를 사용하여 지원됩니다.

HTTPS 부하 분산을 위한 QUIC 프로토콜 지원

HTTPS 부하 분산은 부하 분산기와 클라이언트 간의 연결에서 QUIC 프로토콜을 지원합니다. QUIC는 TCP와 유사한 정체 제어와 HTTP/2용 SSL/TLS에 해당하는 보안 및 향상된 성능을 제공하는 전송 레이어 프로토콜입니다. QUIC를 이용하면 클라이언트 연결 초기화 시간을 줄이고 다중화 스트림의 대기 행렬 막힘을 제거할 수 있으며 클라이언트 IP 주소 변경 시 연결 이전을 지원합니다.

QUIC는 부하 분산기와 백엔드가 아니라, 클라이언트와 부하 분산기 간의 연결에 영향을 줍니다.

대상 프록시의 QUIC 재정의 설정에서 다음 중 하나를 사용할 수 있습니다.

  • 가능하다면 부하 분산기에 대한 QUIC 협상을 수행합니다.
  • 부하 분산기의 QUIC를 항상 사용 중지합니다.

QUIC 재정의 설정에 대한 값을 지정하지 않으면 Google에서 QUIC 사용 시기를 관리합니다. Google은 gcloud 명령줄 도구--quic-override 플래그가 ENABLE로 설정되었거나 REST APIquicOverride 플래그가 ENABLE로 설정된 경우에만 QUIC를 사용 설정합니다.

QUIC 지원 사용 및 사용 중지에 대한 자세한 내용은 대상 프록시를 참조하세요. 다음과 같이 QUIC 지원을 사용 설정 또는 중지할 수 있습니다.

QUIC에는 다음과 같은 SSL 인증서 요구사항이 있습니다.

  • SSL 인증서의 commonName(CN) 속성은 부하 분산기의 IP 주소로 확인되는 DNS 이름과 일치해야 합니다. 그렇지 않으면 부하 분산기가 QUIC 콘텐츠를 제공하지 않습니다.
  • SSL 인증서는 클라이언트에서 신뢰하는 인증 기관(CA)에서 서명해야 합니다. 부하 분산기가 자체 서명된 인증서 또는 클라이언트에서 신뢰하지 않는 CA에서 서명한 인증서를 사용하는 경우 QUIC 전송을 협상할 수 없습니다.

QUIC 협상 방식

QUIC를 사용 설정하면 부하 분산기가 QUIC 기능을 클라이언트에 공지할 수 있어 QUIC를 지원하는 클라이언트는 HTTPS 부하 분산기와의 QUIC 연결 설정을 시도할 수 있습니다. 올바르게 구현된 클라이언트는 QUIC 연결을 설정할 수 없다면 언제나 HTTPS 또는 HTTP/2로 대체합니다. 이러한 대체 기능 덕분에 부하 분산기에서 QUIC를 사용 설정하거나 사용 중지해도 부하 분산기가 클라이언트에 연결하는 기능에 방해가 되지 않습니다.

HTTPS 부하 분산기에서 QUIC를 사용 설정하면 상황에 따라 클라이언트가 QUIC를 협상하는 대신 HTTPS 또는 HTTP/2로 대체할 수 있습니다. 이러한 경우의 예시는 다음과 같습니다.

  • 클라이언트가 HTTPS 부하 분산기가 지원하는 QUIC 버전과 호환되지 않는 QUIC 버전을 지원하는 경우
  • 부하 분산기가 UDP 트래픽이 차단되거나 비율 제한에 도달하여 QUIC가 작동하지 않는 것을 감지하는 경우
  • 버그, 취약점 또는 기타 문제에 대한 대응으로 HTTPS 부하 분산기에서 QUIC가 일시적으로 사용 중지된 경우

이러한 환경 때문에 연결이 HTTPS나 HTTP/2로 대체되더라도 부하 분산기의 장애로 간주되지 않습니다.

QUIC를 사용하기 전에 앞서 설명한 동작을 워크로드가 수용할 수 있는지 확인하세요.

SSL 인증서

대상 HTTPS 프록시에서 하나 이상의 SSL 인증서를 참조해야 합니다.

이러한 인증서는 대상 HTTPS 프록시가 Google 프런트엔드(GFE)와 클라이언트 간의 통신을 보호하는 데 사용됩니다. 이러한 인증서는 자체 관리형 또는 Google 관리형 SSL 인증서일 수 있습니다.

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

최상의 보안을 위해 GFE에서 백엔드로의 트래픽을 암호화할 수도 있습니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.

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

TLS 지원

기본적으로 HTTPS 대상 프록시는 클라이언트 SSL 요청을 종료할 때 TLS 1.0, 1.1, 1.2, 1.3만 허용합니다. SSL 정책을 이용하면 이 기본 동작을 변경하고 부하 분산기가 SSL과 클라이언트를 협상하는 방법을 제어할 수 있습니다.

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

제한 시간 및 재시도

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

    • 백엔드에서 HTTP 응답을 반환하는 데 시간이 더 오래 걸릴 것으로 예상되는 경우
    • 연결이 WebSocket으로 업그레이드되는 경우(HTTP(S) 부하 분산에만 해당)

    부하 분산기를 통해 전송된 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) 부하 분산 로깅 및 모니터링을 참조하세요.

잘못된 요청 및 응답 처리

외부 HTTP(S) 부하 분산기는 여러 가지 이유로 클라이언트 요청과 백엔드 응답이 각각 백엔드 또는 클라이언트에 도달하지 못하도록 차단합니다. 이러한 이유로는 HTTP/1.1 규정 준수를 위한 이유도 있고 예기치 않은 데이터가 백엔드로 또는 백엔드에서 전달되는 것을 방지하기 위한 이유도 있습니다. 사용 중지할 수 있는 검사가 없습니다.

부하 분산기는 HTTP/1.1 규정 준수를 위해 다음과 같은 경우 차단을 수행합니다.

  • 요청의 첫 번째 줄을 파싱할 수 없습니다.
  • 헤더에 : 구분 기호가 없습니다.
  • 헤더 또는 첫 번째 줄에 잘못된 문자가 있습니다.
  • 콘텐츠 길이가 유효한 숫자가 아니거나 콘텐츠 길이 헤더가 여러 개입니다.
  • 전송 인코딩 키가 여러 개 있거나 인식할 수 없는 전송 인코딩 값이 존재합니다.
  • 분할되지 않은 본문이 있으며 콘텐츠 길이가 지정되지 않았습니다.
  • 본문 단위를 파싱할 수 없습니다. 이는 일부 데이터가 백엔드에 도달하는 유일한 경우입니다. 부하 분산기는 파싱할 수 없는 청크를 수신하면 클라이언트 및 백엔드와의 연결을 닫습니다.

다음 중 하나라도 해당하면 부하 분산기가 요청을 차단합니다.

  • 요청 헤더와 요청 URL의 총 크기가 외부 HTTP(S) 부하 분산의 최대 요청 헤더 크기 한도를 초과합니다.
  • 요청 메서드가 본문을 허용하지 않지만 요청에 본문이 존재합니다.
  • 요청에 Upgrade 헤더가 포함되어 있고 WebSocket 연결을 사용 설정하기 위해 Upgrade 헤더가 사용되지 않습니다.
  • HTTP 버전을 알 수 없습니다.

다음 중 하나라도 해당하면 부하 분산기가 백엔드의 응답을 차단합니다.

  • 응답 헤더의 총 크기가 외부 HTTP(S) 부하 분산의 최대 응답 헤더 크기 한도를 초과합니다.
  • HTTP 버전을 알 수 없습니다.

사양 및 제한사항

  • HTTP(S) 부하 분산은 HTTP/1.1 100 Continue 응답을 지원합니다.

HTTP/2 제한사항

  • 부하 분산기와 인스턴스 사이의 HTTP/2에는 HTTP(S)보다 인스턴스에 훨씬 더 많은 TCP 연결이 필요할 수 있습니다. HTTP(S)와의 연결 수를 줄이는 최적화 방법인 연결 풀링은 현재 HTTP/2에서 사용할 수 없습니다.
  • 부하 분산기와 백엔드 간의 HTTP/2는 다음을 지원하지 않습니다.
    • 서버 푸시
    • WebSocket

Cloud CDN 사용 제한사항

  • 동일한 백엔드 서비스로 IAP(Identity-Aware Proxy) 또는 Cloud CDN을 사용 설정할 수 없습니다. 그러면 구성 프로세스가 실패합니다.

다음 단계