이 페이지는 Cloud Translation API를 통해 번역되었습니다.

고급 부하 분산 최적화

이 페이지에서는 서비스 부하 분산 정책을 사용하여 다음 부하 분산기의 고급 비용, 지연 시간, 복원력 최적화를 지원하는 방법을 설명합니다.

전역 외부 애플리케이션 부하 분산기
리전 간 내부 애플리케이션 부하 분산기
전역 외부 프록시 네트워크 부하 분산기
리전 간 내부 프록시 네트워크 부하 분산기

Traffic Director는 또한 고급 부하 분산 최적화를 지원합니다. 자세한 내용은 Traffic Director 문서에서 고급 부하 분산 개요를 참조하세요.

서비스 부하 분산 정책(serviceLbPolicy)은 부하 분산기의 백엔드 서비스와 연결된 리소스입니다. 서비스 부하 분산 정책을 사용하면 백엔드 서비스와 연결된 백엔드 내에서 트래픽이 분산되는 방식에 영향을 주는 매개변수를 맞춤설정할 수 있습니다.

특정 리전 또는 영역 내에서 트래픽이 분산되는 방식을 결정하는 데 사용되는 부하 분산 알고리즘을 맞춤설정합니다.
부하 분산기가 비정상 백엔드로부터 트래픽을 빠르게 드레이닝할 수 있도록 자동 용량 드레이닝을 사용 설정합니다.
장애 조치 임곗값을 설정하여 백엔드가 비정상으로 간주되는 경우를 결정합니다. 이렇게 하면 비정상 백엔드가 방지되도록 트래픽을 다른 백엔드로 장애 조치할 수 있습니다.

또한 특정 백엔드를 선호 백엔드로 지정할 수 있습니다. 나머지 백엔드로 요청을 전송하기 전에 이러한 백엔드의 가용 용량을 모두 사용해야 합니다.

다음 다이어그램은 Cloud Load Balancing이 라우팅, 부하 분산, 트래픽 분산을 평가하는 방법을 보여줍니다.

Cloud Load Balancing이 라우팅 및 트래픽 분산을 결정하는 방법

시작하기 전에

이 페이지 내용을 살펴보기 전에 외부 애플리케이션 부하 분산기 개요 페이지에 설명된 요청 분산 프로세스를 자세히 검토하세요. 항상 프리미엄 등급인 부하 분산기의 경우 이 페이지에서 설명하는 모든 부하 분산 알고리즘은 원하는 리전이 이미 최대 용량인 경우에 리전 간 분산을 지원합니다.

지원되는 백엔드

서비스 부하 분산 정책과 선호하는 백엔드는 다음 표와 같이 지원되는 백엔드를 사용하는 부하 분산기에서만 구성될 수 있습니다.

백엔드	지원 여부
인스턴스 그룹 비관리형 영역 관리형
리전 MIG
영역 NEG(`GCE_VM_IP_PORT` 엔드포인트)
하이브리드 NEG(`NON_GCP_PRIVATE_IP_PORT` 엔드포인트)
서버리스 NEG
인터넷 NEG
Private Service Connect NEG

부하 분산 알고리즘

이 섹션에서는 서비스 부하 분산 정책에서 구성할 수 있는 부하 분산 알고리즘에 대해 설명합니다. 알고리즘을 구성하지 않거나 서비스 부하 분산 정책을 전혀 구성하지 않으면 기본적으로 부하 분산기에 WATERFALL_BY_REGION이 사용됩니다.

리전별 폭포

WATERFALL_BY_REGION은 기본 부하 분산 알고리즘입니다. 이 알고리즘을 사용하면 한 리전의 모든 Google 프런트엔드(GFE)가 구성된 대상 용량(용량 확장 처리로 수정됨)에 비례해서 백엔드를 채우려고 시도합니다.

개별 두 번째 레이어 GFE는 두 번째 레이어 GFE에 가능한 한 가장 가까운(네트워크 왕복 시간에 따라 정의됨) 영역의 백엔드 인스턴스 또는 엔드포인트를 선택하는 것을 선호합니다. WATERFALL_BY_REGION은 영역 간 지연 시간을 낮은 요청율에서 최소화하기 때문에 각 두 번째 레이어 GFE는 두 번째 레이어 GFE의 선호 영역에 있는 백엔드에만 요청을 보낼 수 있습니다.

