전역 외부 애플리케이션 부하 분산기의 트래픽 관리 설정

이 문서에서는 특정 사용 사례에 트래픽 관리를 사용하는 예시를 다룹니다. 다른 많은 사용 사례가 있을 수 있습니다.

이 문서에는 전역 외부 애플리케이션 부하 분산기의 예시가 포함되어 있습니다. 전역 외부 애플리케이션 부하 분산기는 EXTERNAL_MANAGED 부하 분산 스키마와 전역 부하 분산 구성요소(예: 전달 규칙, URL 맵, 백엔드 서비스)를 사용합니다.

기본 애플리케이션 부하 분산기의 트래픽 관리에 대한 자세한 내용은 기본 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.

리전 외부 애플리케이션 부하 분산기의 트래픽 관리에 대한 자세한 내용은 리전 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.

이 페이지에 설명된 고급 라우팅 기능 외에도 지원되는 애플리케이션 부하 분산기는 서비스 확장 프로그램과 통합되어 부하 분산 데이터 경로에 커스텀 로직을 삽입할 수 있습니다.

시작하기 전에

트래픽 관리의 작동 방식을 이해해야 합니다. 자세한 내용은 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.

트래픽 관리 구성 및 테스트

선택한 구성 환경 내에서 YAML 구성을 사용하여 트래픽 관리를 설정합니다. URL 맵과 백엔드 서비스 각각에 자체 YAML 파일이 있습니다. 선택한 기능에 따라 URL 맵 YAML 파일, 백엔드 서비스 YAML 파일 또는 두 파일을 모두 작성해야 합니다.

이러한 YAML 파일을 작성하는 데 도움이 필요한 경우 이 페이지의 예시와 Cloud Load Balancing API 문서를 사용하면 됩니다.

Google Cloud 콘솔은 지원되지 않습니다.

전역 URL 맵 API 및 전역 백엔드 서비스 API 문서는 관계, 제한사항, 카디널리티와 관련된 시맨틱스를 포함한 전체 필드 목록을 제공합니다

URL 맵에 구성 테스트를 추가하여 URL 맵에서 요청을 의도한 대로 라우팅하도록 할 수 있습니다. 다양한 URL 맵 규칙으로 실험하고 맵에서 트래픽을 적절한 백엔드 서비스나 백엔드 버킷으로 라우팅하는지 확인하기 위해 필요한 만큼 테스트를 실행할 수 있습니다. 자세한 내용은 URL 맵에 테스트 추가를 참조하세요. 실제로 맵을 배포하지 않고 URL 맵의 새 변경사항을 테스트하려면 URL 맵 구성 유효성 검사를 참조하세요.

트래픽을 단일 서비스에 매핑

모든 트래픽을 단일 서비스에 전송합니다. 자리표시자를 바꿔야 합니다.

    defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
            weight: 100

두 서비스 간 트래픽 분할

둘 또는 여러 서비스 간에 트래픽을 분할합니다. 자리표시자를 바꿔야 합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

URL 리디렉션 구성

다음 예에서는 구성 가능한 301 MOVED_PERMANENTLY_DEFAULT 응답 코드를 반환합니다. 이 예에서는 적절한 URI로 Location 응답 헤더를 설정하여 리디렉션 작업에 지정된 대로 호스트와 경로를 바꿉니다.

백엔드 버킷의 리디렉션을 만들려면 defaultService 필드에 projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET를 사용합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

트래픽 미러링

선택한 백엔드 서비스로 요청을 전달하는 것 외에 동일한 요청을 파이어 앤 포겟(fire-and-forget) 방식으로 구성된 미러링 백엔드 서비스에 전송합니다. 즉, 부하 분산기는 미러링된 요청을 보내는 백엔드의 응답을 기다리지 않습니다. 요청 미러링은 백엔드 서비스의 새 버전을 테스트하는 데 유용합니다. 또한 미러링을 사용하면 프로덕션 버전이 아닌 백엔드 서비스의 디버그 버전에서 프로덕션 오류를 디버깅할 수 있습니다.

