AI API のサーキットブレーカーを設計する
AI API のサーキットブレーカーを設計する：明確な判断、再利用可能な成果物、失敗試験、運用シグナル、出典付き制約を含む本番ガイド。
AI API のサーキットブレーカーを設計する：明確な判断、再利用可能な成果物、失敗試験、運用シグナル、出典付き制約を含む本番ガイド。
先に結論
AI API のサーキットブレーカーを設計するは一時的な設定ではなく、信頼性制御の契約として実装します。トラフィック移動前にプロトコル、owner、証拠、rollback を固定します。制御点は closed, open, half_open, failure_window です。
判断は契約表と決定的な例で固定します。ai-api-circuit-breaker の必須制御に wire 証拠、永続 readback、owner のいずれかがなければ rollout しません。
範囲と責任
クライアント作業と control plane を分けます。クライアントはファイルや環境変数、ゲートウェイは認証・ルート・制限・会計・試行、プロバイダーはネイティブプロトコルと変動する能力を所有します。テキスト応答 1 回は 1 経路だけの証拠です。
記事は判断・リスク・検証を担当し、ライブ文書は変動するコマンドと UI 手順を担当します。これにより、同じ検索意図の owner を重複させず能力ツリーを作れます。
このページの owner 記録は ai-api-circuit-breaker、固定制御点は closed, open, half_open, failure_window です。各値は wire または永続状態の境界で検証し、マーケティング名から推測しません。
実用的な成果物: AI API のサーキットブレーカーを設計する
次のレビュー記録が成果物です。技術値を明示し、スクリーンショットに頼らず設定、wire 証拠、永続状態を比較できます。
| 制御点 | 固定判断 | 保存する証拠 |
|---|---|---|
breaker_key |
provider_route_plus_protocol_plus_failure_class |
route_id + endpoint + normalized_error_class |
closed_state |
rolling_window_with_minimum_sample |
eligible_attempts + failures + window_bounds |
open_state |
fail_fast_without_upstream_attempt |
decision_timestamp + reopen_at + returned_error |
half_open_state |
bounded_probe_concurrency |
probe_count + outcomes + state_transition |
fallback |
same_contract_eligible_route_only |
eligibility_reason + route_choice + terminal_state |
operator_override |
time_bounded_and_audited |
actor + reason + expiry + restored_policy |
決定的な例
例はプレースホルダーと決定的入力のみです。レビュー済み識別子だけに置換し、秘密や顧客内容を入れず、正確な snapshot を保存します。
state = CLOSED
if eligible_failures(window) >= threshold and samples >= minimum:
state = OPEN
reopen_at = now + cool_down
if state == OPEN and now < reopen_at:
return fail_fast
if state == OPEN and now >= reopen_at:
state = HALF_OPEN
if bounded_probe_succeeds():
state = CLOSED
else:
state = OPEN
段階的な検証
順番に検証します。後段の成功は前段の欠落を補えず、すべての試行を 1 つの論理リクエストへ関連付けます。
- クライアント、ゲートウェイポリシー、モデル alias、ルート、観測基準を固定する。
breaker_keyの証拠：provider_route_plus_protocol_plus_failure_classを強制し、route_id + endpoint + normalized_error_classを保存します。 - 決定的な正常 probe を実行し、応答、request ID、ルート、終端状態、usage を保存する。
closed_stateの証拠：rolling_window_with_minimum_sampleを強制し、eligible_attempts + failures + window_boundsを保存します。 - 対になる異常、上限、切断ケースを実行し、想定層で失敗することを確認する。
open_stateの証拠：fail_fast_without_upstream_attemptを強制し、decision_timestamp + reopen_at + returned_errorを保存します。 - 実際のプロトコル面で再実行し、隣接 endpoint からネイティブ対応を推測しない。
half_open_stateの証拠：bounded_probe_concurrencyを強制し、probe_count + outcomes + state_transitionを保存します。 - owner、有効期限、停止閾値、rollback を持つ限定 cohort に展開する。
fallbackの証拠：same_contract_eligible_route_onlyを強制し、eligibility_reason + route_choice + terminal_stateを保存します。 - 永続設定と会計を再読し、一時アクセスとテストデータを削除する。
operator_overrideの証拠：time_bounded_and_auditedを強制し、actor + reason + expiry + restored_policyを保存します。
防ぐべき失敗
以下はすべて公開停止条件です。HTTP 200、dashboard、1 回のデモで上書きできません。
global_breaker—global_breakerが発生したら rollout を停止し、定義済み owner、証拠、rollback で処理します。正常 probe では上書きできません。mixed_denominator—mixed_denominatorが発生したら rollout を停止し、定義済み owner、証拠、rollback で処理します。正常 probe では上書きできません。half_open_stampede—half_open_stampedeが発生したら rollout を停止し、定義済み owner、証拠、rollback で処理します。正常 probe では上書きできません。fallback_cascade—fallback_cascadeが発生したら rollout を停止し、定義済み owner、証拠、rollback で処理します。正常 probe では上書きできません。
シグナルと停止条件
成功と損害を同時に観測します。閾値は workload の方針であり、観測前に SLO と分母を固定します。
| シグナル | 閾値 | アクション |
|---|---|---|
eligible_failure_ratio |
reviewed_window_and_minimum_sample |
open_route_breaker |
open_fail_fast_latency |
<_caller_remaining_deadline |
repair_local_decision_path |
half_open_probe_concurrency |
<=_configured_probe_limit |
reject_extra_probes |
fallback_headroom |
>=_required_reserved_capacity |
shed_load_instead_of_failover |
Modelflare の境界
Modelflare は互換・ネイティブルート、限定キー、グループ、usage、失敗処理を集中管理できます。設定済み channel は全フィールド、alias、保持約束、region、fallback の証明ではありません。ネイティブに検証し、永続的な最終精算を会計の真実とします。
これは実装方法であり、認証、法的判断、uptime 履歴、普遍的 benchmark ではありません。T-1 に契約、モデル、価格、保持、region を再確認し、核心事実が変われば日付を移します。
同じトピック群を読む
親記事は広い判断、兄弟記事は次の実装、ドキュメントは現在の設定を担当します。managed CMS に related-slug がないため本文リンクを保持します。
よくある質問
AI API のサーキットブレーカーを設計する：成功リクエスト 1 回で承認できますか？
できません。異常系、限定 rollout、永続 readback、停止条件は別々の gate です。
AI API のサーキットブレーカーを設計する：モデルと価格を数か月前に固定しますか？
しません。placeholder または snapshot を使い、T-1 に再確認します。
AI API のサーキットブレーカーを設計する：何を保存しますか？
機密を除いた ID、設定版、時刻、終端状態、usage、最終請求、レビュー判断です。
出典と確認日
出典は 2026-08-07 に確認しました。外部契約と原則を示しますが、未検証ルートや将来状態は証明しません。