Envoy を使用して高度なトラフィック管理を構成する

このドキュメントでは、Envoy を使用する Traffic Director のデプロイ用に高度なトラフィック管理を構成する方法について説明します。

始める前に

高度なトラフィック管理を構成する前に、Envoy で Traffic Director を設定する準備の手順に沿って、Traffic Director と仮想マシン(VM)ホストまたは必要な Google Kubernetes Engine(GKE)クラスタを構成します。必要な Google Cloud リソースを作成します。

高度なトラフィック管理機能の可用性は、選択したリクエスト プロトコルによって異なります。このプロトコルは、ターゲット HTTP または HTTPS プロキシ、ターゲット gRPC プロキシ、またはターゲット TCP プロキシ リソースを使用してルーティングを構成するときに構成されます。

  • ターゲット HTTP プロキシとターゲット HTTPS プロキシでは、このドキュメントで説明するすべての機能を使用できます。
  • ターゲット gRPC プロキシでは、一部の機能を使用できます。
  • ターゲット TCP プロキシでは、高度なトラフィック管理機能は使用できません。

詳細については、Traffic Director の機能高度なトラフィック管理をご覧ください。エンドツーエンドの設定ガイドについては、プロキシレス gRPC サービスを使用して高度なトラフィック管理を構成するをご覧ください。

トラフィック分割を設定する

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

  • Traffic Director のデプロイに review-url-map という URL マップがあります。
  • URL マップは、デフォルトのバックエンド サービスとして機能する review1 という 1 つのバックエンド サービスにすべてのトラフィックを送信します。
  • トラフィックの 5% を新しいバージョンのサービスにルーティングする予定です。このサービスは、バックエンド サービス review2 に関連付けられたネットワーク エンドポイント グループ(NEG)のバックエンド VM またはエンドポイントで実行されます。
  • ホストルールやパスマッチャーは使用しません。

URL マップでまだ参照されていない新しいサービスにトラフィックを分割する場合は、まず新しいサービスを weightedBackendServices に追加し、それに 0 の重みを設定します。次に、そのサービスに割り当てられた重みを徐々に増やしていきます。

トラフィック分割を設定する手順は次のとおりです。

コンソール

  1. Google Cloud Console で [Traffic Director] ページに移動します。

    [Traffic Director] に移動

  2. [ルーティング ルール マップ] をクリックします。

  3. [ルーティング ルール マップを作成] をクリックします。

  4. [ルーティング ルール マップを作成] ページで、名前を入力します。

  5. [プロトコル] メニューで [HTTP] を選択します。

  6. 既存の転送ルールを選択します。

  7. [ルーティング ルール] で [詳細なホスト、パス、ルートのルール] を選択します。

  8. [ホストとパスのマッチャー] で、[Add hosts and path matcher] をクリックします。これにより、トラフィックを分割するように構成できる新しいパスマッチャーが追加されます。

  9. [パスマッチャー] フィールドに次の設定を追加します。

        - defaultService: global/backendServices/review1
          name: matcher1
          routeRules:
          - priority: 2
            matchRules:
            - prefixMatch: ''
            routeAction:
             weightedBackendServices:
             - backendService: global/backendServices/review1
               weight: 95
             - backendService: global/backendServices/review2
               weight: 5
    
  10. [完了] をクリックします。

  11. [保存] をクリックします。

新しいバージョンに問題がないことを確認したら、2 つのサービスの重みを徐々に調整し、最終的にはすべてのトラフィックを review2 に送信できます。

gcloud

  1. gcloud export コマンドを使用して、URL マップの構成を取得します。

    gcloud compute url-maps export review-url-map \
        --destination=review-url-map-config.yaml
    
  2. review-url-map-config.yaml ファイルに次のセクションを追加します。

         hostRules:
         - description: ''
          hosts:
           - '*'
         pathMatcher: matcher1
         pathMatchers:
         - defaultService: global/backendServices/review1
           name: matcher1
           routeRules:
           - priority: 2
             matchRules:
             - prefixMatch: ''
             routeAction:
              weightedBackendServices:
              - backendService: global/backendServices/review1
                weight: 95
              - backendService: global/backendServices/review2
                weight: 5
    
  3. URL マップを更新します。

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

