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 の重みを設定します。次に、そのサービスに割り当てられた重みを徐々に増やしていきます。

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

Console

  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 に送信できます。

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

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

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

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

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

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

Console

  1. 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 を使用してセッション アフィニティを構成する手順は次のとおりです。

Console

  1. 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 秒に相当します。

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

Console

  1. 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 に設定されています。

地域による負荷分散ポリシーを設定する手順は次のとおりです。

Console

  1. 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 リソースのドキュメントをご覧ください。

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 番目のルールが一致する場合でも、最初のルールが優先されるため無視されます。

次のステップ