ルートルールとトラフィック ポリシーを使用したトラフィック管理

Traffic Director をフルマネージド Envoy とともに利用する場合と同じテクノロジーにより、ルートルールやトラフィック ポリシーを使用してトラフィックを制御できます。内部 HTTP(S) 負荷分散では、Envoy の高度なトラフィック制御機能が、使い慣れた GCP の負荷分散コンポーネント(URL マップバックエンド サービスなど)を使用して提供されます。

ルートルールでは、受信したリクエストの中から一致するものを見つけて、その一致に基づいてルーティングが決定されます。GCP では、リクエストと一致する最初のルートルールが見つかったらその後のルールは検索されません。その次には、ルートルールのアクションが適用されます。ルートルールは、パスマッチャーやパスルールの代替として使用されます。

トラフィックのルーティングの後、トラフィック ポリシーにより次のようにトラフィックが管理されます。

  • ロードバランサの設定によって、負荷分散アルゴリズムが制御される。
  • 接続プールの設定によって、アップストリーム サービスへの接続量が制御される。
  • 外れ値検出によって、負荷分散プールから正常でないホストの追い出しが制御される。

ユースケースの例

ルートルールとトラフィック ポリシーを使用すると、トラフィックの分割トラフィック ステアリングフォールト インジェクション回路遮断、およびミラーリングが実装できます。

トラフィック分割では、ルートルールに複数のバックエンド サービスを指定できます。各バックエンド サービスには、ルートルールに一致するリクエストの割合を指定します。たとえば、トラフィックの 95% を 1 つのサービス インスタンスに、5% を別のサービス インスタンスにそれぞれ送信できます。トラフィック分割は通常、新しいバージョンのデプロイ、A/B テスト、サービス移行などのプロセスに使用されます。

Google Cloud Load Balancing のトラフィック分割(クリックして拡大)
Google Cloud Load Balancing のトラフィック分割(クリックして拡大)

トラフィック ステアリングでは、HTTP リクエスト ヘッダーの内容に基づいてサービス インスタンスにトラフィックが転送されます。たとえば、ユーザーのデバイスが user-agent:Android をリクエスト ヘッダーに持つ Android デバイスの場合、トラフィック ステアリングでは、Android トラフィックを受信するよう指定されたサービス インスタンスにそのトラフィックが送信され、その他のデバイスを処理するインスタンスには user-agent:Android を含まないトラフィックが送信されます。

Google Cloud Load Balancing のトラフィック ステアリング(クリックして拡大)
Google Cloud Load Balancing のトラフィック ステアリング(クリックして拡大)

フォールト インジェクションを使用すると、遅延ないしは中止されたリクエストなどのサービス障害シナリオをシミュレートしてサービスの復元力をテストできます。フォールト インジェクションでは、リクエストの一部を意図的に遅延させて、選択したバックエンド サービスにリクエストが送信されます。中断インジェクションでは、障害のレスポンス コードを含むリクエストは、バックエンド サービスに転送するのではなく、それらのリクエストの一部に直接応答するようにプロキシを構成します。

回路遮断では、特定のサービスが構成可能な回数だけ連続してそのサービスに到達できなかった場合にそのサービスに対するすべてのリクエストに制限が適用されます。

ミラーリングを使用すると、ルートルールで一致したリクエストのコピーを 2 番目のバックエンド サービスに送信できます。プロキシは、2 番目のバックエンド サービスからのレスポンスを待機するのではなく、2 番目のバックエンド サービスからのレスポンスを破棄します。ミラーリングは、バックエンド サービスの新しいバージョンをテストする際に利用できます。また、本番環境バージョンではなくバックエンド サービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。

ルートルールについて

