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

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

このドキュメントでは、グローバル外部アプリケーション ロードバランサの例を示します。グローバル外部アプリケーション ロードバランサは、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

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

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

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

   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

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

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

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

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

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

  4. 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)
}

サービスを作成する

この関数を呼び出して、redgreenblue という 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

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

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

  1. [ルーティング ルール] で [詳細なホスト、パス、ルートのルール] を選択します。
  2. [新しいホストとパスのマッチャー] で [サービス] を red-service に設定してデフォルトのアクションを作成します。
  3. [完了] をクリックします。
  4. [Add hosts and path matcher] をクリックします。
  5. [ホスト] フィールドに、ロードバランサの転送ルールの IP アドレスを入力します。
  6. 次の 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
    
  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. これをファイルの末尾に追加して、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
    
  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 に送信されたリクエストが想定どおりに分割されることを確認します。

トラフィック制御では、提供された 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 マップ内のルートルールは、指定された順序で解釈されます。これは、パスルールが解釈される方法(最長一致法)とは異なります。パスルールの場合、グローバル外部アプリケーション ロードバランサは単一のパスルールのみを選択します。ただし、ルートルールを使用する場合は、複数のルールが適用される場合があります。

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

次のステップ