백엔드 서비스 개요

백엔드 서비스는 Cloud Load Balancing이 트래픽을 분산하는 방법을 정의합니다. 백엔드 서비스 구성에는 백엔드에 연결하는 데 사용되는 프로토콜, 다양한 배포 및 세션 설정, 상태 확인, 제한 시간 등의 다양한 값 집합이 포함됩니다. 이 설정은 부하 분산기의 동작을 세부적으로 제어할 수 있습니다. 빠르게 시작해야 하는 경우 대부분의 설정에는 쉽게 구성할 수 있는 기본값이 있습니다.

다음 Google Cloud Load Balancing 서비스에 대한 백엔드 서비스를 구성할 수 있습니다.

  • 외부 HTTP(S) 부하 분산
  • 내부 HTTP(S) 부하 분산
  • SSL 프록시 부하 분산
  • TCP 프록시 부하 분산
  • 내부 TCP/UDP 부하 분산

Traffic Director도 백엔드 서비스를 사용합니다. 네트워크 부하 분산은 백엔드 서비스를 사용하지 않습니다.

부하 분산기, Envoy 프록시, 프록시리스 gRPC 클라이언트는 백엔드 서비스 리소스의 구성 정보를 사용하여 다음을 수행합니다.

  • 올바른 백엔드(인스턴스 그룹 또는 네트워크 엔드포인트 그룹(NEG))로 트래픽 전달. 백엔드 서비스 대신 백엔드 버킷을 사용하도록 외부 HTTP(S) 부하 분산기를 구성할 수 있습니다. 외부 HTTP(S) 부하 분산기와 백엔드 버킷 사용에 대한 자세한 정보는 백엔드 버킷으로 부하 분산기 설정을 참조하세요.
  • 각 백엔드의 설정인 분산 모드에 따라 트래픽을 분산.
  • 백엔드 상태를 모니터링할 상태 확인 결정.
  • 세션 어피니티 지정.
  • 다음과 같은 기타 서비스가 사용 설정되는지 확인.
    • Cloud CDN(외부 HTTP(S) 부하 분산기만 해당)
    • Google Cloud Armor 보안 정책(외부 HTTP(S) 부하 분산기만 해당)
    • IAP(Identity-Aware Proxy)(외부 HTTP(S) 부하 분산기만 해당)

백엔드 서비스를 만들거나 백엔드 서비스에 백엔드를 추가할 때 이러한 값을 설정합니다.

백엔드 서비스의 범위는 전역 또는 리전입니다.

백엔드 서비스 리소스의 속성에 대한 자세한 내용은 다음 참조를 확인하세요.

사용 중인 제품(부하 분산기 또는 Traffic Director)에 따라 다음과 같은 사항이 결정됩니다.

  • 최대 백엔드 서비스 개수
  • 백엔드 서비스의 범위
  • 각 백엔드 서비스가 사용할 수 있는 백엔드 유형
  • 백엔드 서비스의 부하 분산 스키마
제품 최대 백엔드 서비스 개수 백엔드 서비스 범위 지원되는 백엔드 유형 부하 분산 스키마
외부 HTTP(S) 부하 분산 복수 전역1 각 백엔드 서비스는 다음과 같은 백엔드 조합을 지원합니다.
  • 모든 인스턴스 그룹 백엔드: 관리형, 비관리형 또는 관리형과 비관리형 조합의 인스턴스 그룹 백엔드 하나 이상
  • 모든 영역별 NEG: 하나 이상의 영역별 NEG
  • 모든 서버리스 NEG: 하나 이상의 App Engine, Cloud Run 또는 Cloud Functions 서비스
  • 인터넷 NEG 1개
외부
내부 HTTP(S) 부하 분산 복수 리전 각 백엔드 서비스는 다음과 같은 백엔드 조합을 지원합니다.
  • 모든 인스턴스 그룹 백엔드: 관리형, 비관리형 또는 관리형과 비관리형 조합의 인스턴스 그룹 백엔드 하나 이상, 또는
  • 모든 영역별 NEG: 하나 이상의 영역별 NEG
INTERNAL_MANAGED
SSL 프록시 부하 분산 1 전역1 백엔드 서비스는 다음과 같은 백엔드 조합을 지원합니다.
  • 모든 인스턴스 그룹 백엔드: 관리형, 비관리형 또는 관리형과 비관리형 조합의 인스턴스 그룹 백엔드 하나 이상, 또는
  • 모든 영역별 NEG: 하나 이상의 영역별 NEG, 또는
  • 인터넷 NEG 1개
외부
TCP 프록시 부하 분산 1 전역1 백엔드 서비스는 다음과 같은 백엔드 조합을 지원합니다.
  • 모든 인스턴스 그룹 백엔드: 관리형, 비관리형 또는 관리형과 비관리형 조합의 인스턴스 그룹 백엔드 하나 이상, 또는
  • 모든 영역별 NEG: 하나 이상의 영역별 NEG, 또는
  • 인터넷 NEG 1개
외부
내부 TCP/UDP 부하 분산 1 리전이지만 전역으로 액세스할 수 있도록 구성 가능 백엔드 서비스는 다음과 같은 백엔드 조합을 지원합니다.
  • 모든 인스턴스 그룹 백엔드: 관리형, 비관리형 또는 관리형과 비관리형 조합의 인스턴스 그룹 백엔드 하나 이상
내부
Traffic Director 복수 전역 각 백엔드 서비스는 다음과 같은 백엔드 조합을 지원합니다.
  • 모든 인스턴스 그룹 백엔드: 관리형, 비관리형 또는 관리형과 비관리형 조합의 인스턴스 그룹 백엔드 하나 이상, 또는
  • 모든 영역별 NEG: 하나 이상의 영역별 NEG
INTERNAL_SELF_MANAGED

1 HTTP(S) 부하 분산, SSL 프록시 부하 분산, TCP 프록시 부하 분산에서 사용하는 백엔드 서비스는 스탠더드 또는 프리미엄 네트워크 등급에서 항상 전역으로 지원됩니다. 하지만 표준 등급에서는 다음 제한사항이 적용됩니다.

백엔드

백엔드는 Google Cloud 부하 분산기, Traffic Director가 구성된 Envoy 프록시 또는 프록시리스 gRPC 클라이언트에서 트래픽을 수신하는 엔드포인트 그룹입니다. 다음과 같이 여러 가지 유형의 백엔드가 있습니다.

또한 백엔드 서비스 대신 백엔드 버킷을 사용하여 Cloud Storage 버킷 백엔드를 만들 수 있습니다.

