サーキットブレーカーの設計パターン

サーキットブレーカーは、ソフトウェア開発で使用される設計パターンです。障害を検出するために使用され、メンテナンス中、一時的な外部システム障害、予期しないシステム障害時に障害が頻繁に発生するのを防ぐロジックをカプセル化します。サーキットブレーカーパターンは、特に分散システムで連鎖的な障害を防ぎます。^[1]

マーク・ブルッカーによると、サーキットブレーカーは部分的な障害をシステム全体の障害と誤認し、誤ってシステム全体をダウンさせる可能性がある。特に、シャードシステムとセルベースのアーキテクチャはこの問題に対して脆弱である。回避策としては、サーバーがクライアントにどの部分が過負荷になっているかを示し、クライアントが対応するミニサーキットブレーカーを使用することである。ただし、この回避策は複雑でコストがかかる可能性がある。^{[2] [3]}

サーキットブレーカーパターンは、再試行、フォールバック、タイムアウトパターンなどの他のパタ​​ーンと併用する必要があります。これにより、システムのフォールトトレランスが向上します。^[4]

アプリケーションが 1 秒間に 100 回データベースに接続し、データベースに障害が発生したとします。アプリケーション設計者は、同じエラーが頻繁に発生することを望んでいません。また、TCP 接続のタイムアウトを待たずに、エラーを迅速かつ適切に処理したいと考えています。

一般的に、Circuit Breaker は外部サービスの可用性を確認するために使用できます。外部サービスとは、アプリケーションが使用するデータベース サーバーまたは Web サービスです。

サーキット ブレーカーは障害を検出し、アプリケーションが失敗する可能性のあるアクションを実行できないようにします (再試行しても安全になるまで)。

サーキット ブレーカー デザイン パターンの実装では、一連のリクエストにわたって接続の状態を保持する必要があります。実際のリクエストから障害を検出するロジックをオフロードする必要があります。したがって、サーキット ブレーカー内のステート マシンは、通過するリクエストとある意味で同時に動作する必要があります。これを実現する 1 つの方法は、非同期です。

マルチノード (クラスター化) サーバーでは、上流サービスの状態をクラスター内のすべてのノードに反映する必要があります。したがって、実装では、アプリケーションにとって外部サービスであるものの可用性を記録するために、 MemcachedやRedisなどのネットワーク キャッシュ、またはローカル キャッシュ (ディスクまたはメモリ ベース) などの永続ストレージ レイヤーを使用する必要がある場合があります。

Circuit Breaker は、指定された間隔で外部サービスの状態を記録します。

アプリケーションから外部サービスが使用される前に、ストレージ層がクエリされ、現在の状態が取得されます。

メリットが結果を上回ると言っても過言ではありませんが、サーキット ブレーカーを実装すると、ストレージ スペース、アプリケーションの複雑さ、実行中のアプリケーションの計算コストに悪影響を及ぼします。これは、サーキットの状態を確認するために実行パスに追加のコードが追加されるためです。これは、以下の PHP の例で確認できます。データベースの状態を確認するために APC を確認すると、数サイクル余分にかかります。また、サーキット ブレーカー コード自体を実行すると、それが実行されるシステムのリソースが消費されるため、「実際の」アプリケーションに残される実行パワーが少なくなります。^{[なぜ? ]}

どの程度かは、使用されるストレージ層と一般に利用可能なリソースによって異なります。この点で最大の要因となるのは、キャッシュの種類です。たとえば、ディスクベースかメモリベースか、ローカルかネットワークかなどです。

• 閉鎖
• 開ける
• 半開き

すべてが正常な場合、回路ブレーカーは閉じたままで、すべてのリクエストは以下に示すようにサービスに渡されます。障害の数がしきい値を超えて増加すると、回路ブレーカーがトリップして開いた状態になります。

この状態では、サーキット ブレーカーはサービスを呼び出すことなく、すぐにエラーを返します。タイムアウト期間が経過すると、サーキット ブレーカーは半開状態に移行します。通常、タイムアウトが指定される監視システムがあります。

この状態では、サーキット ブレーカーは、サービスからの限られた数の要求が通過して操作を呼び出すことを許可します。要求が成功すると、サーキット ブレーカーはクローズ状態になります。ただし、要求が引き続き失敗すると、オープン状態に戻ります。

以下は PHP でのサンプル実装です。概念実証では、MySQL サーバーのステータスを共有メモリ キャッシュ (APC ユーザー キャッシュ) に保存します。

次のスクリプトは、 crontabを通じて設定された間隔で実行できます。

$mysqli  =  new  mysqli ( "localhost" 、 "ユーザー名" 、 "パスワード" );

if  ( $mysqli -> connect_error )  { 
    apcu_add ( "dbStatus" ,  "down" ); 
}  else  { 
    apcu_add ( "dbStatus" ,  "up" ); 
    $mysqli -> close (); 
}

if  ( apcu_fetch ( "dbStatus" )  ===  "down" )  { 
    echo  "データベースサーバーは現在利用できません。 1 分後にもう一度お試しください。" ; 
    exit ; 
}

$mysqli  =  new  mysqli ( "localhost" 、 "username" 、 "password" 、 "database" ); 
$result  =  $mysqli -> query ( "SELECT * FROM table" );

• 図による PHP 実装の例
• C# を使用した Polly の再試行パターンの例
• Anders Lybeckers による Polly を使用した C# 実装の例
• Polly NuGet パッケージ
• Alexandr Nikitin による C# 実装の例
• Pythonでの実装
• RESTfulアーキテクチャに適用される安定性パターン
• マーティン・ファウラー・ブリキ