このドキュメントでは、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] ページに移動します。
[ルーティング ルール マップを作成] をクリックします。
[ルーティング ルールのマップ名] に入力します。
[プロトコル] メニューから [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] ページに移動します。
- 更新するバックエンド サービスの名前をクリックします。
- [編集] をクリックします。
- [詳細構成] をクリックします。
- [サーキット ブレーカー] で [有効にする] チェックボックスをオンにします。
- [編集] をクリックします。
- [接続あたりの最大リクエスト数] に「
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] ページに移動します。
- 更新するバックエンド サービスの名前をクリックします。
- [編集] をクリックします。
- [詳細構成] をクリックします。
- [サーキット ブレーカー] で [有効にする] チェックボックスをオンにします。
- [編集] をクリックします。
- [接続あたりの最大リクエスト数] に「
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] ページに移動します。
更新するバックエンド サービスの名前をクリックします。
[編集]
をクリックします。[詳細構成] をクリックします。
[セッション アフィニティ] で [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] ページに移動します。
サービスの名前をクリックします。
[編集]
をクリックします。[詳細構成] をクリックします。
[外れ値検出] チェックボックスをオンにします。
[編集]
をクリックします。[連続するエラー] を
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] ページに移動します。
サービスの名前をクリックします。
[編集]
をクリックします。[詳細構成] をクリックします。
[トラフィック ポリシー] の [地域による負荷分散] メニューで、[リングハッシュ] を選択します。
[保存] をクリックします。
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 番目のルールが一致する場合でも、最初のルールが優先されるため無視されます。