ルートルールは、HTTP リクエストとの一致を調べる複数の方法を提供し、複数のバックエンド サービス間のトラフィック分割やリダイレクト、リクエストやレスポンスの変更などのさまざまなアクションを実行します。ルートルールは順番に実行され、URL マップのルールのマッチングに柔軟性を提供します。最初の一致が見つかると、内部 HTTP(S) 負荷分散によるルールの評価が停止し残りのルールはすべて無視されます。

  • マッチング ルールでは、内部 HTTP(S) 負荷分散が 1 つ以上のリクエストの属性との一致を検索し、ルートルールで指定されたアクションを実行します。リクエストの次の属性を使用して、一致条件を指定できます。

    • Host: ホスト名は URL のドメイン名部分です。たとえば、URL http://example.net/video/hd のうちホスト名の部分は example.net です。リクエストのホスト名は、たとえば次の curl コマンドを実行して Host ヘッダーから得られます。
    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    

    ここで、10.1.2.9 は負荷分散された IP アドレスです。

    • パスはホスト名から始まります。たとえば、/images です。このルールは、パス全体またはパスの先頭部分のみの一致を照合できます。

    • Cookie のマッチングを可能にする HTTP ヘッダーなどの HTTP リクエスト パラメータ、およびクエリ パラメータに基づくマッチング(GET 変数)。

  • ルート アクションにより、ルートルールがリクエストの属性と一致したときに実行される特定のアクションを含む内部 HTTP(S) 負荷分散が構成されます。次のような高度なルート アクションを使用できます。

    • リダイレクト: 内部 HTTP(S) 負荷分散によって、構成可能な 3xx レスポンス コードが返されます。Location レスポンス ヘッダーに適切な URI を設定すると、リダイレクト アクションで指定されたホストとパスが置き換わります。

    • URL の書き換え: 内部 HTTP(S) 負荷分散によって、URL のホスト名部分、URL のパス部分、またはその両方を書き換えてから、選択したバックエンド サービスにリクエストが送信されます。

    • ヘッダー変換: 内部 HTTP(S) 負荷分散によって、バックエンド サービスにリクエストを送信する前にリクエスト ヘッダーを追加または削除できます。また、バックエンド サービスからレスポンスを受信した後に、レスポンス ヘッダーを追加または削除することもできます。

    • トラフィックのミラーリング: 選択されたバックエンド サービスにリクエストを転送するだけでなく、内部 HTTP(S) 負荷分散によって、構成されたミラー バックエンド サービスに「ファイア アンド フォーゲット方式」で同じリクエストを送信します。ミラーリングは、バックエンド サービスの新しいバージョンをテストする際に利用できます。また、本番環境バージョンではなくバックエンド サービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。

    • 重み付けトラフィック分割は、個々のバックエンド サービスに割り当てられたユーザーが定義した重みに応じて、一致したルールのトラフィックを複数のバックエンド サービスに分散させる構成です。この機能は、段階的なデプロイや A/B テストの構成に利用できます。たとえば、99% のトラフィックが安定したバージョンのアプリケーションに送信され、1% のトラフィックが新しいバージョンの別のサービスに送信されるように構成できます。

  • 再試行するには、ロードバランサが失敗したリクエストを再試行する条件、再試行までのロードバランサの待機時間、再試行の最大回数を設定します。

  • フォールト インジェクション: 内部 HTTP(S) 負荷分散では、高レイテンシ、サービス過負荷、サービス障害、ネットワーク パーティショニングなどの障害をシミュレートするリクエストを処理する際に意図的にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。

  • 遅延インジェクションでは、リクエストのユーザー定義部分に遅延が発生し、選択したバックエンド サービスにリクエストが送信されます。

  • 中断インジェクションでは、ユーザー定義の HTTP ステータス コードを含むリクエストは、バックエンド サービスに転送するのではなく、それらのリクエストの一部に直接応答するようにプロキシを構成します。

  • セキュリティ ポリシー: Cross-Origin Resource Sharing(CORS)ポリシーは CORS リクエストを適用するための内部 HTTP(S) 負荷分散設定を処理します。

トラフィック ポリシーについて