리전에 분무

SPRAY_TO_REGION 알고리즘은 각 두 번째 레이어 GFE가 두 번째 레이어 GFE에 가장 가까운 영역에 있는 백엔드 인스턴스 또는 엔드포인트를 선택하는 데 어떠한 선호도도 갖지 않는 정도까지 각 두 번째 레이어 GFE의 개별 동작을 수정합니다. SPRAY_TO_REGION을 사용할 경우 각 두 번째 레이어 GFE는 두 번째 레이어 GFE와 백엔드 인스턴스 또는 엔드포인트 사이의 왕복 시간 감소를 위한 선호도 없이 해당 리전의 모든 영역에서 모든 백엔드 인스턴스 또는 엔드포인트로 요청을 전송합니다.

WATERFALL_BY_REGION과 마찬가지로, 총체적으로 리전의 모든 두 번째 레이어 GFE는 구성된 대상 용량(용량 확장 처리로 수정됨)에 비례해서 백엔드를 채웁니다.

SPRAY_TO_REGION은 특히 낮은 요청률에서 리전의 모든 영역에 있는 백엔드 간에 보다 균일한 분산 기능을 제공하지만 이러한 균일한 분산과 관련해서 다음을 고려해야 합니다.

백엔드가 작동 중지되지만 상태 점검은 계속 통과할 경우에는 개별 영향이 덜 심각하더라도 더 많은 두 번째 레이어 GFE가 영향을 받습니다.
각각의 두 번째 레이어 GFE에 특정 영역에 대한 선호도가 없기 때문에 두 번째 레이어 GFE에서는 영역 간 트래픽이 더 많이 발생합니다. 또한 처리되는 요청 수에 따라 각 두 번째 레이어 GFE는 백엔드에 대해 더 많은 TCP 연결을 생성할 수 있습니다.

영역별 폭포

WATERFALL_BY_ZONE 알고리즘은 각 두 번째 레이어 GFE가 두 번째 레이어 GFE에 가장 가까운 영역에 있는 백엔드 인스턴스 또는 엔드포인트를 선택하는 데 매우 강력한 선호도를 갖는 범위까지 각 두 번째 레이어 GFE의 개별 동작을 수정합니다. WATERFALL_BY_ZONE의 경우 각 두 번째 레이어 GFE는 두 번째 레이어 GFE가 가장 선호되는 영역에 백엔드 인스턴스 또는 엔드포인트를 채우거나 비례적으로 초과해서 채울 때 리전의 다른 영역에 있는 백엔드 인스턴스 또는 엔드포인트에만 요청을 보냅니다.

WATERFALL_BY_ZONE 알고리즘은 지연 시간을 최소화하지만 다음을 고려해야 합니다.

WATERFALL_BY_ZONE은 본질적으로 영역 간 연결을 최소화하지 않습니다. 이 알고리즘은 지연 시간에 따라서만 작동합니다.
WATERFALL_BY_ZONE은 각 두 번째 레이어 GFE가 다른 영역을 채우기 전에 가장 선호되는 영역을 항상 먼저 채우도록 보장하지 않습니다. 유지보수 이벤트가 있으면 두 번째 레이어 GFE의 모든 트래픽이 일시적으로 다른 영역의 백엔드 인스턴스 또는 엔드포인트로 전송될 수 있습니다.
WATERFALL_BY_ZONE을 사용하면 전반적으로 리전 내의 모든 백엔드 인스턴스 또는 엔드포인트 간에 요청이 덜 균일하게 분산될 수 있습니다. 예를 들어 두 번째 레이어 GFE의 최고 선호 영역에 있는 백엔드 인스턴스 또는 엔드포인트가 최대 용량까지 채워지고, 다른 영역의 백엔드는 최대 용량까지 채워지지 않을 수 있습니다.

부하 분산 알고리즘 비교

다음 표에서는 여러 다른 부하 분산 알고리즘을 비교해서 보여줍니다.