기본적으로 미러링된 백엔드 서비스는 원래 트래픽이 가중치가 적용된 여러 백엔드 서비스 간에 분할되는 경우에도 모든 요청을 수신합니다. 선택적 mirrorPercent 플래그를 사용하여 미러링할 요청의 비율을 0과 100.0 사이의 값으로 지정하여 요청의 일부만 수신하도록 미러링된 백엔드 서비스를 구성할 수 있습니다. 비율 기반 요청 미러링은 미리보기 상태입니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

가중치가 적용된 백엔드 서비스가 여러 개 있고 원래 요청을 처리하는 데 사용된 백엔드 서비스를 기록하려면 이 정보를 포함하는 커스텀 헤더를 모든 요청에 추가하면 됩니다. 다음 예에서는 x-weighted-picked-backend라는 커스텀 헤더를 모든 클라이언트 요청에 추가합니다. 헤더 값에는 원래 요청을 제공한 백엔드 서비스의 이름을 사용합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

트래픽 미러링을 사용할 때는 다음 제한사항에 유의하세요.

• 트래픽 미러링은 두 백엔드 서비스 모두 관리형 인스턴스 그룹, 영역 NEG 또는 하이브리드 NEG 백엔드를 사용하는 경우에 지원됩니다. 인터넷 NEG, 서버리스 NEG, Private Service Connect 백엔드에서는 지원되지 않습니다.
• 미러링된 백엔드 서비스에 대한 요청은 Cloud Logging 및 Cloud Monitoring의 로그 또는 측정항목을 생성하지 않습니다.

요청된 URL 재작성

선택한 백엔드 서비스에 요청을 전송하기 전에 URL의 호스트 이름 부분이나 URL의 경로 부분 또는 둘 다 재작성할 수 있습니다. 자리표시자를 바꿔야 합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

요청 재시도

부하 분산기가 실패한 요청을 재시도하는 조건, 재시도 전 부하 분산기가 대기하는 시간, 최대 재시도 허용 횟수를 구성합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

경로 제한 시간 지정

선택한 경로의 제한 시간을 지정합니다. 제한 시간은 요청이 완전히 처리된 시간부터 응답이 완전히 처리될 때까지 계산됩니다. 제한 시간에는 모든 재시도 횟수가 포함됩니다. 자리표시자를 바꿔야 합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

결함 주입 구성

높은 지연 시간, 서비스 과부하, 서비스 장애, 네트워크 파티션 나누기 등의 장애를 시뮬레이션하는 요청을 제공할 때 의도적으로 오류를 발생시킬 수 있습니다. 이 기능은 장애를 시뮬레이션하면서 서비스의 복원력을 테스트하는 데 유용합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

CORS 구성

교차 출처 리소스 공유(CORS) 요청을 적용하기 위한 설정을 처리하도록 CORS 정책을 구성합니다.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://my-domain.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

요청 및 응답 헤더 추가 및 삭제

참고: URL 맵 및 백엔드 서비스에 구성된 커스텀 헤더 동작에 대한 변경사항이 발표되었습니다. 이 변경사항은 2022년 11월 14일 이전에 커스텀 헤더를 사용한 기존 트래픽이 있는 프로젝트에는 영향을 미치지 않습니다. 자세한 내용은 2022년 11월 14일의 출시 노트를 참조하세요.

백엔드 서비스에 요청을 보내기 전에 요청 헤더를 추가하고 삭제합니다. 또한 백엔드 서비스에서 응답을 수신한 후 응답 헤더를 추가하거나 삭제합니다.

headerName 및 headerValue의 유효한 값에는 제한이 있습니다. 자세한 내용은 커스텀 헤더 작동 방식을 참조하세요.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

이상점 감지 구성