동일한 백엔드 서비스에는 여러 유형의 백엔드를 사용할 수 없습니다. 예를 들어 단일 백엔드 서비스는 인스턴스 그룹과 영역별 NEG의 조합을 참조할 수 없습니다. 그러나 동일한 백엔드 서비스에서는 다양한 인스턴스 그룹 유형의 조합을 사용할 수 있습니다. 예를 들어 단일 백엔드 서비스가 관리형 인스턴스 그룹과 비관리형 인스턴스 그룹의 조합을 참조할 수 있습니다. 어떤 백엔드가 어떤 백엔드 서비스와 호환되는지에 대한 자세한 내용은 이전 섹션의 표를 참조하세요.

백엔드 서비스와 연결된 백엔드 인스턴스 그룹 또는 NEG를 삭제할 수 없습니다. 인스턴스 그룹 또는 NEG를 삭제하기 전에 먼저 이를 참조하는 모든 백엔드 서비스에서 백엔드로 삭제해야 합니다.

백엔드 프로토콜

백엔드 서비스를 만들 때는 백엔드의 통신에 사용되는 프로토콜을 지정해야 합니다. 백엔드 서비스당 하나의 프로토콜만 지정할 수 있으며 대체 프로토콜로 사용할 보조 프로토콜은 지정할 수 없습니다.

사용 가능한 프로토콜은 다음과 같습니다.

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP
  • gRPC(Traffic Director만 해당)

유효한 프로토콜은 부하 분산기 유형 또는 Traffic Director 사용 여부에 따라 다릅니다. 자세한 내용은 부하 분산기 기능Traffic Director 기능을 참조하세요.

백엔드 서비스의 프로토콜을 변경하면 부하 분산기를 통해 백엔드에 몇 분 동안 액세스할 수 없습니다.

부하 분산기와 백엔드 간의 암호화

HTTP(S) 부하 분산, TCP 프록시 부하 분산, SSL 프록시 부하 분산의 경우 Google은 Google Cloud 내에서 Google 프런트엔드(GFE)와 백엔드 간의 트래픽을 자동으로 암호화합니다.

네트워크 수준의 암호화 외에도 보안 프로토콜을 백엔드 서비스 프로토콜로 사용할 수 있습니다. 보안 프로토콜에는 SSL, HTTPS, HTTP/2(TLS 사용)가 포함됩니다. GFE 기반 부하 분산기와 내부 HTTP(S) 부하 분산 및 Traffic Director에 사용할 수 있습니다.

보안 백엔드 서비스 프로토콜을 사용하여 부하 분산기를 백엔드에 연결하는 경우 GFE는 SSL 또는 HTTPS 클라이언트입니다. 마찬가지로 Traffic Director를 사용하여 구성된 클라이언트 측 프록시는 보안 백엔드 서비스 프로토콜을 사용하여 백엔드에 연결할 때, 프록시는 SSL 또는 HTTPS 클라이언트입니다.

다음과 같은 경우 백엔드 인스턴스에 연결하기 위한 보안 프로토콜이 권장됩니다.

  • 부하 분산기(또는 Traffic Director)에서 백엔드 인스턴스로 감사 가능하고 암호화된 연결이 필요한 경우

  • 부하 분산기가 인터넷 NEG를 통해 Google Cloud 외부에 있는 백엔드 인스턴스에 연결하는 경우. 인터넷 NEG 백엔드와의 통신은 공개 인터넷을 전송할 수 있습니다. 부하 분산기가 인터넷 NEG에 연결되면 공개 CA 서명 인증서가 유효성 검사 요구사항을 충족해야 합니다.

부하 분산기와 백엔드 간에 보안 프로토콜을 사용하려면 다음 요구사항에 유의하세요.

  • 부하 분산기의 백엔드 서비스는 SSL(TLS), HTTPS 또는 HTTP/2 프로토콜을 사용해야 합니다.

  • 백엔드 인스턴스 소프트웨어는 백엔드 서비스와 동일한 프로토콜을 사용하여 트래픽을 제공해야 합니다. 예를 들어 백엔드 서비스가 HTTPS를 사용하는 경우 HTTPS를 사용하도록 백엔드 인스턴스를 구성해야 합니다. HTTP/2 프로토콜을 사용하는 경우 백엔드는 TLS를 사용해야 합니다. 구성 안내는 백엔드 인스턴스의 소프트웨어 문서를 참조하세요.

  • 백엔드 인스턴스에 비공개 키와 인증서를 설치해야 합니다. 이러한 인증서는 부하 분산기의 SSL 인증서와 일치하지 않아도 됩니다. 설치 안내는 백엔드 인스턴스의 소프트웨어 문서를 참조하세요.

  • 백엔드 인스턴스에서 실행 중인 소프트웨어는 SSL 또는 HTTPS 서버로 작동해야 합니다. 구성 안내는 백엔드 인스턴스의 소프트웨어 문서를 참조하세요.

인스턴스 그룹 또는 영역별 NEG 백엔드를 사용할 때는 다음 사항에 유의하세요.

  • GFE가 백엔드에 대한 TLS 세션을 시작하면 GFE는 서버 이름 표시(SNI) 확장 프로그램을 사용하지 않습니다.

  • GFE가 Google Cloud 내 백엔드에 연결하는 경우 GFE는 백엔드에 있는 모든 인증서를 수락합니다. GFE는 인증서 유효성 검사를 수행하지 않습니다. 예를 들어 다음 상황에서도 인증서가 유효한 것으로 간주됩니다.

    • 인증서가 자체 서명됩니다.
    • 인증서가 알 수 없는 인증 기관(CA)에 의해 서명됩니다.
    • 인증서가 만료되었거나 아직 유효하지 않습니다.
    • CNsubjectAlternativeName 속성이 Host 헤더 또는 DNS PTR 레코드와 일치하지 않습니다.
Google 암호화에 대한 자세한 내용은 Google Cloud의 전송 중인 데이터 암호화를 참조하세요.

인스턴스 그룹

이 섹션에서는 인스턴스 그룹이 백엔드 서비스와 작동하는 방식을 설명합니다.

백엔드 VM 및 외부 IP 주소

백엔드 서비스의 백엔드 VM에는 외부 IP 주소가 필요하지 않습니다.

  • 외부 HTTP(S) 부하 분산기, SSL 프록시 부하 분산기, TCP 프록시 부하 분산기의 경우: 클라이언트는 부하 분산기의 외부 IP 주소를 사용하여 Google 프런트엔드(GFE)와 통신합니다. GFE는 기본 네트워크 인터페이스의 내부 IP 주소를 사용하여 백엔드 VM 또는 엔드포인트와 통신합니다. GFE는 프록시이므로 백엔드 VM 자체에는 외부 IP 주소가 필요하지 않습니다.

  • 내부 HTTP(S) 부하 분산기, 내부 TCP/UDP 부하 분산기, Traffic Director: 내부 부하 분산기와 Traffic Director의 백엔드 VM에는 외부 IP 주소가 필요하지 않습니다.

이름이 지정된 포트