동작	리전별 폭포	리전에 분무	영역별 폭포
단일 리전 내에서 균등한 용량 사용	예	예	아니요
여러 리전 간 균일한 용량 사용	아니요	아니요	아니요
부하 부산기에서 균일한 트래픽 분할	아니요	예	아니요
영역 간 트래픽 분산	예. 네트워크 지연 시간을 최적화하면서 리전의 영역 간에 트래픽이 균일하게 분산됩니다. 필요한 경우 영역 간에 트래픽이 전송될 수 있습니다.	예	예. 최대 용량에 도달할 때까지 가장 가까운 영역으로 트래픽이 우선 전달됩니다. 그런 후 가장 가까운 다음 영역으로 이동합니다.
로컬 영역의 트래픽 급증 민감도	평균. 영역간 분산을 위해 지금까지 전달된 트래픽 양에 따라 달라집니다.	낮음. 단일 영역의 트래픽 급증이 리전 내 모든 영역에 분산됩니다.	높음. 부하 분산기가 반응할 수 있을 때까지 단일 영역의 트래픽 급증이 전적으로 동일한 영역에서만 처리될 가능성이 높습니다.

자동 용량 드레이닝

백엔드가 비정상이면 일반적으로 가능한 한 빨리 부하 분산 결정에서 제외해야 합니다. 비정상 백엔드를 제외하면 정상 상태의 백엔드로만 트래픽이 전송되어 전반적으로 지연 시간이 최적화됩니다.

자동 용량 드레이닝 기능을 사용 설정하면 상태 점검을 통과하는 백엔드 인스턴스 또는 엔드포인트 비율이 25% 미만일 때 부하 분산기가 해당 백엔드 용량을 자동으로 0으로 축소합니다. 이렇게 하면 전역 부하 분산 풀에서 비정상 백엔드가 삭제됩니다. 이 작업은 해당 백엔드에 대한 트래픽 라우팅을 방지하려는 경우에 백엔드에 대해 backendService.capacityScaler를 0으로 설정하는 것과 기능적으로 동일합니다.

이전에 자동으로 드레이닝한 백엔드의 인스턴스 또는 엔드포인트 중에서 60초 동안 상태 점검을 통과하는 비율이 35%(임곗값보다 10% 높음)에 달하면 백엔드가 자동으로 드레이닝 취소되고 다시 부하 분산 풀에 추가됩니다. 이렇게 하면 백엔드가 지속적으로 정상 상태로 유지되고 드레이닝 또는 드레이닝 해제 상태로 빈번하게 전환되지 않습니다.

자동 용량 드레이닝을 사용 설정한 경우에도 부하 분산기는 백엔드의 상태에 관계없이 백엔드 서비스에 연결된 백엔드를 50% 넘게 드레이닝하지 않습니다. 연결된 백엔드 비율을 50%로 유지함으로써 정상 백엔드를 과부하시킬 위험을 줄입니다.

자동 용량 드레이닝의 한 가지 사용 사례는 선호 백엔드의 과부하 위험을 최소화하는 것입니다. 예를 들어 백엔드가 선호 백엔드로 표시되었지만 인스턴스 또는 엔드포인트가 대부분 비정상이면 자동 용량 드레이닝을 통해 해당 백엔드가 부하 분산 풀에서 삭제됩니다. 선호 백엔드에 있는 남은 정상 상태의 인스턴스 또는 엔드포인트를 과부하시키는 대신 자동 용량 드레이닝이 트래픽을 다른 백엔드로 전환합니다.

서비스 부하 분산 정책에 다라 자동 용량 드레이닝을 사용 설정할 수 있습니다. 자세한 내용은 서비스 부하 분산 정책 구성을 참조하세요.

분산 모드를 사용하지 않는 백엔드에서는 자동 용량이 지원되지 않습니다. 여기에는 인터넷 NEG, 서버리스 NEG, PSC NEG와 같은 백엔드가 포함됩니다.

장애 조치 임곗값

부하 분산기는 멀티 수준 방식으로 백엔드 간의 트래픽 분산을 결정합니다. 안정 상태에서는 위에서 설명한 부하 분산 알고리즘 중 하나를 기반으로 선택된 백엔드로 트래픽을 전송합니다. 기본 백엔드라고 하는 이러한 백엔드는 지연 시간과 용량 측면에서 최적의 백엔드로 간주됩니다.

또한 부하 분산기는 기본 백엔드가 비정상이 되고 트래픽을 처리할 수 없는 경우에 사용할 수 있는 다른 백엔드를 추적합니다. 이러한 백엔드를 장애 조치 백엔드라고 합니다. 이러한 백엔드는 일반적으로 용량이 남아 있는 인접한 백엔드입니다.

