내부 애플리케이션 부하 분산기의 트래픽 관리 개요

리전 내부 애플리케이션 부하 분산기와 리전 간 내부 애플리케이션 부하 분산기는 다음과 같은 고급 트래픽 관리 기능을 지원합니다.

• 트래픽 조정. HTTP(S) 매개변수(예: 호스트, 경로, 헤더, 기타 요청 매개변수)에 따라 트래픽을 지능적으로 라우팅합니다.
• 트래픽 작업. 요청 기반 및 응답 기반 작업을 수행합니다(예: 리디렉션 및 헤더 변환).
• 트래픽 정책. 부하 분산 동작을 미세 조정합니다(예: 고급 부하 분산 알고리즘).

URL 맵 및 백엔드 서비스를 사용하여 이러한 기능을 설정할 수 있습니다. 자세한 내용은 다음 항목을 참조하세요.

• URL 맵 개요
• URL 맵 사용
• 백엔드 서비스 이해

참고: 리전 간 내부 애플리케이션 부하 분산기의 경우 전역 URL 맵 및 전역 백엔드 서비스 API를 사용해야 합니다.

이 문서에 제공된 예시에서 regions/REGION/backendServices를 global/backendServices로 바꿔 사용할 수 있습니다.

사용 사례

트래픽 관리는 많은 사용 사례를 해결합니다. 이 섹션에서는 몇 가지 개략적인 예시를 설명합니다.

트래픽 조정: 헤더 기반 라우팅

트래픽 조정을 사용하면 요청 헤더와 같은 HTTP 매개변수를 기반으로 직접 트래픽을 서비스 인스턴스로 보낼 수 있습니다. 예를 들어 사용자의 기기가 모바일 기기이고 요청 헤더에 user-agent:Mobile이 있다고 가정하면 트래픽 조정은 모바일 트래픽을 수신하도록 지정된 서비스 인스턴스에 트래픽을 전송하고 다른 기기를 다루는 인스턴스에는 user-agent:Mobile이 없는 트래픽을 전송합니다.

그림 1. Cloud Load Balancing 트래픽 조정(확대하려면 클릭)

트래픽 작업: 가중치 기반 트래픽 분할

기존 프로덕션 서비스의 새 버전을 배포하면 일반적으로 위험합니다. 테스트가 스테이징으로 전달되더라도 사용자의 100%가 바로 새 버전을 사용하는 것을 원하지 않을 것입니다. 트래픽 관리를 사용하면 여러 백엔드 서비스에서 백분율 기반 트래픽 분할을 정의할 수 있습니다.

예를 들어 트래픽의 95%를 이전 버전의 서비스로, 5%를 새 버전의 서비스로 전송할 수 있습니다. 새 프로덕션 버전이 제대로 작동하는지 확인한 후 트래픽의 100%가 서비스의 새 버전에 도달할 때까지 점진적으로 비율을 변경할 수 있습니다. 트래픽 분할은 일반적으로 새 버전 배포, A/B 테스팅, 서비스 마이그레이션 등과 유사한 프로세스에 사용됩니다.

그림 2. Google Cloud Load Balancing 트래픽 분할(확대하려면 클릭)

트래픽 정책: 요청 미러링

예를 들어 나중에 다시 재생하기 위해 요청 세부정보를 데이터베이스에 기록할 수 있는 추가 서비스에 모든 트래픽을 미러링해야 한다는 조직의 규정 준수 요구 사항이 있을 수 있습니다.

서비스 확장 프로그램을 통한 확장성

서비스 확장 프로그램과 통합하면 지원되는 애플리케이션 부하 분산기의 부하 분산 데이터 경로에 커스텀 로직을 삽입할 수 있습니다.

자세한 내용은 서비스 확장 프로그램 개요를 참조하세요.

트래픽 관리 구성요소

높은 수준에서 부하 분산기는 리전별 URL 맵 및 리전별 백엔드 서비스 리소스를 활용하여 트래픽 관리를 제공합니다.

리전 간 내부 애플리케이션 부하 분산기의 경우 트래픽 관리는 전역 URL 맵 및 전역 백엔드 서비스 리소스를 사용합니다.