부하 분산기는 부하 분산기의 전달 규칙에 지정된 하나 이상의 포트 번호의 프런트엔드에서 리슨할 수 있습니다. 백엔드에서 부하 분산기는 동일하거나 다른 포트 번호로 트래픽을 전달할 수 있습니다. 백엔드 인스턴스(Compute Engine 인스턴스)가 이 포트 번호를 리슨합니다. 인스턴스 그룹에서 이 포트 번호를 구성하고 백엔드 서비스 구성에서 참조합니다.

백엔드 포트 번호는 이름/값 쌍이므로 이름이 지정된 포트라고 합니다. 인스턴스 그룹에서 포트의 키 이름과 값을 정의합니다. 그러면 백엔드 서비스 구성에서 이름이 지정된 포트를 참조합니다.

인스턴스 그룹의 이름이 지정된 포트가 백엔드 서비스 구성의 --port-name과 일치하는 경우, 백엔드 서비스는 인스턴스 그룹의 VM과 통신하기 위해 이 포트 번호를 사용합니다.

다음 부하 분산기 유형의 각 백엔드 Compute Engine 인스턴스 그룹에 이름이 지정된 포트가 있어야 합니다.

  • 내부 HTTP(S) 부하 분산
  • HTTP(S) 부하 분산
  • SSL 프록시 부하 분산
  • TCP 프록시 부하 분산

이름이 지정된 포트를 만드는 방법은 다음 안내를 참조하세요.

예를 들어 인스턴스 그룹에서 이름이 지정된 포트를 다음과 같이 설정할 수 있습니다. 여기서 서비스 이름은 my-service-name이고 포트는 8888입니다.

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

그런 다음 백엔드 서비스의 --port-namemy-service-name으로 설정할 수 있습니다.

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

다음에 유의하세요.

  • 각 백엔드 서비스는 단일 포트 이름을 구독합니다. 각 백엔드 인스턴스 그룹에 해당 이름의 이름이 지정된 포트가 하나 이상 있어야 합니다.

  • 각 인스턴스 그룹이 동일한 포트 이름에 대해 다른 포트 번호를 지정하는 경우 백엔드 서비스는 다른 인스턴스 그룹의 VM과 통신할 때 다른 포트 번호를 사용할 수 있습니다.

  • 백엔드 서비스에서 사용하는 확인된 포트 번호는 부하 분산기의 전달 규칙에서 사용하는 포트 번호와 일치하지 않아도 됩니다.

다음과 같은 경우에는 이름이 지정된 포트가 사용되지 않습니다.

  • 영역별 NEG 또는 인터넷 NEG 백엔드의 경우. 이는 NEG가 엔드포인트 자체에서 다른 메커니즘을 사용하여 포트를 정의하기 때문입니다.
  • 서버리스 NEG 백엔드의 경우. 이는 NEG에 엔드포인트가 없기 때문입니다.
  • 내부 TCP/UDP 부하 분산기의 경우. 내부 TCP/UDP 부하 분산기는 프록시가 아닌 패스스루 부하 분산기이고 백엔드 서비스는 이름이 지정된 포트를 구독하지 않기 때문입니다.

이름이 지정된 포트에 대한 자세한 내용은 SDK 문서의 gcloud compute instance-groups managed set-named-portsgcloud compute instance-groups unmanaged set-named-ports를 참조하세요.

인스턴스 그룹에 대한 제한 및 지침

부하 분산기의 인스턴스 그룹을 만들 때 다음과 같은 제한사항 및 안내 사항에 유의하세요.

  • VM을 두 개 이상의 부하 분산 인스턴스 그룹에 넣지 않습니다. VM이 2개 이상의 비관리형 인스턴스 그룹의 구성원이거나 하나의 관리형 인스턴스 그룹과 하나 이상의 비관리형 인스턴스 그룹의 구성원인 경우, Google Cloud에는 해당 인스턴스 그룹 중 하나만 특정 백엔드 서비스의 백엔드로 사용할 수 있는 제약이 있습니다.

    VM이 여러 부하 분산기에 참여해야 하는 경우 각 백엔드 서비스의 백엔드와 동일한 인스턴스 그룹을 사용해야 합니다. 트래픽을 다른 포트로 분산하려면 하나의 인스턴스 그룹에 필요한 이름이 지정된 포트를 만들고 각 백엔드 서비스가 고유한 이름이 지정된 포트를 구독하도록 합니다.

  • 백엔드 서비스 두 개 이상의 백엔드로 동일한 인스턴스 그룹을 사용할 수 있습니다. 이 경우 백엔드가 호환되는 분산 모드를 사용해야 합니다. 호환은 분산 모드가 동일하거나 CONNECTIONRATE의 조합이어야 함을 의미합니다. 호환되지 않는 조합은 다음과 같습니다.

    • CONNECTION(UTILIZATION 포함)
    • RATE(UTILIZATION 포함)

    다음 예를 참조하세요.

    • 외부 HTTP(S) 부하 분산기의 경우 external-https-backend-service, 내부 TCP/UDP 부하 분산기의 경우 internal-tcp-backend-service 등 백엔드 서비스 두 개가 있습니다.
    • internal-tcp-backend-service에서 instance-group-a라고 하는 인스턴스 그룹을 사용하고 있습니다.
    • 내부 TCP/UDP 부하 분산기는 CONNECTION 분산 모드만 지원하므로 internal-tcp-backend-service에서는 CONNECTION 분산 모드를 적용해야 합니다.
    • external-https-backend-service에서 RATE 분산 모드를 적용하는 경우 external-https-backend-service에서 instance-group-a를 사용할 수도 있습니다.
    • UTILIZATION 분산 모드를 사용하면 external-https-backend-service에서 instance-group-a도 사용할 수 없습니다.
  • 여러 백엔드 서비스의 백엔드 역할을 하는 인스턴스 그룹 하나의 분산 모드를 변경하려면 다음 안내를 따르세요.

    • 하나 이외의 모든 백엔드 서비스에서 인스턴스 그룹을 삭제합니다.
    • 남은 하나의 백엔드 서비스에서 백엔드의 분산 모드를 변경합니다.
    • 새 분산 모드를 지원하는 경우 인스턴스 그룹을 나머지 백엔드 서비스에 백엔드로 다시 추가합니다.
  • 인스턴스 그룹이 여러 백엔드 서비스와 연결된 경우 각 백엔드 서비스는 인스턴스 그룹의 동일한 이름이 지정된 포트 또는 다른 이름이 지정된 포트를 참조할 수 있습니다.

  • 둘 이상의 백엔드 서비스에 자동 확장의 관리형 인스턴스 그룹을 추가하지 않는 것이 좋습니다. 추가하면 그룹의 인스턴스가 예측할 수 없거나 불필요하게 확장될 수 있습니다. 특히 HTTP 부하 분산 사용률 자동 확장 측정 항목을 사용하는 경우에는 더욱 그렇습니다.

    • 권장되지는 않지만 이 시나리오는 자동 확장 측정항목이 부하 분산기의 제공 용량과 관련이 없는 CPU 사용률 또는 Cloud Monitoring 측정항목인 경우에는 사용될 수 있습니다. 이러한 자동 확장 측정항목 중 하나를 사용하면 불규칙한 확장을 방지할 수 있습니다.

