외부 애플리케이션 부하 분산기의 요청 분산

이 문서에서는 외부 애플리케이션 부하 분산기가 연결을 처리하고, 트래픽을 라우팅하고, 세션 어피니티를 유지하는 방법을 자세히 설명합니다.

연결 작동 방식

Google Cloud의 외부 애플리케이션 부하 분산기(전역 및 리전)는 분산 프록시(GFE) 또는 Envoy 관리 서브넷을 사용하여 라우팅을 간소화합니다. 구성 가능한 제한 시간, TLS 종료, 기본 제공 보안을 통해 전 세계 또는 리전에서 규정을 준수하는 확장 가능한 애플리케이션 제공을 보장합니다.

전역 외부 애플리케이션 부하 분산기 연결

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

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

백엔드 서비스 구성에 따라 각 GFE에서 백엔드에 연결하는 데 사용하는 프로토콜은 HTTP, HTTPS 또는 HTTP/2일 수 있습니다. HTTP 또는 HTTPS 연결에서 사용되는 HTTP 버전은 HTTP 1.1입니다.

HTTP 연결 유지는 HTTP 1.1 사양에서 지정된 대로 기본적으로 사용 설정됩니다. HTTP 연결 유지는 동일한 TCP 세션을 효율적으로 사용하려고 하지만 보장되지는 않습니다. GFE는 클라이언트 HTTP 연결 유지 제한 시간 610초와 기본 백엔드 연결 유지 제한 시간 값 600초를 사용합니다. 클라이언트 HTTP 연결 유지 제한 시간을 업데이트할 수 있지만 백엔드 연결 유지 제한 시간 값은 고정되어 있습니다. 백엔드 서비스 제한 시간을 설정하여 요청 및 응답 제한 시간을 구성할 수 있습니다. 밀접하게 관련되어 있지만 HTTP 연결 유지와 TCP 유휴 상태 제한 시간은 동일하지 않습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.

트래픽이 고르게 분산되도록 부하 분산기에서 Connection: close 헤더가 포함된 응답을 완료한 후 FIN ACK 패킷을 전송하여 TCP 연결을 완전히 닫거나 응답을 완료한 후 HTTP/2 GOAWAY 프레임을 실행할 수 있습니다. 이 동작은 활성 요청 또는 응답을 방해하지 않습니다.

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

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

리전 외부 애플리케이션 부하 분산기 연결

리전 외부 애플리케이션 부하 분산기는 Envoy 프록시에 구현되는 관리형 서비스입니다. 리전 외부 애플리케이션 부하 분산기는 프록시 전용 서브넷이라는 공유 서브넷을 사용하여 Google에서 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 프로비저닝합니다. 이 프록시 전용 서브넷의 --purpose 플래그는 REGIONAL_MANAGED_PROXY로 설정됩니다. 특정 네트워크와 리전의 모든 리전 Envoy 기반 부하 분산기가 이 서브넷을 공유합니다.

클라이언트는 부하 분산기의 IP 주소와 포트를 사용하여 부하 분산기에 연결합니다. 클라이언트와 동일한 리전에 있는 프록시 전용 서브넷으로 클라이언트 요청이 전달됩니다. 부하 분산기에서 클라이언트 요청을 종료한 후 프록시 전용 서브넷에서 백엔드로 새 연결을 엽니다. 따라서 부하 분산기에서 전송된 패킷에는 프록시 전용 서브넷의 소스 IP 주소가 포함됩니다.

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

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

  • 클라이언트는 HTTP 1.1 또는 HTTP/2 프로토콜을 사용하여 부하 분산기와 통신할 수 있습니다.
  • HTTPS를 사용하면 최신 클라이언트는 HTTP/2로 기본 설정됩니다. 이는 HTTPS 부하 분산기가 아니라 클라이언트에서 제어됩니다.
  • 부하 분산기에서 구성을 변경하여 HTTP/2를 사용 중지할 수는 없습니다. 하지만 일부 클라이언트는 HTTP/2 대신 HTTP 1.1을 사용하도록 구성할 수 있습니다. 예를 들어 curl과 함께 --http1.1 매개변수를 사용합니다.
  • 외부 애플리케이션 부하 분산기는 HTTP/1.1 100 Continue 응답을 지원합니다.

각 모드의 외부 애플리케이션 부하 분산기 전달 규칙에서 지원하는 프로토콜의 전체 목록은 부하 분산기 기능을 참조하세요.

클라이언트 패킷의 소스 IP 주소

백엔드에서 인식하는 패킷의 소스 IP 주소는 부하 분산기의Google Cloud 외부 IP 주소가 아닙니다. 다시 말해 TCP 연결이 두 개 있습니다.

전역 외부 애플리케이션 부하 분산기:

  • 원래 클라이언트에서 부하 분산기(GFE)로의 연결 1:

    • 소스 IP 주소: 원래 클라이언트 (또는 클라이언트가 NAT 게이트웨이 또는 전달 프록시 뒤에 있는 경우 외부 IP 주소)입니다.
    • 대상 IP 주소: 부하 분산기의 IP 주소입니다.

  • 부하 분산기(GFE)에서 백엔드 VM 또는 엔드포인트로의 연결 2:

    • 소스 IP 주소: IP 주소는 방화벽 규칙에 지정된 범위 중 하나입니다.

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

리전 외부 애플리케이션 부하 분산기:

  • 원래 클라이언트에서 부하 분산기(프록시 전용 서브넷)로의 연결 1:

    • 소스 IP 주소: 원래 클라이언트 (또는 클라이언트가 NAT 게이트웨이 또는 전달 프록시 뒤에 있는 경우 외부 IP 주소)입니다.
    • 대상 IP 주소: 부하 분산기의 IP 주소입니다.

  • 부하 분산기(프록시 전용 서브넷)에서 백엔드 VM 또는 엔드포인트로의 연결 2:

    • 소스 IP 주소: 동일한 리전 및 네트워크에 부하 분산기로 배포된 모든 Envoy 기반 부하 분산기에서 공유되는 프록시 전용 서브넷의 IP 주소입니다.

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

특수 라우팅 경로

Google Cloud 는 VPC 네트워크에 정의되지 않은 특수 경로를 사용해서 다음 유형의 트래픽에 대한 패킷을 라우팅합니다.

Google Cloud 는 프록시 전용 서브넷에 대한 서브넷 경로를 사용하여 다음 유형의 트래픽에 대한 패킷을 라우팅합니다.

  • 분산된 Envoy 상태 확인을 사용하는 경우

리전 외부 애플리케이션 부하 분산기에서는 Google Cloud 가 오픈소스 Envoy 프록시를 사용하여 부하 분산기에 대한 클라이언트 요청을 종료합니다. 부하 분산기가 TCP 세션을 종료하고 리전의 프록시 전용 서브넷에서 백엔드로 새 TCP 세션을 엽니다. VPC 네트워크 내에 정의된 경로가 Envoy 프록시와 백엔드의 상호 통신을 지원합니다.

열린 포트

GFE에는 동일한 아키텍처에서 실행되는 다른 Google 서비스를 지원하는 열린 포트가 여러 개 있습니다. 포트 스캔을 실행하면 GFE에서 실행되는 다른 Google 서비스에 대한 다른 열린 포트가 표시될 수 있습니다.