URL 맵을 사용하여 트래픽 조정 및 트래픽 작업을 설정할 수 있습니다. URL 맵과 연결된 Google Cloud 리소스에는 다음이 포함됩니다.

• 라우팅 규칙
• 규칙 일치
• 규칙 작업

백엔드 서비스를 사용하여 트래픽 정책을 설정할 수 있습니다. 백엔드 서비스와 연결된 Google Cloud 리소스에는 다음이 포함됩니다.

• 회로 차단기
• 리전 부하 분산기 정책
• 일관성 있는 해시 부하 분산기 설정
• 이상점 감지

다음 다이어그램에서는 각 기능을 구현하는 데 사용되는 리소스를 보여줍니다.

그림 3. Cloud Load Balancing 데이터 모델(확대하려면 클릭)

백엔드로 요청 라우팅

리전 내부 애플리케이션 부하 분산기에서 트래픽의 백엔드는 2단계 접근 방식을 사용하여 결정됩니다.

• 부하 분산기는 백엔드가 있는 백엔드 서비스를 선택합니다. 백엔드는 비관리형 인스턴스 그룹의 Compute Engine 가상 머신(VM) 인스턴스, 관리형 인스턴스 그룹(MIG)의 Compute Engine VM 또는 네트워크 엔드포인트 그룹(NEG)의 Google Kubernetes Engine(GKE) 노드를 사용하는 컨테이너일 수 있습니다. 부하 분산기는 리전별 URL 맵에 정의된 규칙에 따라 백엔드 서비스를 선택합니다.
• 백엔드 서비스는 리전별 백엔드 서비스에 정의된 정책에 따라 백엔드 인스턴스를 선택합니다.

라우팅을 구성할 때는 다음 모드 중에서 선택할 수 있습니다.

• 단순한 호스트 및 경로 규칙
• 고급 호스트, 경로, 라우팅 규칙

두 모드는 상호 배타적입니다. 각 URL 맵에는 둘 중 하나의 모드만 포함할 수 있습니다.

단순한 호스트 및 경로 규칙

단순한 호스트 및 경로 규칙에서 URL 맵은 URL 맵 개요에 설명된 대로 작동합니다.

다음 다이어그램은 단순한 호스트 및 경로 규칙의 논리적 흐름을 보여줍니다.

그림 4. 단순한 호스트 및 경로 규칙이 있는 URL 맵 흐름(확대하려면 클릭)

요청은 먼저 호스트 규칙을 사용하여 평가됩니다. 호스트는 요청에 의해 지정된 도메인입니다. 요청의 host가 hosts 필드에 있는 항목 중 하나와 일치하는 경우 관련 경로 일치자가 사용됩니다.

다음으로 경로 일치자가 평가됩니다. 경로 규칙은 가장 긴 길이의 경로부터 일치 방식으로 평가되며 원하는 순서로 경로 규칙을 지정할 수 있습니다. 가장 구체적인 일치 항목이 발견되면 해당 백엔드 서비스로 요청이 라우팅됩니다. 요청이 일치하지 않으면 기본 백엔드 서비스가 사용됩니다.

일반적인 단순한 호스트 및 경로 규칙은 동영상 트래픽이 video-backend-service로 이동하고 다른 모든 트래픽은 web-backend-service로 이동합니다.

gcloud compute url-maps describe lb-map

defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

고급 호스트, 경로, 라우팅 규칙

고급 호스트, 경로, 라우팅 규칙은 간단한 호스트 및 경로 규칙과 비교하여 추가 구성 옵션을 제공합니다. 이러한 옵션은 고급 트래픽 관리 패턴을 사용하고 일부 시맨틱스를 수정합니다. 예를 들어 라우팅 규칙은 연관된 우선순위 값을 가지며 가장 긴 길이의 경로부터 일치 시맨틱스를 사용하는 대신 우선순위 순서로 해석됩니다.

이전 단순 호스트 및 경로 규칙 예시처럼 URL 맵을 사용하여 고급 트래픽 관리를 구성할 수 있습니다. 예를 들어 다음 URL 맵은 트래픽의 95%가 하나의 백엔드 서비스로 라우팅되고 5%의 트래픽은 다른 백엔드 서비스로 라우팅되는 라우팅을 구성합니다.