영역별 네트워크 엔드포인트 그룹

백엔드로 영역별 네트워크 엔드포인트 그룹(NEG)을 사용하는 백엔드 서비스는 VM 내에서 실행되는 애플리케이션 또는 컨테이너 간에 트래픽을 분산합니다.

영역별 네트워크 엔드포인트는 다음 두 가지 방법 중 하나로 지정된 IP 주소와 포트의 조합입니다.

  • 10.0.1.1:80과 같은 IP address:port 쌍을 지정합니다.
  • 네트워크 엔드포인트 IP 주소만 지정합니다. NEG의 기본 포트는 자동으로 IP address:port 쌍의 포트로 사용됩니다.

네트워크 엔드포인트는 특정 VM을 참조하는 대신 IP 주소 및 포트별로 서비스를 나타냅니다. 네트워크 엔드포인트 그룹은 네트워크 엔드포인트의 논리적 그룹입니다.

자세한 내용은 부하 분산의 네트워크 엔드포인트 그룹 개요를 참조하세요.

인터넷 네트워크 엔드포인트 그룹

인터넷 NEG는 온프레미스 인프라 또는 타사에서 제공하는 인프라에서 호스팅되는 전역 리소스입니다.

인터넷 NEG는 IP 주소 또는 호스트 이름과 선택적 포트의 조합입니다.

  • 공개적으로 확인할 수 있는 정규화된 도메인 이름 및 선택적 포트로, 예를 들어 backend.example.com:443입니다. (기본 포트는 HTTP의 경우 80 HTTPS의 경우 443)
  • 공개적으로 액세스할 수 있는 IP 주소 및 선택적 포트로, 예를 들어 203.0.113.8:80 또는 203.0.113.8:443입니다.(기본 포트는 HTTP의 경우 80 HTTPS의 경우 443)

백엔드로 인터넷 네트워크 엔드포인트 그룹을 사용하는 외부 HTTP(S) 부하 분산기의 백엔드 서비스는 Google Cloud 외부의 목적지에 트래픽을 분산합니다.

자세한 내용은 인터넷 네트워크 엔드포인트 그룹 개요를 참조하세요.

서버리스 네트워크 엔드포인트 그룹

네트워크 엔드포인트 그룹(NEG)은 부하 분산기의 백엔드 엔드포인트 그룹을 지정합니다. 서버리스 NEGCloud Run, App Engine 또는 Cloud Functions 서비스를 가리키는 백엔드입니다.

서버리스 NEG는 다음을 나타낼 수 있습니다.

  • Cloud Run 서비스나 동일한 URL 패턴을 공유하는 서비스 그룹
  • Cloud Functions 함수나 동일한 URL 패턴을 공유하는 함수 그룹
  • App Engine 앱(스탠더드 또는 플렉스), 앱 내의 특정 서비스 또는 특정 버전의 앱

자세한 내용은 서버리스 네트워크 엔드포인트 그룹 개요를 참조하세요.

트래픽 분산

백엔드 서비스 리소스의 다음 필드 값에 따라 백엔드 동작의 몇 가지 측면이 결정됩니다.

  • 분산 모드는 부하 분산기가 새 요청 또는 연결의 백엔드 준비 상태를 측정하는 방법을 정의합니다.
  • 대상 용량은 대상 최대 연결 수, 대상 최대 속도 또는 대상 최대 CPU 사용률을 정의합니다.
  • 용량 확장기는 대상 용량을 수정하지 않고 전체적인 사용 가능 용량을 조정하는 데 사용됩니다.

분산 모드

분산 모드는 부하 분산기의 백엔드가 추가 트래픽을 처리할 수 있는지 아니면 완전히 로드되었는지를 결정합니다. Google Cloud에는 세 가지 분산 모드가 있습니다.

  • CONNECTION
  • RATE
  • UTILIZATION

분산 모드 옵션은 백엔드 서비스의 부하 분산 스키마, 백엔드 서비스의 프로토콜, 백엔드 서비스에 연결된 백엔드 유형에 따라 다릅니다.

백엔드 서비스에 백엔드를 추가할 때 분산 모드를 설정합니다. 참고로 서버리스 NEG에 대한 분산 모드는 설정할 수 없습니다.

분산 모드 지원되는 부하 분산 스키마 지원되는 백엔드 서비스 프로토콜 지원되는 백엔드 유형 적용 가능한 제품
CONNECTION EXTERNAL
INTERNAL
SSL, TCP, UDP
프로토콜 옵션은 부하 분산기 유형에 따라 제한됩니다. 예를 들어 내부 TCP/UDP 부하 분산은 TCP 또는 UDP 프로토콜만 사용합니다.
인스턴스 그룹 또는 영역별 NEG(지원되는 경우)
예를 들어 내부 TCP/UDP 부하 분산은 영역별 NEG를 지원하지 않습니다.
  • SSL 프록시 부하 분산
  • TCP 프록시 부하 분산
  • 내부 TCP/UDP 부하 분산
RATE EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
HTTP, HTTPS, HTTP2, gRPC 인스턴스 그룹 또는 영역별 NEG
  • 외부 HTTP(S) 부하 분산
  • 내부 HTTP(S) 부하 분산
  • Traffic Director (INTERNAL_SELF_MANAGED; HTTP, gRPC 프로토콜만 해당)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
모든 프로토콜 인스턴스 그룹만 해당. 영역별 NEG는 사용률 모드를 지원하지 않습니다.
  • 외부 HTTP(S) 부하 분산
  • 내부 HTTP(S) 부하 분산
  • SSL 프록시 부하 분산
  • TCP 프록시 부하 분산
  • Traffic Director (INTERNAL_SELF_MANAGED; HTTP, gRPC 프로토콜만 해당)

백엔드 서비스와 연결된 모든 VM의 평균 사용률이 10% 미만인 경우 Google Cloud에서 특정 영역을 우선 선택할 수 있습니다. 이는 관리형 리전별 인스턴스 그룹, 다른 영역의 관리형 영역별 인스턴스 그룹, 비관리형 영역별 인스턴스 그룹을 사용하는 경우에 발생할 수 있습니다. 이러한 영역별 불균형은 부하 분산기에 더 많은 트래픽이 전송되면 자동으로 해결됩니다.