新しいバージョンに問題がないことを確認したら、2 つのサービスの重みを徐々に調整し、最終的にはすべてのトラフィックを review2 に送信できます。

部分的なリリースを設定する

カナリア処理と呼ばれる部分的なデプロイ プロセスを使用して、本番環境サーバーにリリースする前に、新しいソフトウェア バージョンをごく少数のサーバーにリリースします。

部分的なリリースの場合、weightedBackendServices が使用されます。部分的なリリースを有効にするには、バックエンド サービスをテストまたはカナリア サービスとして指定し、重み付けをします(2 または 5 など)。これらのサーバーにのみ新しいソフトウェア バージョンをデプロイします。新しいバージョンに問題がないことを確認したら、残りのサービスにデプロイします。

  • 部分的なリリースを有効にするには、次の YAML コードサンプルを使用します。
pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_PARTIAL_URL
            weight: 2
          - backendService: BACKEND_SERVICE_URL
            weight: 98
  • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
  • BACKEND_SERVICE_PARTIAL_URL は、トラフィックの 2% を受信するバックエンド サービスの URL です。
  • BACKEND_SERVICE_URL は、トラフィックの 98% を受信するバックエンド サービスの URL です。

Blue/Green デプロイを設定する

Blue/Green デプロイは、本番環境トラフィックをサービスの新しいリリースまたは以前のリリースのロールバックに切り替えるのに必要な時間を短縮するリリースモデルです。これらのデプロイでは、本番環境で使用可能な両方のバージョンのサービスを維持し、トラフィックを一方から他方に移行します。

Blue/Green デプロイでは、weightedBackendServices を使用します。以下の YAML の例では、SERVICE_BLUE_URL へのバックエンドは現在の本番環境リリースに完全にデプロイされ、SERVICE_GREEN_URL のバックエンドは新しいリリースに完全にデプロイされます。この例の構成では、GREEN デプロイが本番環境のトラフィックの 100% を受信します。問題が見つかった場合は、2 つのデプロイの重みを逆にすることで、不具合のある GREEN リリースを元に戻し、正常な BLUE リリースを復元できます。両方のバージョンでトラフィックを受信できる体制が整っているため、いずれの場合でもトラフィックを迅速に移行できます。

  • Blue/Green デプロイを有効にするには、次の YAML コードサンプルを使用します。
pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_BLUE_URL
            weight: 0
          - backendService: BACKEND_SERVICE_GREEN_URL
            weight: 100
  • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
  • BACKEND_SERVICE_BLUE_URL は、トラフィックを受信しないバックエンド サービスの URL です。
  • BACKEND_SERVICE_GREEN_URL は、トラフィックをすべて受信するバックエンド サービスの URL です。

トラフィックのミラーリングを設定する

トラフィックのミラーリングは、新しいサービスのデバッグやテストのために 2 つの異なるバックエンド サービスにトラフィックを転送する場合に使用します。

次の例では、すべてのリクエストが SERVICE_URLMIRROR_SERVICE_URL に送信されます。クライアントには SERVICE_URL からのレスポンスのみが返されます。MIRROR_SERVICE_URL はクライアントに影響しません。

トラフィックのミラーリングを設定する手順は次のとおりです。

コンソール

  1. Google Cloud Console で [Traffic Director] ページに移動します。

    [Traffic Director] に移動

  2. [ルーティング ルール マップ] をクリックします。

  3. [ルーティング ルール マップを作成] をクリックします。

  4. [ルーティング ルール マップを作成] ページで、名前を入力します。

  5. [プロトコル] リストで [HTTP] を選択します。

  6. 既存の転送ルールを選択します。

  7. [ルーティング ルール] で [詳細なホスト、パス、ルートのルール] を選択します。

  8. [ホストとパスのマッチャー] で、[Add hosts and path matcher] をクリックします。これにより、トラフィックをミラーリングするように構成できる新しいパスマッチャーが追加されます。

  9. [パスマッチャー] フィールドに次の設定を追加します。

        - defaultService: DEFAULT_SERVICE_URL
          name: matcher1
          routeRules:
          - matchRules:
            - prefixMatch: '/'
            routeAction:
             weightedBackendServices:
             - backendService: BACKEND_SERVICE_URL
               weight: 100
             requestMirrorPolicy:
               backendService: BACKEND_SERVICE_MIRROR_URL
    
    • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
    • BACKEND_SERVICE_URL は、ミラーリングされるバックエンドの URL です。
    • BACKEND_SERVICE_MIRROR_URL は、ミラーリングするバックエンド サービスの URL です。
  10. [完了] をクリックします。

  11. [保存] をクリックします。