トラフィック ポリシーは、障害が発生しているバックエンド サービスへの応答などの負荷分散の振る舞いや、局所的な障害がその他のサービス メッシュに影響を与えないようにする方法を定義するグループ化された設定です。バックエンド サービスでは、次のトラフィック ポリシー機能が構成されます。

  • 負荷分散ポリシー: 内部 HTTP(S) 負荷分散は使用可能な容量に基づいて負荷分散を実行し、プロキシが NEG 内のバックエンド VM またはエンドポイントの特定の GCP ゾーンを選択するために、Envoy ドキュメントの説明どおりに地域区分のレベルを設定します(GCP ゾーンごとに)。バックエンド サービスで指定された負荷分散ポリシーによって、重み付けされた地域区分が選択された後に、その地域区分内の NEG のバックエンド VM やエンドポイントの選択に使用されるアルゴリズムが決定されます。負荷分散アルゴリズムには、リクエストが最も少ない NEG のラウンドロビン、リングハッシュ、バックエンド VM、エンドポイントなどが含まれます。内部 HTTP(S) 負荷分散では、URL マップとバックエンド サービスを使用して負荷分散が行われます。

  • セッション アフィニティ: 内部 HTTP(S) 負荷分散では、HTTP Cookie ベースのアフィニティ、HTTP ヘッダーベースのアフィニティ、クライアント IP アドレスのアフィニティ、生成された Cookie アフィニティといったオプションが提供されます。routeAction に複数の weightedBackendServices が含まれている場合、アフィニティ設定が適用されないことに注意してください。セッション アフィニティの詳細については、セッション アフィニティをご覧ください。

  • 外れ値検出は、NEG の正常でないバックエンド VM またはエンドポイントのエビクションの基準、およびバックエンドまたはエンドポイントがトラフィックを再度受信するのに十分に正常だと考えられるのはいつであるかを定義する基準を指定するためのポリシーのセットです。

  • 回路遮断は、バックエンド サービスへの接続量と接続あたりのリクエスト数の上限が設定されます。

トラフィック制御データモデル

既存の GCP リソースは、高度なルートポリシーやトラフィック ポリシーなどの機能の実装に使用されます。次の図は、各機能の実装に使用されるリソースを示しています。

Google Cloud Load Balancing のトラフィック ステアリング(クリックして拡大)
Google Cloud Load Balancing のデータモデル(クリックして拡大)

URL マッピング リソース

URL マッピング コンポーネントは、パスマッチングの高度なルーティング機能をサポートするように拡張されています。パス接頭辞、フルパス、HTTP ヘッダー、クエリ パラメータに基づいてリクエストの一致を調べることができます。接頭辞とフルパスは、パス部分の一致に適用されます。詳しくは、Envoy プロキシ ルートマッチのドキュメントをご覧ください。

  • パスマッチング: 内部 HTTP(S) 負荷分散では、URL マップのパスマッチャーのコンセプトが拡張されています。GCP HTTP(S) ロードバランサの場合と同様にシンプルなパスルールを引き続き使用することも、代わりに、ルートルールを使用することもできます。2 種類のルールは別々に使用します。1 つの URL マップに含めることができるのは 1 つだけです。パスルールは最長一致法で評価されます。ルールの適用順序は任意に指定できます。ルートルールは順番に解釈されます。これにより、複雑なルート基準を柔軟に定義できます。

    • ルートルール(HttpRouteRule): 内部 HTTP(S) 負荷分散では、ルートルールが指定された順序で評価されます。これにより、複雑なルーティング基準を定義できます。ルートルールのコンポーネントは次のとおりです。

      • ルートルール マッチング(HttpRouteRuleMatch): ルートルールをリクエストに適用するかどうかを指定します。パスルール、HTTP ヘッダー、クエリ(GET)パラメータのすべてまたは一部の一致を調べます。

        ルールのアクションを有効にするには、HttpRouteRuleMatch 内で一致条件をすべて満たす必要があります。ルールの HttpRouteRuleMatch が複数である場合、リクエストが HttpRouteRuleMatch のいずれかと一致するとルールのアクションが有効になります。

      • ルート アクション(HttpRouteAction): HttpRouteRuleMatch 内の条件が満たされたときに内部 HTTP(S) 負荷分散が実行するアクションを指定できます。トラフィック分割、URL 書き換え、再試行とミラーリング、フォールト インジェクション、CORS ポリシーなどがあります。

      • リダイレクト アクション(HttpRedirectAction): HttpRouteRuleMatch 内の条件が満たされたときに HTTP リダイレクトで応答するよう内部 HTTP(S) 負荷分散を構成できます。

      • ヘッダー アクション(HttpHeaderAction): HttpRouteRuleMatch 内の条件が満たされたときに実行されるリクエストとリスポンスのヘッダー変換ルールを構成できます。

    • パスルール(PathRule): 内部 HTTP(S) 負荷分散は、既存の URL マッピングとの互換性を保つためにパスマッチングのパスルール オブジェクトをサポートします。パスルールは任意の順序で入力できます。内部 HTTP(S) 負荷分散では、最長一致法でパスマッチング中のすべてのパスルールから各パスへのリクエストのパスの一致が調べられます。パスが一致した場合、トラフィックは対応するパスルールのバックエンド サービスに転送されます。