GFE 기반 부하 분산기(전역 외부 애플리케이션 부하 분산기와 기본 애플리케이션 부하 분산기)는 항상 포트 80 및 443을 부하 분산기의 전달 규칙에서 구성한 다른 포트와 함께 열린 상태로 표시합니다. 그러나 포트 80 또는 포트 443에 대한 전달 규칙을 구성하지 않았으면 해당 포트로 전송되는 모든 연결이 거부됩니다. 반대로 리전 외부 애플리케이션 부하 분산기는 Envoy 프록시를 사용하여 구현되며 스캔 중에는 추가적인 열린 포트를 표시하지 않습니다.

다음과 같은 이유로 GFE 기반 부하 분산기의 IP 주소에 포트 스캔을 실행하는 것은 감사 측면에서 유용하지 않습니다.

  • 포트 스캔(예: nmap 사용)에서는 일반적으로 TCP SYN 프로브를 수행할 때 응답 패킷이나 TCP RST 패킷을 예상하지 않습니다. GFE는 전달 규칙을 구성한 포트에만 SYN 프로브에 대한 응답으로 SYN-ACK 패킷을 전송합니다. GFE는 부하 분산기의 IP 주소 및 이 전달 규칙에 구성된 목적지 포트로 전송된 패킷에 대한 응답으로만 패킷을 백엔드로 전송합니다. 다른 IP 주소나 포트로 전송되는 패킷은 백엔드로 전송되지 않습니다.

    GFE는 Google Cloud Armor와 같은 보안 기능을 구현합니다. GFE는 Cloud Armor Standard를 사용하여 볼륨 및 프로토콜 기반 DDoS 공격과 SYN 플러드로부터 상시 보호 기능을 제공합니다. Cloud Armor를 명시적으로 구성하지 않은 경우에도 이 보호 기능을 사용할 수 있습니다. 보안 정책을 구성하거나 Managed Protection 플러스에 등록한 경우에만 요금이 청구됩니다.

  • 부하 분산기의 IP 주소로 전송되는 패킷은 Google Fleet의 모든 GFE가 응답할 수 있습니다. 하지만 부하 분산기 IP 주소와 목적지 포트 조합을 스캔하면 TCP 연결당 GFE 1개만 조사됩니다. 부하 분산기의 IP 주소는 단일 기기 또는 시스템에 할당되지 않습니다. 따라서 GFE 기반 부하 분산기의 IP 주소를 스캔해도 Google Fleet에 있는 모든 GFE가 스캔되지 않습니다.

이러한 점을 고려하여 백엔드 인스턴스의 보안을 감사하는 효과적인 방법을 몇 가지 소개합니다.

  • 보안 감사자는 부하 분산기 구성의 전달 규칙 구성을 검사해야 합니다. 전달 규칙에서는 부하 분산기가 패킷을 수락하여 백엔드로 전달하는 대상 포트를 정의합니다. GFE 기반 부하 분산기의 경우 외부 전달 규칙마다 하나의 대상 TCP 포트만 참조할 수 있습니다. TCP 포트 443을 사용하는 부하 분산기에서는 연결이 QUIC(HTTP/3)로 업그레이드되면 UDP 포트 443이 사용됩니다.

  • 보안 감사자는 백엔드 VM에 적용 가능한 방화벽 규칙 구성을 검사해야 합니다. 설정한 방화벽 규칙은 GFE에서 백엔드 VM으로 들어오는 트래픽을 차단하지만 GFE로 들어오는 트래픽은 차단하지 않습니다. 권장사항은 방화벽 규칙 섹션을 참조하세요.

TLS 종료

다음 표에서는 외부 애플리케이션 부하 분산기가 TLS 종료를 처리하는 방법을 요약해서 보여줍니다.

부하 분산기 모드 TLS 종료
전역 외부 애플리케이션 부하 분산기 전 세계 어디에나 있을 수 있는 GFE에서 TLS가 종료됩니다.
기본 애플리케이션 부하 분산기 전 세계 어디에나 있을 수 있는 GFE에서 TLS가 종료됩니다.
리전 외부 애플리케이션 부하 분산기 TLS는 사용자가 선택한 리전의 프록시 전용 서브넷에 있는 Envoy 프록시에서 종료됩니다. TLS가 종료되는 리전을 지리적으로 제어해야 하는 경우 이 부하 분산기 모드를 사용합니다.

제한 시간 및 재시도

외부 애플리케이션 부하 분산기는 HTTP 또는 HTTPS 트래픽에 대해 다음 유형의 제한 시간을 지원합니다.

제한 시간 유형 및 설명 기본값 커스텀 제한 시간 값 지원
전역 기본 리전
백엔드 서비스 제한 시간1

요청 및 응답 제한 시간. 부하 분산기가 요청의 첫 번째 바이트를 백엔드로 보내는 시점과 백엔드가 HTTP 응답의 마지막 바이트를 부하 분산기로 반환하는 시점 사이에 허용되는 최대 시간을 나타냅니다. 백엔드가 이 제한 시간 내에 전체 HTTP 응답을 부하 분산기에 반환하지 않았으면 남은 응답 데이터가 삭제됩니다.
  • 백엔드 서비스의 서버리스 NEG: 60분
  • 백엔드 서비스의 다른 모든 백엔드 유형: 30초 =
  • 백엔드 버킷: 24시간(86,400초)
클라이언트 HTTP 연결 유지 제한 시간

클라이언트와 부하 분산기의 프록시 사이의 TCP 연결이 유휴 상태로 유지될 수 있는 최대 시간입니다. 여러 HTTP 요청에 같은 TCP 연결이 사용될 수 있습니다.

  • 전역 외부 애플리케이션 부하 분산기와 기본 애플리케이션 부하 분산기의 경우 부하 분산기 프록시는 첫 번째 레이어 GFE입니다.
  • 리전 외부 애플리케이션 부하 분산기의 경우 부하 분산기 프록시는 Envoy 소프트웨어입니다.
 610초
백엔드 HTTP 연결 유지 제한 시간

부하 분산기의 프록시와 백엔드 사이의 TCP 연결이 유휴 상태로 유지될 수 있는 최대 시간입니다. 여러 HTTP 요청에 같은 TCP 연결이 사용될 수 있습니다.

  • 전역 외부 애플리케이션 부하 분산기와 기본 애플리케이션 부하 분산기의 경우 부하 분산기 프록시는 두 번째 레이어 GFE입니다.
  • 리전 외부 애플리케이션 부하 분산기의 경우 부하 분산기 프록시는 Envoy 소프트웨어입니다.
  • 백엔드 서비스: 10분(600초)
  • 백엔드 버킷: 6분(360초)
QUIC 세션 유휴 제한 시간

(다운스트림) 클라이언트와 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 GFE 사이에 QUIC 세션이 유휴 상태일 수 있는 최대 시간입니다.

전역 외부 애플리케이션 부하 분산기와 기본 애플리케이션 부하 분산기의 경우:

QUIC 세션 유휴 제한 시간은 클라이언트 유휴 제한 시간 또는 GFE 유휴 제한 시간(300초)의 최솟값입니다.

GFE 유휴 제한 시간은 300초로 고정됩니다. 클라이언트 유휴 제한 시간은 값을 구성할 수 있습니다.

1서버리스 NEG 백엔드의 경우에는 구성할 수 없습니다. 백엔드 버킷에 대해 구성할 수 없습니다.

백엔드 서비스 제한 시간