gcloud

  1. gcloud export コマンドを使用して、URL マップの構成を取得します。

    gcloud compute url-maps export review-url-map \
        --destination=review-url-map-config.yaml
    
  2. review-url-map-config.yaml ファイルに次のセクションを追加します。

         hostRules:
         - description: ''
          hosts:
           - '*'
         pathMatcher: matcher1
         pathMatchers:
        - defaultService: DEFAULT_SERVICE_URL
          name: matcher1
          routeRules:
          - matchRules:
            - prefixMatch: '/'
            routeAction:
             weightedBackendServices:
             - backendService: BACKEND_SERVICE_URL
               weight: 100
             requestMirrorPolicy:
               backendService: BACKEND_SERVICE_MIRROR_URL
    
    • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
    • BACKEND_SERVICE_URL は、ミラーリングされるバックエンドの URL です。
    • BACKEND_SERVICE_MIRROR_URL は、ミラーリングするバックエンド サービスの URL です。
  3. URL マップを更新します。

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

サーキット ブレーカーを設定する

クライアント リクエストでバックエンドが過負荷にならないように、サーキット ブレーカーで障害しきい値を設定できます。リクエストが設定した上限に達すると、クライアントは新しい接続の許可や追加のリクエストの送信を停止し、バックエンドの復旧のための時間を確保します。

バックエンドを過負荷状態にせずにエラーをクライアントに返すことで、カスケード障害を回避できます。これにより、自動スケーリングによって容量を増やしてトラフィックの急増に対応するなど、過負荷状態を管理する時間を確保しつつ、一部のトラフィックを処理できます。

次の例では、サーキット ブレーカーを次のように設定します。

  • 接続あたりの最大リクエスト数: 100
  • 最大接続数: 1,000
  • 最大保留リクエスト数: 200
  • 最大リクエスト数: 1,000
  • 最大再試行回数: 3

サーキット ブレーカーを設定するには、次の手順に従います。

コンソール

  1. Google Cloud Console で [Traffic Director] ページに移動します。

    [Traffic Director] に移動

  2. 更新するバックエンド サービスの名前をクリックします。

  3. [編集] をクリックします。

  4. [詳細構成] をクリックします。

  5. [サーキット ブレーカー] で [有効にする] チェックボックスをオンにします。

  6. [編集] をクリックします。

    1. [接続あたりの最大リクエスト数] に「100」と入力します。
    2. [最大接続数] に「1000」と入力します。
    3. [保留中のリクエストの最大数] に「200」と入力します。
    4. [最大リクエスト数] に「1000」と入力します。
    5. [最大再試行回数] に「3」と入力します。
  7. [保存] をクリックし、もう一度 [保存] をクリックします。

gcloud

  1. gcloud export コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME は、バックエンド サービスの名前に置き換えます。

     gcloud compute backend-services export BACKEND_SERVICE_NAME \
         --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. BACKEND_SERVICE_NAME.yaml ファイルを次のように更新します。

     affinityCookieTtlSec: 0
     backends:
     - balancingMode: UTILIZATION
       capacityScaler: 1.0
        group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
       maxUtilization: 0.8
     circuitBreakers:
       maxConnections: 1000
       maxPendingRequests: 200
       maxRequests: 1000
       maxRequestsPerConnection: 100
       maxRetries: 3
     connectionDraining:
       drainingTimeoutSec: 300
     healthChecks:
       - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     localityLbPolicy: ROUND_ROBIN
     name: BACKEND_SERVICE_NAME
     port: 80
     portName: http
     protocol: HTTP
     sessionAffinity: NONE
     timeoutSec: 30
    
  3. バックエンド サービス構成ファイルを更新します。

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

