Fault Tolerance

マイクロサービス アーキテクチャでは、サービスは分散ネットワーク呼び出しの Web を形成します。これにより、チームはサービスを独立して構築および拡張できますが、システム全体の信頼性がその最も弱い部分と同じ程度にしか強くないことも意味します。重要なサービスがダウンしたり応答しなくなったりすると、アプリケーション全体が中断される連鎖的な障害が引き起こされる可能性があります。 単一の依存関係が失敗した瞬間に一般的な「500 Internal Server Error」または空白のページがユーザーに返されるのは、ユーザー エクスペリエンスが低下します。代わりに、回復力のあるシステムは、問題が発生した場合に正常に機能を低下させるように構築されています。 ここで、フォールバック パターンが登場します。プライマリ サービス呼び出しが失敗した場合に、安全な代替実行パスを定義することで、機能が低下した状態であってもアプリケーションの機能を維持できます。 このガイドでは、フォールバック パターン、フォールバック パターンを実装するための一般的な戦略、フォールバック パターンが他の復元パターンとどのように相互作用するか、Java (Resilience4j) と Go でフォールバック ロジックを記述する方法について説明します。 現実世界の例え: コーヒーショップのバックアップ計画 ラテを買うために地元のコーヒーショップに入ったと想像してください。バリスタが注文を入力しますが、カードをタップしようとすると、支払い端末が接続エラーを点滅させます。店のインターネットプロバイダーが停止しているためです。 コーヒーショップはすぐに照明を消し、ドアに鍵をかけて、すべての顧客を家に送り返しますか? もちろん違います。彼らは フォールバック戦略 を実装しています。 ※現金を持っている場合は、現金で支払えるか尋ねられます。 ※常連のお客様の場合、バリスタがお客様のお名前と注文を台帳に記載し、次回来店時にお支払いをお願いする場合がございます。 カード トークンをローカルに保存し、後でインターネットが回復したときに支払いを処理するオフライン カード リーダーを使用する場合があります。 ソフトウェア設計では: コーヒーの注文はクライアントのリクエストです。 カード ターミナルは、主要なダウンストリーム サービス (ペイメント ゲートウェイ API など) です。 インターネットの停止は、ネットワークのタイムアウトまたはサービスのクラッシュです。 レジャー/オフライン リーダーはフォールバック実行パスです。 一般的なフォールバック戦略 ビジネス ロジックと失敗したサービスの重要度に応じて、いくつかのフォールバック戦略から選択できます。

マイクロサービス アーキテクチャでは、サービスはメモリ内呼び出しではなくネットワーク経由で通信します。この分離により、大規模な水平スケーリングと独立した展開が可能になりますが、ネットワークの信頼性が低いという重大な脆弱性も生じます。 ダウンストリーム サービスでは、いつでも、短時間のネットワーク障害、一時的な CPU スパイク、データベース ロックの急速な競合、ローリング アップデートの再起動が発生する可能性があります。これらの一時的な障害は 一時的な障害 として知られています。 ダウンストリーム呼び出しが失敗した瞬間にサービスがすぐにエラーをスローし、リクエストを失敗させると、脆弱なユーザー エクスペリエンスが作成されます。代わりに、これらの一時的なエラーの多くは、少し待ってから再試行することで自動的に解決できます。ここで 再試行パターン が役に立ちます。 このガイドでは、再試行パターン、内部でどのように動作するか、単純な実装の危険性、Java (Resilience4j) と Go で再試行パターンを正しく実装する方法について説明します。 現実世界のたとえ: 話し中の回線にリダイヤルする あなたが友人に電話しようとしていると想像してください。あなたは相手の番号にダイヤルしますが、相手は現在別の通話中であるため、話中信号を受け取ります。 あなたはすぐに諦めて連絡先を削除し、二度と話せないと思い込んでいませんか?もちろん違います。電話を切り、少し待ってから、もう一度相手の番号をダイヤルします。まだ通話中の場合は、5 分待ってからもう一度試してください。 最終的に通話は終了し、再試行は成功します。 マイクロサービスでは: 呼び出しは、ダウンストリーム サービスへの API リクエストです。 ビジー信号は、一時的なネットワーク エラーまたは 503 Service Unavailable 応答です。 リダイヤルは再試行です。 待機時間はバックオフ期間です。 危険: 単純な再試行と「再試行の嵐」 再試行メカニズムの実装は、一見すると簡単に思えます。HTTP 呼び出しを for ループでラップし、成功するまで試行し続けるだけです。ただし、単純な再試行の実装では、軽微な問題がシステム全体の壊滅的な停止に簡単に変化する可能性があります。 突然のトラフィックの急増に苦戦しているダウンストリーム サービスを想像してください。データベースは 99% の CPU 使用率で実行されており、リクエストがタイムアウトし始めています。

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