NEG에서 비정상 백엔드 VM 또는 엔드포인트를 제거하는 기준과 백엔드 또는 엔드포인트에서 트래픽을 다시 수신하기에 충분할 정도로 정상임을 판단하는 기준을 지정합니다. 자리표시자를 바꿔야 합니다.

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: 30
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: 1
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900

트래픽 분할 설정: 세부 단계

참고: 가중치가 적용된 트래픽 분할을 사용하는 경우 세션 어피니티를 구성하지 마세요. 구성하면 가중치가 적용된 트래픽 분할 구성이 우선 적용됩니다.

이 예시에서는 다음 단계를 설명합니다.

1. 서비스별로 고유한 템플릿을 만듭니다.

2. 위에서 만든 템플릿에 대한 인스턴스 그룹을 만듭니다.

3. 트래픽 분산을 95%/5%로 설정하는 라우팅 규칙을 만듭니다.

4. 트래픽 분할 비율이 대략 구성과 일치함을 보여주는 curl 명령어를 전송합니다.

여기에서는 다음과 같이 설정되었다고 가정합니다.

• 대상 프록시 및 전달 규칙이 URL 맵(global-lb-map)과 함께 생성되었습니다.

• URL 맵은 모든 트래픽을 기본 백엔드 서비스인 red-service라는 하나의 백엔드 서비스로 전송합니다.

• 트래픽 중 5%를 blue-service로, 나머지 95%를 green-service로 전송하는 대체 경로를 설정합니다

• 경로 일치자가 사용됩니다.

• Cloud Shell이나 bash가 설치된 다른 환경을 사용 중이어야 합니다.

서비스 정의

다음 bash 함수는 인스턴스 템플릿과 관리형 인스턴스 그룹을 포함하는 백엔드 서비스를 만듭니다.

이 안내에서는 HTTP 상태 점검(global-lb-basic-check)이 생성되었다고 가정합니다. 자세한 내용은 다음 페이지 중 하나를 참조하세요.

• Compute Engine 백엔드로 전역 외부 애플리케이션 부하 분산기 설정
• 백엔드 버킷으로 전역 외부 애플리케이션 부하 분산기 설정
• 하이브리드 연결로 전역 외부 애플리케이션 부하 분산기 설정
• Cloud Run, App Engine 또는 Cloud Run Functions로 전역 외부 애플리케이션 부하 분산기 설정

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

서비스 생성

red, green 및 blue의 세 가지 서비스를 만드는 함수를 호출합니다. red 서비스는 / 요청에 대해 기본 서비스 역할을 합니다. green 및 blue 서비스는 각각 트래픽의 95% 및 5%를 처리할 수 있도록 모두 /prefix에서 설정됩니다.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /prefix
make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix

URL 맵 만들기

콘솔

1. Google Cloud 콘솔의 부하 분산 페이지로 이동합니다.
   부하 분산으로 이동
2. global-lb-map 링크를 클릭합니다.
3. 수정 을 클릭합니다.

새 라우팅 규칙 구성

1. 라우팅 규칙에서 고급 호스트, 경로 및 경로 규칙을 선택합니다.
2. 새 호스트 및 경로 일치자에서 서비스를 red-service로 설정하여 기본 작업을 만듭니다.
3. 완료를 클릭합니다.
4. 호스트 및 경로 일치자 추가를 클릭합니다.
5. 호스트 필드에 부하 분산기 전달 규칙의 IP 주소를 입력합니다.

6. 다음 YAML 콘텐츠를 경로 일치자 상자에 붙여넣습니다.

   defaultService: projects/PROJECT_ID/global/backendServices/red-service
   name: matcher1
   routeRules:
   - priority: 2
     matchRules:
       - prefixMatch: /PREFIX
     routeAction:
       weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/green-service
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/blue-service
           weight: 5
   

7. 완료를 클릭합니다.

8. 업데이트를 클릭합니다.

gcloud

1. gcloud compute url-maps export 명령어를 사용하여 기존 URL 맵을 내보냅니다.

   gcloud compute url-maps export global-lb-map \
     --destination=global-lb-map-config.yaml \
     --global
   