高度なトラフィック管理では、設定した Cookie に基づいてセッション アフィニティを構成できます。

HTTP_COOKIE を使用してセッション アフィニティを構成する手順は次のとおりです。

コンソール

  1. Google Cloud Console で [Traffic Director] ページに移動します。

    [Traffic Director] に移動

  2. 更新するバックエンド サービスの名前をクリックします。

  3. [編集] をクリックします。

  4. [詳細構成] をクリックします。

  5. [セッション アフィニティ] で [HTTP Cookie] を選択します。

  6. [地域による負荷分散ポリシー] で [リングハッシュ] を選択します。

    1. [HTTP Cookie 名] フィールドに「http_cookie」と入力します。
    2. [HTTP Cookie パス] フィールドに「/cookie_path」と入力します。
    3. [HTTP Cookie TTL] フィールドに「100」と入力します。
    4. [最小リングサイズ] フィールドに「10000」と入力します。
  7. [保存] をクリックします。

gcloud

  1. gcloud export コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME は、バックエンド サービスの名前に置き換えます。

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. 次のように YAML ファイルを更新します。

    sessionAffinity: 'HTTP_COOKIE'
    localityLbPolicy: 'RING_HASH'
    consistentHash:
    httpCookie:
      name: 'http_cookie'
      path: '/cookie_path'
      ttl:
        seconds: 100
        nanos: 30
    minimumRingSize: 10000
    
  3. バックエンド サービス構成ファイルをインポートします。

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

外れ値検出を設定する

外れ値検出によって、負荷分散プールから正常でないホストのエビクションが制御されます。Traffic Director は、NEG 内の正常でないバックエンド VM やエンドポイントをエビクションさせるための基準と、バックエンドやエンドポイントが再びトラフィックを受信するのに十分な健全性を持つと判断された場合の基準を指定する一連のポリシーを使用してこれを実行します。

次の例のバックエンド サービスには、バックエンドとして 1 つのインスタンス グループがあります。外れ値検出の設定で、外れ値検出分析が 1 秒に 1 回実行されることが指定されています。エンドポイントから 5 つの連続した 5xx エラーが返された場合、最初の 30 秒間は負荷分散の候補から除外されます。同じエンドポイントの実際の除外時間は、除外される回数 × 30 秒に相当します。

バックエンド サービス リソースに外れ値検出を設定するには、次の手順を行います。

コンソール

  1. Google Cloud Console で [Traffic Director] ページに移動します。

    [Traffic Director] に移動

  2. サービスの名前をクリックします。

  3. [編集] をクリックします。

  4. [詳細構成] をクリックします。

  5. [外れ値検出] チェックボックスをオンにします。

  6. [編集] をクリックします。

    1. [連続するエラー] を 5 に設定します。
    2. [間隔] を 1000 ミリ秒に設定します。
    3. [ベースの排出時間] を 30000 ミリ秒に設定します。
  7. [保存] をクリックし、もう一度 [保存] をクリックします。

gcloud

  1. gcloud export コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME は、バックエンド サービスの名前に置き換えます。

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. BACKEND_SERVICE_NAME をバックエンド サービスの名前に置き換えて、以下のように YAML ファイルを更新します。

    name: BACKEND_SERVICE_NAME
    loadBalancingScheme: INTERNAL_SELF_MANAGED
    backends:
    - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: $INSTANCE_GROUP_URL
    healthChecks:
    - $HEALTH_CHECK_URL
    port: 80
    portName: http
    protocol: HTTP
    outlierDetection:
     consecutiveErrors: 5,
     interval:
         seconds: 1,
         nanos: 0
     baseEjectionTime:
         seconds: 30,
         nanos: 0
    
  3. バックエンド サービス構成ファイルをインポートします。

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

地域による負荷分散ポリシーを設定する

地域による負荷分散ポリシーを使用して、Traffic Director で提供される局所性の重み付けと優先度に基づいて負荷分散アルゴリズムを選択します。たとえば、正常なエンドポイント間で重み付けされたラウンドロビンを実行します。また、一貫したハッシュを実行することもできます。

次の例のバックエンド サービスには、バックエンドとして 1 つのインスタンス グループがあります。地域によるロード バランシング ポリシーは RING_HASH に設定されています。