기본 백엔드의 인스턴스나 엔드포인트가 비정상이 되면 부하 분산기에서 트래픽을 즉시 다른 백엔드로 이동하지 않습니다. 대신 부하 분산기는 먼저 트래픽 부하가 안정화되도록 트래픽을 같은 백엔드의 다른 정상 인스턴스나 엔드포인트로 이동합니다. 기본 백엔드의 엔드포인트 다수가 비정상이고 같은 백엔드의 나머지 엔드포인트에서 추가 트래픽을 처리할 수 없으면 부하 분산기는 장애 조치 임곗값을 사용하여 트래픽을 장애 조치 백엔드로 전송하는 시기를 결정합니다. 부하 분산기는 장애 조치 임곗값까지 기본 백엔드의 비정상 상태를 허용합니다. 그런 다음 트래픽은 기본 백엔드에서 이동합니다.

장애 조치 임곗값은 1~99 사이이며 정상이어야 하는 백엔드의 엔드포인트 백분율로 표현됩니다. 정상 엔드포인트 비율이 장애 조치 임곗값 미만이면 부하 분산기에서 트래픽을 장애 조치 백엔드로 전송하려고 시도합니다. 기본적으로 장애 조치 임곗값은 70입니다.

장애 조치 임곗값이 너무 높게 설정되면 일시적인 상태 변경으로 인해 불필요한 트래픽이 분산될 수 있습니다. 장애 조치 임곗값이 너무 낮게 설정되면 비정상 엔드포인트가 많더라도 부하 분산기에서 트래픽을 기본 백엔드로 계속 전송합니다.

장애 조치 결정은 현지화됩니다. 각 로컬 Google 프런트엔드(GFE)는 서로 독립적으로 동작합니다. 장애 조치 백엔드에서 추가 트래픽을 처리할 수 있는지 확인하는 것은 개발자 책임입니다.

장애 조치 트래픽으로 인해 백엔드에서 과부하가 발생할 수 있습니다. 백엔드가 비정상인 경우에도 부하 분산기에서 트래픽을 계속 전송할 수 있습니다. 사용 가능한 백엔드 풀에서 비정상 백엔드를 제외하려면 자동 용량 드레이닝 기능을 사용 설정합니다.

선호 백엔드

선호 백엔드는 트래픽을 다른 백엔드로 전달하기 전에 용량을 완전히 사용하려는 백엔드입니다. 선호 백엔드의 구성된 용량을 초과하는 트래픽은 남은 비선호 백엔드로 라우팅됩니다. 그런 후 부하 분산 알고리즘이 백엔드 서비스의 비선호 백엔드 간에 트래픽을 분산합니다.

후속 요청을 남은 백엔드로 라우팅하기 전에 백엔드 서비스에 연결된 백엔드 하나 이상을 선호하고 완전히 사용하도록 부하 분산기를 구성할 수 있습니다.

선호 백엔드를 사용할 때는 다음과 같은 제한사항을 고려하세요.

선호 백엔드로 구성된 백엔드가 클라이언트에서 더 멀리 있어서 클라이언트 요청에 대한 평균 지연 시간이 더 높아질 수 있습니다. 이러한 상황은 다른 더 가까운 백엔드가 있어서 낮은 지연 시간으로 클라이언트를 지원할 수 있더라도 발생합니다.
특정 부하 분산 알고리즘(WATERFALL_BY_REGION, SPRAY_TO_REGION, WATERFALL_BY_ZONE)은 선호 백엔드로 구성된 백엔드에 적용되지 않습니다.

선호 백엔드를 설정하는 방법은 선호 백엔드 설정을 참조하세요.

서비스 부하 분산 정책 구성

서비스 부하 분산 정책 리소스를 사용하면 다음 필드를 구성할 수 있습니다.

부하 분산 알고리즘
자동 용량 드레이닝
장애 조치 임곗값

선호 백엔드를 설정하려면 선호 백엔드 설정을 참조하세요.

정책 만들기

서비스 부하 분산 정책을 만들고 구성하려면 다음 단계를 수행합니다.

