ホームAIのサーキットブレーカー：1つのツールの障害で、すべてのリクエストを停滞させてはならない理由

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Home AI Circuit Breakers: Why One Failing Tool Should Not Stall Every Request - Zima Store Online

サーキットブレーカーは、復旧の見込みが立つまで繰り返しの呼び出しを停止することで、1つの障害が発生したホームAIツールによってすべてのリクエストが滞るのを防ぎます。

エージェントは、検索、文字起こし、カメラAPI、スマートホームブリッジなどに依存する場合があります。1つのツールがハングすると、それに触れるすべてのワークフローがワーカーを消費し、タイムアウトまで待機してから再試行する可能性があります。サーキットブレーカーは、繰り返される障害を一時的な即時拒否に変換し、スレッドとキュー容量を、まだ成功できるリクエストのために確保します。

繰り返されるタイムアウトは、障害のあるツール以外の容量も消費する

タイムアウトは、接続、ワーカー、ワークフローの期限を占有する一方で、有用な結果を何も生みません。エージェントの並列ステップによってこのコストは増大し、再試行によって、すでに不健全な依存先が使い続けられる可能性があります。ローカルモデルが高速でも、ユーザーは同じ失敗が避けられない外部呼び出しを待つことになります。

AWSはサーキットブレーカーパターンを、障害を監視し、しきい値に達するとリクエストをブロックするステートフルなプロキシとして説明しています。このパターンは、障害が予想される依存先に容量を使い続けるのを止める点で、再試行とは異なります。

即時失敗により、オーケストレーターはオプションのステップを省略したり、キャッシュ済みの証拠を使用したり、部分的な可用性を報告したりできます。また、期限内に完了できない呼び出しでルートキューが埋まるのを防ぎます。この違いは、現実的な家庭内の運用条件でも重要です。

クローズ、オープン、ハーフオープンの状態で復旧を制御する

クローズ状態では呼び出しが通過し、障害がカウントされます。設定されたしきい値を超えるとサーキットがオープンになり、クールダウン期間中は呼び出しを拒否します。その後、ハーフオープン状態で限定的なプローブを許可し、成功すればサーキットをクローズし、失敗すれば再びオープンにします。

Microsoftのブレーカーの状態に関するガイダンスでは、障害数、タイムアウト、復旧動作を操作に合わせる必要があると強調されています。読み取りエンドポイントと書き込みエンドポイントで障害のパターンが異なる場合、1つの共有ブレーカーでは粗すぎる可能性があります。中間状態は、後の診断やレビューで確認できるようにしておくべきです。

ブレーカーは、ツールの操作と障害の種類に応じてスコープを設定する必要があります。認証エラー、レート制限、タイムアウト、無効な引数、モデルによる拒否には、それぞれ異なる復旧ルールが必要です。これらを1つのカウンターにまとめると、実際の障害を隠してしまう可能性があります。

フォールバックは可用性を維持できるが、正確性を低下させる可能性がある

キャッシュされた天気の値は表示には十分でも、嵐の際に窓を閉める判断には安全でない可能性があります。CPUモデルは遅くても正しく回答できる一方、汎用的な結果は完全に見えてエージェントを誤らせることがあります。サーキットブレーカーが保護するのは容量であり、意味上の品質ではありません。

エージェント向けサーキットブレーカーのカタログは、エージェントツールへのサーキットブレーキングを適用し、フォールバックと可観測性の必要性を指摘しています。エージェントでは、オープンサーキットの結果を構造化された状態に保ち、プランナーが利用できない証拠と否定的な回答を区別できるようにする必要があります。

障害の境界は、現在の結果を得るために欠落しているツールを必要とするあらゆるアクションです。その場合はフェイルクローズし、利用できない依存先を明示したうえで、古い証拠や低品質な証拠に黙って置き換えるのではなく、承認を求めるか後で再試行してください。

Featured

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

ZimaCube2

1つのツール障害を注入し、分離を追跡する

破壊的でないツールを1つ選び、混在するワークフローを継続させながら、タイムアウト、エラー、低速な応答を注入します。ブレーカーの状態、障害ウィンドウ、同時呼び出し数、キューの深さ、選択されたフォールバック、復旧プローブを記録します。無関係なツールが通常のレイテンシーを維持していることを確認してください。

CPUフェイルオーバーで説明されているCPUフォールバックの境界をテストします。ただし、劣化した実行であることを明示し、ワークフローの期限を依然として満たせるか測定してください。ハーフオープンのプローブによって、待機中のリクエストが大量に発生しないことを確認します。

障害のある操作が分離され、呼び出し元が構造化された利用不可状態を受け取り、制御されたプローブの後に復旧によってブレーカーがクローズされる場合にのみ合格とします。キャッシュ結果やフォールバック結果によってアクションが変わる場合は、そのフォールバックを有効にする前にポリシーゲートを追加してください。