자세한 내용은 gcloud beta compute backend-services add-backend를 참조하세요.

부하 분산기의 분산 모드 변경

일부 부하 분산기의 경우 백엔드 서비스에 가능한 분산 모드가 하나뿐이므로 분산 모드를 변경할 수 없습니다.

  • 내부 TCP/UDP 부하 분산기의 백엔드 서비스는 CONNECTION 분산 모드만 사용할 수 있습니다.
  • 모든 백엔드가 NEG인 외부 HTTP(S) 부하 분산기의 백엔드 서비스는 RATE 분산 모드만 사용할 수 있습니다.
  • 모든 백엔드가 NEG인 내부 HTTP(S) 부하 분산기의 백엔드 서비스는 RATE 분산 모드만 사용할 수 있습니다.
  • 모든 백엔드가 NEG인 SSL 프록시 부하 분산기의 백엔드 서비스는 CONNECTION 분산 모드만 사용할 수 있습니다.
  • 모든 백엔드가 NEG인 TCP 프록시 부하 분산기의 백엔드 서비스는 CONNECTION 분산 모드만 사용할 수 있습니다.

일부 부하 분산기의 경우 백엔드 서비스에 두 가지 이상의 모드를 사용할 수 있으므로 분산 모드를 변경할 수 있습니다.

  • 모든 백엔드가 인스턴스 그룹인 외부 HTTP(S) 부하 분산기의 백엔드 서비스는 RATE 또는 UTILIZATION 분산 모드를 사용할 수 있습니다.
  • 모든 백엔드가 인스턴스 그룹인 내부 HTTP(S) 부하 분산기의 백엔드 서비스는 RATE 또는 UTILIZATION 분산 모드를 사용할 수 있습니다.
  • 모든 백엔드가 인스턴스 그룹인 SSL 프록시 부하 분산기의 백엔드 서비스는 CONNECTION 또는 UTILIZATION 분산 모드를 사용할 수 있습니다.
  • 모든 백엔드가 인스턴스 그룹인 TCP 프록시 부하 분산기의 백엔드 서비스는 CONNECTION 또는 UTILIZATION 분산 모드를 사용할 수 있습니다.

대상 용량

각 분산 모드에는 대상 최대 연결 수, 대상 최대 속도 또는 대상 최대 CPU 사용률을 정의하는 해당 대상 용량이 있습니다. 모든 분산 모드에서 대상 용량은 회선 차단기가 아닙니다. 모든 백엔드 VM 또는 엔드포인트가 최댓값에 이르는 등의 특정 조건에서 부하 분산기는 최댓값을 초과합니다.

  • CONNECTION 분산 모드에서 대상 용량은 동시 연결이 가능한 대상 최대 수를 정의합니다. 다음 설정 중 하나를 사용할 수 있습니다.

    • max-connections-per-instance(VM당)
    • max-connections-per-endpoint(영역별 NEG의 엔드포인트당)
    • max-connections(전체 그룹의 영역별 NEG 및 영역별 비관리형 인스턴스 그룹당)

    max-connections-per-instance 또는 max-connections-per-endpoint를 지정하면 Google Cloud는 다음과 같이 유효한 VM당 또는 엔드포인트당 대상을 계산합니다.

    • (VM당 최대 연결 수 * 총 VM 수) / 정상 VM 수
    • (엔드포인트당 최대 연결 수 * 총 엔드포인트 수) / 정상적인 엔드포인트 수

    max-connections를 지정하면 Google Cloud는 다음과 같은 방식으로 유효한 VM당 또는 엔드포인트당 대상을 계산합니다.

    • 최대 연결 수 / 정상 VM 수
    • 최대 연결 수 / 정상적인 엔드포인트 수
  • RATE 분산 모드의 경우 대상 용량은 HTTP 요청의 대상 최대 속도를 정의합니다. 다음 설정 중 하나를 사용할 수 있습니다.

    • max-rate-per-instance(각 VM용)
    • max-rate-per-endpoint(영역별 NEG의 각 엔드포인트용)
    • max-rate(전체 그룹의 영역별 NEG 및 영역별 비관리형 인스턴스 그룹용)

    max-rate-per-instance 또는 max-rate-per-endpoint를 지정하면 Google Cloud는 다음과 같이 유효한 VM당 또는 엔드포인트당 대상 속도를 계산합니다.

    • VM당 최대 속도 * 총 VM 수 / 정상 VM 수
    • 엔드포인트당 최대 속도 * 총 엔드포인트 수 / 정상 엔드포인트 수

    max-rate를 지정하면 Google Cloud는 다음과 같은 방식으로 유효한 VM당 또는 엔드포인트당 대상 속도를 계산합니다.

    • 최대 속도 / 정상 VM 수
    • 최대 속도 / 정상 엔드포인트 수
  • UTILIZATION 분산 모드의 경우 필수 대상 용량이 없습니다. 다음 표에 요약된 대로 백엔드 유형에 따라 다양한 옵션이 제공됩니다.

이 표에서는 특정 부하 분산기와 백엔드 유형에 가능한 모든 분산 모드를 설명합니다. 또한 분산 모드와 함께 지정해야 하는 사용 가능한 용량 또는 필수 용량 설정도 나타나 있습니다.

부하 분산기 백엔드 유형 분산 모드 대상 용량
내부 TCP/UDP 부하 분산 인스턴스 그룹 CONNECTION 최대 연결 수를 지정할 수 없습니다.
SSL 프록시 부하 분산, TCP 프록시 부하 분산 인스턴스 그룹 CONNECTION 다음 중 하나를 반드시 지정해야 합니다.
1. 영역별 인스턴스 그룹당 최대 연결 수
2. 인스턴스당 최대 연결 수
(영역별 또는 리전별 인스턴스 그룹)
UTILIZATION 다음 중 하나를 선택적으로 지정할 수 있습니다.
1. 최대 사용률
2. 영역별 인스턴스 그룹당 최대 연결 수
3. 인스턴스당 최대 연결 수
(영역별 또는 리전별 인스턴스 그룹)
4. 1번과 2번을 함께 지정
5. 1번과 3번을 함께 지정
영역별 NEG CONNECTION 다음 중 하나를 반드시 지정해야 합니다.
1. 영역별 NEG당 최대 연결 수
2. 엔드포인트당 최대 연결 수
HTTP(S) 부하 분산, 내부 HTTP(S) 부하 분산, Traffic Director 인스턴스 그룹 RATE 다음 중 하나를 반드시 지정해야 합니다.
1. 영역별 인스턴스 그룹당 최대 속도
2. 인스턴스당 최대 속도
(영역별 또는 리전별 인스턴스 그룹)
UTILIZATION 다음 중 하나를 선택적으로 지정할 수 있습니다.
1. 최대 사용률
2. 영역별 인스턴스 그룹당 최대 속도
3. 인스턴스당 최대 속도
(영역별 또는 리전별 인스턴스 그룹)
4. 1번과 2번을 함께 지정
5. 1번과 3번을 함께 지정
영역별 NEG RATE 다음 중 하나를 반드시 지정해야 합니다.
1. 영역별 NEG당 최대 속도
2. 엔드포인트당 최대 속도

