HTTP(S) 부하 분산 개념

이 문서에서는 HTTP 또는 HTTPS 부하 분산을 구성하기 위해 알아야 하는 개념을 소개합니다.

기초

HTTP(S) 부하 분산기는 다양한 요소로 구성됩니다. 다음 다이어그램은 완전한 HTTP(S) 부하 분산기의 아키텍처를 보여줍니다.

콘텐츠 기반 및 리전 간 부하 분산 다이어그램(확대하려면 클릭)
콘텐츠 기반 및 리전 간 부하 분산 다이어그램(확대하려면 클릭)

다음 섹션에서는 각 구성요소가 어떻게 결합하여 각 유형의 부하 분산기를 구성하는지 설명합니다. 각 구성요소에 대한 자세한 설명은 아래의 구성요소를 참조하세요.

HTTP 부하 분산

완전한 HTTP 부하 분산기는 다음과 같이 구성됩니다.

  1. 전달 규칙이 들어오는 요청을 대상 HTTP 프록시로 보냅니다.
  2. 대상 HTTP 프록시는 각 요청과 URL 맵을 대조해 요청에 맞는 백엔드 서비스를 결정합니다.
  3. 백엔드 서비스는 연결된 백엔드의 제공 용량, 영역, 인스턴스 상태에 따라 각 요청을 적절한 백엔드로 보냅니다. 각 백엔드 인스턴스의 상태는 HTTP 상태 확인, HTTPS 상태 확인 또는 HTTP/2 상태 확인을 사용하여 확인됩니다. 백엔드 서비스가 HTTPS 또는 HTTP/2 상태 확인을 사용하도록 구성된 경우에는 요청이 백엔드 인스턴스로 가는 도중에 암호화됩니다.
  4. 부하 분산기와 인스턴스 간의 세션은 HTTP, HTTPS 또는 HTTP/2 프로토콜을 사용할 수 있습니다. HTTPS 또는 HTTP/2를 사용하는 경우 백엔드 서비스의 각 인스턴스에는 SSL 인증서가 있어야 합니다.

HTTPS 부하 분산

HTTPS 부하 분산기는 위에서 설명한 HTTP 부하 분산기와 기본 구조가 같지만 다음과 같은 차이점이 있습니다.

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

  • 클라이언트는 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 서비스를 지원하는 열린 포트가 여러 개 있습니다. GCP HTTP(S) 부하 분산기의 외부 IP 주소에 대해 보안 또는 포트 검사를 실행하면 추가 포트가 열려있는 것처럼 보입니다.

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

구성요소

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

전달 규칙 및 주소

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

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

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

대상 프록시

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

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

  • Via: 1.1 google(요청 및 응답)
  • X-Forwarded-Proto: [http | https](요청만)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP>(요청만) 쉼표로 구분된 IP 주소 목록은 요청이 통과하는 중개자에 의해 추가됩니다. GCP 내부에서 X-forwarded-For 헤더에 데이터를 추가하는 프록시를 실행하는 경우 소프트웨어에서 해당 프록시의 존재와 수를 고려해야 합니다. 부하 분산기는 <immediate client IP>와 <global forwarding rule external IP> 항목만 제공합니다. 목록의 다른 모든 항목은 확인 없이 전달됩니다. <immediate client IP> 항목은 부하 분산기에 직접 연결된 클라이언트입니다. <global forwarding rule external IP> 항목은 부하 분산기 전달 규칙의 외부 IP 주소입니다. 추가 항목이 존재한다면 목록의 첫 번째 항목이 원래 클라이언트의 주소입니다. <immediate client IP> 항목 앞에 있는 다른 항목은 요청을 부하 분산기에 전달한 다른 프록시를 나타냅니다.
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(요청만)
    Stackdriver Trace용 매개변수입니다.

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

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

URL 맵

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

SSL 인증서

HTTPS 부하 분산을 사용하려면 대상 HTTPS 프록시에 하나 이상의 SSL 인증서를 설치해야 합니다. 최대 15개의 SSL 인증서를 설치할 수 있습니다. 인증서는 대상 HTTPS 프록시가 부하 분산기와 클라이언트 간의 통신을 인증하는 데 사용됩니다. 인증서는 Google 관리형 또는 자체 관리형 SSL 인증서일 수 있습니다.

