サーキットブレーカーは、ローカルエージェントのワークフローで障害が発生した外部ツールの影響をどのように封じ込めるのか？

サーキットブレーカーは、繰り返しの呼び出しを停止し、制御された結果を返し、通常のトラフィックを復旧させる前に回復を検証することで、障害が発生している外部ツールを封じ込めます。

ローカルエージェントは、クラウドモデル、検索API、通知サービス、リモートのスマートホームブリッジなどに依存しながら、ワークフローの他の部分を正常に実行することがあります。封じ込めの境界がなければ、1つの遅い依存先がエージェントの時間予算を使い果たし、さらなるリトライを引き起こす可能性があります。サーキットブレーカーは、その不確かなリモート状態を、オーケストレーターが判断できる明示的なローカル状態に変換します。

ブレーカーはツール選択と外部実行の間に配置される

通常、エージェントはツールを選択し、引数を検証してから、呼び出しをエグゼキューターに渡します。サーキットブレーカーは、この最後の境界にステートフルなラッパーを追加します。モデルが要求した内容を変更するのではなく、エグゼキューターが依存先に接続すべきか、ローカルで試行を拒否すべきか、または限定的な回復プローブを許可すべきかを判断します。

このラッパーは完了した呼び出しを監視し、成功、タイムアウト、トランスポート障害、レート制限、その他の設定済みの失敗シグナルなどに結果を分類します。一般的なサーキットブレーカーパターンはリモート呼び出しをラップし、失敗を追跡してしきい値を超えるとオープンし、その後テストリクエストを許可します。これにより、依存先の健全性をモデルのプロンプトレベルの判断から切り離せます。

したがって、直接の出力は単なるツール例外ではありません。ブレーカーの状態、実行が試行されたかどうか、どの継続経路がまだ許可されているかを含む、構造化されたオーケストレーション結果です。

直近の失敗は状態遷移に圧縮される

クローズ状態では、ブレーカーは呼び出しを通過させ、ポリシーに関連する結果だけを記録します。そのため、単発のタイムアウトだけで有用なツールが無効になるとは限りません。一般的な実装では、直近の件数、割合、または時間ウィンドウを評価し、ローカルの証拠が設定された失敗または低速呼び出しのしきい値を超えた場合にのみオープンします。

しきい値によって、多数のノイズの多いイベントが1つの安定した制御判断に変換されます。エラー率のしきい値を設けると、ネットワーク障害中に、要求された操作ごとに新たな接続を確立して失敗するのではなく、接続の過剰な再試行を抑えられます。

何を失敗とみなすかは、ツールの契約に合わせる必要があります。認証拒否、不正な引数、恒久的に存在しないリソースは、レイテンシー、一時的な利用不能、レート制限とは通常異なる扱いが必要です。

割合のしきい値にも、意味のある十分な観測数が必要です。1回の失敗でオープンすると、利用頻度の低いツールが不安定になります。一方、大きなサンプルを待つと、頻繁に失敗する依存先を長く稼働させすぎる可能性があります。そのため、サンプリングウィンドウと最小呼び出し数は、言語モデルではなくブレーカーポリシーに属します。

オープン状態の回路はリモート待機をローカル失敗に変える

ブレーカーがオープンすると、エグゼキューターは明示的なクールダウン時間の間、その依存先への接続を停止します。そのため、新たな試行は別のリモートタイムアウトを待つのではなく、ローカルで失敗します。健全なローカルツール、検索ステップ、推論処理は、失敗した依存先のレイテンシーを引き継がずに継続できます。

このフェイルファスト経路は、遅延だけでなくリソースへの負荷も封じ込めます。繰り返されるリモート呼び出しは、待機中にソケット、ワーカースロット、メモリ、キュー内のタスクを保持する可能性があるためです。外部呼び出し用の追加容量を確保する前に操作を拒否することで、継続的な障害中のリソース枯渇を抑えられます。

封じ込めは全体ではなく選択的に行われます。読み取りと書き込みでは失敗時のコストが異なる場合があるため、通常、ブレーカーは1つの依存先、さらに操作クラス単位にスコープを設定すべきです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

リトライとタイムアウトはブレーカーが観測する内容を変える

リトライは一時的だと考えられる失敗に対処する一方、サーキットブレーカーは失敗が継続的になり、試行を停止すべき状態になったことを記憶します。そのため、両者の配置によってブレーカーが確認する証拠が変わります。保護対象の1回の実行内で行われるリトライは、1つの論理呼び出しとして数えられる場合がありますが、ブレーカーの外側で行われるリトライは、それぞれ別の失敗サンプルを追加する可能性があります。

タイムアウトは、低速な呼び出しがいつ失敗サンプルになるかも定義します。レジリエンスパターンでは、それぞれ異なる失敗境界を担うため、タイムアウト、リトライ、サーキットブレーカーを分けて扱います。

ツールに冪等でない副作用がある場合、この分離は特に重要になります。同じツール呼び出しの反復ループは、モデルの判断から発生することもあれば、モデルより下位のリトライ層から発生することもあります。また、タイムアウトした書き込みによって外部システムがすでに変更されたかどうかを、ブレーカーが証明することはできません。

そのため、安全な実行経路では、リトライ予算とブレーカーの状態を別々に記録します。これによりオーケストレーターは、アクションが一度も試行されなかったのか、1回試行されたのか、依存先の失敗が繰り返された後にブロックされたのかを説明できます。

フォールバックはツールが成功したふりをせずにワークフローの意味を保つ

回路をオープンすることで分かるのは、プライマリツールを実行できるかどうかだけです。オーケストレーターには、ユーザーの意図を保つ継続ポリシーも必要です。タスクによっては、部分的な結果を返す、キャッシュされた読み取りデータを使う、プロバイダーを切り替える、タスクをキューに入れる、人による確認を求める、または停止するといった対応が考えられます。

フォールバックには劣化メタデータを含める必要があり、元の結果を装ってはいけません。下流のステップは、古いキャッシュコンテンツや代替された証拠に基づいて動作している場合、高い影響を伴うアクションを制限できます。

安全なフォールバックが存在しない呼び出しもあります。通知はキューに入れられますが、ドア制御コマンドを推測した状態で置き換えるべきではありません。また、キャッシュされたインベントリからバックアップの削除を推測してはいけません。

ハーフオープンのプローブはリトライの波を解放せずにアクセスを復旧する

外部ツールが復旧する可能性があるため、オープン状態の回路を永続的に閉じたままにはできません。そこで、クールダウン時間が経過した後、ブレーカーは少数の試行呼び出しだけを受け入れます。依存先が再び安全にトラフィックを受け入れられることをプローブが示すまで、通常のワークロードはブロックされたままです。

プローブが成功するとブレーカーはクローズに向かって遷移し、失敗すると再びオープンして待機時間をリセットします。サーキットブレーカーの状態を監視すると、繰り返しのオープンや長い復旧期間がツールエラーの中に埋もれず、可視化されます。

ヘルスプローブが成功したからといって、以前の書き込みを安全に再実行できるとは限りません。依存先が読み取りチェックには応答しても、以前の副作用が不明なまま残っている可能性があります。そのため、中断されたアクションを再開できるかどうかは、冪等性キー、チェックポイント、照合、承認の境界によって引き続き決まります。

プローブの受け入れ条件を通常のトラフィックより狭くするのは意図的な設計です。何百もの待機中のリクエストが一度に依存先へ到達すると、回復の証拠が役に立たなくなる可能性があるためです。同時実行するプローブ数を制限することで、ブレーカー自身が急増を引き起こし、回復したばかりのツールを再び不健全に見せてしまう事態を防げます。