Alibaba Cloud Service Mesh:ASM を使用したフォールトトレラントな分散システムの構築

フォールトトレランスメカニズムの選択

次の表は、ASM が提供するフォールトトレランスメカニズム、各メカニズムが対応する障害モード、およびそれを設定するリソースについて説明しています。

タイムアウトとリトライは単一のリクエストパスを制御しますが、バルクヘッドパターンと外れ値検出は、ターゲットサービスが受信する負荷と、どのホストが負荷分散プールに残るかを制御します。任意のリトライポリシーと同じルートにタイムアウトを設定してください。ルートのタイムアウトは、サイドカープロキシがリトライに費やす合計時間を制限します。

前提条件

このトピックで説明するメカニズムには、次の要件が適用されます。

• ASM インスタンスのバージョン — デフォルトの HTTP リクエストリトライポリシーを設定するには、バージョン 1.15.3.120 以降の ASM インスタンスが必要です。インスタンスのアップグレード方法の詳細については、「ASM インスタンスのアップグレード」をご参照ください。

• メトリクスのレポートと収集 — ホストレベルのサーキットブレーキングメトリクスは、サイドカープロキシがレポートし、Prometheus が収集した後にのみ利用可能になります。これらのメトリクスに依存する前に、「ホストレベルのサーキットブレーキングメトリクスの表示」および「ホストレベルのサーキットブレーキングメトリクスの収集とアラートの設定」で説明されている設定を完了してください。

タイムアウト

タイムアウトの仕組み

サービスがアップストリームサービスにリクエストを送信する際、アップストリームサービスが応答しない場合があります。リクエストの待機時間を設定します。待機時間が経過してもアップストリームサービスが応答しない場合、リクエストはアップストリームサービスを待ち続けるのではなく、即座に失敗します。

タイムアウトは、バックエンドサービスが応答しない場合にアプリケーションがエラーを確実に受け取れるようにし、アプリケーションが適切なフォールバック動作で障害を処理できるようにします。タイムアウトは、リクエストを送信するクライアントが応答を待つ時間を変更するものであり、ターゲットサービスがリクエストを処理する方法には影響しません。したがって、タイムアウトはリクエストされた操作が失敗したことを意味するわけではありません。

ルートタイムアウトの設定

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

次の仮想サービスは、httpbin アプリケーションへのルートのタイムアウトを設定します。

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

リトライ

リトライの仕組み

他のサービスへのリクエストが、リクエストタイムアウト、接続タイムアウト、サービス停止時間などのエラーで失敗した場合、リトライポリシーを設定すると、サイドカープロキシはそのサービスにリクエストを再送信します。

ルートのリトライポリシーの設定

ASM は、仮想サービスを使用して HTTP リクエストのリトライポリシーを定義することをサポートしています。次の例では、メッシュ内のサービスが 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 リトライ条件

次の表は、retryOn フィールドに設定できる一般的な HTTP リクエストのリトライ条件について説明しています。

gRPC リトライ条件

gRPC リクエストは HTTP/2 に基づいているため、HTTP リクエストのリトライポリシーの retryOn フィールドに gRPC のリトライ条件を設定することもできます。次の表は、一般的な gRPC リクエストのリトライ条件について説明しています。

デフォルトの HTTP リクエストリトライポリシーの設定

デフォルトでは、仮想サービスで HTTP リクエストのリトライポリシーを定義していなくても、メッシュ内のサービスは他の HTTP サービスにアクセスする際にデフォルトの HTTP リクエストリトライポリシーを適用します。デフォルトのリトライポリシーは、リトライ回数が 2、リトライタイムアウトなしで、デフォルトのリトライ条件として connect-failure、refused-stream、unavailable、cancelled、retriable-status-codes を使用します。インスタンスのデフォルトポリシーを上書きするには、ASM コンソールの [基本情報] ページでデフォルトの HTTP リクエストリトライポリシーを設定してください。

この機能には、サポートされている ASM インスタンスのバージョンが必要です。詳細については、「前提条件」をご参照ください。

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

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

3. 基本情報 ページの 設定情報 セクションで、デフォルトの HTTP リクエストリトライポリシー の横にある 編集 をクリックします。

4. デフォルトの HTTP リクエストリトライポリシー ダイアログボックスで、次の表に従って設定を構成し、OK をクリックします。

   設定を送信すると、新しい HTTP リクエストリトライポリシーがメッシュ内のサービスのデフォルトリトライポリシーを上書きします。

バルクヘッド

バルクヘッドパターンの仕組み

バルクヘッドパターンは、クライアントがターゲットサービスに対して行うことができる接続数とアクセスリクエスト数を制限し、単一のクライアントがそのサービスに過負荷をかけるのを防ぎます。設定されたしきい値を超えると、リクエストはドロップされます。バルクヘッドパターンは、サービスが使用するリソースを分離し、連鎖障害を回避するのに役立ちます。