高度なルート機能の URL マップ階層は次のとおりです。

  • デフォルトのバックエンド サービス
  • 内部 HTTP(S) 負荷分散のみ: デフォルトのルート アクション
  • 内部 HTTP(S) 負荷分散のみ: デフォルトのリダイレクト
  • 内部 HTTP(S) 負荷分散のみ: ヘッダー アクション
  • ホストルールのリスト
  • パスマッチャーのリスト。各パスマッチャーには以下が含まれます。
    • 内部 HTTP(S) 負荷分散のみ: デフォルトのルート アクション
    • 内部 HTTP(S) 負荷分散のみ: デフォルトのリダイレクト
    • 内部 HTTP(S) 負荷分散のみ: ヘッダー アクション
    • パスマッチングのデフォルトのバックエンド サービス
    • パスルールのリスト
    • 内部 HTTP(S) 負荷分散のみ: ルートルールのリスト
      • 内部 HTTP(S) 負荷分散のみ: マッチング ルールのリスト
      • 内部 HTTP(S) 負荷分散のみ: バックエンド サービス
      • 内部 HTTP(S) 負荷分散のみ: ルート アクション
      • 内部 HTTP(S) 負荷分散のみ: リダイレクト
      • 内部 HTTP(S) 負荷分散のみ: ヘッダー アクション

バックエンド サービス リソース

内部 HTTP(S) 負荷分散は、負荷分散スキームが INTERNAL_MANAGED であるバックエンド サービスを使用します。このスキームのバックエンド サービスは、大量のトラフィック ポリシーを実装する設定をサポートします。内部マネージド バックエンド サービスに指定できる属性は次のとおりです。

  • 負荷分散ポリシー(LocalityLoadBalancingPolicy): 内部マネージド バックエンド サービスの場合、トラフィック分散では負荷分散モード負荷分散ポリシーが使用されます。バックエンド サービスは、最初にバックエンド グループ(インスタンス グループ、マネージド インスタンス グループ、ネットワーク エンドポイント グループ)にトラフィックを転送します。バックエンド グループが選択されると、ロードバランサによって負荷分散ポリシーに従ってトラフィックが分散されます。負荷分散モードでは、内部 HTTP(S) 負荷分散によりローカルの負荷分散が最初に選択されます(GCP ゾーンなど)。NEG 内の特定のバックエンド VM またはエンドポイントを選択する場合は負荷分散ポリシーが使用されます。

  • セッション アフィニティ(SessionAffinity): 内部マネージド バックエンド サービスは、クライアント IP アドレス、HTTP Cookie ベース、HTTP ヘッダーベース、生成された Cookie アフィニティの 4 つのセッション アフィニティをサポートします。

  • コンシステント ハッシュ(ConsistentHashLoadBalancerSettings)では、内部 HTTP(S) 負荷分散の Cookie とヘッダーからコンシステント ハッシュの作成基準を定義して、新しいリクエストを NEG 内の同じバックエンド VM やエンドポイントに一貫して転送します。

  • 回路遮断(CircuitBreakers)では、バックエンド サービスの特定のバックエンド VM またはエンドポイントへのトラフィック量を制限するパラメータを定義します。これにより、効果的な方法で処理できないリクエストによってサービスが過負荷になるのを防ぐことができます。

  • 外れ値検出(OutlierDetection)では、NEG のバックエンド VM またはエンドポイントが正常でないとみなされて負荷分散の考慮から除外される条件を定義します。バックエンド サービスにリンクされたヘルスチェックによって NEG のバックエンド VM またはエンドポイントが正常でないとマークされた場合、そのバックエンド VM またはエンドポイントは正常ではないとみなされます。

トラフィック制御の構成

次のセクションでは、トラフィック制御の構成について説明します。

トラフィック制御を構成する前に

HTTP(S) 負荷分散の設定の準備の手順に沿って、必要な VM ホストまたは GKE クラスタを設定します。また、必要な GCP リソースを作成します。

トラフィック分割の設定

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

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

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

  3. 95% / 5% のカナリア処理を設定するルーティング ルールを作成します。

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

