【レジリエンス設計パターン】 レジリエンス設計パターン：リトライ、ロールバック、タイムアウト、サーキットブレーカー

レジリエンスとは何ですか?

ソフトウェアはそれ自体が目的ではありません。ビジネス プロセスをサポートし、顧客を満足させ続けます。ソフトウェアが運用環境で実行されていなければ、価値を生み出すことはできません。ただし、生産的なソフトウェアは正しく、信頼性があり、使用可能である必要もあります。

ソフトウェア設計の回復力に関して言えば、主な目標は、その範囲内の障害だけでなく、依存する他のコンポーネントの障害も許容できる堅牢なコンポーネントを構築することです。自動フェイルオーバーや冗長性などの技術によりコンポーネントの耐障害性を高めることができますが、今日のほぼすべてのシステムは分散されています。単純な Web アプリケーションであっても、Web サーバー、データベース、ファイアウォール、プロキシ、ロード バランサー、およびキャッシュ サーバーを含めることができます。また、ネットワークインフラ自体も多くのコンポーネントで構成されているため、必ずどこかで障害が発生します。

完全に障害が発生した場合に加えて、サービスの応答に時間がかかる場合もあります。実際、応答形式は正しいにもかかわらず、セマンティクスに対して間違った方法で応答する可能性さえあります。同様に、システムに含まれるコンポーネントが多いほど、障害が発生する可能性が高くなります。

一般に、ユーザビリティは重要な品質特性と考えられています。これは、コンポーネントが使用可能であるべき時間と比較して、コンポーネントが実際に使用可能である時間を表します。それは次の式で表すことができます。

従来のアプローチは稼働時間を増やすことを目的としていますが、最新のアプローチは回復時間を短縮してダウンタイムを削減することを目的としています。これは、障害を何としても阻止したり、障害が発生したときに長期間利用できなくなるのではなく、障害に対処できるため便利です。Uwe Friedrichsen は、回復力のある設計パターンを、疎結合、分離、遅延制御、監視の 4 つのカテゴリに分類しています。

このブログ投稿では、レイテンシ制御カテゴリ内の 4 つのパターン (再試行、フォールバック、タイムアウト、サーキット ブレーカー) を見ていきたいと思います。理論を紹介した後、Eclipse Vert.x を使用してこれらのパターンを実際に適用する方法を見ていきます。この投稿は、代替実装について説明し、調査結果を要約することで終了します。

モデル

例のシーン

パターンの機能を説明するために、非常に単純な使用例を使用します。決済サービスがショッピング プラットフォームの一部であると想像してください。顧客が支払いを希望する場合、支払いサービスは不正な意図がないことを確認する必要があります。そのために、同社は不正行為チェックサービスを要請した。

この場合、当社のサービスは HTTP ベースのインターフェースを提供します。トランザクションを確認するために、Payment Service は HTTP リクエストを Fraud Check Service に送信します。すべてが正常であれば、トランザクションが不正であったかどうかを示すブール値を含む 200 応答が返されます。しかし、不正行為チェックサービスが応答しない場合はどうなるでしょうか? 内部サーバー エラー (500) が返された場合はどうなりますか?

ここでは、考えられるコミュニケーションの問題を解決するための具体的な 4 つのパターンを見てみましょう。これは特定の例ですが、信頼性の低いチャネルを介して信頼性の低いサービスと通信することを伴う他のコンスタレーションを想像することができます。

リトライ

予期しない応答 (または応答の欠如) がリクエストを再送信することで解決できると想定される場合は、再試行パターンを使用すると役立ちます。これは非常に単純なパターンで、失敗したリクエストは、操作が失敗としてマークされる前に、構成可能な回数だけ再試行されます。

以下のアニメーションは、不正な小切手を発行しようとする決済サービスを示しています。最初のリクエストは、Fraud Check サービスの内部サーバー エラーにより失敗しました。決済サービスはリクエストを再試行し、取引が不正ではないという回答を受け取ります。

再試行は次のような場合に役立ちます。

• パケットロスなどの一時的なネットワーク問題

• ターゲット サービスの内部エラー (例: データベースの停止が原因)

• ターゲットサービスへの大量のリクエストが原因で応答しない、または応答が遅い

