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

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

このドキュメントでは、グローバル外部アプリケーションロードバランサの例を示します。グローバル外部アプリケーションロードバランサは、EXTERNAL_MANAGED ロードバランシングスキームとグローバルロードバランシングコンポーネント（転送ルール、URL マップ、バックエンドサービスなど）を使用します。

従来のアプリケーションロードバランサを使用したトラフィック管理については、従来のアプリケーションロードバランサのトラフィック管理の概要をご覧ください。

リージョン外部アプリケーションロードバランサを使用したトラフィック管理については、リージョン外部アプリケーションロードバランサのトラフィック管理の概要をご覧ください。

このページで説明する高度なルーティング機能に加えて、特定のアプリケーションロードバランサでは Service Extension との統合により、Service Extension コールアウトを構成して、ロードバランシングデータパスにカスタムロジックを挿入できます。

始める前に

トラフィック管理の仕組みについて理解する必要があります。詳細については、グローバル外部アプリケーションロードバランサのトラフィック管理の概要をご覧ください。

トラフィック管理の構成とテスト

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

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

Google Cloud コンソールはサポートされていません。

グローバル URL マップ API とグローバルバックエンドサービス API のドキュメントには、関係、制限、カーディナリティに関連するセマンティクスなど、フィールドの完全なリストが記載されています。

URL マップに構成テストを追加すると、URL マップがリクエストを正しくルーティングしているかどうか確認できます。さまざまな URL マップルールをテストし、必要な回数のテストを実行して、マップがトラフィックを適切なバックエンドサービスまたはバックエンドバケットにルーティングすることを確認できます。詳細については、URL マップにテストを追加するをご覧ください。マップを実際にデプロイせずに URL マップの新しい変更をテストする場合は、URL マップ構成を検証するをご覧ください。

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

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

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

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

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

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

URL のリダイレクトの構成

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

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         urlRedirect:
           hostRedirect: "new-host-name.com" # Omit to keep the requested host
           pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
           prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
           redirectResponseCode: FOUND
           stripQuery: True

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

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

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

トラフィックミラーリングは、以下の対象でサポートされています。

マネージドインスタンスグループ、ゾーン NEG、ハイブリッド NEG のバックエンド。インターネット NEG、サーバーレス NEG、Private Service Connect のバックエンドではサポートされていません。
本文が存在しない HTTP リクエスト。

ミラーリングは、特定の部分のリクエスト��対してのみ構成することはできません。複数の重み付けされたバックエンドサービス間でトラフィックを分割しても、ミラーバックエンドサービスはすべてのリクエストを受信します。ただし、カスタムヘッダーを使用して、元のリクエストの処理に使用されたバックエンドサービスを記録できます。次の例では、x-weighted-picked-backend というカスタムヘッダーをすべてのクライアントリクエストに追加します。ヘッダー値には、元のリクエストを処理したバックエンドサービスの名前を使用します。

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

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

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

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

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

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

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

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

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

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

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

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

headerName と headerValue には有効な値に制限があります。詳細については、カスタムヘッダーの仕組みをご覧ください。

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: 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: 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

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

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

サービスごとに異なるテンプレートを作成します。
テンプレートのインスタンスグループを作成します。
95% / 5% のトラフィック分割を設定するルーティングルールを作成します。
curl コマンドを送信すると、構成とほぼ一致するトラフィック分割率が表示されます。

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

global-lb-map という URL マップとともに、ターゲットプロキシと転送ルールが作成される。
URL マップによって、すべてのトラフィックが��フォルトのバックエンドサービスである red-service というバックエンドサービスに送信される。
トラフィックの 5% を blue-service、95% を green-service に送信する代替パスを設定している。
パスマッチャーが使用されている。
Cloud Shell（または bash がインストールされているその他の環境）を使用している。

サービスを定義する

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

ここでは、HTTP ヘルスチェック（global-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=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 という 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 マップの作成

Console

Google Cloud コンソールの [ロードバランシング] ページに移動します。
[ロードバランシング] に移動
[global-lb-map] リンクをクリックします。
[編集] をクリックします。

新しいルーティングルールの構成

[ルーティングルール] で [詳細なホスト、パス、ルートのルール] を選択します。
[新しいホストとパスのマッチャー] で [サービス] を red-service に設定してデフォルトのアクションを作成します。
[完了] をクリックします。
[Add hosts and path matcher] をクリックします。
[ホスト] フィールドに、ロードバランサの転送ルールの IP アドレスを入力します。

次の YAML コンテンツを [パスマッチャー] ボックスに貼り付けます。

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

[完了] をクリックします。
[更新] をクリックします。

gcloud

gcloud compute url-maps export コマンドを使用して、既存の URL マップをエクスポートします。
```
gcloud compute url-maps export global-lb-map \
  --destination=global-lb-map-config.yaml \
  --global
```

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

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

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` に基づいてセッションアフィニティを設定する

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

gcloud compute backend_services export コマンドを使用してバックエンドサービスの構成を取得します。
```
gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --global
```

次のように 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

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

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

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

トラブルシューティング

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

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

症状:

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

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

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

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

次のステップ

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