サービスの定義

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

ここでは、HTTP ヘルスチェック(l7-ilb-basic-check)が作成されていることが前提です。Compute Engine VM に対する内部 HTTP(S) 負荷分散の設定の手順をご覧ください。

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=l7-ilb-tag,http-server \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  sudo apt-get update
  sudo apt-get install apache2 -y
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee $www_dir/index.html
  sudo service apache2 restart
  "; \
  gcloud beta compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud beta compute backend-services create "${name}-service" \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud beta compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

サービスの作成

この関数を呼び出して、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 マップファイルの作成

URL マップファイル canary.yaml を、目的のカナリア設定とともに書き込みます。

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

  • リージョンは us-west1 である。
  • 内部 HTTP(S) 負荷分散のデプロイメントには、l7-ilb-map という URL マップが含まれる。
  • ターゲット プロキシと転送ルールが作成されている。
  • 転送ルールのアドレスは 10.1.2.9 である。

    Compute Engine VM の内部 HTTP(S) 負荷分散の設定の手順をご覧ください。

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

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

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

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

ここでは、project-id を GCP プロジェクト ID に置き換えてください。

defaultService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/red-service
hostRules:
- description: ''
  hosts:
  - '*'
  pathMatcher: matcher1
kind: compute#urlMap
name: l7-ilb-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /prefix
    routeAction:
      weightedBackendServices:
      - backendService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/green-service
        weight: 95
      - backendService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/blue-service
        weight: 5
region: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1
selfLink: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/urlMaps/l7-ilb-map

URL マップのインポート

gcloud beta compute url-maps import l7-ilb-map \
    --region=us-west1 \
    --source=canary.yaml

構成のテスト

カナリーの構成をテストするには、最初に 10.1.2.9/(前に設定されたロードバランサの IP アドレス)へのリクエストがデフォルトの red 構成によって処理されることを確認します。

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

クライアント VM の作成

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

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

クライアントで SSH を起動して次のコマンドを実行します。

for LB_IP in 10.1.2.9; 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 10.1.2.9:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

10.1.2.9/prefix にリクエストを送信する

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

for LB_IP in 10.1.2.9; 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 10.1.2.9/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 のサービスにそれぞれ正しく送信されています。

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

HTTP_COOKIE を使用してセッション アフィニティを構成するには、次の手順を行います。

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

    gcloud beta 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: 30
     minimumRingSize: 10000
    
  3. red-service-config.yaml ファイルの次の行を削除します。

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

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

トラブルシューティング

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

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

症状:

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

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

URL マップ内のルートルールは、指定された順序で解釈されます。これは、パスルールが解釈される方法(最長一致法)とは異なります。パスルールの場合は、内部 HTTP(S) 負荷分散で単一パスルールのみが選択されます。しかし、ルートルールを使用する場合は、複数のルートルールが適用される可能性があります。

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

制限事項

  • UrlMap.defaultRouteActionUrlMap.defaultUrlRedirect は現在、意図したとおりに動作しません。UrlMapUrlMap.hostRules[] にあるホストのいずれにも一致しないトラフィックの処理に関して UrlMap.defaultService を定義してください。同様に UrlMap.pathMatchers[].defaultRouteActionUrlMap.pathMatchers[].defaultUrlRedirect は現在、意図したとおりに動作しません。pathMatcherrouteRules のいずれにも一致しないトラフィックの処理に関して UrlMap.pathMatchers[].defaultService を定義してください。
  • RouteRule.service.は現在、意図したとおりに動作しません。この問題を回避するには、RouteRule.weightedBackendServices に 1 つの WeightedBackendService を指定します。
  • gcloud import コマンドを実行しても、バックエンド サービスや URL マップなどのリソースの最上位フィールドは削除されません。たとえば、circuitBreakers を設定してバックエンド サービスを作成した場合、後続の gcloud import コマンドでバックエンド サービスを更新できます。しかし、これらの設定をバックエンド サービスから削除することはできません。一方、リソースは circuitBreakers を設定しなくても削除および再作成できます。
  • gcloud export コマンドを実行すると、int64 フィールドが整数ではなく文字列としてエクスポート ファイルにエクスポートされます。エクスポートされたファイルをインポートするには、手動で引用符を削除してください。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...