구성 가능한 백엔드 서비스 제한 시간은 부하 분산기에서 백엔드가 HTTP 요청을 처리하고 해당 HTTP 응답을 반환할 때까지 기다리는 최대 시간을 나타냅니다. 서버리스 NEG를 제외하고 백엔드 서비스 제한 시간의 기본값은 30초입니다.

예를 들어 500MB 파일을 다운로드하려는데 백엔드 서비스 제한 시간이 90초라면 부하 분산기는 백엔드가 500MB 파일 전체를 90초 이내에 전송할 것으로 예상합니다. 백엔드가 전체 HTTP 응답을 보내지 못할 정도로 짧게 백엔드 서비스 제한 시간을 구성할 수 있습니다. 이 경우 부하 분산기에 백엔드로부터의 HTTP 응답 헤더가 최소한 한 개 이상 있으면 부하 분산기가 전체 응답 헤더와 백엔드 서비스 제한 시간 내에 가능할 만큼 응답 본문을 반환합니다.

백엔드 서비스 제한 시간을 백엔드가 HTTP 응답을 처리하는 데 필요한 가장 긴 시간으로 설정하는 것이 좋습니다. 백엔드에서 실행 중인 소프트웨어가 HTTP 요청을 처리하고 전체 응답을 반환하는 데 더 많은 시간이 필요한 경우 백엔드 서비스 제한 시간을 늘리는 것이 좋습니다. 예를 들어 jsonPayload.statusDetail client_timed_out 오류와 함께 HTTP 408 상태 코드 응답이 표시되면 제한 시간을 늘리는 것이 좋습니다.

백엔드 서비스 제한 시간은 1~2,147,483,647초 사이의 값을 허용하지만 큰 값은 실용적인 구성 옵션이 아닙니다. Google Cloud 는 기본 TCP 연결이 백엔드 서비스 제한 시간 값 전체에 대해 열린 상태로 유지된다고 보장하지 않습니다. 전역 및 기본 애플리케이션 부하 분산기의 경우 GFE는 효과적인 최대 백엔드 서비스 제한 시간으로 86,400초(1일)를 적용합니다. 클라이언트 시스템은 TCP 연결을 사용하여 장시간 열어 두는 대신 재시도 로직을 구현해야 합니다.

백엔드 서비스 제한 시간을 구성하려면 다음 방법 중 하나를 사용하세요.

콘솔

부하 분산기의 백엔드 서비스의 제한 시간 필드를 수정합니다.

gcloud

gcloud compute backend-services update 명령어를 사용하여 백엔드 서비스 리소스의 --timeout 파라미터를 수정합니다.

API

전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 경우 전역 backendServices 리소스에 대해 timeoutSec 파라미터를 수정합니다.

리전 외부 애플리케이션 부하 분산기의 경우 regionBackendServices 리소스에 대해 timeoutSec 파라미터를 수정합니다.

WebSocket 연결 제한 시간은 항상 백엔드 서비스 제한 시간과 동일하지 않습니다. WebSocket 연결 제한 시간은 부하 분산기 유형에 따라 다릅니다.

부하 분산기 모드 기본값 WebSocket에 대한 제한 시간 설명
전역 외부 애플리케이션 부하 분산기 백엔드 서비스 제한 시간: 30초

활성 WebSocket 연결은 부하 분산기의 구성된 백엔드 서비스 제한 시간을 사용하지 않습니다. 연결은 24시간(86,400초) 후 자동으로 닫힙니다. 이 24시간 한도는 고정되어 있으며 24시간보다 클 경우 백엔드 서비스 제한 시간을 재정의합니다.

백엔드 서비스 제한 시간 후 유휴 websocket 연결이 닫힙니다.

Google Cloud 는 소프트웨어 업데이트 및 기타 정기 유지보수를 위해 GFE를 주기적으로 다시 시작하므로 24시간(86,400초)을 초과하는 백엔드 서비스 제한 시간 값은 권장되지 않습니다. 백엔드 서비스 제한 시간 값으로 유지보수 활동이 지연되지 않습니다. 백엔드 서비스 제한 시간 값이 길수록 Google Cloud에서 유지보수를 위해 TCP 연결을 종료할 가능성이 높습니다.
기본 애플리케이션 부하 분산기 백엔드 서비스 제한 시간: 30초

유휴 또는 활성 여부에 관계없이 백엔드 서비스 시간 제한 후 WebSocket 연결이 자동으로 종료됩니다.

Google Cloud 는 소프트웨어 업데이트 및 기타 정기 유지보수를 위해 GFE를 주기적으로 다시 시작하므로 24시간(86,400초)을 초과하는 백엔드 서비스 제한 시간 값은 권장되지 않습니다. 백엔드 서비스 제한 시간 값으로 유지보수 활동이 지연되지 않습니다. 백엔드 서비스 제한 시간 값이 길수록 Google Cloud에서 유지보수를 위해 TCP 연결을 종료할 가능성이 높습니다.
리전 외부 애플리케이션 부하 분산기 백엔드 서비스 제한 시간: 30초

활성 WebSocket 연결은 부하 분산기의 백엔드 서비스 제한 시간을 사용하지 않습니다.

백엔드 서비스 제한 시간 후 유휴 websocket 연결이 닫힙니다.

Google Cloud 는 주기적으로 Envoy 소프트웨어 작업을 다시 시작하거나 제공 수를 변경합니다. 백엔드 서비스 제한 시간 값이 길수록 Envoy 태스크가 재시작되거나 TCP 연결을 종료할 가능성이 높습니다.

리전 외부 애플리케이션 부하 분산기는 URL 맵의 구성된 routeActions.timeout 파라미터를 사용하고 백엔드 서비스 제한 시간을 무시합니다. routeActions.timeout이 구성되지 않았으면 백엔드 서비스 제한 시간의 값이 사용됩니다. routeActions.timeout이 제공되면 백엔드 서비스 제한 시간이 무시되고 대신 routeActions.timeout 값이 요청 및 응답 제한 시간으로 사용됩니다.

클라이언트 HTTP 연결 유지 제한 시간

클라이언트 HTTP 연결 유지 제한 시간은 (다운스트림) 클라이언트와 다음 유형의 프록시 중 하나 사이에 TCP 연결이 유휴 상태가 될 수 있는 최대 시간을 나타냅니다.

  • 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 경우: 첫 번째 레이어 Google 프런트엔드
  • 리전 외부 애플리케이션 부하 분산기의 경우: Envoy 프록시

클라이언트 HTTP 연결 유지 제한 시간은 기본 TCP 연결의 TCP 유휴 상태 제한 시간을 나타냅니다. 클라이언트 HTTP 연결 유지 제한 시간은 WebSocket에 적용되지 않습니다.

클라이언트 HTTP 연결 유지 제한 시간의 기본값은 610초입니다. 전역 및 리전 외부 애플리케이션 부하 분산기의 경우 5~1200초 사이의 값을 사용하여 클라이언트 HTTP 연결 유지 제한 시간을 구성할 수 있습니다.

클라이언트 HTTP 연결 유지 제한 시간을 구성하려면 다음 방법 중 하나를 사용하세요.

콘솔

부하 분산기의 프런트엔드 구성에 대한 HTTP 연결 유지 제한 시간 필드를 수정합니다.

gcloud

전역 외부 애플리케이션 부하 분산기의 경우 gcloud compute target-http-proxies update 명령어 또는 gcloud compute target-https-proxies update 명령어를 사용하여 대상 HTTP 프록시 또는 대상 HTTPS 프록시 리소스의 --http-keep-alive-timeout-sec 매개변수를 수정합니다.

