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

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

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

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

    - 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

[完了] をクリックします。
[保存] をクリックします。

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

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

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

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

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

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

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

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

Console

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

[Traffic Director] に移動
更新するバックエンドサービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[サーキットブレーカー] で [有効にする] チェックボックスをオンにします。
[編集] をクリックします。
1. [接続あたりの最大リクエスト数] に「100」と入力します。
2. [最大接続数] に「1000」と入力します。
3. [保留中のリクエストの最大数] に「200」と入力します。
4. [最大リクエスト数] に「1000」と入力します。
5. [最大再試行回数] に「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/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

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

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

`HTTP_COOKIE` に基づいてセッションアフィニティを設定する

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

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

Console

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

[Traffic Director] に移動
更新するバックエンドサービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[セッションアフィニティ] で [HTTP Cookie] を選択します。
[地域による負荷分散ポリシー] で [リングハッシュ] を選択します。
1. [HTTP Cookie 名] フィールドに「http_cookie」と入力します。
2. [HTTP Cookie パス] フィールドに「/cookie_path」と入力します。
3. [HTTP Cookie TTL] フィールドに「100」と入力します。
4. [最小リングサイズ] フィールドに「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] に移動
サービスの名前をクリックします。
[編集] をクリックします。
[詳細構成] をクリックします。
[外れ値検出] チェックボックスをオンにします。
[編集] をクリックします。
1. [連続するエラー] を 5 に設定します。
2. [間隔] を 1000 ミリ秒に設定します。
3. [ベースの排出時間] を 30000 ミリ秒に設定します。
[保存] をクリックし、もう一度 [保存] をクリックします。

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

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

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

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

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

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

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

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

次の例では、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'

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 の metadata セクションに以下を追加します。
```
   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 番目のルールが一致する場合でも、最初のルールが優先されるため無視されます。

次のステップ

Envoy を使用するデプロイのトラブルシューティングを参照して、Traffic Director の構成の問題を解決する。

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

始める前に

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

Console

gcloud

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

Console

gcloud

HTTP_COOKIE に基づいてセッション アフィニティを設定する

Console

gcloud

外れ値検出を設定する

Console

gcloud

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

Console

gcloud

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

gcloud

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

gcloud

gcloud

トラブルシューティング

次のステップ

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

`HTTP_COOKIE` に基づいてセッションアフィニティを設定する

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