gcloud compute url-maps describe lb-map

defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

호스트 규칙

요청이 부하 분산기에 도달하면 요청의 host 필드는 URL 맵에서 정의된 hostRules에 대해 평가됩니다. 각 호스트 규칙은 하나 이상의 호스트 목록과 단일 경로 일치자(pathMatcher)로 구성됩니다. hostRules가 정의되지 않은 경우 요청은 defaultService로 라우팅됩니다.

자세한 내용은 리전별 URL 맵 API 문서의 hostRules[] 및 defaultService를 참조하세요.

경로 일치자

요청이 호스트 규칙과 일치하면 부하 분산기는 호스트에 해당하는 경로 일치자를 평가합니다.

경로 일치자는 다음으로 구성됩니다.

• 하나 이상의 경로 규칙(pathRules) 또는 라우팅 규칙(routeRules)
• 다른 백엔드 서비스가 일치하지 않을 때 사용되는 기본 백엔드 서비스인 기본 서비스(defaultService)

자세한 내용은 리전별 URL 맵 API 문서의 pathMatchers[], pathMatchers[].pathRules[], pathMatchers[].routeRules[]를 참조하세요.

경로 규칙

경로 규칙(pathRules)은 / 또는 /video와 같은 하나 이상의 URL 경로를 지정합니다. 경로 규칙은 일반적으로 앞에서 설명한 단순한 호스트 및 경로 기반 라우팅 유형을 위한 것입니다.

자세한 내용은 리전별 URL 맵 API 문서의 pathRules[]를 참조하세요.

라우팅 규칙

라우팅 규칙(routeRules)은 들어오는 요청의 정보를 일치시켜 이 일치를 기반으로 라우팅을 결정합니다.

라우팅 규칙에는 다양한 일치 규칙(matchRules) 및 라우팅 작업(routeAction)이 포함될 수 있습니다.

일치 규칙은 HTTP(S) 요청의 경로, 헤더, 쿼리 매개변수를 기반으로 들어오는 요청을 평가합니다. 일치 규칙은 다양한 유형의 일치(예: 프리픽스 일치) 및 수정자(예: 대소문자 구분 안 함)를 지원합니다. 예를 들어 커스텀 정의 HTTP 헤더의 존재 여부에 따라 HTTP(S) 요청을 백엔드 세트로 보낼 수 있습니다.

참고: 일치 옵션 및 시맨틱스는 일치하는 요청 부분에 따라 다릅니다. 자세한 내용은 리전별 URL 맵 API 문서의 matchRules[]를 참조하세요.

여러 라우팅 규칙이 있는 경우 부하 분산기는 우선순위에 따라 priority 필드를 기준으로 규칙을 실행하여 일치, 라우팅, 기타 작업에 대한 커스텀 로직을 지정할 수 있습니다.

지정된 경로 규칙 내에서 첫 번째 일치가 이루어지면 부하 분산기는 일치 규칙 평가를 중지하고 나머지 일치 규칙은 무시됩니다.

Google Cloud는 다음 작업을 수행합니다.

1. 요청과 일치하는 첫 번째 일치 규칙을 찾습니다.
2. 다른 일치 규칙을 찾지 않습니다.
3. 해당 라우팅 작업에 해당하는 작업을 적용합니다.

다음 표에 설명된 대로 경로 규칙에는 여러 구성요소가 있습니다.