리전 외부 애플리케이션 부하 분산기의 경우 리전 대상 HTTP(S) 프록시의 연결 유지 제한 시간 파라미터를 직접 업데이트할 수 없습니다. 리전 대상 프록시의 연결 유지 제한 시간 파라미터를 업데이트하려면 다음을 수행해야 합니다.

  1. 원하는 제한 시간 설정으로 새 대상 프록시를 만듭니다.
  2. 현재 대상 프록시에서 나머지 모든 설정을 복사하여 새 대상 프록시에 적용합니다. 대상 HTTPS 프록시의 경우 여기에 새 대상 프록시에 대한 모든 SSL 인증서 또는 인증서 맵 연결이 포함됩니다.
  3. 새 대상 프록시를 가리키도록 전달 규칙을 업데이트합니다.
  4. 이전 대상 프록시를 삭제합니다.

API

전역 외부 애플리케이션 부하 분산기의 경우 targetHttpProxies 리소스 또는 targetHttpsProxies 리소스에 대해 httpKeepAliveTimeoutSec 파라미터를 수정합니다.

리전 외부 애플리케이션 부하 분산기의 경우 리전 대상 HTTP(S) 프록시의 연결 유지 제한 시간 파라미터를 직접 업데이트할 수 없습니다. 리전 대상 프록시의 연결 유지 제한 시간 파라미터를 업데이트하려면 다음을 수행해야 합니다.

  1. 원하는 제한 시간 설정으로 새 대상 프록시를 만듭니다.
  2. 현재 대상 프록시에서 나머지 모든 설정을 복사하여 새 대상 프록시에 적용합니다. 대상 HTTPS 프록시의 경우 여기에 새 대상 프록시에 대한 모든 SSL 인증서 또는 인증서 맵 연결이 포함됩니다.
  3. 새 대상 프록시를 가리키도록 전달 규칙을 업데이트합니다.
  4. 이전 대상 프록시를 삭제합니다.

부하 분산기의 클라이언트 HTTP 연결 유지 제한 시간은 다운스트림 클라이언트 또는 프록시에서 사용하는 HTTP 연결 유지 (TCP 유휴 상태) 제한 시간보다 커야 합니다. 다운스트림 클라이언트의 HTTP 연결 유지(TCP 유휴 상태) 제한 시간이 부하 분산기의 클라이언트 HTTP 연결 유지 제한 시간보다 길면 경합 상태가 발생할 수 있습니다. 다운스트림 클라이언트의 관점에서 설정된 TCP 연결은 부하 분산기에서 허용하는 것보다 유휴 상태를 더 오랫동안 허용됩니다. 즉, 부하 분산기가 TCP 연결이 종료된 것으로 간주하면 다운스트림 클라이언트는 패킷을 전송할 수 있습니다. 이 경우 부하 분산기는 TCP 재설정(RST) 패킷으로 응답합니다.

클라이언트 HTTP 연결 유지 제한 시간이 만료되면 GFE 또는 Envoy 프록시가 클라이언트로 TCP FIN을 보내어 연결을 정상적으로 종료합니다.

백엔드 HTTP 연결 유지 제한 시간

외부 애플리케이션 부하 분산기는 최소 2개 이상의 TCP 연결을 사용하는 프록시입니다.

  • 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 경우 (다운스트림) 클라이언트와 첫 번째 레이어 GFE 사이에 첫 번째 TCP 연결이 존재합니다. 첫 번째 레이어 GFE가 두 번째 레이어 GFE에 연결하면 두 번째 레이어 GFE에서 백엔드에 대한 두 번째 TCP 연결을 엽니다.
  • 리전 외부 애플리케이션 부하 분산기의 경우 (다운스트림) 클라이언트와 Envoy 프록시 사이에 첫 번째 TCP 연결이 존재합니다. 그러면 Envoy 프록시가 백엔드에 대한 두 번째 TCP 연결을 엽니다.

각 요청 후 부하 분산기의 보조 TCP 연결이 닫히지 않을 수 있습니다. 개방형 상태로 유지하여 여러 HTTP 요청 및 응답을 처리할 수 있습니다. 백엔드 HTTP 연결 유지 제한 시간 제한은 TCP 부하 분산기와 백엔드 간의 TCP 유휴 상태 제한 시간을 정의합니다. 백엔드 HTTP 연결 유지 제한 시간은 WebSocket에 적용되지 않습니다.

백엔드 연결 유지 제한 시간은 10분(600초)으로 고정되며 변경할 수 없습니다. 따라서 부하 분산기가 최소 10분 동안 연결을 유휴 상태로 유지할 수 있습니다. 이 기간이 지나면 부하 분산기가 언제든지 백엔드에 종료 패킷을 보낼 수 있습니다.

부하 분산기의 백엔드 연결 유지 제한 시간은 백엔드에서 실행되는 소프트웨어에서 사용하는 연결 유지 제한 시간보다 짧아야 합니다. 이렇게 하면 백엔드의 운영체제가 TCP 재설정(RST)으로 TCP 연결을 종료할 가능성이 있는 경합 상태가 방지됩니다. 부하 분산기의 백엔드 연결 유지 제한 시간을 구성할 수 없으므로 HTTP 연결 유지 (TCP 유휴 상태) 제한 시간 값이 600초를 초과하도록 백엔드 소프트웨어를 구성해야 합니다.

백엔드 HTTP 연결 유지 제한 시간이 만료되면 GFE 또는 Envoy 프록시가 백엔드 VM으로 TCP FIN을 보내어 연결을 정상적으로 종료합니다.

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

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

QUIC 세션 유휴 제한 시간

QUIC 세션 유휴 제한 시간은 클라이언트와 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 GFE 사이에 QUIC 세션이 유휴 상태일 수 있는 최대 시간을 나타냅니다.

QUIC 세션 유휴 제한 시간 값은 클라이언트 유휴 제한 시간 또는 GFE 유휴 제한 시간(300초)의 최솟값으로 정의됩니다. GFE 유휴 제한 시간은 300초로 고정됩니다. 클라이언트 유휴 제한 시간은 값을 구성할 수 있습니다.

재시도

재시도 로직에 대한 지원은 외부 애플리케이션 부하 분산기의 모드에 따라 달라집니다.

부하 분산기 모드 재시도 로직
전역 외부 애플리케이션 부하 분산기

URL 맵에서 재시도 정책을 사용하여 구성 가능합니다. 재시도 정책을 사용하여 구성할 수 있는 최대 재시도 횟수(numRetries)는 25입니다. 구성 가능한 최대 perTryTimeout은 24시간입니다.

재시도를 사용 중지하려면 numRetries을 1로 명시적으로 설정해야 합니다.

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

HTTP POST 요청은 재시도되지 않습니다.

재시도한 요청은 최종 응답의 로그 항목을 하나만 생성합니다.
기본 애플리케이션 부하 분산기

연결 재시도에 대한 재시도 정책을 변경할 수 없습니다.

HTTP POST 요청은 재시도되지 않습니다.

HTTP GET 요청은 백엔드의 80% 이상이 정상인 경우 항상 재시도됩니다. 그룹에 백엔드 인스턴스가 하나만 있는데 이 백엔드 인스턴스에 연결하지 못할 경우 비정상 백엔드 인스턴스의 비율이 100%이므로 GFE에서 요청을 재시도하지 않습니다.