ただし、ターゲット サービスの過負荷が問題の原因である場合、再試行によって問題がさらに悪化する可能性があることに注意してください。復元モードがサービス拒否攻撃に変わるのを避けるために、再試行を指数関数的バックオフやサーキット ブレーカーなどの他の技術と組み合わせることができます (以下を参照)。

後退する

フォールバック パターンを使用すると、別のサービスへのリクエストが失敗した場合でもサービスの実行を継続できます。応答がない場合に計算を中止する代わりに、代替値を入力します。

以下のアニメーションも、支払いサービスが不正チェック サービスにリクエストを行っている様子を示しています。同様に、Fraud Check サービスは内部サーバー エラーを返します。ただし、今回はトランザクションが不正ではないことを前提としたフォールバックを使用します。

代替値は常に可能であるとは限りませんが、慎重に使用すれば、全体的な回復力を大幅に向上させることができます。上記の例では、不正チェック サービスが利用できない場合、トランザクションを不正ではないものとして扱うことに戻るのは危険である可能性があります。最初にサービスにスパムを送信し、次に不正なトランザクションを実行しようとする不正なトランザクションの攻撃対象領域を開くことさえあります。

一方、フォールバックがすべてのトランザクションが不正であると想定する場合、支払いは行われず、フォールバックは基本的に役に立ちません。適切な妥協策は、リスクと顧客を失わないことの間で適切なバランスをとるために、単純なビジネス ルール (かなり少数のトランザクションを単に通過させるなど) に戻ることかもしれません。

タイムアウト (タイムアウト)

タイムアウト スキームは非常に単純で、多くの HTTP クライアントにはデフォルトのタイムアウトが設定されています。目標は、応答に対する無限の待機時間を回避することです。これにより、タイムアウト内に応答が受信されない場合、各要求は失敗したと見なされます。

以下のアニメーションは、決済サービスが不正チェック サービスからの応答を待機し、タイムアウト後に操作を中止する様子を示しています。

ほぼすべてのアプリケーションは、リクエストが永久にスタックすることを避けるためにタイムアウトを使用します。ただし、タイムアウトへの対処は簡単ではありません。オンライン ストアでの注文がタイムアウトになったと想像してください。注文が正常に行われたかどうかはわかりませんが、注文の作成がまだ進行中である場合、またはリクエストが処理されなかった場合、応答はタイムアウトになります。タイムアウトと再試行を組み合わせると、注文が重複する可能性があります。注文を失敗としてマークすると、顧客は注文が成功しなかったと考えるかもしれませんが、実際には成功した可能性があり、料金が請求されます。

また、タイムアウトは、遅い応答が到着するのに十分な長さである必要がありますが、決して到着しない応答の待機を停止するのに十分な低さである必要があります。

ブレーカ

電子機器において、サーキット ブレーカーはコンポーネントを過負荷による損傷から保護するスイッチです。ソフトウェアでは、サーキット ブレーカーは、高負荷のためにサービスがすでに部分的に利用できないときに、サービスをスパム攻撃から保護します。

Martin Fowler がサーキットブレーカーのパターンについて説明しています。これは、クローズ (リクエストは自由に流れることができる)、オープン (リクエストは拒否され、リモート リソースに送信されない)、およびハーフ オープン (プローブ リクエストにより、リクエストが自由に流れることができる)、ハーフ オープン (プローブ リクエストが許可されるかどうかを決定できる) の 3 つの状態を切り替えるステートフル ソフトウェア コンポーネントとして実装できます。回路を閉じます)。以下のアニメーションは、サーキット ブレーカーの動作を示しています。

決済サービスから不正チェック サービスへのリクエストはサーキット ブレーカーを通過します。2 つの内部サーバー エラーの後、回線が開かれ、後続のリクエストはブロックされました。しばらく待つと回路は半開状態になります。この状態では、リクエストの通過が許可され、失敗した場合はオープンに戻り、成功した場合はクローズに戻ります。次のリクエストは成功するため、回線は再び閉じます。