HTTPS 부하 분산기의 SSL 인증서를 설치하는 방법에 대한 자세한 내용은 SSL 인증서를 참조하세요.

부하 분산기에서 백엔드까지 HTTPS 또는 HTTP/2를 사용하려면 각 VM 인스턴스에 SSL 인증서를 설치해야 합니다. VM 인스턴스에 SSL 인증서를 설치하려면 애플리케이션 문서의 안내를 따르세요. 이러한 인증서는 자체 서명이 가능합니다.

SSL 정책

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

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

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

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

백엔드 서비스

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

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

각 백엔드는 인스턴스 그룹과 추가 제공 용량 메타데이터로 구성됩니다. 백엔드 제공 용량은 CPU 또는 초당 요청 수(RPS)를 기반으로 합니다.

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

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

상태 확인

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

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

백엔드 프로토콜

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

백엔드 VM에 HTTP/2를 사용하려면 HTTP/2 상태 확인을 사용하세요.

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

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

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

Google Cloud Platform 애플리케이션에서 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를 사용하여 HTTP(S) 부하 분산기를 구성하려면 인그레스를 사용한 부하 분산용 HTTP/2를 참조하세요.

gRPC와 HTTP/2를 인그레스와 함께 사용할 수도 있습니다. 자세한 내용은 인그레스를 사용한 부하 분산용 HTTP/2를 참조하세요

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

백엔드 버킷

백엔드 버킷은 들어오는 트래픽을 Google Cloud Storage 버킷으로 전달합니다. 기존 부하 분산기에 버킷을 추가하는 방법의 예시는 Cloud Storage 버킷을 부하 분산기에 추가를 참조하세요.

방화벽 규칙

130.211.0.0/2235.191.0.0/16의 트래픽이 인스턴스에 도달하도록 허용하는 방화벽 규칙을 만들어야 합니다. 이 주소는 부하 분산기가 백엔드 인스턴스에 연결하는 데 사용하는 IP 주소 범위입니다. 이 규칙은 부하 분산기와 상태 검사기에서 전송되는 트래픽을 모두 허용합니다. 이 규칙은 사용자의 전역 전달 규칙이 사용하도록 구성된 포트의 트래픽을 허용해야 하며, 상태 검사기는 같은 포트를 사용하도록 구성해야 합니다. 상태 검사기가 다른 포트를 사용한다면 해당 포트에 대한 다른 방화벽 규칙을 만들어야 합니다.

방화벽 규칙은 네트워크 끝단이 아닌 인스턴스 수준에서 트래픽을 차단하거나 허용합니다. 트래픽이 부하 분산기 자체에 도달하는 것은 막지 못합니다.

특정 시점의 외부 IP 주소를 확인하려면 Google Compute Engine FAQ의 안내를 따르세요.

반환 경로

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

부하 분산 알고리즘

HTTP(S) 부하 분산은 인스턴스 부하를 확인하는 두 가지 방법을 제공합니다. 백엔드 서비스 리소스 내에서 balancingMode 속성은 초당 요청 수(RPS) 또는 CPU 사용률 모드 중에서 하나를 선택합니다. 두 모드 모두 최댓값을 지정할 수 있습니다. HTTP(S) 부하 분산기는 부하를 한도 미만으로 유지하려고 하지만 장애 조치 또는 부하 급증 이벤트 중에 한도를 초과하는 짧은 버스트가 발생할 수 있습니다.

들어오는 요청은 리전에 충분한 용량이 있으면 사용자와 가장 가까운 리전으로 전송됩니다. 리전에서 백엔드로 둘 이상의 영역이 구성된 경우 알고리즘의 기본 동작은 각 그룹의 용량에 따라 각 영역의 인스턴스 그룹에 트래픽을 분산하는 것입니다. 영역 내에서 요청은 라운드 로빈 알고리즘을 사용하여 인스턴스에 고르게 분산됩니다. 세션 어피니티를 구성하여 라운드 로빈 분산을 재정의할 수 있습니다. 단, 분산 모드를 초당 요청 수(RPS)로 설정하면 세션 어피니티가 가장 잘 작동합니다.