경로 규칙 구성요소(API field name)	설명
우선순위(priority)	지정된 경로 일치자 내의 경로 규칙에 지정된 0~2,147,483,647(즉, (2^31) -1)의 숫자입니다. 우선순위는 라우팅 규칙 평가 순서를 결정합니다. 우선순위가 25인 규칙보다 우선순위가 4인 규칙을 평가할 수 있도록 규칙의 우선순위는 숫자가 증가함에 따라 감소합니다. 요청과 일치하는 첫 번째 규칙이 적용됩니다. 우선순위 번호에는 차이가 있을 수 있습니다. 우선순위가 같은 규칙을 두 개 이상 만들 수 없습니다.
설명(description)	최대 1,024자에 대한 설명입니다(선택사항).
서비스(service)	이 규칙이 일치하는 경우 트래픽이 전송되는 백엔드 서비스 리소스의 전체 또는 부분 URL입니다.
일치 규칙(matchRules)	요청에 대해 평가되는 하나 이상의 규칙입니다. 이러한 matchRules는 경로, HTTP 헤더, 쿼리(GET) 매개변수와 같은 요청의 HTTP 속성의 전체 또는 하위 집합을 일치시킬 수 있습니다. matchRule 내에서 routeRule의 routeActions를 적용하려면 모든 일치 기준을 충족해야 합니다. routeRule에 여러 개의 matchRules가 있으면 요청이 routeRule의 matchRules와 일치하는 경우 routeRule의 routeActions가 적용됩니다.
라우팅 작업(routeAction)	일치 규칙 기준이 충족될 때 수행할 작업을 지정할 수 있습니다. 이러한 작업에는 트래픽 분할, URL 재작성, 재시도 및 미러링, 결함 주입, CORS 정책이 있습니다.
리디렉션 작업(urlRedirect)	일치 규칙 기준이 충족되면 HTTP 리디렉션으로 응답하도록 작업을 구성할 수 있습니다. 이 필드는 라우팅 작업과 함께 사용할 수 없습니다.
헤더 작업(headerAction)	matchRules 내의 기준이 충족되면 요청 및 응답 헤더 변환 규칙을 구성할 수 있습니다.

자세한 내용은 리전별 URL 맵 API 문서에서 다음 필드를 참조하세요.

• routeRules[]
• routeRules[].priority
• routeRules[].description
• routeRules[].service
• routeRules[].matchRules[]
• routeRules[].routeAction
• routeRules[].urlRedirect
• routeRules[].headerAction

일치 규칙

일치 규칙(matchRules)은 요청에 대한 1개 이상의 속성을 일치시키고 라우팅 규칙에 지정된 조치를 취합니다. 다음 목록은 일치 규칙을 사용하여 일치시킬 수 있는 요청 속성의 몇 가지 예시를 제공합니다.

• 호스트: 호스트 이름은 URL의 도메인 이름 부분입니다. 예를 들어 URL http://example.net/video/hd의 호스트 이름 부분은 example.net입니다. 요청에서 호스트 이름은 curl 명령어 예시에 표시된 대로 Host 헤더에서 가져옵니다. 여기서 10.1.2.9는 부하 분산된 IP 주소입니다.

  curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
  

• 경로는 호스트 이름을 따릅니다(예: /images). 전체 경로 또는 경로의 앞 부분만 일치시킬지 여부는 규칙에서 지정할 수 있습니다.

• HTTP 헤더 같은 다른 HTTP 요청 매개변수는 쿠키 일치뿐만 아니라 쿼리 매개변수(GET 변수) 기반의 일치도 허용합니다.

지원되는 일치 규칙 전체 목록은 리전별 URL 맵 API 문서의 pathMatchers[].routeRules[].matchRules[]를 참조하세요.

라우팅 작업

라우팅 작업은 라우팅 규칙이 요청의 속성과 일치할 때 취할 특정 조치입니다.

