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

고급 부하 분산 최적화

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

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

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

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

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

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

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

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

시작하기 전에

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

지원되는 백엔드

서비스 부하 분산 정책 및 이 페이지에 설명된 모든 기능에는 분산 모드를 지원하는 호환되는 백엔드가 필요합니다. 지원되는 백엔드는 다음 표에 요약되어 있습니다.

백엔드	지원 여부
인스턴스 그룹	영역 비관리형 인스턴스 그룹과 영역 관리형 인스턴스 그룹은 지원되지만 리전 관리형 인스턴스 그룹은 지원되지 않습니다.
영역 NEG(`GCE_VM_IP_PORT` 엔드포인트)
영역 NEG(`GCE_VM_IP` 엔드포인트)	이러한 유형의 NEG는 애플리케이션 부하 분산기 및 프록시 네트워크 부하 분산기에서 지원되지 않습니다.
하이브리드 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의 최고 선호 영역에 있는 백엔드 인스턴스 또는 엔드포인트가 최대 용량까지 채워지고, 다른 영역의 백엔드는 최대 용량까지 채워지지 않을 수 있습니다.

부하 분산 알고리즘 비교

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

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

자동 용량 드레이닝 및 드레이닝 취소

자동 용량 드레이닝 및 언드레이닝은 상태 점검과 백엔드 용량의 개념을 결합합니다. 자동 용량 드레이닝을 사용하면 상태 점검이 유효한 백엔드 용량을 0으로 설정하는 추가 신호로 사용됩니다. 자동 용량 제거를 사용하면 상태 검사가 유효한 백엔드 용량을 이전 값으로 복원하는 추가 신호로 사용됩니다.

자동 용량 소모 및 소모 해제 없이 특정 리전의 모든 백엔드에서 요청을 전달하지 않으려면 해당 리전의 각 백엔드의 유효 용량을 수동으로 0으로 설정해야 합니다. 예를 들어 용량 확장 처리를 사용하여 이 작업을 할 수 있습니다.

자동 용량 드레이닝 및 언드레이닝을 사용하면 상태 점검을 드레이닝 또는 언드레이닝을 통해 백엔드의 용량을 조정하는 신호로 사용할 수 있습니다.

자동 용량 드레이닝 및 드레이닝 해제를 사용 설정하려면 서비스 부하 분산 정책 구성을 참고하세요.

자동 용량 드레이닝

자동 용량 드레이닝은 다음 두 조건이 모두 충족되면 백엔드의 용량을 0으로 설정합니다.

백엔드 인스턴스 또는 엔드포인트의 25% 미만이 상태 확인을 통과합니다.
자동으로 배수될 백엔드 인스턴스 그룹 또는 NEG의 총 개수가 총 백엔드 인스턴스 그룹 또는 NEG의 50% 를 초과하지 않습니다. 50% 비율을 계산할 때 용량이 0인 백엔드는 분자에 포함되지 않습니다. 하지만 모든 백엔드는 분모에 포함됩니다.

용량이 0인 백엔드는 다음과 같습니다.

인스턴스 그룹 용량이 인스턴스별로 정의된 구성원 인스턴스가 없는 백엔드 인스턴스 그룹
NEG 용량이 엔드포인트별로 정의된 구성원 엔드포인트가 없는 백엔드 NEG
용량 스케일러가 0으로 설정된 백엔드 인스턴스 그룹 또는 NEG

자동으로 드레이닝된 백엔드 용량은 용량 스케일러 값을 설정하지 않고 백엔드의 backendService.backends[].capacityScaler를 0로 수동으로 설정하는 것과 기능적으로 동일합니다.

자동 용량 언드레이닝

자동 용량 드레이닝 취소는 백엔드 인스턴스 또는 엔드포인트 중 35% 이상이 60초 이상 상태 점검을 통과하면 백엔드의 용량을 백엔드의 용량 스케일러로 제어되는 값으로 반환합니다. 60초 요구사항은 상태 확인이 연속으로 실패했다가 통과할 때 순차적으로 배출되고 배출되지 않을 가능성을 줄입니다.

장애 조치 기준점

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

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

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

장애 조치 기준점은 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 network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
 --source=PATH_TO_POLICY_FILE \
 --location=global
```
- YAML 파일을 사용하지 않는 경우. 또는 YAML 파일을 사용하지 않고 서비스 부하 분산 정책 기능을 구성할 수 있습니다.
  
  부하 분산 알고리즘을 설정하고 자동 드레이닝을 사용 설정하려면 다음 매개변수를 사용합니다.
```
gcloud 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 compute backend-services update BACKEND_SERVICE_NAME \
  --service-lb-policy=SERVICE_LB_POLICY_NAME \
  --global

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

gcloud 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 compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

선호 백엔드 설정

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

gcloud

선호 백엔드 추가

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

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

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

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

백엔드 선호도 업데이트

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

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

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

gcloud 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 필드를 사용하여 구성됩니다.

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

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

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

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

제한사항

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