内部アプリケーション ロードバランサのトラフィック管理を設定する

このドキュメントで説明するトラフィック管理の使用例は、特定のユースケースのものです。他にもさまざまなユースケースが考えられます。

このドキュメントでは、次のロードバランサの例を示します。

• リージョン外部アプリケーション ロードバランサ
• リージョン内部アプリケーション ロードバランサ
• クロスリージョン内部アプリケーション ロードバランサ

リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサリージョン ロードバランサのトラフィック管理構成については、リージョン URL マップ API とリージョン バックエンド サービス API のドキュメントをご覧ください。フィールドの完全なリストや、関係、制限、カーディナリティに関するセマンティクスを確認できます。

2 つのロードバランサの違いはロード バランシングのスキームだけです。

• リージョン外部アプリケーション ロードバランサは EXTERNAL_MANAGED を使用します。
• リージョン内部のアプリケーション ロードバランサでは、INTERNAL_MANAGED を使用します。

リージョン内部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサトラフィック管理の構成:

• リージョン内部アプリケーション ロードバランサは、リージョン URL マップ API を使用します。リージョン バックエンド サービス API のドキュメントには、フィールドの完全なリストと、関係、制限、カーディナリティに関するセマンティクスなどが記載されています。

• クロスリージョン内部アプリケーション ロードバランサはグローバル URL マップ API を使用します。グローバル バックエンド サービス API のドキュメントにはフィールドの完全なリストと、関係、制限、カーディナリティに関するセマンティクスが記載されています。

注: クロスリージョン内部アプリケーション ロードバランサについては、regions/REGION/backendServices を global/backendServices に置き換えることで、このドキュメントで説明している例を使用できます。

このページで説明する高度なルーティング機能に加えて、サポートされているアプリケーション ロードバランサは Service Extensions と統合されているため、ロード バランシング データパスにカスタム ロジックを挿入できます。

始める前に

• トラフィック管理の仕組みについて理解する必要があります。詳細については、トラフィック管理のコンセプトをご覧ください。

• 内部アプリケーション ロードバランサの設定の手順に沿って、必要な VM ホストまたは GKE クラスタを構成します。

• ロードバランサの構成の説明に従って、必要なヘルスチェックを作成するか、既存のヘルスチェックを再使用します。

トラフィック管理の構成

選択した構成環境で、YAML 構成を使用してトラフィック管理を設定します。URL マップとバックエンド サービスにはそれぞれ独自の YAML ファイルがあります。必要な機能に応じて、URL マップの YAML、バックエンド サービスの YAML、またはその両方を記述する必要があります。

これらの YAML ファイルの作成方法については、このページの例と Cloud Load Balancing API ドキュメントをご覧ください。

リージョン内部アプリケーション ロードバランサの場合は、Google Cloud コンソールを使用してトラフィック管理を構成することもできます。

リージョン内部のアプリケーション ロードバランサとリージョン外部のアプリケーション ロードバランサについては、リージョン URL マップ API と リージョン バックエンド サービス API のドキュメントに、関係、制限、カーディナリティに関するセマンティクスなどを含む、フィールドの全リストも確認できます。

Google Cloud コンソールで YAML のサンプルにアクセスする

Google Cloud コンソールで YAML のサンプルにアクセスするには:

1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

   [ロード バランシング] に移動

2. [ロードバランサを作成] をクリックします。
3. ウィザードの指示に従って、リージョン内部アプリケーション ロードバランサを作成します。
4. ルーティング ルールの構成で、[詳細なホスト、パス、ルートのルール] を選択します。
5. [Add hosts and path matcher] をクリックします。
6. [コード ガイダンス] のリンクをクリックします。

[パスマッチャーの YAML の例] ページが表示されます。

1 つのサービスへのトラフィックのマッピング

すべてのトラフィックを 1 つのサービスに送信します。プレースホルダを置き換えてください。

    defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

2 つのサービス間でのトラフィックの分割

2 つ以上のサービス間でトラフィックを分割します。プレースホルダを置き換えてください。

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

URL のリダイレクトの構成

次のサンプルでは、構成可能な 3xx レスポンス コードが返されます。また、このサンプルでは、Location レスポンス ヘッダーに適切な URI を設定し、リダイレクト アクションで指定されたホストとパスを置き換えます。

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: URL_MAP_NAME
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/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

トラフィックのミラーリング

