次の方法で共有

部分的な障害を処理するための戦略

ヒント

このコンテンツは、.NET Docs で入手できる、またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、コンテナー化された .NET アプリケーションの電子ブックである .NET マイクロサービス アーキテクチャからの抜粋です。

PDF をダウンロードする

コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャの電子ブックの表紙サムネイル。

部分的な障害に対処するには、ここで説明するいずれかの方法を使用します。

内部マイクロサービス間で非同期通信 (メッセージ ベースの通信など) を使用します。 内部マイクロサービス全体で同期 HTTP 呼び出しの長いチェーンを作成しないことを強くお勧めします。その設計が最終的に不適切な停止の主な原因になるためです。 逆に、クライアント アプリケーションとマイクロサービスまたはきめ細かい API ゲートウェイの第 1 レベル間のフロントエンド通信を除き、内部マイクロサービス全体で、最初の要求/応答サイクルを過ぎた後に非同期 (メッセージベース) 通信のみを使用することをお勧めします。 最終的な整合性とイベントドリブン アーキテクチャは、波及効果を最小限に抑えるのに役立ちます。 これらのアプローチでは、より高いレベルのマイクロサービスの自律性が強制されるため、ここで説明した問題を回避できます。

指数バックオフで再試行を使用します。 この手法は、サービスが短時間しか使用できなかった場合に、呼び出しの再試行を一定回数実行することで、短い間欠的なエラーを回避するのに役立ちます。 これは、断続的なネットワークの問題や、マイクロサービス/コンテナーがクラスター内の別のノードに移動された場合に発生する可能性があります。 ただし、これらの再試行がサーキット ブレーカーで適切に設計されていない場合は、波及効果を悪化させ、最終的には サービス拒否 (DoS) を引き起こす可能性があります。

ネットワーク タイムアウトを回避します。 一般に、クライアントは無期限にブロックしないようにし、応答を待機するときに常にタイムアウトを使用するように設計する必要があります。 タイムアウトを使用すると、リソースが無期限に関連付けられなくなります。

サーキット ブレーカー パターンを使用する。 この方法では、クライアント プロセスは失敗した要求の数を追跡します。 エラー率が構成された制限を超えると、"サーキット ブレーカー" がトリップし、それ以降の試行はすぐに失敗します。 (多数の要求が失敗した場合は、サービスが利用できず、要求の送信が無意味であることを示します)。タイムアウト期間が経過すると、クライアントは再試行し、新しい要求が成功した場合は、サーキット ブレーカーを閉じます。

フォールバックを提供します。 この方法では、クライアント プロセスは、キャッシュされたデータや既定値の返しなど、要求が失敗したときにフォールバック ロジックを実行します。 これはクエリに適したアプローチであり、更新やコマンドに対してより複雑です。

キューに入る要求の数を制限します。 クライアントは、クライアント マイクロサービスが特定のサービスに送信できる未処理の要求の数に上限を課す必要もあります。 制限に達した場合、追加の要求を行うのはおそらく無意味であり、これらの試行はすぐに失敗します。 実装に関しては、Polly Bulkhead 分離 ポリシーを使用してこの要件を満たすことができます。 このアプローチは、基本的には、実装として SemaphoreSlim を使用した並列化スロットルです。 また、バルクヘッドの外側にある待機列も許可されます。 (たとえば、容量がいっぱいと見なされるため) 実行前でも、余分な負荷を事前に取り除くことができます。 これにより、サーキットブレーカーが障害を検出してから応答するまでの時間を要するのに対し、特定の障害シナリオに対する応答がより迅速になります。 Polly の BulkheadPolicy オブジェクトは、バルクヘッドとキューの完全な量を公開し、オーバーフロー時のイベントを提供するため、自動水平スケーリングを推進するためにも使用できます。

その他のリソース

前へ次へ