라우팅 작업(API field name)	설명
리디렉션(urlRedirect)	구성 가능한 3xx 응답 코드를 반환합니다. 또한 적절한 URI로 Location 응답 헤더를 설정하여 리디렉션 작업에 지정된 대로 호스트와 경로를 바꿉니다.
URL 재작성(urlRewrite)	선택한 백엔드 서비스에 요청을 전송하기 전에 URL의 호스트 이름 부분이나 URL의 경로 부분 또는 둘 다 재작성할 수 있습니다.
헤더 변환(headerAction)	백엔드 서비스에 요청을 보내기 전에 요청 헤더를 추가하고 제거합니다. 또한 백엔드 서비스에서 응답을 수신한 후 응답 헤더를 추가하거나 삭제할 수 있습니다.
트래픽 미러링(requestMirrorPolicy)	선택한 백엔드 서비스로 요청을 전달하는 것 외에 동일한 요청을 파이어 앤 포겟(fire-and-forget) 방식으로 구성된 미러링 백엔드 서비스에 전송합니다. 부하 분산기는 미러링된 요청을 보내는 백엔드의 응답을 기다리지 않습니다. 미러링은 백엔드 서비스의 새 버전을 테스트하는 데 유용합니다. 또한 미러링을 사용하면 프로덕션 버전이 아닌 백엔드 서비스의 디버그 버전에서 프로덕션 오류를 디버깅할 수 있습니다. 트래픽 미러링을 사용할 때는 다음 제한사항에 유의하세요. 트래픽 미러링은 두 백엔드 서비스 모두 관리형 인스턴스 그룹, 영역 NEG 또는 하이브리드 NEG 백엔드를 사용하는 경우에 지원됩니다. 인터넷 NEG, 서버리스 NEG, Private Service Connect 백엔드에서는 지원되지 않습니다. 미러링된 백엔드 서비스에 대한 요청은 Cloud Logging 및 Cloud Monitoring의 로그 또는 측정항목을 생성하지 않습니다.
가중치가 적용된 트래픽 분할(weightedBackendServices)	일치하는 규칙의 트래픽을 개별 백엔드 서비스에 할당된 사용자 정의 가중치에 맞게 여러 백엔드 서비스에 배포할 수 있습니다. 이 기능은 스테이징 배포 또는 A/B 테스팅을 구성하는 데 유용합니다. 예를 들어 트래픽 중 99%는 안정적인 애플리케이션 버전이 실행되는 서비스에 전송하고 나머지 1%는 해당 애플리케이션이 최신 버전이 실행되는 별도의 서비스에 전송하도록 라우팅 작업을 구성할 수 있습니다.
재시도(retryPolicy)	부하 분산기가 실패한 요청을 재시도하는 조건, 재시도 전 부하 분산기가 대기하는 시간, 최대 재시도 허용 횟수를 구성합니다.
제한 시간(timeout)	선택한 경로의 제한 시간을 지정합니다. 제한 시간은 요청이 완전히 처리된 시간부터 응답이 완전히 처리될 때까지 계산됩니다. 제한 시간에는 모든 재시도 횟수가 포함됩니다.
결함 주입(faultInjectionPolicy)	높은 지연 시간, 서비스 과부하, 서비스 장애, 네트워크 파티션 나누기 등의 장애를 시뮬레이션하는 요청을 제공할 때 의도적으로 오류를 발생시킬 수 있습니다. 이 기능은 장애를 시뮬레이션하면서 서비스의 복원력을 테스트하는 데 유용합니다.
지연 주입(faultInjectionPolicy)	선택한 백엔드 서비스에 요청을 전송하기 전에 일부 사용자 정의 요청에 지연이 발생하도록 합니다.
취소 주입(faultInjectionPolicy)	요청을 백엔드 서비스로 전달하는 대신 사용자 정의 HTTP 상태 코드가 있는 일부 요청에 직접 응답하도록 합니다.
보안 정책(corsPolicy)	교차 출처 리소스 공유(CORS) 정책은 CORS 요청을 적용하는 데 필요한 설정을 처리합니다.

다음 라우팅 작업 중 하나를 지정할 수 있습니다.

• 트래픽을 단일 서비스로 라우팅(service)
• 여러 서비스 간에 트래픽 분할(weightedBackendServices weight:x의 경우 x는 0에서 1,000 사이여야 함)
• 리디렉션 URL(urlRedirect)

또한 앞에서 언급된 라우팅 작업 중 하나를 다음 라우팅 작업 중 하나 이상과 결합할 수 있습니다.

• 트래픽 미러링(requestMirrorPolicy)
• URL 호스트 및 경로 재작성(urlRewrite)
• 실패한 요청 재시도(retryPolicy)
• 제한 시간 설정(timeout)
• 트래픽 비율에 결함 도입(faultInjectionPolicy)
• CORS 정책 추가(corsPolicy)
• 요청 또는 응답 헤더 조작(headerAction)

라우팅 작업의 구성 및 시맨틱스에 대한 자세한 내용은 리전별 URL 맵 API 문서에서 다음을 참조하세요.

• urlRedirect
• urlRewrite
• headerAction
• requestMirrorPolicy
• weightedBackendServices
• retryPolicy
• timeout
• faultInjectionPolicy
• corsPolicy

HTTP에서 HTTPS로 리디렉션

