Bulkhead Pattern

マイクロサービス アーキテクチャでは、単一のアプリケーションが数十または数百の独立した連携サービスに分割されます。この設計により、モジュール性とスケーラビリティが向上しますが、1 つのサービスで障害が発生すると連鎖的にシステム全体が停止する可能性があります。 という大きなリスクも伴います。 ダウンストリーム サービスが遅くなったり応答しなくなったりすると、アップストリーム サービスへの受信リクエストが蓄積され始めます。すべてが同じメモリ、CPU、またはスレッド プールを共有している場合、依存関係が遅いと利用可能なリソースがすぐに使い果たされ、アプリケーション全体がクラッシュする可能性があります。 この連鎖的な失敗はドミノ効果として知られています。これを防ぐために、システム設計者は バルクヘッド パターン を使用します。 このガイドでは、簡単な例え話、アーキテクチャ上の概念、Java (Resilience4j) と Go のコード例を使用して、バルクヘッド パターンとは何か、その仕組み、実装方法について説明します。 現実世界のたとえ: 船の防水隔壁 このパターンの名前は造船業界に由来しています。 隔壁 は、船の船体の内側に作られた水密壁です。船体の内部に単一の巨大なオープンスペースがあるのではなく、内部はいくつかの独立した密閉されたコンパートメントに分割されています。 船が障害物に衝突して船体が破損すると、損傷した区画に水が浸入します。ただし、水密隔壁のおかげで、水はその 1 つのコンパートメントに閉じ込められます。船の残りの部分は乾いていて浮力があるため、浮いたまま安全な場所に到達できます。 隔壁がなければ、水が船体全体を自由に流れ、最終的には船が沈没してしまいます。 ソフトウェアエンジニアリングでは: Ship はアプリケーションまたはサービス全体です。 コンパートメントは、分離されたリソース プール (スレッド、接続、CPU) です。 ハル違反 とは、下流のマイクロサービスでの障害または速度低下です。 フラッディングはリソースの枯渇です。 問題: 共有リソース プールとスレッドの枯渇 なぜバルクヘッドが必要なのかを理解するために、リソースがグローバルに共有される場合に何が起こるかを見てみましょう。 ユーザーリクエストを処理する API ゲートウェイまたは Web サーバーを想像してください。すべての着信呼び出しを処理するための 100 スレッドからなる単一のグローバル スレッド プールがあります。サーバーは 3 つのダウンストリーム サービスと対話します。