地域によるロード バランシング ポリシーを設定する手順は次のとおりです。

コンソール

  1. Google Cloud Console で [Traffic Director] ページに移動します。

    [Traffic Director] に移動

  2. サービスの名前をクリックします。

  3. [編集] をクリックします。

  4. [詳細構成] をクリックします。

  5. [トラフィック ポリシー] の [地域による負荷分散] メニューで、[リングハッシュ] を選択します。

  6. [保存] をクリックします。

gcloud

  1. gcloud export コマンドを実行して、バックエンド サービスの構成をエクスポートします。BACKEND_SERVICE_NAME は、バックエンド サービスの名前に置き換えます。

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. BACKEND_SERVICE_NAME.yaml ファイルを次のように更新します。

    name: shopping-cart-service
    loadBalancingScheme: INTERNAL_SELF_MANAGED
    backends:
    - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: $INSTANCE_GROUP_URL
    healthChecks:
    - $HEALTH_CHECK_URL
    port: 80
    portName: http
    protocol: HTTP
    localityLbPolicy: RING_HASH
    
  3. バックエンド サービス構成ファイルをインポートします。

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

地域によるロード バランシング ポリシーの仕組みについては、backendService リソースのドキュメントをご覧ください。

URL リダイレクトの設定

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

  • Traffic Director のデプロイに review-url-map という URL マップがあります。
  • URL マップは、デフォルトのバックエンド サービスとして機能する review1 という 1 つのバックエンド サービスにすべてのトラフィックを送信します。
  • ホスト間でトラフィックをリダイレクトします。

URL リダイレクトを設定する手順は次のとおりです。

コンソール

  1. Google Cloud Console で [Traffic Director] ページに移動します。

    [Traffic Director] に移動

  2. [ルーティング ルール マップ] をクリックします。

  3. [ルーティング ルール マップを作成] をクリックします。

  4. [ルーティング ルール マップを作成] ページで、名前を入力します。

  5. [プロトコル] メニューで [HTTP] を選択します。

  6. 既存の転送ルールを選択します。

  7. [ルーティング ルール] で [詳細なホスト、パス、ルートのルール] を選択します。

  8. [ホストとパスのマッチャー] で、[Add hosts and path matcher] をクリックします。これにより、トラフィックをリダイレクトする新しいパスマッチャーが追加されます。

  9. [パスマッチャー] フィールドに次の設定を追加します。

        - defaultService: global/backendServices/review1
          name: matcher1
          routeRules:
          - matchRules:
            - prefixMatch: ''
            urlRedirect:
             hostRedirect: '[REDIRECT_HOST]'
             pathRedirect: '[REDIRECT_URL]'
             redirectResponseCode: 'FOUND',
            stripQuery: True
    
  10. [完了] をクリックします。

  11. [保存] をクリックします。

gcloud

  1. gcloud export コマンドを使用して、URL マップの構成を取得します。

    gcloud compute url-maps export review-url-map \
        --destination=review-url-map-config.yaml
    
  2. review-url-map-config.yaml ファイルに次のセクションを追加します。

         hostRules:
         - description: ''
          hosts:
           - '*'
         pathMatcher: matcher1
         pathMatchers:
        - defaultService: global/backendServices/review1
          name: matcher1
          routeRules:
          - matchRules:
            - prefixMatch: ''
            urlRedirect:
             hostRedirect: '[REDIRECT_HOST]'
             pathRedirect: '[REDIRECT_URL]'
             redirectResponseCode: 'FOUND',
            stripQuery: True
    
  3. URL マップを更新します。

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

URL 書き換えによってトラフィック ステアリングを設定する

トラフィック ステアリングを使用すると、ヘッダー値などのリクエスト属性に基づいて、複数のバックエンド サービスにトラフィックを転送できます。さらに、リクエストがバックエンド サービスに転送される前に、リクエストの URL の書き換えなどのアクションを構成できます。

