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

構成はプレビュー版をご利用のお客様に対してサポートされていますが、新規の Cloud Service Mesh ユーザーにはおすすめしません。詳細については、Cloud Service Mesh サービス ルーティングの概要をご覧ください。

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

始める前に

高度なトラフィック管理を構成する前に、Envoy を使用して Cloud Service Mesh の設定を準備するの手順に沿って、Cloud Service Mesh と仮想マシン（VM）ホストまたは必要な Google Kubernetes Engine（GKE）クラスタを構成します。必要な Google Cloud リソースを作成します。

高度なトラフィック管理機能の可用性は、選択したリクエスト プロトコルによって異なります。このプロトコルは、ターゲット HTTP または HTTPS プロキシ、ターゲット gRPC プロキシ、またはターゲット TCP プロキシ リソースを使用してルーティングを構成するときに構成されます。

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

詳細については、Cloud Service Mesh の機能と高度なトラフィック管理をご覧ください。 エンドツーエンドの設定ガイドについては、プロキシレス gRPC サービスを使用して高度なトラフィック管理を構成するをご覧ください。

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

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

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

URL マップでまだ参照されていない新しいサービスにトラフィックを分割する場合は、まず新しいサービスを weightedBackendServices に追加し、それに 0 の重みを設定します。次に、そのサービスに割り当てられた重みを徐々に増やしていきます。

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

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    Cloud Service Mesh に移動する

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

部分的なリリースを設定する

カナリア処理と呼ばれる部分的デプロイ プロセスを使用して、新しいソフトウェア バージョンをごく少数のサーバーにリリースしてから、新しいバージョンを本番環境サーバーの残高にリリースします。

部分的なリリースの場合、weightedBackendServices が使用されます。部分的なリリースを有効にするには、バックエンド サービスをテストまたはカナリア サービスとして指定し、重み付けをします（2 または 5 など）。これらのサーバーにのみ新しいソフトウェア バージョンをデプロイします。新しいバージョンに問題がないことを確認したら、残りのサービスにデプロイします。

  • 部分的なリリースを有効にするには、次の YAML コードサンプルを使用します。
pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_PARTIAL_URL
            weight: 2
          - backendService: BACKEND_SERVICE_URL
            weight: 98
  • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
  • BACKEND_SERVICE_PARTIAL_URL は、トラフィックの 2% を受信するバックエンド サービスの URL です。
  • BACKEND_SERVICE_URL は、トラフィックの 98% を受信するバックエンド サービスの URL です。

Blue/Green デプロイを設定する

Blue/Green デプロイは、本番環境トラフィックをサービスの新しいリリースまたは以前のリリースのロールバックに切り替えるのに必要な時間を短縮するリリースモデルです。これらのデプロイでは、本番環境で使用可能な両方のバージョンのサービスを維持し、トラフィックを一方から他方に移行します。

Blue/Green デプロイでは、weightedBackendServices を使用します。以下の YAML の例では、SERVICE_BLUE_URL へのバックエンドは現在の本番環境リリースに完全にデプロイされ、SERVICE_GREEN_URL のバックエンドは新しいリリースに完全にデプロイされます。この例の構成では、GREEN デプロイが本番環境のトラフィックの 100% を受信します。問題が見つかった場合は、2 つのデプロイの重みを逆にすることで、不具合のある GREEN リリースを元に戻し、正常な BLUE リリースを復元できます。両方のバージョンでトラフィックを受信できる体制が整っているため、いずれの場合でもトラフィックを迅速に移行できます。

  • Blue/Green デプロイを有効にするには、次の YAML コードサンプルを使用します。
pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_BLUE_URL
            weight: 0
          - backendService: BACKEND_SERVICE_GREEN_URL
            weight: 100
  • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
  • BACKEND_SERVICE_BLUE_URL は、トラフィックを受信しないバックエンド サービスの URL です。
  • BACKEND_SERVICE_GREEN_URL は、トラフィックをすべて受信するバックエンド サービスの URL です。

トラフィックのミラーリングを設定する

トラフィックのミラーリングは、新しいサービスのデバッグやテストのために 2 つの異なるバックエンド サービスにトラフィックを転送する場合に使用します。

次の例では、すべてのリクエストが SERVICE_URL と MIRROR_SERVICE_URL に送信されます。クライアントには SERVICE_URL からのレスポンスのみが返されます。MIRROR_SERVICE_URL はクライアントに影響しません。

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

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    Cloud Service Mesh に移動する

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

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

  4. [ルーティング ルール マップを作成] ページで、名前を入力します。

  5. [プロトコル] リストで [HTTP] を選択します。

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

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

  8. [ホストとパスのマッチャー] で、[Add hosts and path matcher] をクリックします。これにより、トラフィックを分割するように構成できる新しいパスマッチャーが追加されます。

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

        - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL
    • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
    • BACKEND_SERVICE_URL は、ミラーリングされるバックエンドの URL です。
    • BACKEND_SERVICE_MIRROR_URL は、ミラーリングするバックエンド サービスの URL です。

  10. [完了] をクリックします。

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

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: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL
    • DEFAULT_SERVICE_URL は、サービスのデフォルトの URL です。
    • BACKEND_SERVICE_URL は、ミラーリングされるバックエンドの URL です。
    • BACKEND_SERVICE_MIRROR_URL は、ミラーリングするバックエンド サービスの URL です。

  3. URL マップを更新します。

    gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

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

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

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

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

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

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

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    Cloud Service Mesh に移動する

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

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    Cloud Service Mesh に移動する

  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