最大接続数と接続タイムアウトは、TCP と HTTP の両方に有効な一般的な接続設定ですが、接続あたりの最大リクエスト数と保留中のリクエストの最大数は、HTTP/1.1、HTTP/2、および gRPC 接続にのみ有効です。

接続プールの制限の設定

ASM は、宛先ルールを使用してバルクヘッドパターンを設定することをサポートしています。次の宛先ルールでは、他のサービスから httpbin アプリケーションへのリクエストは、1 つの TCP 接続、接続あたり 1 つのリクエスト、および 1 つの保留中のリクエストに制限されます。これらの接続プールのしきい値を超えるリクエストは、503 応答で拒否されます。サイドカープロキシは、サービスのホストへの接続を確立するために最大 10 秒間待機します。

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

サーキットブレーキング

このセクションでは、宛先ルールを使用して設定する外れ値検出について説明します。ASM は、別のサーキットブレーキングメカニズムである ASMCircuitBreaker も提供します。外れ値検出では、クライアント上のサイドカープロキシが各アップストリームサービスホストのエラー率を個別に検出し、そのホストが連続してエラーを生成した場合に、サービスの負荷分散プールからホストを除外します。

外れ値検出の仕組み

サーキットブレーキングとは、応答しないサービスにリクエストを繰り返し送信しないようにする仕組みです。代わりに、特定の期間内に発生する障害の数が監視されます。

エラー率がしきい値を超えると、サーキットブレーカーはリクエストをドロップし、サーキットブレーカーが閉じるまですべての後続リクエストは失敗します。

外れ値検出の設定

ASM は、宛先ルールを使用して外れ値検出を設定することをサポートしています。次の宛先ルールでは、サイドカープロキシは 5 秒ごとに httpbin アプリケーションのホストをスキャンして除外対象を検出します。3 回連続でエラーを生成したホストは、httpbin の負荷分散プールから少なくとも 5 分間除外されます。除外されなかったホストは、maxEjectionPercent が設定する除外制限内で、他のサービスからのリクエストを引き続き処理します。この例で使用されている値のリスクについては、次の表の maxEjectionPercent の行をご参照ください。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 3
      interval: 5s
      baseEjectionTime: 5m
      maxEjectionPercent: 100

ホストレベルのサーキットブレーキングメトリクスの表示

ASM のホストレベルのサーキットブレーキングは、サーキットブレーキングが発生したかどうかを判断するのに役立つ一連の関連メトリクスを生成します。次の表は、これらのメトリクスの一部を示しています。

これらのメトリクスを利用可能にするには、サイドカープロキシの proxyStatsMatcher 設定を構成して、サイドカープロキシが関連メトリクスをレポートするようにし、その後 Prometheus を使用してサーキットブレーキングに関連するメトリクスを収集および表示します。次の手順を順番に実行してください。

1. proxyStatsMatcher を使用して、サーキットブレーキングメトリクスをレポートするようにサイドカープロキシを設定します。proxyStatsMatcher を設定する際は、[Regular Expression Match] を選択し、値を .*outlier_detection.* に設定します。詳細については、「proxyStatsMatcher」をご参照ください。

2. httpbin ステートレスワークロードを再デプロイします。詳細については、「ワークロードの再デプロイ」をご参照ください。

ホストレベルのサーキットブレーキングメトリクスの収集とアラートの設定

ホストレベルのサーキットブレーキングメトリクスのレポートを設定した後、関連するメトリクスを Prometheus に収集し、主要なメトリクスに基づいてアラートルールを設定することで、サーキットブレーキングが発生した際に迅速にアラートを受け取ることができます。以下の手順では、Managed Service for Prometheus を使用して、ホストレベルのサーキットブレーキングメトリクスの収集とアラートの設定方法について説明します。

1. Managed Service for Prometheus で、データプレーンクラスター用の [Alibaba Cloud ASM] コンポーネントを統合するか、最新バージョンにアップグレードして、Managed Service for Prometheus が公開されたサーキットブレーキングメトリクスを収集できるようにします。統合コンポーネントの更新方法の詳細については、「統合コンポーネントの管理」をご参照ください。(「メッシュモニタリングのためのセルフマネージド Prometheus の統合」に従ってサービスメッシュメトリクスを収集するセルフマネージド Prometheus インスタンスを設定している場合は、この手順を実行する必要はありません。)

2. ホストレベルのサーキットブレーキングのアラートルールを作成します。詳細については、「カスタム PromQL クエリを使用した Prometheus アラートルールの作成」をご参照ください。次の表に、アラートルールの主要なパラメーターの入力例を示します。残りのパラメーターは、前述のドキュメントを参照して、独自の要件に基づいて入力できます。