高度なトラフィック管理の構成

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

高度なトラフィック管理を構成する前に

Traffic Director の設定の手順に沿って、Traffic Director と必要な VM ホストまたは GKE クラスタを構成します。必要な Google Cloud リソースを作成します。

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

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

トラフィック分割の設定

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

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

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

Console

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

    [Traffic Director] ページに移動

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

  3. [ルーティング ルールのマップ名] に入力します。

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

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

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

  7. [パスマッチャー] で [ホストとパスマッチャーを追加する] を選択します。これにより、トラフィックを分割するように構成できる新しいパスマッチャーが追加されます。

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

        - 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
    
  9. [完了] をクリックします。

  10. [作成] をクリックします。

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. [編集] をクリックします。
  7. [接続あたりの最大リクエスト数] に「100」と入力します。
  8. [最大接続数] に「1000」と入力します。
  9. [保留中のリクエストの最大数] に「200」と入力します。
  10. [最大リクエスト数] に「1000」と入力します。
  11. [最大再試行回数] に「3」と入力します。
  12. [保存] をクリックします。
  13. [保存] をクリックします。

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/<var>PROJECT_ID</var>/zones/<var>ZONE</var>/instanceGroups/<var>INSTANCE_GROUP_NAME</var>
       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/<var>PROJECT_ID</var>/global/healthChecks/<var>HEALTH_CHECK_NAME</var>
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     localityLbPolicy: ROUND_ROBIN
     name: <var>BACKEND_SERVICE_NAME</var>
     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
    

次のサーキット ブレーカーの例は、ショッピング カート サービスがバックエンドとして 1 つのインスタンス グループを持つユースケースのためのものです。サーキット ブレーカーの設定には、次の上限が示されています。

  • 接続あたりの同時リクエストの最大数
  • 同時接続の最大数
  • 保留中のリクエストの最大数
  • 同時リクエストの最大数
  • 同時再試行の最大数

このサーキット ブレーカーを設定する手順は次のとおりです。

Console

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

    [Traffic Director] ページに移動

  2. 更新するバックエンド サービスの名前をクリックします。
  3. [編集] をクリックします。
  4. [詳細構成] をクリックします。
  5. [サーキット ブレーカー] で [有効にする] チェックボックスをオンにします。
  6. [編集] をクリックします。
  7. [接続あたりの最大リクエスト数] に「100」と入力します。
  8. [最大接続数] に「1000」と入力します。
  9. [保留中のリクエストの最大数] に「200」と入力します。
  10. [最大リクエスト数] に「20000」と入力します。
  11. [最大再試行回数] に「3」と入力します。
  12. [保存] をクリックします。
  13. [保存] をクリックします。

gcloud

  1. gcloud export コマンドを使用してバックエンド サービスの構成をエクスポートします。ここで、BACKEND_SERVICE_NAME はバックエンド サービスの名前です。

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    

高度なトラフィック管理では、設定した Cookie に基づいてセッション アフィニティを構成できます。HTTP_COOKIE ベースのセッション アフィニティを構成するには、次に示す手順を行います。

HTTP_COOKIE を使用してセッション アフィニティを構成するには:

Console

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

    [Traffic Director] ページに移動

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

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

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

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

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

  7. [HTTP Cookie 名] フィールドに「http_cookie」と入力します。

  8. [HTTP Cookie パス] フィールドに「/cookie_path」と入力します。

  9. [HTTP Cookie TTL] フィールドに「100」と入力します。

  10. [最小リングサイズ] フィールドに「10000」と入力します。

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

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. [編集] をクリックします。

  7. [連続するエラー] を 5 に設定します。

  8. [間隔] を 1000 ミリ秒に設定します。

  9. [ベースの排出時間] を 30000 ミリ秒に設定します。

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

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

gcloud

  1. gcloud export コマンドを使用してバックエンド サービスの構成をエクスポートします。ここで、BACKEND_SERVICE_NAME はバックエンド サービスの名前です。

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

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

MetadataFilter の一致に基づく構成フィルタリングの設定

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

この機能を使用すると、構成の段階的なデプロイを簡単に行うことができます。たとえば、forwarding-rule1 という名前の転送ルールを作成します。これは、ノード メタデータに「app: レビュー」と「version: カナリア」が含まれる Envoy にのみ push されます。

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

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

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 ファイルを更新します。

    metadataFilters:
    - filterMatchCriteria: MATCH_ALL
      filterLabels:
      - name: 'app'
        value: 'review'
      - name: 'version'
        value: 'canary'
    
  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.yaml のメタデータ セクションに次の行を追加します。

        app: 'review'
        version: 'canary'
    

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

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

トラブルシューティング

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

症状:

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

解決策: 各ルールに割り当てられた優先度を確認します。ルートルールは優先度順に解釈されます。

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

  • 最初のルートルール

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

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

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