次の例では、/mobile/ で始まるリクエストパスとリクエストの User-AgentAndroid が含まれている場合、リクエストは SERVICE_ANDROID_URL に転送されます。リクエストをバックエンド サービスに送信する前に、URL のプレフィックスを REWRITE_PATH_ANDROID/android/ など)に変更できます。ただし、パスの先頭に /mobile/ があり、User-AgentiPhone が含まれている場合、トラフィックは SERVICE_IPHONE_URL に転送され、URL プレフィックスが REWRITE_PATH_IPHONE に変更されます。先頭に /mobile/ があり、User-Agent に Android または iPhone 以外の値が設定されている他のリクエストはすべて SERVICE_GENERIC_DEVICE_URL に送信されます。

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*Android.*
         service: $[SERVICE_ANDROID_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_ANDROID]
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*iPhone.*
         service: [SERVICE_IPHONE_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_IPHONE]
       - matchRules:
         - prefixMatch: /mobile/
         service: [SERVICE_GENERIC_DEVICE_URL]

フォールト インジェクションを設定する

フォールト インジェクションを使用すると、特定のルートに固定遅延または強制停止(中断)の一方または両方を挿入して、アプリケーションの耐障害性をテストできます。

次の例では、すべてのリクエストが SERVICE_URL に送信され、リクエストの 100% に 10 秒の固定遅延が追加されます。リクエストを送信するクライアントで、すべてのレスポンスが 10 秒遅延することを確認できます。また、リクエストの 50% に Service Unavailable 503 レスポンスを含む停止障害が適用されます。クライアントで、リクエストの 50% が 503 レスポンスを受信することを確認できます。これらのリクエストはバックエンド サービスに到達しません。

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: [SERVICE_URL]
            weight: 100
          faultInjectionPolicy:
            delay:
              fixedDelay:
                seconds: 10
                nanos: 0
              percentage: 100
            abort:
              httpStatus: 503
              percentage: 50

MetadataFilters の一致に基づいて構成フィルタリングを設定する

MetadataFilters は転送ルールと HttpRouteRuleMatch で有効になっています。この機能を使用して、特定の転送ルールまたはルートルールを制御し、ノード メタデータがメタデータ フィルタの設定と一致するプロキシにのみ転送ルールまたはルートルールが転送されるようにします。MetadataFilters を指定しない場合、ルールはすべての Envoy プロキシに送信されます。

この機能を使用すると、構成の段階的なデプロイを簡単に行うことができます。たとえば、forwarding-rule1 という名前の転送ルールを作成し、ノード メタデータに app: reviewversion: canary が含まれている Envoy にのみ push されるようにします。

転送ルールに MetadataFilters を追加する手順は次のとおりです。

gcloud

  1. gcloud export コマンドを使用して、転送ルールの構成を取得します。

    gcloud compute forwarding-rules export forwarding-rule1 \
        --destination=forwarding-rule1-config.yaml \
        --global
    
  2. 転送ルールを削除します。

    gcloud compute forwarding-rules delete forwarding-rule1 \
        --global
    
  3. forwarding-rule1-config.yaml ファイルを更新します。

    次の例では、MATCH_ALL メタデータ フィルタを作成します。

     metadataFilters:
     - filterMatchCriteria: 'MATCH_ALL'
       filterLabels:
       - name: 'app'
         value: 'review'
       - name: 'version'
         value: 'canary'
    

    次の例では、MATCH_ANY メタデータ フィルタを作成します。

     metadataFilters:
     - filterMatchCriteria: 'MATCH_ANY'
       filterLabels:
       - name: 'app'
         value: 'review'
       - name: 'version'
         value: 'production'
    
  4. forwarding-rule1-config.yaml ファイルから出力専用フィールドをすべて削除します。詳細については、gcloud compute forwarding-rules import のドキュメントをご覧ください。

  5. gcloud import コマンドを実行して forwarding-rule1-config.yaml ファイルを更新します。

    gcloud compute forwarding-rules import forwarding-rule1 \
        --source=forwarding-rule1-config.yaml \
        --global
    
  6. Envoy を起動する前に、以下の手順で Envoy にノードのメタデータを追加します。文字列値のみがサポートされています。

    a. VM ベースのデプロイの場合は、bootstrap_template.yamlmetadata セクションに以下を追加します。

       app: 'review'
       version: 'canary'
    

    b. Google Kubernetes Engine または Kubernetes ベースのデプロイの場合は、trafficdirector_istio_sidecar.yamlenv セクションに次の行を追加します。

       - name: ISTIO_META_app
         value: 'review'
       - name: ISTIO_META_version
         value: 'canary'
    