2. global-lb-map-config.yaml URL 맵 파일을 파일 끝에 추가하여 업데이트합니다.

   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/red-service
     name: matcher1
     routeRules:
     - priority: 2
       matchRules:
         - prefixMatch: /PREFIX
       routeAction:
         weightedBackendServices:
           - backendService: projects/PROJECT_ID/global/backendServices/green-service
             weight: 95
           - backendService: projects/PROJECT_ID/global/backendServices/blue-service
             weight: 5
   

3. gcloud compute url-maps import 명령어를 사용하여 URL 맵을 업데이트합니다.

   gcloud compute url-maps import global-lb-map \
      --global \
      --source=global-lb-map-config.yaml
   

구성 테스트

구성을 테스트하려면 먼저 앞에서 설정한 부하 분산기의 IP 주소에 대한 요청이 기본 red 구성에서 처리되는지 확인해야 합니다.

그런 다음 FORWARDING_RULE_IP_ADDRESS/prefix로 전송된 요청이 예상대로 분할되는지 확인합니다.

HTTP_COOKIE를 기준으로 세션 어피니티 설정

트래픽 제어를 사용하면 제공된 쿠키를 기준으로 세션 어피니티를 구성할 수 있습니다. red-service라는 백엔드 서비스에 HTTP_COOKIE 기반 세션 어피니티를 구성하려면 다음 지침을 따르세요.

1. gcloud compute backend_services export 명령어를 사용하여 백엔드 서비스 구성을 가져옵니다.

   gcloud compute backend-services export red-service \
       --destination=red-service-config.yaml \
       --global
   

2. 다음과 같이 red-service-config.yaml 파일을 업데이트합니다.

   sessionAffinity: 'HTTP_COOKIE'
   localityLbPolicy: 'RING_HASH'
   consistentHash:
    httpCookie:
     name: 'http_cookie'
     path: '/cookie_path'
     ttl:
       seconds: 100
       nanos: 0
    minimumRingSize: 10000
   

3. red-service-config.yaml 파일에서 다음 줄을 삭제합니다.

   sessionAffinity: NONE
   

4. 백엔드 서비스 구성 파일을 업데이트합니다.

   gcloud compute backend-services import red-service \
       --source=red-service-config.yaml \
       --global
   

문제 해결

구성된 라우팅 규칙 및 트래픽 정책에 따라 트래픽이 라우팅되지 않으면 이 정보를 사용하여 문제를 해결합니다.

로깅 및 모니터링에 대한 자세한 내용은 외부 HTTP(S) 로깅 및 모니터링을 참조하세요.

증상

• 문제가 되는 규칙보다 상위 규칙의 서비스로 전송되는 트래픽이 증가했습니다.
• 특정 라우팅 규칙에 대한 4xx 및 5xx HTTP 응답 횟수가 예기치 않게 증가했습니다.

해결책: 라우팅 규칙의 순서를 확인합니다. 라우팅 규칙은 지정된 순서대로 평가됩니다.

URL 맵 내 라우팅 규칙은 지정된 순서에 따라 평가됩니다. 이 방법은 경로 규칙이 가장 긴 프리픽스 일치 항목을 기준으로 평가되는 방식과 다릅니다. 경로 규칙의 경우 전역 외부 애플리케이션 부하 분산기는 단일 경로 규칙만 선택합니다. 하지만 라우팅 규칙을 사용하면 둘 이상이 적용될 수 있습니다.

라우팅 규칙을 정의하는 경우 원래는 후속 라우팅 규칙에 따라 라우팅되어야 하는 트래픽이 목록의 상단에 있는 규칙에 따라 의도치 않게 라우팅되지 않는지 확인해야 합니다. 잘못 전송된 트래픽을 수신하는 서비스는 요청을 거부하므로 라우팅 규칙의 서비스에 수신되는 트래픽 양이 줄어들거나 전혀 수신되지 않을 수 있습니다.

다음 단계

• 부하 분산기 설정 삭제