서비스 부하 분산 정책 리소스를 만듭니다. 이 작업은 YAML 파일을 사용하거나, gcloud 매개변수를 사용하거나, 직접적인 방법으로 수행할 수 있습니다.
- YAML 파일을 사용하는 경우. YAML 파일에 서비스 부하 분산 정책을 지정합니다. 다음은 부하 분산 알고리즘을 구성하고 자동 용량 드레이닝을 사용 설정하며 커스텀 장애 조치 임곗값을 설정하는 방법을 보여주는 샘플 YAML 파일입니다.
```
name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
autoCapacityDrain:
    enable: True
failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
```
  다음을 바꿉니다.
  - PROJECT_ID: 프로젝트 ID입니다.
  - SERVICE_LB_POLICY_NAME: 서비스 부하 분산 정책의 이름입니다.
  - FAILOVER_THRESHOLD_VALUE: 장애 조치 임곗값입니다. 1~99 사이의 숫자여야 합니다.
  - LOAD_BALANCING_ALGORITHM: 사용할 부하 분산 알고리즘입니다. SPRAY_TO_REGION, WATERFALL_BY_REGION, WATERFALL_BY_ZONE일 수 있습니다.
  YAML 파일을 만든 후 파일을 새로운 서비스 부하 분산 정책으로 가져옵니다.
```
gcloud beta network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
 --source=PATH_TO_POLICY_FILE \
 --location=global
```
- YAML 파일을 사용하지 않는 경우. 또는 YAML 파일을 사용하지 않고 서비스 부하 분산 정책 기능을 구성할 수 있습니다.
  
  부하 분산 알고리즘을 설정하고 자동 드레이닝을 사용 설정하려면 다음 매개변수를 사용합니다.
```
gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
 --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
 --auto-capacity-drain \
 --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
 --location=global
```
  다음을 바꿉니다.
  - SERVICE_LB_POLICY_NAME: 서비스 부하 분산 정책의 이름입니다.
  - LOAD_BALANCING_ALGORITHM: 사용할 부하 분산 알고리즘입니다. SPRAY_TO_REGION, WATERFALL_BY_REGION, WATERFALL_BY_ZONE일 수 있습니다.
  - FAILOVER_THRESHOLD_VALUE: 장애 조치 임곗값입니다. 1~99 사이의 숫자여야 합니다.

--service-lb-policy 필드가 새로 생성된 서비스 부하 분산 정책 리소스를 참조하도록 백엔드 서비스를 업데이트합니다. 백엔드 서비스는 하나의 서비스 부하 분산 정책 리소스와만 연결할 수 있습니다.

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
  --service-lb-policy=SERVICE_LB_POLICY_NAME \
  --global

백엔드 서비스를 만드는 동안 백엔드 서비스에 서비스 부하 분산 정책을 연결할 수 있습니다.

gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
    --protocol=PROTOCOL \
    --port-name=NAMED_PORT_NAME \
    --health-checks=HEALTH_CHECK_NAME \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME \
    --service-lb-policy=SERVICE_LB_POLICY_NAME \
    --global

정책 삭제

백엔드 서비스에서 서비스 부하 분산 정책을 삭제하려면 다음 명령어를 사용합니다.

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

선호 백엔드 설정

Google Cloud CLI 또는 API를 사용해서 선호 백엔드를 구성할 수 있습니다.

gcloud

선호 백엔드 추가

선호 백엔드를 설정하려면 백엔드 서비스에 백엔드를 추가할 때 gcloud beta compute backend-services add-backend 명령어를 사용해서 --preference 플래그를 설정합니다.

gcloud beta compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

PREFERENCE를 백엔드에 할당하려는 선호도 수준으로 바꿉니다. PREFERRED 또는 DEFAULT일 수 있습니다.

나머지 명령어는 사용 중인 백엔드 유형(인스턴스 그룹 또는 NEG)에 따라 달라집니다. 모든 필수 매개변수는 gcloud beta compute backend-services add-backend 명령어를 참조하세요.

백엔드 선호도 업데이트

백엔드의 --preference 매개변수를 업데이트하려면 gcloud beta compute backend-services update-backend 명령어를 사용합니다.

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

나머지 명령어는 사용 중인 백엔드 유형(인스턴스 그룹 또는 NEG)에 따라 달라집니다. 다음 예시 명령어는 백엔드 인스턴스 그룹의 선호도를 업데이트하고 이를 PREFERRED로 설정합니다.

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