부하 분산기는 첫 번째 요청이 백엔드 서비스에서 응답 헤더를 받기 전에 실패한 경우 실패한 GET 요청을 재시도합니다.

재시도한 요청은 최종 응답의 로그 항목을 하나만 생성합니다. 자세한 내용은 외부 애플리케이션 부하 분산기 로깅 및 모니터링을 참조하세요.

요청이 실패하면 부하 분산기가 HTTP 502 응답을 생성합니다.
리전 외부 애플리케이션 부하 분산기

URL 맵에서 재시도 정책을 사용하여 구성 가능합니다. 기본 재시도 횟수(numRetries)는 1입니다. 재시도 정책을 사용하여 구성할 수 있는 최대 재시도 횟수는 25회입니다. 구성 가능한 최대 perTryTimeout은 24시간입니다.

재시도 정책이 없으면 HTTP 본문이 없는 실패한 요청(예: GET 요청)은 502, 503, 또는 504 응답이 한 번만 재시도됩니다.

HTTP POST 요청은 재시도되지 않습니다.

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

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

잘못된 요청 및 응답 처리

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

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

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

요청 처리

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

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

응답 처리

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

  • 응답 헤더의 총 크기가 외부 애플리케이션 부하 분산기의 최대 응답 헤더 크기 한도를 초과합니다.
  • HTTP 버전을 알 수 없습니다.

요청과 응답을 모두 처리할 때 부하 분산기는 HTTP/1.1에서 홉별 헤더를 삭제하거나 덮어쓰기한 후 대상에 전달할 수 있습니다.

트래픽 분산

백엔드 인스턴스 그룹 또는 NEG를 백엔드 서비스에 추가할 때 백엔드 로드 및 대상 용량을 측정하는 방법을 정의하는 분산 모드를 지정합니다. 외부 애플리케이션 부하 분산기는 두 가지 분산 모드를 지원합니다.

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

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

백엔드 간에 트래픽이 분산되는 방식은 부하 분산기의 모드에 따라 다릅니다.

전역 외부 애플리케이션 부하 분산기

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

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

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

전역 외부 애플리케이션 부하 분산기의 경우 부하 분산은 2계층입니다. 분산 모드에 따라 각 백엔드 (인스턴스 그룹 또는 NEG)로 전송되는 트래픽의 가중치 또는 비율이 결정됩니다. 그런 다음 부하 분산 정책(LocalityLbPolicy)에 따라 그룹 내 인스턴스 또는 엔드포인트에 트래픽이 분산되는 방식이 결정됩니다. 자세한 내용은 부하 분산 지역 정책(백엔드 서비스 API 문서)을 참조하세요.

기본 애플리케이션 부하 분산기의 경우 가장 선호하는 백엔드(인스턴스 그룹 또는 NEG)를 선택하기 위해 분산 모드가 사용됩니다. 그러면 트래픽은 백엔드 내에서 인스턴스 또는 엔드포인트 간에 라운드 로빈 방식으로 분산됩니다.

요청 분산 방법

GFE 기반 외부 애플리케이션 부하 분산기는 다음 프로세스를 사용하여 수신 요청을 분산합니다.

  1. 클라이언트에서 첫 번째 레이어 GFE까지 에지 라우터는 Google 네트워크 경계에 있는 전달 규칙의 외부 IP 주소를 공지합니다. 각 공지는 레이어 3 및 레이어 4 부하 분산 시스템 (Maglev)에 대한 다음 홉을 나열합니다. Maglev 시스템은 트래픽을 첫 번째 레이어 Google 프런트엔드 (GFE)로 라우팅합니다.
    • 프리미엄 등급을 사용하는 경우 Google은 전 세계 모든 접속 지점에서 부하 분산기의 IP 주소를 공지합니다. 각 부하 분산기 IP 주소는 전역 애니캐스트입니다.
    • 표준 등급을 사용하는 경우 Google은 전달 규칙의 리전과 연결된 접속 지점에서 부하 분산기의 IP 주소를 공지합니다. 부하 분산기에서 리전 외부 IP 주소를 사용합니다. 표준 등급 전달 규칙을 사용하면 부하 분산기의 전달 규칙과 동일한 리전에 있는 인스턴스 그룹 및 영역 NEG 백엔드로 제한됩니다.
  2. 첫 번째 레이어 GFE에서 두 번째 레이어 GFE로 첫 번째 레이어 GFE에서 필요한 경우 TLS를 종료한 후 이 프로세스에 따라 두 번째 레이어 GFE로 트래픽을 라우팅합니다.
    • 첫 번째 레이어 GFE는 URL 맵을 파싱하고 백엔드 서비스 또는 백엔드 버킷을 선택합니다.
    • 인터넷 NEG가 있는 백엔드 서비스의 경우 첫 번째 레이어 GFE가 첫 번째 레이어 GFE와 같은 위치에 있는 두 번째 레이어 외부 전달 게이트웨이를 선택합니다. 전달 게이트웨이가 인터넷 NEG 엔드포인트로 요청을 전송합니다. 그러면 인터넷 NEG의 요청 배포 프로세스가 완료됩니다.
    • 서버리스 NEG, Private Service Connect(PSC) NEG, 단일 리전 백엔드 버킷이 있는 백엔드 서비스의 경우 첫 번째 레이어 GFE는 NEG 또는 버킷의 리전과 일치하는 리전에서 두 번째 레이어 GFE를 선택합니다. 멀티 리전 Cloud Storage 버킷의 경우 첫 번째 레이어 GFE는 버킷의 리전 또는 멀티 리전 버킷과 가능한 한 가까운 리전(네트워크 왕복 시간으로 정의됨)에서 두 번째 레이어 GFE를 선택합니다.
    • 인스턴스 그룹이 있는 백엔드 서비스, GCE_VM_IP_PORT 엔드포인트가 있는 영역 NEG, 하이브리드 NEG의 경우 Google의 용량 관리 시스템은 첫 번째 레이어 GFE에 각 백엔드의 사용 및 구성된 용량을 알립니다. 백엔드에 구성된 용량은 분산 모드, 분산 모드의 대상 용량 및 용량 확장 처리로 정의됩니다.
      • 표준 등급: 첫 번째 레이어 GFE가 백엔드가 포함된 리전에서 두 번째 레이어 GFE를 선택합니다.
      • 프리미엄 등급: 첫 번째 레이어 GFE는 적용 가능한 리전 집합에서 두 번째 레이어 GFE를 선택합니다. 적용 가능한 리전은 백엔드가 구성된 모든 리전이며 용량이 0인 백엔드가 구성된 리전은 제외됩니다. 첫 번째 레이어 GFE는 해당 리전에서 가장 가까운 두 번째 레이어 GFE를 선택합니다(네트워크 왕복 시간으로 정의됨). 백엔드가 두 개 이상의 리전에 구성된 경우 첫 번째 선택 리전이 가득 차면 첫 번째 레이어 GFE가 다른 적용 가능한 리전으로 요청을 스필링할 수 있습니다. 첫 번째 선택 리전의 모든 백엔드가 용량에 도달하면 다른 리전으로 스필오버할 수 있습니다.
  3. 두 번째 레이어 GFE가 백엔드를 선택합니다. 두 번째 레이어 GFE는 리전의 영역에 있습니다. 다음 프로세스를 사용하여 백엔드를 선택합니다.
    • 서버리스 NEG, Private Service Connect NEG, 백엔드 버킷이 있는 백엔드 서비스의 경우 두 번째 레이어 GFE가 요청을 Google의 프로덕션 시스템으로 전달합니다. 그러면 백엔드의 요청 배포 프로세스가 완료됩니다.

    • 인스턴스 그룹이 있는 백엔드 서비스, GCE_VM_IP_PORT 엔드포인트가 있는 영역 NEG, 하이브리드 NEG의 경우 Google의 상태 확인 프로브 시스템은 두 번째 레이어 GFE에 백엔드 인스턴스 또는 엔드포인트의 상태 확인 상태를 알립니다.

      프리미엄 등급만 해당: 두 번째 레이어 GFE의 해당 리전에 정상 백엔드 인스턴스나 엔드포인트가 없는 경우 백엔드가 구성된 다른 적용 가능한 리전의 다른 두 번째 레이어 GFE에 요청을 보낼 수 있습니다. 서로 다른 리전의 두 번째 레이어 GFE 간에 스필오버를 수행하면 가능한 모든 리전 간 조합이 소진되지 않습니다. 특정 리전의 백엔드에서 트래픽을 보내야 하는 경우 상태 확인에 실패하도록 백엔드를 구성하는 대신 백엔드의 용량 확장 처리를 0으로 설정하여 첫 번째 레이어 GFE가 이전 단계에서 해당 리전을 제외하도록 해야 합니다.

    그런 다음 두 번째 레이어 GFE가 다음 단계에 설명된 대로 해당 리전 내의 영역에 있는 백엔드 인스턴스 또는 엔드포인트로 요청을 전달합니다.

  4. 두 번째 레이어 GFE에서 영역을 선택합니다. 기본적으로 두 번째 레이어 GFE는 WATERFALL_BY_REGION 알고리즘을 사용합니다. 여기서 각 두 번째 레이어 GFE는 두 번째 레이어 GFE가 포함된 영역과 동일한 영역에 있는 백엔드 인스턴스 또는 엔드포인트를 선택하는 것을 선호합니다. WATERFALL_BY_REGION은 영역 간 트래픽을 최소화하므로 요청 비율이 낮기 때문에 각 두 번째 레이어 GFE가 두 번째 레이어 GFE 자체와 동일한 영역에 있는 백엔드에만 요청을 보낼 수 있습니다.

    전역 외부 애플리케이션 부하 분산기의 경우에만 serviceLbPolicy를 사용하여 다음 대체 알고리즘 중 하나를 사용하도록 두 번째 레이어 GFE를 구성할 수 있습니다.

    • SPRAY_TO_REGION: 두 번째 레이어 GFE는 두 번째 레이어 GFE와 동일한 영역에서 백엔드 인스턴스 또는 엔드포인트를 선택하는 것을 선호하지 않습니다. 두 번째 레이어 GFE가 리전의 모든 영역에 있는 모든 백엔드 인스턴스 또는 엔드포인트에 트래픽을 분산하려고 시도합니다. 이렇게 하면 영역 간 트래픽 증가하는 대신 부하가 보다 고르게 분산될 수 있습니다.
    • WATERFALL_BY_ZONE: 두 번째 레이어 GFE가 두 번째 레이어 GFE와 동일한 영역에서 백엔드 인스턴스 또는 엔드포인트를 선택하는 것이 좋습니다. 두 번째 레이어 GFE는 현재 영역의 모든 백엔드가 구성된 용량에 도달한 후에만 다른 영역의 백엔드로 요청을 전달합니다.
  5. 두 번째 레이어 GFE가 영역 내에서 인스턴스 또는 엔드포인트를 선택합니다. 기본적으로 두 번째 레이어 GFE가 라운드 로빈 방식으로 요청을 백엔드로 분산합니다. 전역 외부 애플리케이션 부하 분산기의 경우에만 부하 분산 지역 정책(localityLbPolicy)을 사용하여 이를 변경할 수 있습니다. 부하 분산 지역 정책은 이전 단계에서 설명한 선택한 영역 내의 백엔드에만 적용됩니다.