용량 확장 처리

원하는 경우 용량 확장 처리를 조정하면 대상 용량을 유지하면서 대상 용량 확장(최대 사용률, 최대 속도 또는 최대 연결 수)을 축소할 수 있습니다. 용량 확장 처리는 대상 용량을 지원하는 모든 부하 분산기에서 지원됩니다. 유일한 예외는 내부 TCP/UDP 부하 분산기입니다.

기본적으로 용량 확장 처리는 1.0(100%)입니다. 예를 들어 백엔드 인스턴스의 현재 사용량 비율이 80%이고 최대 사용률이 80%로 설정된 경우 백엔드 서비스가 이 인스턴스에 대한 요청 전송을 중지합니다.

capacity-scaler: 1 * 0.8

용량 확장 처리를 0.0으로 설정하거나 0.1(10%)에서 1.0(100%)까지로 설정할 수 있습니다. 배율이 0(0.0)이면 모든 새 연결이 수행되지 않습니다. 백엔드 서비스에 연결된 백엔드가 한 개뿐이면 0.0 설정을 구성할 수 없습니다.

두 백엔드 서비스가 인스턴스 그룹 백엔드를 공유할 때 용량 확장 처리 사용

동일한 인스턴스 그룹 백엔드를 사용하는 2개의 백엔드 서비스가 있는 경우 두 백엔드 서비스 간에 인스턴스 그룹의 용량을 할당해야 합니다.

예를 들어 2개의 백엔드 서비스 모두에서 용량 확장 처리를 0.5로 설정하면 각 백엔드 서비스는 인스턴스 그룹 용량의 40%를 할당받습니다.

capacity-scaler: 0.5 * 0.8

각 백엔드 서비스가 인스턴스 그룹 용량의 40%를 사용한 경우 요청이 더 이상 이 인스턴스 그룹으로 전송되지 않습니다.

Traffic Director 및 트래픽 분산

Traffic Director도 백엔드 서비스 리소스를 사용합니다. 특히 Traffic Director는 부하 분산 스키마가 INTERNAL_SELF_MANAGED인 백엔드 서비스를 사용합니다. 내부 자체 관리형 백엔드 서비스의 경우 트래픽 분산은 부하 분산 모드부하 분산 정책의 조합을 기반으로 합니다. 백엔드 서비스는 백엔드의 분산 모드에 따라 백엔드로 트래픽을 전달합니다. 그런 다음 Traffic Director가 부하 분산 정책에 따라 트래픽을 분산합니다.

내부 자체 관리형 백엔드 서비스는 다음 분산 모드를 지원합니다.

  • UTILIZATION - 모든 백엔드가 인스턴스 그룹인 경우
  • RATE - 모든 백엔드가 인스턴스 그룹 또는 영역별 NEG인 경우

RATE 분산 모드를 선택하면 최대 속도, 인스턴스당 최대 속도 또는 엔드포인트당 최대 속도를 지정해야 합니다.

Traffic Director에 대한 자세한 내용은 Traffic Director 개념을 참조하세요.

세션 어피니티

세션 어피니티가 없으면 부하 분산기는 5-튜플 해시를 기반으로 다음과 같이 새 요청을 배포합니다.

  • 클라이언트 IP 주소
  • 클라이언트 소스 포트
  • 부하 분산기의 전달 규칙 IP 주소
  • 부하 분산기의 대상 포트
  • Layer 3 프로토콜(백엔드 서비스를 사용하는 모든 부하 분산기의 TCP 프로토콜)

백엔드 인스턴스 그룹 또는 영역별 NEG의 분산 모드에 따라 백엔드가 언제 용량에 도달하는지를 정의합니다. 일부 애플리케이션에서는 특정 사용자의 여러 요청이 동일한 백엔드 또는 엔드포인트로 전달되어야 합니다. 이러한 애플리케이션에는 광고 게재, 게임 또는 내부 캐싱이 많이 발생하는 서비스에서 사용하는 스테이트풀(Stateful) 서버가 포함됩니다.

세션 어피니티는 SSL, HTTP(S), HTTP/2 프로토콜을 포함한 TCP 트래픽에 사용할 수 있습니다. 백엔드 인스턴스 또는 엔드포인트가 정상 상태이고 분산 모드에 기반한 용량에 도달하지 않으면 후속 요청은 동일한 백엔드 VM 또는 엔드포인트로 전달됩니다. 세션 어피니티를 구성할 때 다음 사항에 유의하세요.

  • UDP 트래픽에는 세션이 지원되지 않으므로 이 유형의 트래픽에는 세션 어피니티가 적합하지 않습니다.

  • 프록시리스 gRPC 서비스를 구성하면 Traffic Director는 세션 어피니티를 지원하지 않습니다.

  • 인증 또는 보안 목적으로 세션 어피니티를 사용하지 않습니다. 세션 어피니티는 백엔드가 용량에 도달하거나 이를 초과한 경우 또는 비정상 상태가 되면 중단되도록 설계되었습니다.

  • Google Cloud 부하 분산기는 최선의 방식으로 세션 어피니티를 제공합니다. 백엔드 상태 확인의 상태 변경 또는 분산 모드에서 측정되는 백엔드의 가득 찬 상태에 대한 변경과 같은 요인으로 인해 세션 어피니티가 손상될 수 있습니다. None 이외의 세션 어피니티는 UTILIZATION 분산 모드와 함께 사용하지 않는 것이 좋습니다. 인스턴스 사용률의 변경으로 인해 부하 분산 서비스가 새 요청이나 연결을 가득 차지 않은 백엔드 VM으로 전송할 수 있기 때문입니다. 이 경우 세션 어피니티가 손상됩니다. 대신 RATE 또는 CONNECTION 분산 모드를 사용하여 세션 어피니티가 손상될 가능성을 줄이세요.

다음 표는 세션 어피니티 옵션을 보여줍니다.

제품 세션 어피니티 옵션
내부 TCP/UDP • 없음
• 클라이언트 IP
• 클라이언트 IP 및 프로토콜
• 클라이언트 IP, 프로토콜, 포트
TCP 프록시
SSL 프록시
• 없음
• 클라이언트 IP
외부 HTTP(S) • 없음
• 클라이언트 IP
• 생성된 쿠키
내부 HTTP(S) • 없음
• 클라이언트 IP
• 생성된 쿠키
• 헤더 필드
• HTTP 쿠키
네트워크 네트워크 부하 분산은 백엔드 서비스를 사용하지 않습니다. 대신 대상 풀을 통해 네트워크 부하 분산기의 세션 어피니티를 설정합니다. 대상 풀sessionAffinity 매개변수를 참조하세요.
Traffic Director • 없음
• 클라이언트 IP
• 생성된 쿠키
• 헤더 필드
• HTTP 쿠키