HTTP 트래픽을 HTTPS로 리디렉션해야 하는 경우 공통 IP 주소를 사용하는 전달 규칙 두 개를 만들 수 있습니다.

2개의 전달 규칙이 공통 내부 IP 주소를 공유하려면 IP 주소를 예약하고 --purpose=SHARED_LOADBALANCER_VIP 플래그를 포함해야 합니다.

gcloud compute addresses create NAME \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

전체 예시는 리전 외부 애플리케이션 부하 분산기의 HTTP-HTTPS 리디렉션 설정을 참조하세요.

트래픽 정책

백엔드 서비스 리소스를 사용하면 트래픽 그룹을 구성하여 인스턴스 그룹 또는 네트워크 엔드포인트 그룹(NEG) 내에서 부하 분산을 미세 조정할 수 있습니다. 이 정책은 URL 맵을 사용하여 백엔드 서비스를 선택한 후에만 적용됩니다(앞에서 설명한 대로).

트래픽 정책을 통해 다음을 수행할 수 있습니다.

• 백엔드 서비스 내 인스턴스 간 부하 분산 알고리즘을 제어할 수 있습니다.
• 업스트림 서비스에 대한 연결 볼륨을 제어할 수 있습니다.
• 백엔드 서비스에서 비정상 호스트의 제거를 제어할 수 있습니다.

다음 트래픽 정책 기능은 리전별 백엔드 서비스에서 구성됩니다.

트래픽 정책(API field name)	설명
부하 분산 지역 정책(LocalityLbPolicy)	백엔드 서비스의 경우 트래픽 분산은 부하 분산 모드 및 부하 분산 지역 정책을 기반으로 합니다. 분산 모드에 따라 각 백엔드(인스턴스 그룹 또는 GCE_VM_IP_PORT NEG)로 전송되어야 하는 트래픽의 가중치/비율이 결정됩니다. 부하 분산 정책(LocalityLbPolicy)은 영역이나 그룹의 백엔드가 부하 분산되는 방식을 결정합니다. 백엔드 서비스가 트래픽을 수신하면 백엔드의 분산 모드에 따라 백엔드(인스턴스 그룹 또는 GCE_VM_IP_PORT NEG)로 트래픽을 전달합니다. 백엔드가 선택되면 트래픽은 지역 정책에 따라 각 영역 내 인스턴스나 엔드포인트 간에 분산됩니다. 리전 관리형 인스턴스 그룹의 경우 지역 정책은 각 구성 영역에 적용됩니다. 지원되는 분산 모드는 분산 모드를 참조하세요. 지원되는 부하 분산 정책 알고리즘은 리전 백엔드 서비스 API 문서의 localityLbPolicy를 참조하세요.
세션 어피니티(consistentHash)	HTTP 쿠키 기반 어피니티, HTTP 헤더 기반 어피니티, 클라이언트 IP 주소 어피니티, 스테이트풀(Stateful) 쿠키 기반 세션 어피니티, 생성된 쿠키 어피니티가 포함됩니다. 세션 어피니티는 백이 정상이고 용량이 있는 한 특정 클라이언트에서 동일한 백엔드로 요청을 전송합니다. 세션 어피니티에 대한 자세한 내용은 리전별 백엔드 서비스 API 문서의 consistentHash를 참조하세요.
이상점 감지(outlierDetection)	NEG에서 비정상 백엔드 VM 또는 엔드포인트를 제거하는 기준과 백엔드 또는 엔드포인트에서 트래픽을 다시 수신하기에 충분할 정도로 정상임을 판단하는 기준을 지정하는 정책 집합입니다. 이상점 감지에 대한 자세한 내용은 리전 백엔드 서비스 API 문서의 outlierDetection을 참조하세요.
회로 차단(circuitBreakers)	백엔드 서비스 연결량 및 연결당 요청의 상한값을 설정합니다. 회로 차단에 대한 자세한 내용은 리전 백엔드 서비스 API 문서의 circuitBreakers를 참조하세요.

다음 단계

• 내부 애플리케이션 부하 분산기에 대한 트래픽 관리를 구성하려면 내부 애플리케이션 부하 분산기의 트래픽 관리 설정을 참조하세요.