리전 외부 애플리케이션 부하 분산기

리전 외부 애플리케이션 부하 분산기의 경우 트래픽 분산은 부하 분산 모드 및 부하 분산 지역 정책을 기반으로 합니다.

분산 모드에 따라 각 그룹 (인스턴스 그룹 또는 NEG)으로 전송되는 트래픽의 가중치 및 비율이 결정됩니다. 부하 분산 지역 정책(LocalityLbPolicy)에 따라 그룹 내 백엔드의 부하 분산 방식이 결정됩니다.

백엔드 서비스가 트래픽을 수신하면 백엔드의 분산 모드에 따라 백엔드(인스턴스 그룹 또는 NEG)로 트래픽을 전달합니다. 백엔드가 선택되면 부하 분산 지역 정책에 따라 해당 백엔드 그룹의 인스턴스 또는 엔드포인트 간에 트래픽이 분산됩니다.

자세한 내용은 다음을 참조하세요.

세션 어피니티

애플리케이션 부하 분산기의 백엔드 서비스에 구성된 세션 어피니티는 정상 백엔드 인스턴스 또는 엔드포인트의 수가 일정하게 유지되고 이전에 선택한 백엔드 인스턴스 또는 엔드포인트의 용량이 충분한 경우 특정 클라이언트의 요청을 동일한 백엔드로 전송하려고 합니다. 분산 모드의 대상 용량은 백엔드가 언제 용량에 도달하는지를 결정합니다.

다음 표에는 다양한 애플리케이션 부하 분산기에서 지원되는 다양한 세션 어피니티 옵션이 나와 있습니다. 다음 섹션인 세션 어피니티 유형에서는 각 세션 어피니티 유형을 자세히 설명합니다.

표: 지원되는 세션 어피니티 설정
제품 세션 어피니티 옵션
  • 없음(NONE)
  • 클라이언트 IP(CLIENT_IP)
  • 생성된 쿠키(GENERATED_COOKIE)
  • 헤더 필드(HEADER_FIELD)
  • HTTP 쿠키(HTTP_COOKIE)
  • 스테이트풀(Stateful) 쿠키 기반 어피니티(STRONG_COOKIE_AFFINITY)

또한 다음을 참고하세요

  • 부하 분산 지역 정책(localityLbPolicy)의 유효한 기본값은 세션 어피니티 설정에 따라 변경됩니다. 세션 어피니티가 구성되지 않은 경우, 즉 세션 어피니티가 기본값 NONE으로 유지되는 경우 localityLbPolicy의 기본값은 ROUND_ROBIN입니다. 세션 어피니티가 NONE 이외의 값으로 설정된 경우 localityLbPolicy의 기본값은 MAGLEV입니다.
  • 전역 외부 애플리케이션 부하 분산기에서 가중치가 적용된 트래픽 분할을 사용하는 경우 세션 어피니티를 구성하지 마세요. 구성하면 가중치가 적용된 트래픽 분할 구성이 우선 적용됩니다.
기본 애플리케이션 부하 분산기
  • 없음(NONE)
  • 클라이언트 IP(CLIENT_IP)
  • 생성된 쿠키(GENERATED_COOKIE)