選択されたバックエンド サービスにリクエストを転送するだけでなく、構成されたミラー バックエンド サービスに「ファイア アンド フォーゲット」方式で同じリクエストを送信します。つまり、ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待ちません。リクエスト ミラーリングは、バックエンド サービスの新しいバージョンをテストする際に利用できます。また、本番環境バージョンではなくバックエンド サービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。

デフォルトでは、元のトラフィックが複数の重み付けされたバックエンド サービス間で分割されている場合でも、ミラーリングされたバックエンド サービスはすべてのリクエストを受信します。オプションの mirrorPercent フラグを使用して、ミラーリングされるリクエストの割合を 0 ～ 100.0 の値で指定することで、リクエストの割合のみを受信するようにミラーリングされたバックエンド サービスを構成できます。割合ベースのリクエスト ミラーリングはプレビュー版です。

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

トラフィック ミラーリングを使用する場合は、次の制限事項に注意してください。

• トラフィック ミラーリングは、両方のバックエンド サービスにマネージド インスタンス グループ、ゾーン NEG、またはハイブリッド NEG のバックエンドがある場合にサポートされます。インターネット NEG、サーバーレス NEG、Private Service Connect のバックエンドではサポートされていません。
• ミラーリングされたバックエンド サービスへのリクエストでは、Cloud Logging と Cloud Monitoring のログや指標は生成されません。

リクエストされた URL の書き換え

選択したバックエンド サービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。プレースホルダを置き換えてください。

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/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/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

ルート タイムアウトの指定

選択したルートのタイムアウトを指定します。リクエストが完全に処理されてからレスポンスが完全に処理されるまでのタイムアウトが計算されます。タイムアウトにはすべての再試行が含まれます。プレースホルダを置き換えてください。

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

フォールト インジェクションの構成

高レイテンシ、サービス過負荷、サービス障害、ネットワーク パーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。

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

CORS の構成

クロスオリジン リソース シェアリング（CORS）ポリシーを構成して、CORS リクエストを適用するための設定を処理します。

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

リクエスト ヘッダーとレスポンス ヘッダーの追加と削除

バックエンド サービスにリクエストを送信する前にリクエスト ヘッダーを追加および削除します。また、バックエンド サービスからレスポンスを受信した後に、レスポンス ヘッダーを追加および削除することもできます。

リージョン外部アプリケーション ロードバランサと内部アプリケーション ロードバランサは、カスタム ヘッダーでの変数の使用もサポートしています。カスタム ヘッダー値（headerValue）フィールドに 1 つ以上の変数を指定すると、変数が対応するリクエストごとの値に変換されます。サポートされているヘッダー値の一覧については、URL マップでカスタム ヘッダーを作成するをご覧ください。

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
               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: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/regions/REGION/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
    region: region/REGION

サーキット ブレーカーの構成

クライアント リクエストでバックエンドが過負荷にならないように、回路遮断で障害しきい値を設定できます。リクエストが設定したしきい値に達すると、ロードバランサは新しい接続や追加のリクエストの送信の許可を停止し、バックエンドの復旧のための時間を確保します。そのため、バックエンドで過負荷を発生させずにエラーをクライアントに返すことで、カスケード障害を回避できます。これにより、自動スケーリングによって容量を増やしてトラフィックの急増に対応するなど、過負荷状態を管理する時間を確保しつつ、一部のトラフィックを処理できます。

接続あたりのリクエスト数と、バックエンド サービスへの接続量に上限を設定します。また、保留中のリクエストと再試行の数も制限します。

    loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
    localityLbPolicy: RANDOM
    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: region/REGION/instanceGroups/INSTANCE_GROUP
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 0
    healthChecks:
    - region/REGION/healthChecks/HEALTH_CHECK

トラフィック分割の設定: 詳細な手順

この例では次の手順を説明します。

1. サービスごとに異なるテンプレートを作成します。

2. テンプレートのインスタンス グループを作成します。

3. 95% / 5% のトラフィック分割を設定するルーティング ルールを作成します。

4. curl コマンドを送信すると、構成とほぼ一致するトラフィック分割率が表示されます。

ここでは、次のことを想定しています。

• リージョンは us-west1 である。

• regional-lb-map という URL マップとともに、ターゲット プロキシと転送ルールが作成される。

• URL マップによって、すべてのトラフィックがデフォルトのバックエンド サービスである red-service というバックエンド サービスに送信される。

• トラフィックの 5% を blue-service、95% を green-service に送信する代替パスを設定している。

• パスマッチャーが使用されている。

• Cloud Shell（または bash がインストールされているその他の環境）を使用している。

サービスを定義する

