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

このドキュメントでは、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

Cloud Console の [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
[ルーティングルールマップを作成] をクリックします。
[ルーティングルールのマップ名] に入力します。
[プロトコル] メニューから [HTTP] を選択します。
既存の転送ルールを選択します。
[ルーティングルール] で [詳細なホスト、パス、ルートのルール] を選択します。
[パスマッチャー] で [ホストとパスマッチャーを追加する] を選択します。これにより、トラフィックを分割するように構成できる新しいパスマッチャーが追加されます。

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

    - 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

[完了] をクリックします。
[作成] をクリックします。

gcloud

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

gcloud compute url-maps export review-url-map \
    --destination=review-url-map-config.yaml

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

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

Cloud Console で [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
更新するバックエンドサービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[サーキットブレーカー] で [有効にする] チェックボックスをオンにします。
[編集] をクリックします。
[接続あたりの最大リクエスト数] に「100」と入力します。
[最大接続数] に「1000」と入力します。
[保留中のリクエストの最大数] に「200」と入力します。
[最大リクエスト数] に「1000」と入力します。
[最大再試行回数] に「3」と入力します。
[保存] をクリックします。
[保存] をクリックします。

gcloud

gcloud export コマンドを使用してバックエンドサービスの構成を取得します。ここで、BACKEND_SERVICE_NAME はバックエンドサービスの名前です。
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

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
```

バックエンドサービス構成ファイルを更新します。

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

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

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

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

Console

Cloud Console で [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
更新するバックエンドサービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[サーキットブレーカー] で [有効にする] チェックボックスをオンにします。
[編集] をクリックします。
[接続あたりの最大リクエスト数] に「100」と入力します。
[最大接続数] に「1000」と入力します。
[保留中のリクエストの最大数] に「200」と入力します。
[最大リクエスト数] に「20000」と入力します。
[最大再試行回数] に「3」と入力します。
[保存] をクリックします。
[保存] をクリックします。

gcloud

gcloud export コマンドを使用してバックエンドサービスの構成をエクスポートします。ここで、BACKEND_SERVICE_NAME はバックエンドサービスの名前です。
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

`HTTP_COOKIE` に基づいたセッションアフィニティの設定

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

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

Console

Cloud Console で [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
更新するバックエンドサービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[セッションアフィニティ] で [HTTP Cookie] を選択します。
[地域による負荷分散ポリシー] で [リングハッシュ] を選択します。
[HTTP Cookie 名] フィールドに「http_cookie」と入力します。
[HTTP Cookie パス] フィールドに「/cookie_path」と入力します。
[HTTP Cookie TTL] フィールドに「100」と入力します。
[最小リングサイズ] フィールドに「10000」と入力します。
[保存] をクリックします。

gcloud

gcloud export コマンドを使用してバックエンドサービスの構成をエクスポートします。ここで、BACKEND_SERVICE_NAME はバックエンドサービスの名前です。
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

次のように YAML ファイルを更新します。

sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 30
minimumRingSize: 10000

バックエンドサービス構成ファイルをインポートします。

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

Cloud Console で [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
サービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[外れ値検出] チェックボックスをオンにします。
[編集] をクリックします。
[連続するエラー] を 5 に設定します。
[間隔] を 1000 ミリ秒に設定します。
[ベースの排出時間] を 30000 ミリ秒に設定します。
[保存] をクリックします。
[保存] をクリックします。

gcloud

gcloud export コマンドを使用してバックエンドサービスの構成をエクスポートします。ここで、BACKEND_SERVICE_NAME はバックエンドサービスの名前です。
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

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
  ````

バックエンドサービス構成ファイルをインポートします。

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

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

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

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

Console

Cloud Console で [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
サービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[トラフィックポリシー] の [地域による負荷分散] メニューで、[リングハッシュ] を選択します。
[保存] をクリックします。

gcloud

gcloud export コマンドを使用してバックエンドサービスの構成をエクスポートします。ここで、BACKEND_SERVICE_NAME はバックエンドサービスの名前です。
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

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
````

バックエンドサービス構成ファイルをインポートします。

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

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

gcloud compute forwarding-rules export forwarding-rule1 \
    --destination=forwarding-rule1-config.yaml \
    --global

転送ルールを削除します。

gcloud compute forwarding-rules delete forwarding-rule1 \
    --global

forwarding-rule1-config.yaml ファイルを更新します。

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

forwarding-rule1-config.yaml ファイルから出力専用フィールドをすべて削除します。詳細については、gcloud compute forwarding-rules import のドキュメントをご覧ください。

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

gcloud compute forwarding-rules import forwarding-rule1 \
    --source=forwarding-rule1-config.yaml \
    --global

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
サービスプロジェクト: project1、project2
project1 と project2 で xDS 準拠のプロキシを実行するバックエンドインスタンスまたはエンドポイントを持つバックエンドサービス

project1 を分離するように Traffic Director を構成するには:

gcloud

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

    metadataFilters:
    - filterMatchCriteria: 'MATCH_ALL'
      filterLabels
      - name: 'project_name'
        value: `project1
      - name: 'version'
        value: 'production'

project1 でインスタンスまたはエンドポイントにデプロイされたプロキシを構成する場合は、ブートストラップファイルのノードメタデータセクションに次のメタデータを追加します。
```
   project_name: 'project1'
   version: 'production'
```
project2 にデプロイされているプロキシに、最初の手順で作成した転送ルールが受信されていないことを確認します。これを行うには、project2 でプロキシを実行しているシステムから project1 のサービスにアクセスします。Traffic Director 構成が正しく機能していることを確認する方法については、構成の検証をご覧ください。

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

gcloud

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

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

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ALL'
   filterLabels:
   - name: 'version'
     value: 'test'

テストプロキシにトラフィックを送信して新しい構成をテストし、必要な変更を行います。新しい構成が正しく機能している場合は、テスト対象のプロキシのみが新しい構成を受け取ります。残りのプロキシは新しい構成を受信できず、使用できません。
新しい構成が正しく機能していることを確認したら、構成に関連付けられたメタデータフィルタを削除します。これにより、すべてのプロキシが新しい構成を受信できます。

トラブルシューティング

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

症状:

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

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

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

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

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

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

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

トラフィック分割の設定

Console

gcloud

サーキット ブレーカーの設定

Console

gcloud

Console

gcloud

HTTP_COOKIE に基づいたセッション アフィニティの設定

Console

gcloud

外れ値検出の設定

Console

gcloud

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

Console

gcloud

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

gcloud

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

gcloud

gcloud

トラブルシューティング

サーキットブレーカーの設定

`HTTP_COOKIE` に基づいたセッションアフィニティの設定

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

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