세션 어피니티를 구성할 때 다음 사항에 유의하세요.

  • 인증 또는 보안 목적으로 세션 어피니티를 사용하지 않습니다. 스테이트풀(Stateful) 쿠키 기반 세션 어피니티를 제외한 세션 어피니티는 제공 및 정상 백엔드 수가 변경될 때마다 중단될 수 있습니다. 자세한 내용은 세션 어피니티 손실을 참조하세요.

  • --session-affinity 및 --subsetting-policy 플래그의 기본값은 모두 NONE이며 한 번에 하나만 다른 값으로 설정할 수 있습니다.

세션 어피니티 유형

외부 애플리케이션 부하 분산기의 세션 어피니티는 다음 카테고리 중 하나로 분류할 수 있습니다.
  • 해시 기반 세션 어피니티 (NONE, CLIENT_IP)
  • HTTP 헤더 기반 세션 어피니티 (HEADER_FIELD)
  • 쿠키 기반 세션 어피니티 (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

해시 기반 세션 어피니티

해시 기반 세션 어피니티의 경우 부하 분산기는 일관된 해싱 알고리즘을 사용하여 적격한 백엔드를 선택합니다. 세션 어피니티 설정은 해시를 계산하는 데 사용되는 IP 헤더의 필드를 결정합니다.

해시 기반 세션 어피니티는 다음 유형 중 하나일 수 있습니다.

없음

세션 어피니티를 NONE으로 설정한다고 해서 세션 어피니티가 없다는 의미는 아닙니다. 명시적으로 구성된 세션 어피니티 옵션이 없음을 의미합니다.

해싱은 항상 백엔드를 선택하기 위해 실행됩니다. 세션 어피니티 설정이 NONE이면 부하 분산기가 5튜플 해시를 사용하여 백엔드를 선택합니다. 5-튜플 해시는 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 대상 포트로 구성되어 있습니다.

세션 어피니티의 기본값은 NONE입니다.

클라이언트 IP 어피니티

클라이언트 IP 세션 어피니티 (CLIENT_IP)는 패킷의 소스 및 대상 IP 주소에서 생성된 2튜플 해시입니다. 클라이언트 IP 어피니티는 백엔드가 정상이고 용량이 있는 한 동일한 클라이언트 IP 주소의 모든 요청을 동일한 백엔드로 전달합니다.

클라이언트 IP 어피니티를 사용할 때는 다음 사항에 유의하세요.

  • 패킷 대상 IP 주소는 패킷이 부하 분산기로 직접 전송되는 경우에만 부하 분산기 전달 규칙의 IP 주소와 동일합니다.
  • 패킷이 Google Cloud 부하 분산기에 전송되기 전에 중간 NAT 또는 프록시 시스템에서 처리되는 경우 패킷 소스 IP 주소가 원래 클라이언트와 연결된 IP 주소와 일치하지 않을 수 있습니다. 여러 클라이언트가 동일한 유효 소스 IP 주소를 공유하는 경우 일부 백엔드 VM은 다른 VM보다 더 많은 연결 또는 요청을 수신할 수 있습니다.

HTTP 헤더 기반 세션 어피니티

헤더 필드 어피니티 (HEADER_FIELD)를 사용하면 백엔드 서비스의 consistentHash.httpHeaderName 필드에 있는 HTTP 헤더의 값을 기반으로 요청이 백엔드로 라우팅됩니다. 사용 가능한 모든 백엔드에 요청을 분산하려면 각 클라이언트가 서로 다른 HTTP 헤더 값을 사용해야 합니다.

헤더 필드 어피니티는 다음 조건이 충족되는 경우에 지원됩니다.

  • 부하 분산 지역 정책이 RING_HASH 또는 MAGLEV입니다.
  • 백엔드 서비스의 consistentHash가 HTTP 헤더의 이름(httpHeaderName)을 지정합니다.

쿠키 기반 세션 어피니티는 다음 유형 중 하나일 수 있습니다.

생성된 쿠키 기반 어피니티 (GENERATED_COOKIE)를 사용하면 부하 분산기가 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다.

생성된 쿠키의 이름은 부하 분산기 유형에 따라 다릅니다.

제품 쿠키 이름
전역 외부 애플리케이션 부하 분산기 GCLB
기존 애플리케이션 부하 분산기 GCLB
리전 외부 애플리케이션 부하 분산기 GCILB

생성된 쿠키의 경로 속성은 항상 슬래시 (/)이므로 다른 백엔드 서비스도 생성된 쿠키 어피니티를 사용하는 경우 동일한 URL 맵의 모든 백엔드 서비스에 적용됩니다.

affinityCookieTtlSec 백엔드 서비스 파라미터를 사용하여 쿠키의 TTL (수명) 값을 0~1,209,600초 (양 끝값 포함)로 구성할 수 있습니다. affinityCookieTtlSec이 지정되지 않은 경우 기본 TTL 값은 0입니다.

클라이언트가 HTTP 요청의 Cookie 요청 헤더에 생성된 세션 어피니티 쿠키를 포함하면 세션 어피니티 쿠키가 유효한 경우 부하 분산기가 이러한 요청을 동일한 백엔드 인스턴스 또는 엔드포인트로 전달합니다. 쿠키 값을 특정 백엔드 인스턴스 또는 엔드포인트를 참조하는 색인에 매핑하고 생성된 쿠키 세션 어피니티 요구사항이 충족되는지 확인하여 이 작업을 실행합니다.

생성된 쿠키 어피니티를 사용하려면 다음과 같은 균형 조정 모드와 localityLbPolicy 설정을 구성합니다.

  • 백엔드 인스턴스 그룹의 경우 RATE 분산 모드를 사용합니다.
  • 백엔드 서비스의 localityLbPolicy에는 RING_HASH 또는 MAGLEV를 사용합니다. localityLbPolicy를 명시적으로 설정하지 않으면 부하 분산기는 MAGLEV를 암시적 기본값으로 사용합니다.

자세한 내용은 세션 어피니티 손실을 참조하세요.

HTTP 쿠키 기반 어피니티 (HTTP_COOKIE)를 사용하면 부하 분산기가 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다. 쿠키의 이름, 경로, TTL(수명)을 지정합니다.

모든 애플리케이션 부하 분산기는 HTTP 쿠키 기반 어피니티를 지원합니다.

다음 백엔드 서비스 파라미터와 유효한 값을 사용하여 초, 1초 미만의 값(나노초) 또는 초와 1초 미만의 값(나노초) 모두를 사용하여 쿠키의 TTL 값을 구성할 수 있습니다.

  • consistentHash.httpCookie.ttl.seconds는 0과 315576000000 사이의 값(양 끝값 포함)으로 설정할 수 있습니다.
  • consistentHash.httpCookie.ttl.nanos는 0과 999999999 사이의 값(양 끝값 포함)으로 설정할 수 있습니다. 단위가 나노초이므로 999999999는 .999999999초를 의미합니다.

consistentHash.httpCookie.ttl.seconds와 consistentHash.httpCookie.ttl.nanos가 모두 지정되지 않은 경우 affinityCookieTtlSec 백엔드 서비스 파라미터의 값이 대신 사용됩니다. affinityCookieTtlSec이 지정되지 않은 경우 기본 TTL 값은 0입니다.

클라이언트가 HTTP 요청의 Cookie 요청 헤더에 HTTP 세션 어피니티 쿠키를 포함하면 세션 어피니티 쿠키가 유효한 경우 부하 분산기가 이러한 요청을 동일한 백엔드 인스턴스 또는 엔드포인트로 전달합니다. 쿠키 값을 특정 백엔드 인스턴스 또는 엔드포인트를 참조하는 색인에 매핑하고 생성된 쿠키 세션 어피니티 요구사항이 충족되는지 확인하여 이 작업을 실행합니다.

HTTP 쿠키 어피니티를 사용하려면 다음과 같은 균형 조정 모드 및 localityLbPolicy 설정을 구성합니다.

  • 백엔드 인스턴스 그룹의 경우 RATE 분산 모드를 사용합니다.
  • 백엔드 서비스의 localityLbPolicy에는 RING_HASH 또는 MAGLEV를 사용합니다. localityLbPolicy를 명시적으로 설정하지 않으면 부하 분산기는 MAGLEV를 암시적 기본값으로 사용합니다.

자세한 내용은 세션 어피니티 손실을 참조하세요.

스테이트풀(Stateful) 쿠키 기반 세션 어피니티

상태 저장 쿠키 기반 어피니티 (STRONG_COOKIE_AFFINITY)를 사용하면 부하 분산기가 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다. 쿠키의 이름, 경로, TTL (수명)을 지정합니다.

기본 애플리케이션 부하 분산기를 제외한 모든 애플리케이션 부하 분산기는 스테이트풀(Stateful) 쿠키 기반 어피니티를 지원합니다.

초, 1초 미만의 값(나노초) 또는 초와 1초 미만의 값(나노초) 모두를 사용하여 쿠키의 TTL 값을 구성할 수 있습니다. strongSessionAffinityCookie.ttl로 표시되는 기간은 2주(1,209,600초)를 초과하는 값으로 설정할 수 없습니다.

쿠키의 값은 선택된 인스턴스 또는 엔드포인트를 값 자체에 인코딩하여 선택된 백엔드 인스턴스 또는 엔드포인트를 식별합니다. 쿠키가 유효한 한 클라이언트가 후속 HTTP 요청의 Cookie 요청 헤더에 세션 어피니티 쿠키를 포함하면 부하 분산기는 이러한 요청을 선택한 백엔드 인스턴스 또는 엔드포인트로 전달합니다.

다른 세션 어피니티 방법과의 차이점:

  • 스테이트풀(Stateful) 쿠키 기반 어피니티에는 분산 모드 또는 부하 분산 지역 정책(localityLbPolicy)에 관한 특정한 요구사항이 없습니다.

  • 자동 확장이 관리형 인스턴스 그룹에 새 인스턴스를 추가할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.

  • 선택한 인스턴스가 삭제되지 않는 한 자동 확장이 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.

  • 선택한 인스턴스가 삭제되지 않는 한 자동 복구가 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.

자세한 내용은 세션 어피니티 손실을 참조하세요.

쿠키 기반 어피니티 TTL 0의 의미

생성된 쿠키 어피니티, HTTP 쿠키 어피니티, 스테이트풀 쿠키 기반 어피니티와 같은 모든 쿠키 기반 세션 어피니티에는 TTL 속성이 있습니다.

TTL이 0초이면 부하 분산기가 쿠키에 Expires 속성을 할당하지 않습니다. 이 경우 클라이언트는 쿠키를 세션 쿠키로 취급합니다. 세션의 정의는 클라이언트에 따라 다릅니다.

  • 웹브라우저와 같은 일부 클라이언트는 전체 탐색 세션 동안 쿠키를 유지합니다. 즉, 애플리케이션이 닫힐 때까지 여러 요청에 걸쳐 쿠키가 유지됩니다.

  • 세션을 단일 HTTP 요청으로 취급하여 쿠키를 즉시 삭제하는 클라이언트도 있습니다.

세션 어피니티 상실

모든 세션 어피니티 옵션에는 다음이 필요합니다.

  • 선택한 백엔드 인스턴스 또는 엔드포인트는 백엔드로 구성된 상태를 유지해야 합니다. 다음 이벤트 중 하나가 발생하면 세션 어피니티가 중단될 수 있습니다.
    • 선택한 인스턴스를 인스턴스 그룹에서 삭제합니다.
    • 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 선택한 인스턴스가 관리형 인스턴스 그룹에서 삭제됩니다.
    • 선택한 엔드포인트를 NEG에서 삭제합니다.
    • 선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG를 백엔드 서비스에서 삭제합니다.
  • 선택한 백엔드 인스턴스 또는 엔드포인트가 정상 상태로 유지되어야 합니다. 선택한 인스턴스 또는 엔드포인트가 상태 점검에 실패하면 세션 어피니티가 손상될 수 있습니다.
  • 전역 외부 애플리케이션 부하 분산기 및 기본 애플리케이션 부하 분산기의 경우 라우팅 경로가 변경된 후 후속 요청 또는 연결에 다른 첫 번째 레이어 Google 프런트엔드 (GFE)가 사용되면 세션 어피니티가 중단될 수 있습니다. 인터넷의 클라이언트에서 Google로의 라우팅 경로가 요청 또는 연결 간에 변경되면 다른 첫 번째 레이어 GFE가 선택될 수 있습니다.
스테이트풀(Stateful) 쿠키 기반 세션 어피니티를 제외한 모든 세션 어피니티 옵션에는 다음과 같은 추가 요구사항이 있습니다.

  • 선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG가 대상 용량에서 정의된 대로 가득 차서는 안 됩니다. (리전 관리형 인스턴스 그룹의 경우 선택한 인스턴스가 포함된 인스턴스 그룹의 영역 구성요소가 가득 차서는 안 됩니다.) 인스턴스 그룹 또는 NEG가 가득 차고 다른 인스턴스 그룹 또는 NEG는 가득 차지 않은 경우 세션 어피니티가 손상될 수 있습니다. UTILIZATION 분산 모드를 사용할 때는 가득 찬 상태가 예측 불가능한 방식으로 변경될 수 있으므로 RATE 또는 CONNECTION 분산 모드를 사용하여 세션 어피니티가 손상될 수 있는 상황을 최소화해야 합니다.

  • 구성된 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 구성된 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.

    • 새 인스턴스 또는 엔드포인트 추가:

      • 백엔드 서비스의 기존 인스턴스 그룹에 인스턴스를 추가합니다.
      • 관리형 인스턴스 그룹 자동 확장으로 인해 백엔드 서비스의 관리형 인스턴스 그룹에 인스턴스가 추가됩니다.
      • 백엔드 서비스의 기존 NEG에 엔드포인트를 추가합니다.
      • 백엔드 서비스에 비어 있지 않은 백엔드 인스턴스 그룹 또는 NEG를 추가합니다.

    • 선택한 인스턴스 또는 엔드포인트뿐만 아니라 모든 인스턴스 또는 엔드포인트 삭제:

      • 인스턴스 그룹 백엔드에서 인스턴스를 삭제하는 경우
      • 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 관리형 인스턴스 그룹 백엔드에서 인스턴스가 삭제됩니다.
      • NEG 백엔드에서 엔드포인트를 삭제합니다.
      • 백엔드 서비스에서 비어 있지 않은 기존 백엔드 인스턴스 그룹 또는 NEG를 삭제합니다.

  • 정상 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 정상적인 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.

    • 인스턴스 또는 엔드포인트가 상태 점검을 통과하여 비정상 상태에서 정상 상태로 전환됩니다.
    • 인스턴스 또는 엔드포인트가 상태 점검에 실패하여 정상 상태에서 비정상 상태 또는 시간 초과로 전환됩니다.