次の bash 関数によって、インスタンス テンプレートとマネージド インスタンス グループを含むバックエンド サービスが作成されます。

ここでは、HTTP ヘルスチェック（regional-lb-basic-check）が作成されていることが前提です。手順については、内部アプリケーション ロードバランサを設定するをご覧ください。

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-10 \
    --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=LOAD_BALANCING_SCHEME\
    --protocol=HTTP \
    --health-checks=regional-lb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

サービスを作成する

この関数を呼び出して、red、green、blue という 3 つのサービスを作成します。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 マップの作成

gcloud

1. gcloud compute url-maps export コマンドを使用して、既存の URL マップをエクスポートします。

   gcloud compute url-maps export regional-lb-map \
     --destination=regional-lb-map-config.yaml \
     --region=us-west1
   

2. これをファイルの末尾に追加して、URL マップファイル regional-lb-map-config.yaml を更新します。

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

3. gcloud compute url-maps import コマンドを使用して、URL マップを更新します。

   gcloud compute url-maps import regional-lb-map \
      --region=us-west1 \
      --source=regional-lb-map-config.yaml
   

構成のテスト

構成をテストするには、まず、以前に設定したロードバランサの IP アドレスへのリクエストがデフォルトの red 構成で処理されることを確認します。

次に、FORWARDING_RULE_IP_ADDRESS/PREFIX に送信されたリクエストが想定どおりに分割されることを確認します。

クライアント VM を作成する

手順については、ゾーンで VM インスタンスを作成して接続をテストするをご覧ください。

FORWARDING_RULE_IP_ADDRESS にリクエストを送信する

1. ssh を使用してクライアントに接続します。

   gcloud compute ssh global-lb-client-us-west1-a \
      --zone=us-west1-a
   

2. 次のコマンドを実行します。

   for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
      RESULTS=
      for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
      IFS=':'
      echo "***"
      echo "*** Results of load balancing to $LB_IP: "
      echo "***"
      for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
      echo
   done
   

結果を確認する

***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

FORWARDING_RULE_IP_ADDRESS/PREFIX にリクエストを送信する

FORWARDING_RULE_IP_ADDRESS/PREFIX にリクエストを送信して、トラフィック分割を確認します。

for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/PREFIX: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done

結果を確認する

***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

このカナリアの設定では、/PREFIX リクエストの 95% が green のサービスに、5% が blue のサービスにそれぞれ正しく送信されています。

HTTP_COOKIE に基づいてセッション アフィニティを設定する

トラフィック制御では、提供された Cookie に基づいてセッション アフィニティを構成できます。red-service というバックエンド サービスのために HTTP_COOKIE ベースのセッション アフィニティを構成するには、次に示す手順を行ってください。

1. gcloud compute backend-services export コマンドを使用してバックエンド サービスの構成を取得します。

   gcloud compute backend-services export red-service \
       --destination=red-service-config.yaml \
       --region=us-west1
   

2. 次のように red-service-config.yaml ファイルを更新します。

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

3. red-service-config.yaml ファイルで次の行を削除します。

   sessionAffinity: NONE
   

4. このバックエンド サービス構成ファイルを更新します。

   gcloud compute backend-services import red-service \
       --source=red-service-config.yaml \
       --region=us-west1
   

トラブルシューティング

構成したルートルールとトラフィック ポリシーに従ってトラフィックがルーティングされない場合は、次に示す情報を使用してトラブルシューティングを行ってください。

ロギングとモニタリングについては、内部 HTTP(S) のロギングとモニタリングをご覧ください。

症状:

• ルールの上位にあるサービスへのトラフィックが増加した。
• 指定されたルートルールに対する 4xx および 5xx HTTP レスポンスが予期しない増加を示した。

解決策: ルートルールの順序を確認する。ルートルールは、指定された順序で解釈される。

URL マップ内のルートルールは、指定された順序で解釈されます。これは、パスルールが解釈される方法（最長一致法）とは異なります。パスルールの場合は、内部アプリケーション ロードバランサで単一パスルールのみが選択されます。しかし、ルートルールを使用する場合は、複数のルートルールが適用される可能性があります。

ルートルールを定義するときは、リストの先頭のルールによって、後続のルートルールがルーティングするトラフィックが誤ってルーティングされないように注意します。誤って転送されたトラフィックをサービスが受信するとリクエストが拒否されるため、ルートルールのトラフィックが受信するトラフィックが減少するかまったく受信しなくなります。

次のステップ

• ロードバランサの設定をクリーンアップする。