サーキット ブレーカーは、特に再試行、タイムアウト、フォールバックと組み合わせる場合に便利なツールです。フォールバックは、障害が発生した場合だけでなく、開回路が発生した場合にも使用できます。次のセクションでは、Kotlin で記述された Vert.x コードの例を見ていきます。

Vert.x での実装

前のセクションでは、理論的な観点からさまざまな弾性モードを調査しました。では、それらを実装する方法を見てみましょう。この例のソース コードは GitHub で入手できます。このデモでは Vert.x と Kotlin を使用します。他の代替案については、次のセクションで説明します。

Vert.x は、再試行、フォールバック、タイムアウト、サーキット ブレーカー構成の任意の組み合わせをサポートする強力なデコレータ クラスである CircuitBreaker を提供します。以下に示すように、CircuitBreakerOptions クラスを使用してサーキット ブレーカーを構成できます。

val vertx = Vertx.vertx()
val options = circuitBreakerOptionsOf(
    fallbackOnFailure = false,
    maxFailures = 1,
    maxRetries = 2,
    resetTimeout = 5000,
    timeout = 2000
)
val circuitBreaker = CircuitBreaker.create("my-circuit-breaker", vertx, options)

この例では、操作を失敗とみなす前に 2 回再試行するサーキット ブレーカーを作成しています。障害の後、回路が開きますが、5000 ミリ秒後には再び半開になります。操作は 2000 ミリ秒後にタイムアウトしました。フォールバックが指定されている場合、フォールバックは開回路の場合にのみ呼び出されます。回路ブレーカーは、回路が閉じている場合でも、障害が発生した場合にフォールバックを呼び出すように構成することもできます。

コマンドを実行するには、Handler<Future<T>> 型のハンドラーと、結果を処理する Handler<AsyncResult<T>> 型のハンドラーを実行する非同期コードを提供する必要があります。OK を返し、その後出力する最小限の例は次のようになります。

circuitBreaker.executeCommand(
    Handler<Future<String>> {
        it.complete("OK")
    },
    Handler {
        println(it)
    }
)

Kotlin で Vert.x を使用する場合、ハンドラーを使用する代わりに、サスペンド関数を引数として渡すこともできます。詳細については、CoroutineHandlerFactory クラスとその使用法を参照してください。これらの基本機能に加えて、Vert.x サーキット ブレーカー モジュールは次の高度な機能も提供します。

• イベントバスの通知。サーキット ブレーカーは、状態が変化するたびにイベント バスにイベントを発行できます。これは、これらのイベントに何らかの方法で反応したい場合に便利です。

• 索引。サーキット ブレーカーは、Hystrix ダッシュボードでサーキット ブレーカーの状態を視覚化するために使用されるメトリクスを公開できます。

• 状態変更コールバック。回線の開閉時に呼び出されるカスタム ハンドラーを構成できます。

代替実装

すべてのフレームワークがすぐに柔軟なデザイン パターンをサポートしているわけではありません。Vert.x は、すべての可能なモードをサポートしているわけではありません。Hystrix、resilience4j、failsafe、Istio の復元機能など、復元力のトピックに直接取り組む指定されたプロジェクトがいくつかあります。

Hystrix は多くのアプリケーションで使用されてきましたが、現在は積極的な開発は行われていません。Hystrix、resilience4j、failsafe はすべて、アプリケーションのソース コードから直接呼び出されます。たとえば、インターフェイスを実装したり、アノテーションを使用したりすることで統合できます。

一方、Istio はサービス メッシュであるため、アプリケーション コードではなくインフラストラクチャの一部です。これは、分散サービス システムを調整し、サイドカーの概念を実装するために使用されます。サービス通信は、サービス プロセスと並行する専用プロセスであるサイドカーを通じて行われます。これにより、サイドカーは再試行などのメカニズムを処理できるようになります。

サイドカー アプローチの利点は、ビジネス ロジックと弾力性ロジックを混在させないことです。多くのアプリケーション コードを関与させることなく、サイドカー テクノロジを置き換えることができます。また、サービスを再デプロイすることなく、サイドカー構成を簡単に変更および調整できます。欠点は、スレッド プール分離のためのバルクヘッドなどの特定のモードを使用できないことです。また、フォールバック値などのパターンはビジネス ロジックに大きく依存します。また、新しいインフラストラクチャ コンポーネントを追加するよりも、既存のコード ベースを拡張する方が簡単な場合もあります。

