Alibaba Cloud Service Mesh:フォールトトレランス機能を備えた分散システムを構築するために ASM を使用する

タイムアウト処理

仕組み

クライアントがアップストリームサービスにリクエストを送信すると、アップストリームサービスが応答しない場合があります。タイムアウト期間を設定できます。アップストリームサービスがタイムアウト期間内にリクエストに応答しない場合、クライアントはリクエストを失敗とみなし、アップストリームサービスからの応答を待機しなくなります。

タイムアウト期間が設定されると、バックエンドサービスがタイムアウト期間内に応答しない場合、アプリケーションはリターンエラーを受け取ります。その後、アプリケーションは適切なフォールバックアクションを実行できます。タイムアウト設定は、リクエスト元のクライアントがサービスのリクエストへの応答を待機する時間を指定します。タイムアウト設定は、サービスの処理動作には影響しません。したがって、タイムアウトは、リクエストされた操作が失敗することを意味するものではありません。

ソリューション

ASM を使用すると、仮想サービス内のルートにタイムアウトポリシーを構成して、タイムアウト期間を設定できます。サイドカープロキシがタイムアウト期間内に応答を受信しない場合、リクエストは失敗します。ルートのタイムアウト期間を設定すると、タイムアウト設定は、そのルートを使用するすべてのリクエストに適用されます。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - 'httpbin'
  http:
  - route:
    - destination:
        host: httpbin
    timeout: 5s

timeout: タイムアウト期間を指定します。リクエストされたサービスが指定されたタイムアウト期間内に応答しない場合、エラーが返され、リクエスト元のクライアントは応答を待機しなくなります。

再試行メカニズム

仕組み

ソリューション

ASM を使用すると、仮想サービスを作成して HTTP リクエストの再試行ポリシーを定義できます。この例では、次の再試行ポリシーを定義するために仮想サービスが作成されます。ASM インスタンス内のサービスが httpbin アプリケーションをリクエストする場合、httpbin アプリケーションが応答しない、またはサービスが httpbin アプリケーションへの接続の確立に失敗した場合、サービスは httpbin アプリケーションを最大 3 回再度リクエストします。各リクエストのタイムアウト期間は 5 秒です。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - 'httpbin'
  http:
  - route:
    - destination:
        host: httpbin
    retries:
      attempts: 3
      perTryTimeout: 5s
        retryOn: connect-failure,reset

retries 構造体に次のフィールドを構成して、リクエストに対するサイドカープロキシの再試行動作をカスタマイズできます。

HTTP リクエストのデフォルトの再試行ポリシーを構成する

1. ASM コンソール にログインします。左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[ASM インスタンス] > [基本情報] を選択します。

3. 構成情報[基本情報] ページの 編集既定の HTTP 再試行ポリシー セクションで、 の横にある をクリックします。

4. [デフォルトの HTTP 再試行ポリシー] ダイアログボックスで、関連パラメーターを構成し、[OK] をクリックします。

   パラメーター	説明
   再試行回数	前述の attempts フィールドに対応します。HTTP リクエストのデフォルトの再試行ポリシーでは、このフィールドを 0 に設定できます。これは、デフォルトで HTTP リクエストの再試行が無効になっていることを示します。
   タイムアウト	前述の perTryTimeout フィールドに対応します。
   再試行条件	前述の retryOn フィールドに対応します。

バルクヘッドパターン

仕組み

ソリューション

ASM を使用すると、宛先ルールを作成してバルクヘッドパターンを構成できます。この例では、次のバルクヘッドパターンを定義するために宛先ルールが作成されます。サービスが httpbin アプリケーションをリクエストする場合、同時接続の最大数は 1、接続あたりのリクエストの最大数は 1、リクエストの再試行の最大数は 1 です。さらに、10 秒以内に httpbin アプリケーションへの接続が確立されない場合、サービスは 503 エラーを受け取ります。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
      tcp:
        connectTimeout: 10s
        maxConnections: 1

• http1MaxPendingRequests: リクエストの再試行の最大数を指定します。

• maxRequestsPerConnection: 接続あたりのリクエストの最大数を指定します。

• connectTimeout: 各接続のタイムアウト期間を指定します。

• maxConnections: 同時接続の最大数を指定します。

サーキットブレーカー

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 3  # 連続エラーの数を指定します。
      interval: 5s # 排除検出の時間間隔を指定します。
      baseEjectionTime: 5m # 最小排除期間を指定します。
      maxEjectionPercent: 100 # ロードバランシングプールから排除できるホストの最大割合を指定します。

ホストレベルのサーキットブレーカーのメトリック収集とアラートを構成する

ホストレベルのサーキットブレーキングに関連するメトリクスを構成した後、Prometheus インスタンスを構成してメトリクスを収集できます。また、主要なメトリクスに基づいてアラートルールを構成することもできます。このようにして、サーキットブレーキングが発生したときにアラートが生成されます。次のセクションでは、ホストレベルのサーキットブレーキングのメトリック収集とアラートを構成する方法について説明します。この例では、Managed Service for Prometheus を使用します。

1. Managed Service for Prometheus で、データプレーン上の ACK クラスタを [alibaba Cloud ASM] コンポーネントに接続するか、Alibaba Cloud ASM コンポーネントを最新バージョンにアップグレードします。これにより、サーキットブレーキングメトリクスが Managed Service for Prometheus によって収集されるようになります。コンポーネントを ARMS に統合する方法の詳細については、「コンポーネントの管理」をご参照ください。（「自己管理型 Prometheus インスタンスを使用して ASM インスタンスを監視する」を参照して、自己管理型 Prometheus インスタンスを統合して ASM インスタンスのメトリクスを収集している場合は、この手順を実行する必要はありません。）

2. ホストレベルのサーキットブレーキングのアラートルールを作成します。詳細については、「カスタム PromQL ステートメントを使用してアラートルールを作成する」をご参照ください。次の表は、アラートルールを設定するための主要なパラメーターを指定する方法について説明しています。その他のパラメーターの詳細については、前述のドキュメントをご参照ください。

   パラメーター	例	説明
   カスタム PromQL ステートメント	(sum (envoy_cluster_outlier_detection_ejections_active) by (cluster_name, namespace)) > 0	この例では、envoy_cluster_outlier_detection_ejections_active メトリクスをクエリして、現在のクラスタでホストが排出されているかどうかを判断します。クエリ結果は、サービスが存在する名前空間とサービス名でグループ化されます。
   アラートメッセージ	ホストレベルのサーキットブレーキングがトリガーされました。一部のワークロードでエラーが繰り返し発生し、ホストがロードバランシングプールから排出されました。名前空間: {$labels.namespace}}、ホストの排出が発生したサービス: {{$labels.cluster_name}}。排出されたホストの数: {{ $value }}	この例の警告情報は、サーキットブレーキングをトリガーしたサービスの名前空間、サービス名、および排出されたホストの数を示しています。