다음 섹션에서는 다양한 세션 어피니티 유형을 설명합니다.

클라이언트 IP 어피니티

클라이언트 IP 어피니티는 동일한 클라이언트 IP 주소의 요청을 동일한 백엔드 인스턴스로 전달합니다. 클라이언트 IP 어피니티는 백엔드 서비스를 사용하는 모든 Google Cloud 부하 분산기에 대한 옵션입니다.

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

  • 클라이언트 IP 어피니티는 클라이언트의 IP 주소와 클라이언트가 연결하는 부하 분산기 전달 규칙의 IP 주소로 구성된 2튜플 해시입니다.

  • 부하 분산기에 표시되는 클라이언트 IP 주소는 NAT 뒤에 있거나 프록시를 통해 요청하는 경우 발신 클라이언트가 아닐 수 있습니다. NAT 또는 프록시를 통한 요청은 NAT 라우터 또는 프록시의 IP 주소를 클라이언트 IP 주소로 사용합니다. 이로 인해 수신 트래픽이 불필요하게 동일한 백엔드 인스턴스에 집중될 수 있습니다.

  • 클라이언트가 기존 네트워크에서 다른 네트워크로 이동하면 IP 주소가 변경되어 어피니티가 손상될 수 있습니다.

생성된 쿠키 어피니티가 설정되면 부하 분산기가 첫 번째 요청에서 쿠키를 생성합니다. 부하 분산기는 동일한 쿠키를 사용하는 각 후속 요청에서 같은 백엔드 VM 또는 엔드포인트로 요청을 전달합니다.

  • 외부 HTTP(S) 부하 분산기의 경우 쿠키 이름은 GCLB입니다.
  • 내부 HTTP 부하 분산기 및 Traffic Director의 경우 쿠키 이름은 GCILB입니다.

쿠키 기반 어피니티는 클라이언트 IP 기반 어피니티와 비교하여 부하 분산기에 대한 클라이언트를 더 정확하게 식별할 수 있습니다. 예를 들면 다음과 같습니다.

  1. 쿠키 기반 어피니티를 통해 부하 분산기는 동일한 소스 IP 주소를 공유하는 두 개 이상의 클라이언트 시스템을 고유하게 식별할 수 있습니다. 클라이언트 IP 기반 어피니티를 사용하는 부하 분산기는 동일한 소스 IP 주소의 모든 연결을 동일한 클라이언트 시스템의 연결처럼 처리합니다.

  2. 클라이언트가 IP 주소를 변경하는 경우 쿠키 기반 어피니티가 연결을 새 연결로 취급하는 대신 부하 분산기가 클라이언트의 후속 연결을 인식할 수 있도록 합니다. 클라이언트가 IP 주소를 변경하는 경우의 예시는 휴대기기가 한 네트워크에서 다른 네트워크로 이동하는 경우를 들 수 있습니다.

부하 분산기가 생성된 쿠키 기반 어피니티에 대한 쿠키를 생성하면 쿠키의 path 속성을 /로 설정합니다. URL 맵의 경로 일치자에 호스트 이름에 대한 여러 백엔드 서비스가 있는 경우 모든 백엔드 서비스는 동일한 세션 쿠키를 공유합니다.

부하 분산기에 의해 생성된 HTTP 쿠키의 수명은 구성이 가능합니다. 쿠키를 0(기본값)인 세션 쿠키로만 설정하거나 또는 쿠키의 수명을 1~86400초(24시간 포함) 사이의 값으로 설정할 수 있습니다.

헤더 필드 어피니티

내부 HTTP(S) 부하 분산기에서 다음 두 가지 사항을 모두 충족하는 경우 헤더 필드 어피니티를 사용할 수 있습니다.

  • 부하 분산 지역 정책은 RING_HASH 또는 MAGLEV입니다.
  • 백엔드 서비스의 일관성 있는 해시는 HTTP 헤더의 이름을 지정합니다.

헤더 필드 어피니티는 --custom-request-header 플래그에 지정된 HTTP 헤더의 값을 기반으로 영역별 NEG의 백엔드 VM 또는 엔드포인트로 요청을 라우팅합니다.

헤더 필드 어피니티가 사용되는 내부 HTTP(S) 부하 분산에 대한 자세한 내용은 내부 HTTP(S) 부하 분산 개요를 참조하세요.

내부 HTTP(S) 부하 분산기에서 다음 두 가지 사항을 모두 충족하는 경우 HTTP 쿠키 어피니티를 사용할 수 있습니다.

  • 부하 분산 지역 정책은 RING_HASH 또는 MAGLEV입니다.
  • 백엔드 서비스의 일관성 있는 해시는 HTTP 쿠키의 이름을 지정합니다.

HTTP 쿠키 어피니티는 HTTP_COOKIE 플래그에 지정된 HTTP 쿠키를 기반으로 NEG의 백엔드 VM 또는 엔드포인트로 요청을 라우팅합니다. 클라이언트가 쿠키를 제공하지 않으면 프록시는 쿠키를 생성하여 Set-Cookie 헤더의 클라이언트에 반환합니다.

HTTP 쿠키 어피니티가 사용되는 내부 HTTP(S) 부하 분산에 대한 자세한 내용은 내부 HTTP(S) 부하 분산 개요를 참조하세요.

세션 어피니티 상실

선택한 어피니티 유형에 관계없이 클라이언트는 다음 상황에서 백엔드와의 어피니티를 상실할 수 있습니다.

  • 백엔드 인스턴스 그룹 또는 영역별 NEG가 분산 모드의 대상 용량으로 정의된 용량을 초과하여 실행하는 경우. 이 경우 Google Cloud는 다른 영역에 있을 수 있는 다른 백엔드 인스턴스 그룹 또는 영역별 NEG로 트래픽을 전달합니다. 자체 테스트에 따라 각 백엔드에 알맞은 대상 용량을 지정하면 이를 완화할 수 있습니다.
  • 자동 확장은 관리형 인스턴스 그룹에 인스턴스를 추가하거나 삭제합니다. 이 경우 인스턴스 그룹의 인스턴스 수가 변경되므로 백엔드 서비스는 세션 어피니티의 해시를 다시 계산합니다. 관리형 인스턴스 그룹의 최소 크기가 일반적인 부하를 처리할 수 있도록 하여 이 문제를 완화할 수 있습니다. 그러면 자동 확장은 예상치 못한 부하 증가 시에만 수행됩니다.
  • NEG의 백엔드 VM 또는 엔드포인트가 상태 확인에 실패하면 부하 분산기는 트래픽을 다른 정상 백엔드로 전달합니다. 모든 백엔드가 상태 확인에 실패할 때 부하 분산기의 작동 방식에 대한 자세한 내용은 각 Google Cloud 부하 분산기 문서를 참조하세요.
  • 백엔드 인스턴스 그룹에 UTILIZATION 분산 모드가 적용되면 백엔드 사용률이 변경되어 세션 어피니티가 중단됩니다. 부하 분산기 유형에서 지원되는 RATE 또는 CONNECTION 분산 모드를 사용하면 이를 완화할 수 있습니다.