부하 분산 알고리즘의 구체적인 예시는 HTTP(S) 부하 분산의 작동 원리를 참조하세요.

세션 어피니티

세션 어피니티는 인스턴스가 정상 상태이고 용량이 있는 한 동일한 클라이언트의 모든 요청을 동일한 가상 머신 인스턴스로 전송합니다.

GCP HTTP(S) 부하 분산은 두 가지 유형의 세션 어피니티를 제공합니다.

WebSocket 프록시 지원

HTTP(S) 부하 분산은 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에서는 재정의가 지정되지 않은 QUIC는 사용하지 않습니다. QUIC 지원 사용 및 중지에 대한 자세한 내용은 대상 프록시를 참조하세요. Google Cloud Platform Console을 사용하여 HTTPS 부하 분산기를 만들 때 QUIC를 사용 설정하거나, Google Cloud Platform Console을 사용해서 부하 분산기 구성을 편집하여 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를 사용하기 전에 앞서 설명한 동작을 작업 부하가 수용할 수 있는지 확인하세요.

인터페이스

HTTP(S) 부하 분산 서비스는 다음 인터페이스를 통해 구성하고 업데이트할 수 있습니다.

  • gcloud 명령줄 도구: Cloud SDK에 포함된 명령줄 도구입니다. HTTP(S) 부하 분산 문서에서는 태스크를 수행하기 위해 이 도구를 자주 사용합니다. 이 도구에 대한 전체 개요는 gcloud 도구 가이드를 참조하세요. 부하 분산 관련 명령어는 gcloud compute 명령어 그룹에서 확인할 수 있습니다.

    또한 --help 플래그를 사용하면 gcloud 명령어에 대한 상세한 도움말을 이용할 수 있습니다.

    gcloud compute http-health-checks create --help
    
  • Google Cloud Platform Console: Google Cloud Platform Console을 통해 부하 분산 작업을 처리할 수 있습니다.

  • REST API: 모든 부하 분산 작업은 Google Cloud Load Balancing API를 사용하여 수행할 수 있습니다. API 참조 문서는 사용 가능한 리소스와 메서드를 설명합니다.

TLS 지원

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

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

시간 제한 및 재시도

HTTP(S) 부하 분산에는 두 가지 유형의 시간 제한이 있습니다.

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

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

    GCP HTTP(S) 부하 분산기를 통해 전송된 WebSocket 트래픽의 경우 백엔드 서비스 시간 제한은 WebSocket 연결이 유휴 상태이든 아니든 열린 상태로 유지될 수 있는 최대 시간으로 해석됩니다. 자세한 내용은 백엔드 서비스 설정을 참조하세요.

  • TCP 세션 시간 제한은 10분(600초)으로 고정된 값입니다. 이 세션 시간 제한은 연결 유지 또는 유휴 시간 제한이라고도 하며, 백엔드 서비스를 수정하는 방법으로 값을 구성할 수 없습니다. 백엔드에서 사용하는 웹 서버 소프트웨어는 백엔드가 연결을 조기에 닫지 않도록 연결 유지 제한시간을 600초보다 길게 설정해야 합니다. 이 시간 제한은 WebSocket에는 적용되지 않습니다.

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

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

HTTP(S) 부하 분산은 응답 시간 제한이 끝나는 경우와 같은 특정 상황에서 실패한 GET 요청을 재시도합니다. 실패한 POST 요청은 다시 시도하지 않습니다. 재시도는 2회로 제한됩니다. 재시도한 요청은 최종 응답의 로그 항목을 하나만 생성합니다. 자세한 내용은 로깅을 참조하세요.

잘못된 요청 및 응답 처리

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

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

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

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

  • 요청 URL과 헤더의 조합이 약 15KB를 초과합니다.
  • 요청 메서드가 본문을 허용하지 않지만 요청에 본문이 존재합니다.
  • 요청에 Upgrade 헤더가 포함되어 있고 WebSocket 연결을 사용 설정하기 위해 Upgrade 헤더가 사용되지 않습니다.
  • HTTP 버전을 알 수 없습니다.

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

  • 응답 헤더의 전체 크기가 약 128KB를 초과합니다.
  • HTTP 버전을 알 수 없습니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...