外れ値検出を設定する

外れ値検出によって、負荷分散プールから正常でないホストのエビクションが制御されます。Cloud Service Mesh は、NEG 内の正常でないバックエンド VM やエンドポイントをエビクションさせるための基準と、バックエンドやエンドポイントが再びトラフィックを受信するのに十分な健全性を持つと判断された場合の基準を指定する一連のポリシーを使用してこれを実行します。

次の例のバックエンド サービスには、バックエンドとして 1 つのインスタンス グループがあります。外れ値検出の設定で、外れ値検出分析が 1 秒に 1 回実行されることが指定されています。エンドポイントから 5 つの連続した 5xx エラーが返された場合、最初の 30 秒間は負荷分散の候補から除外されます。同じエンドポイントの実際の除外時間は、除外される回数 × 30 秒に相当します。

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

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    Cloud Service Mesh に移動する

  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

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

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

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

地域によるロードバランシング ポリシーを設定する手順は次のとおりです。

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    Cloud Service Mesh に移動する

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

URL リダイレクトの設定

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

  • Cloud Service Mesh のデプロイに review-url-map という URL マップがあります。
  • URL マップは、デフォルトのバックエンド サービスとして機能する review1 という 1 つのバックエンド サービスにすべてのトラフィックを送信します。
  • ホスト間でトラフィックをリダイレクトします。

URL リダイレクトを設定する手順は次のとおりです。

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    Cloud Service Mesh に移動する

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

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

  4. [ルーティング ルール マップを作成] ページで、名前を入力します。

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

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

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

  8. [ホストとパスのマッチャー] で、[Add hosts and path matcher] をクリックします。これにより、トラフィックをリダイレクトする新しいパスマッチャーが追加されます。

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

        - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

  10. [完了] をクリックします。

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

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:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

  3. URL マップを更新します。

    gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

URL 書き換えにによってトラフィック ステアリングを設定する

トラフィック ステアリングを使用すると、ヘッダー値などのリクエスト属性に基づいて、複数のバックエンド サービスにトラフィックを転送できます。さらに、リクエストがバックエンド サービスに転送される前に、リクエストの URL の書き換えなどのアクションを構成できます。

次の例では、/mobile/ で始まるリクエストパスとリクエストの User-Agent に Android が含まれている場合、リクエストは SERVICE_ANDROID_URL に転送されます。リクエストをバックエンド サービスに送信する前に、URL のプレフィックスを REWRITE_PATH_ANDROID（/android/ など）に変更できます。ただし、パスの先頭に /mobile/ があり、User-Agent に iPhone が含まれている場合、トラフィックは SERVICE_IPHONE_URL に転送され、URL プレフィックスが REWRITE_PATH_IPHONE に変更されます。先頭に /mobile/ があり、User-Agent に Android または iPhone 以外の値が設定されている他のリクエストはすべて SERVICE_GENERIC_DEVICE_URL に送信されます。

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*Android.*
         service: $[SERVICE_ANDROID_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_ANDROID]
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*iPhone.*
         service: [SERVICE_IPHONE_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_IPHONE]
       - matchRules:
         - prefixMatch: /mobile/
         service: [SERVICE_GENERIC_DEVICE_URL]

フォールト インジェクションを設定する

フォールト インジェクションを使用すると、特定のルートに固定遅延または強制停止（中断）の一方または両方を挿入して、アプリケーションの耐障害性をテストできます。

次の例では、すべてのリクエストが SERVICE_URL に送信され、リクエストの 100% に 10 秒の固定遅延が追加されます。リクエストを送信するクライアントで、すべてのレスポンスが 10 秒遅延することを確認できます。また、リクエストの 50% に Service Unavailable 503 レスポンスを含む停止障害が適用されます。クライアントで、リクエストの 50% が 503 レスポンスを受信することを確認できます。これらのリクエストはバックエンド サービスに到達しません。

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: [SERVICE_URL]
            weight: 100
          faultInjectionPolicy:
            delay:
              fixedDelay:
                seconds: 10
                nanos: 0
              percentage: 100
            abort:
              httpStatus: 503
              percentage: 50

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

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

この機能を使用すると、構成の段階的なデプロイを簡単に行うことができます。たとえば、forwarding-rule1 という名前の転送ルールを作成し、ノード メタデータに app: review と version: 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.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 ネットワークにあり、各サービス プロジェクトの Cloud Service Mesh リソースを同じプロジェクト内のプロキシに表示できるようにすることが必要な場合の手順は、次のとおりです。

共有 VPC の設定は次のとおりです。

  • ホスト プロジェクトの名前: vpc-host-project
  • サービス プロジェクト: project1、project2
  • project1 と project2 で xDS 準拠のプロキシを実行するバックエンド インスタンスまたはエンドポイントを持つバックエンド サービス

project1 を分離するように Cloud Service Mesh を構成する手順は次のとおりです。

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 のサービスにアクセスします。Cloud Service Mesh 構成が正しく機能していることを確認する方法については、構成の検証をご覧ください。

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

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

サービス間のトラフィックをブロックする

GKE 上でデプロイされているサービス A とサービス B 間のトラフィックをブロックする場合、サービス セキュリティを設定し、認可ポリシーを使用してサービス間のトラフィックをブロックします。詳しい手順については、Cloud Service Mesh サービス セキュリティと、Envoy とプロキシレス gRPC を使用した設定手順をご覧ください。

次のステップ