HTTP(S) 부하 분산, SSL 프록시 부하 분산 또는 TCP 프록시 부하 분산을 사용하는 경우 다음 사항에 유의하세요.

  • 인터넷의 클라이언트에서 Google로의 라우팅 경로가 요청 또는 연결 간에 변경되면 다른 Google 프런트엔드(GFE)가 프록시로 선택될 수 있습니다. 이러면 세션 어피니티가 중단될 수 있습니다.
  • 특히 대상 최대 용량이 정의되지 않은 UTILIZATION 분산 모드를 사용하면 부하 분산기에 대한 트래픽이 적을 때 세션 어피니티가 손상될 수 있습니다. 대신 RATE 또는 CONNECTION 분산 모드를 사용하도록 전환합니다.

백엔드 서비스 제한 시간

대부분의 Google Cloud 부하 분산기에는 백엔드 서비스 제한 시간이 있습니다. 기본값은 30초입니다.

  • HTTP, HTTPS 또는 HTTP/2를 사용하는 외부 HTTP(S) 부하 분산기 및 내부 HTTP(S) 부하 분산기의 경우 백엔드 서비스 제한 시간은 HTTP(S) 트래픽의 요청/응답 제한 시간입니다. 이 값은 백엔드가 요청에 대한 응답을 모두 반환할 때까지 부하 분산기가 대기하는 시간입니다. 예를 들어 백엔드 서비스 제한 시간이 기본값인 30초인 경우 백엔드가 요청에 대한 응답을 완료할 수 있는 시간은 30초입니다. 백엔드가 부하 분산기에 응답 헤더를 전송하기 전에 연결을 닫거나 시간이 초과되면 부하 분산기가 HTTP GET 요청을 다시 시도합니다. 백엔드가 응답 헤더를 전송하거나(전송하지 않으면 응답 본문이 불완전한 경우에도) 백엔드로 전송된 요청이 HTTP GET 요청이 아닌 경우 부하 분산기는 재시도하지 않습니다. 백엔드가 전혀 응답하지 않으면 부하 분산기가 클라이언트에 HTTP 5xx 응답을 반환합니다. 백엔드가 요청에 응답하기 위해 할당된 시간을 변경하려면 제한 시간 값을 변경합니다.

  • HTTP 트래픽의 경우 클라이언트가 요청 전송을 완료하는 데 걸리는 최대 시간은 백엔드 서비스 제한 시간과 동일합니다. HTTP에 jsonPayload.statusDetail client_timed_out이 포함된 408 응답이 표시되면 이는 클라이언트의 요청이 프록시되거나 백엔드의 응답이 프록시되어 있는 동안에 진행이 부족하다는 의미입니다. 성능 문제가 있는 클라이언트로 인해 문제가 발생하면 백엔드 서비스 제한 시간을 늘려 이 문제를 해결할 수 있습니다.

  • 외부 HTTP(S) 부하 분산기 및 내부 HTTP(S) 부하 분산기의 경우 HTTP 연결이 WebSocket으로 업그레이드되면 백엔드 서비스 제한 시간은 유효 여부에 관계없이 WebSocket을 열 수 있는 최대 시간을 정의합니다.

  • SSL 프록시 부하 분산기와 TCP 프록시 부하 분산기의 경우 제한 시간은 유휴 제한 시간입니다. 연결이 삭제되기 전에 시간을 늘리거나 줄이려면 제한 시간 값을 변경합니다. 이 유휴 제한 시간은 WebSocket 연결에도 사용됩니다.

  • 내부 TCP/UDP 부하 분산기의 경우 백엔드 서비스 제한 시간은 영향이 없습니다.

  • 프록시리스 gRPC 서비스를 구성하면 Traffic Director는 백엔드 서비스 제한 시간을 지원하지 않습니다.

상태 확인

백엔드가 인스턴스 그룹이거나 영역별 NEG인 각 백엔드 서비스에는 연결된 상태 확인이 있어야합니다. 인터넷 NEG를 백엔드로 사용하는 백엔드 서비스는 상태 확인을 참조하지 않아야 합니다.

Google Cloud Console을 사용하여 부하 분산기를 만드는 경우, 필요하면 부하 분산기를 만들 때 상태 확인을 만들거나 기존 상태 확인을 참조할 수 있습니다.

gcloud 명령줄 도구 또는 API를 사용하여 인스턴스 그룹 또는 영역별 NEG 백엔드를 사용하는 백엔드 서비스를 만들 때 기존 상태 확인을 참조해야 합니다. 필요한 상태 확인 유형 및 범위에 대한 자세한 내용은 상태 확인 개요부하 분산기 가이드를 참조하세요.

자세한 내용은 다음 문서를 참조하세요.

백엔드 서비스 리소스에 사용 설정된 추가 기능

HTTP(S) 부하 분산에 사용되는 백엔드 서비스에는 다음과 같은 Google Cloud 기능을 선택적으로 사용할 수 있습니다. 이 문서에서는 다루지 않지만 다음 페이지에서 설명합니다.

  • Google Cloud Armor는 보안 정책으로 DDoS 및 기타 공격으로부터 보호합니다.
  • Cloud CDN은 지연 시간이 짧은 콘텐츠 전송 시스템입니다.
  • 커스텀 헤더 만들기는 부하 분산기에서 요청에 추가하는 추가 헤더입니다.
  • IAP를 사용하면 다음을 수행할 수 있습니다.
    • OAuth 2.0 로그인을 사용하여 Google 계정 인증을 요구
    • ID 및 액세스 관리 권한을 사용하여 액세스를 제어

기타 참고사항

다음 기능은 내부 HTTP(S) 부하 분산기와 Traffic Director에서만 지원됩니다. 하지만 Traffic Director와 함께 프록시리스 gRPC 서비스를 사용하는 경우에는 지원되지 않습니다.

  • 회로 차단
  • 이상점 감지
  • 부하 분산 정책
  • HTTP 쿠키 기반 세션 어피니티
  • HTTP 헤더 기반 세션 어피니티

다음 단계

백엔드 서비스가 부하 분산에 사용되는 방법에 대한 관련 문서 및 정보를 보려면 다음을 검토합니다.