メタデータのフィルタリングの例

複数のプロジェクトが同じ共有 VPC ネットワークにあり、各サービス プロジェクトの Traffic Director リソースを同じプロジェクト内のプロキシに表示できるようにすることが必要な場合の手順は、次のとおりです。

共有 VPC の設定は次のとおりです。

  • ホスト プロジェクトの名前: vpc-host-project
  • サービス プロジェクト: project1project2
  • project1project2 で xDS 準拠のプロキシを実行するバックエンド インスタンスまたはエンドポイントを持つバックエンド サービス

project1 を分離するように Traffic Director を構成するには、次の手順を行います。

gcloud

  1. 次のメタデータ フィルタを使用して、すべての転送ルールを project1 に作成します。

         metadataFilters:
         - filterMatchCriteria: 'MATCH_ALL'
           filterLabels
           - name: 'project_name'
             value: 'project1'
           - name: 'version'
             value: 'production'
    
  2. project1 でインスタンスまたはエンドポイントにデプロイされたプロキシを構成する場合は、ブートストラップ ファイルのノード メタデータ セクションに次のメタデータを追加します。

       project_name: 'project1'
       version: 'production'
    
  3. project2 にデプロイされているプロキシに、最初の手順で作成した転送ルールが受信されていないことを確認します。これを行うには、project2 でプロキシを実行しているシステムから project1 のサービスにアクセスします。Traffic Director 構成が正しく機能していることを確認する方法については、構成の検証をご覧ください。

すべてのプロキシで使用可能にする前に、プロキシのサブセットで新しい構成をテストするには、次の手順を行います。

gcloud

  1. 次のノード メタデータを使用して、テストに使用するプロキシを起動します。テストに使用しないプロキシには、このノード メタデータを挿入しないでください。

      version: 'test'
    
  2. テストする新しい転送ルールごとに、次のメタデータ フィルタを挿入します。

      metadataFilters:
      - filterMatchCriteria: 'MATCH_ALL'
        filterLabels:
        - name: 'version'
          value: 'test'
    
  3. テストプロキシにトラフィックを送信して新しい構成をテストし、必要な変更を行います。新しい構成が正しく機能している場合は、テスト対象のプロキシのみが新しい構成を受け取ります。残りのプロキシは新しい構成を受信できず、使用できません。

  4. 新しい構成が正しく機能していることを確認したら、構成に関連付けられたメタデータ フィルタを削除します。これにより、すべてのプロキシが新しい構成を受信できます。

トラブルシューティング

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

症状:

  • ルールの上位にあるサービスへのトラフィックが増加した。
  • 特定のルートルールに対する 4xx5xx の HTTP レスポンスが予期せず増加した。

解決策: ルートルールは優先度順に解釈されるため、各ルールに割り当てられた優先度を確認してください。

ルートルールを定義する際は、優先度の高い(つまり、優先度の番号が小さい)ルールが、後続のルートルールでルーティングされるトラフィックを誤ってルーティングしないようにします。次に例を示します。

  • 最初のルートルール

    • ルートルール マッチの pathPrefix = /shopping/
    • リダイレクト アクション: バックエンド サービス service-1 にトラフィックを送信
    • ルールの優先度: 4
  • 2 つ目のルートルール

    • ルートルール マッチの regexMatch = /shopping/cart/ordering/.*
    • リダイレクト アクション: バックエンド サービス service-2 にトラフィックを送信
    • ルールの優先度: 8

この場合、パス /shopping/cart/ordering/cart.html のリクエストは service-1 にルーティングされます。2 番目のルールが一致する場合でも、最初のルールが優先されるため無視されます。

サービス間のトラフィックをブロックする

GKE 上でデプロイされているサービス A とサービス B 間のトラフィックをブロックする場合、サービス セキュリティを設定し、認可ポリシーを使用してサービス間のトラフィックをブロックします。詳細な手順については、Traffic Director のサービス セキュリティと、Envoyプロキシレス gRPC の設定手順をご覧ください。

次のステップ