선호 백엔드를 설정하려면 각 백엔드에서 전역 backendServices 리소스를 사용하여 preference 플래그를 설정합니다.

다음은 백엔드 선호도 구성 방법을 보여주는 샘플입니다.

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

다음을 바꿉니다.

PROJECT_ID: 프로젝트 ID입니다.
BACKEND_SERVICE_NAME: 백엔드 서비스의 이름입니다.
BACKEND_1_NAME: 선호 백엔드의 이름입니다.
BACKEND_2_NAME: 기본 백엔드의 이름입니다.

문제 해결

트래픽 분산 패턴은 백엔드 서비스에 새 서비스 부하 분산 정책을 연결할 때 변경될 수 있습니다.

트래픽 문제를 디버깅하려면 Cloud Monitoring을 사용해서 부하 분산기와 백엔드 사이의 트래픽 흐름 방식을 조사합니다. 또한 Cloud Load Balancing 로그 및 측정항목을 통해 부하 분산 동작을 파악할 수 있습니다.

이 섹션에서는 새로 제공된 구성에서 볼 수 있는 몇 가지 공통적인 시나리오를 요약해서 보여줍니다.

단일 소스의 트래픽이 너무 멀리 있는 백엔드로 전송됨

이는 SPRAY_TO_REGION 알고리즘의 의도된 동작입니다. 하지만 넓은 트래픽 분산 범위로 인해 문제가 발생할 수 있습니다. 예를 들어 백엔드가 보다 폭넓은 클라이언트 집합으로부터 트래픽을 수신함에 따라 캐시 적중률이 감소할 수 있습니다. 이 경우 WATERFALL_BY_REGION과 같은 다른 알고리즘을 사용하는 것이 좋습니다.

비정상 엔드포인트가 많은 백엔드로 트래픽이 전송되지 않음

이는 autoCapacityDrain을 사용 설정할 때 의도된 동작입니다. 비정상 엔드포인트가 많은 백엔드는 드레이닝되고 부하 분산 풀에서 삭제됩니다. 이 동작을 원치 않을 경우에는 자동 용량 드레이닝을 사용 중지할 수 있습니다. 하지만 이렇게 하면 비정상 엔드포인트가 많은 백엔드로 트래픽이 전송되어 요청이 실패할 수 있습니다.

가까운 백엔드보다 멀리 있는 백엔드로 트래픽이 전송됨

이는 선호 백엔드가 기본 백엔드보다 멀리 있을 때 발생하는 의도된 동작입니다. 이 동작을 원하지 않을 경우에는 각 백엔드에 대해 선호 설정을 적절히 업데이트합니다.

선호 백엔드를 사용할 때 일부 백엔드로 트래픽이 전송되지 않음

이는 선호 백엔드가 아직 최대 용량에 도달하지 않았을 때 발생하는 의도된 동작입니다. 선호 백엔드는 해당 백엔드에 대한 왕복 지연 시간을 기준으로 먼저 할당됩니다.

다른 백엔드로 트래픽을 전송하려면 다음 중 하나를 수행할 수 있습니다.

다른 백엔드에 대해 선호 설정을 업데이트합니다.
선호 백엔드의 대상 용량 설정을 낮게 설정합니다. 대상 용량은 백엔드 서비스의 분산 모드에 따라 max-rate 또는 max-utilization 필드를 사용하여 구성됩니다.

일시적인 상태 변경 중에 트래픽이 원격 백엔드로 전송됨

이는 장애 조치 임곗값이 높은 값으로 설정된 경우에 발생하는 의도된 동작입니다. 일시적인 상태가 변경될 때 트래픽이 기본 백엔드로 계속 이동하도록 하려면 이 필드를 더 낮은 값으로 설정합니다.

다른 엔드포인트가 비정상인 경우 정상 엔드포인트에 과부하 발생

이는 장애 조치 임곗값이 낮은 값으로 설정된 경우에 발생하는 의도된 동작입니다. 엔드포인트가 비정상이면 이러한 비정상 엔드포인트에 의도된 트래픽이 대신 같은 백엔드에 남아 있는 엔드포인트로 분산됩니다. 장애 조치 동작을 더 빨리 트리거하려면 이 필드를 높은 값으로 설정합니다.

제한사항

각 백엔드 서비스는 단일 서비스 부하 분산 정책 리소스에만 연결할 수 있습니다.