要約する

この投稿では、疎結合、分離、レイテンシー制御、監視がシステムの回復力にどのようにプラスの影響を与えるかを説明しました。再試行モードは、複数回試行することで修正できる通信エラーを処理します。フォールバック モードは、通信障害をローカルで解決するのに役立ちます。タイムアウト モードは、レイテンシの上限を提供します。サーキット ブレーカーは、持続的な通信エラーの場合の再試行と高速フォールバックによる予期しないサービス拒否攻撃の問題を解決します。

Vert.x のようなフレームワークは、すぐに使用できるいくつかの伸縮性のあるパターンを提供します。あらゆるフレームワークで使用できる専用のエラスティック ライブラリもあります。一方、サービス メッシュは、インフラストラクチャ レベルで柔軟なパターンを導入するためのオプションとして存在します。いつものことですが、万能のソリューションは存在せず、何が最適かを見つけるのはチーム次第です。

この記事: https://architect.pub/resilience-design-patterns-retry-fallback-timeout-circuit-break
ディスカッション: Knowledge Planet [チーフ アーキテクト サークル] または WeChat トランペット [ca_cto] を追加するか、QQ グループを追加します [792862318]
一般公開なし	【jiagoushipro】 【スーパーアーキテクト】 アーキテクチャの方法論、アーキテクチャの実践、技術原則、技術トレンドについての鮮やかなグラフィックと詳細な説明。 お待ちしておりますので、ぜひスキャンしてご注目ください。
WeChatのトランペット	[ca_cea] エンタープライズ アーキテクチャ、クラウド コンピューティング、ビッグ データ、データ サイエンス、モノのインターネット、人工知能、セキュリティ、フルスタック開発、DevOps、デジタル化について議論する 50,000 人のコミュニティ。
QQグループ	[285069459] エンタープライズ アーキテクチャ、ビジネス アーキテクチャ、アプリケーション アーキテクチャ、データ アーキテクチャ、技術アーキテクチャ、統合アーキテクチャ、セキュリティ アーキテクチャの詳細な交換。そして、ビッグデータ、クラウドコンピューティング、モノのインターネット、人工知能などのさまざまな新興テクノロジー。 QQ グループに参加して、貴重なレポートや乾物を共有してください。
ビデオ番号	【スーパーアーキテクト】 建築に関する基本的な概念、モデル、手法、経験が1分ですぐに理解できます。 1日1分、仕組みはおなじみです。
知識の惑星	[チーフアーキテクトサークル] 著名人に質問したり、連絡を取ったり、プライベートな情報を共有したりしてください。
ヒマラヤ	[スーパーアーキテクト] 最新のブラックテクノロジー情報と建築体験を道路や車の中で学びましょう。	[知的な瞬間、ミスター・アーキテクチャーがブラックテクノロジーについて語ります]
知識の惑星	より多くの友人、職場、技術的なチャットに会いましょう。	ナレッジプラネット【職場とテクノロジー】
リンクトイン	ハリー	https://www.linkedin.com/in/architect-harry/
LinkedInグループ	LinkedIn アーキテクチャ グループ	https://www.linkedin.com/groups/14209750/
微博	【スーパーアーキテクト】	賢い瞬間‍
ビリビリ	【スーパーアーキテクト】
チクタク	【cea_cio】スーパーアーキテクト
早い労働者	【cea_cio_cto】スーパーアーキテクト
小さな赤い本	[cea_csa_cto] スーパーアーキテクト
Webサイト	CIO（最高情報責任者）	https://cio.ceo
Webサイト	CIO、CTO、CDO	https://cioctocdo.com
Webサイト	アーキテクトの実践的な共有	https://architect.pub
Webサイト	プログラマーによるクラウド開発の共有	https://pgmr.cloud
Webサイト	チーフアーキテクトコミュニティ	https://jiagoushi.pro
Webサイト	開発者チャット	https://ブログ.開発者.チャット
Webサイト	CPOコレクション	https://cpo.work

ご清聴、転送、いいね、ご視聴ありがとうございます。