サーキットブレーカーは、外部サービスへの呼出しで失敗が続いたときに、一時的に呼出しを遮断する設計パターンです。成功しにくい処理を繰り返すことを避け、障害の波及を抑えます。Microsoftのパターン解説
導入時には「何を失敗と数えるか」「いつ遮断するか」「どう復旧を確かめるか」を組で決めます。本稿ではソフトウェアの外部API連携を対象に、開発・運用担当者と委託先が合意すべき条件を整理します。
Closed・Open・Half-openの3状態
基本の状態遷移は次のとおりです。Openは呼出しを遮断し、Closedは呼出しを通す状態を意味します。
| 状態 | 呼出しの扱い | 次の状態へ移る条件 |
|---|---|---|
| Closed：通常 | 呼出しを通し、結果を記録する | 失敗が判定条件を満たしたらOpenへ |
| Open：遮断 | 対象への新たな呼出しを通さず、失敗を返す | 待機期間などの条件を満たしたらHalf-openへ |
| Half-open：復旧試行 | 限定した呼出しで回復を確かめる | 回復条件を満たせばClosed、失敗条件を満たせばOpenへ |
これは基本モデルです。サーキットブレーカー自体が故障箇所を修理するわけではありません。Microsoftの状態遷移の説明
また、復旧判定の細部は実装で異なります。たとえばResilience4jはHalf-openで許可した呼出しの失敗率・遅延率を評価します。「一度成功したら必ず全面再開する」とは決めつけず、採用する実装の仕様を確認してください。Resilience4j公式文書
遮断と復旧の条件を設計書に書く
以下は、設計レビュー用の確認表として本稿が提案する項目です。全システムに共通する推奨秒数や失敗率を置くのではなく、通常時の観測結果と業務上の許容範囲を使って決めます。
| 項目 | 設計時に決めること |
|---|---|
| 遮断する単位 | 外部サービス、API操作など、どの範囲を同じ判定にまとめるか |
| 失敗の分類 | 接続失敗、タイムアウト、応答内容など、何を遮断の根拠にするか |
| 評価範囲 | 直近の件数か時間か。評価に必要な最低件数はいくつか |
| 遮断の条件 | 失敗件数・失敗率・遅延率など、採用実装のどの判定を使うか |
| 復旧試行 | 遮断後の待機時間、試す呼出し数、成功・再遮断の条件 |
| 遮断中の業務 | エラーを返すか、代替表示にするか、後続処理へ回すか |
失敗率だけでなく最低件数も確認します。Resilience4jでは、評価に必要な最低呼出し件数に達しない間は、失敗率による遮断判定が行われません。低頻度APIでは「少数の失敗が続く場合」を試験項目に加えるとよいでしょう。Resilience4jの最低呼出し件数
HTTP応答を分類する際は、HTTP 500と503の違いも参考になります。設計書には番号だけでなく、そのAPIでどの結果を失敗扱いにするかを記載してください。
タイムアウト・リトライと組み合わせる
タイムアウトは1回の呼出しの待機を制限し、リトライは失敗した要求を再試行します。ただし、タイムアウトしても相手側では更新が完了している場合があります。注文・決済などでは、重複して処理しても結果を重ねない冪等性の確認が必要です。AWSのタイムアウトと再試行の解説
また、過負荷時の再試行は相手の負荷を増やします。回数に上限を設け、バックオフで待機間隔を延ばし、ジッターで再試行時刻を分散させる方法があります。複数の層で独立に再試行すると、下流への呼出しが増幅する点にも注意が必要です。AWSのバックオフとジッターの説明
併用時には、次の内容を設定と試験結果で確認することを提案します。
- 1回の待機時間に加え、再試行の待機も含む利用者側の処理期限を決める。
- SDKとアプリなど、再試行を行う層と最大試行回数を一覧にする。
- 遮断中の拒否まで再試行の対象にしていないか確認する。
- ブレーカーが個々の試行を数えるのか、再試行後の最終結果を数えるのか確認する。
さらに、同時実行数の制限も別に確認します。Resilience4jでは、集計窓の件数は同時実行数の上限ではありません。同時実行数を抑える場合はBulkheadとの併用が案内されています。Resilience4jの並行呼出しの説明
導入判断は遮断中の業務から考える
遮断中に利用者へ何を返すかが決まらなければ、技術設定だけでは運用に移せません。たとえば在庫照会が止まった場合に「確認できない」と表示するか、取得時刻を示した過去の情報を出すかは、業務要件として決める事項です。これは設計例であり、過去の在庫情報で注文を確定してよいという意味ではありません。
| 状況 | 本稿が提案する判断 |
|---|---|
| 外部APIの失敗が続き、遮断中の応答も定義できる | 導入候補として遮断と復旧試行を検証する |
| 再試行回数やタイムアウトが把握できていない | まず既存設定と障害時の呼出し数を整理する |
| 処理を後回しにできる | 非同期化も比較し、未完了の仕事の扱いを決める |
| 遮断・復旧の試験を用意できない | 試験と監視の準備を導入条件にする |
非同期化を選ぶ場合も、処理の重複や失敗後の再投入を検討します。比較項目はメッセージキューサービスの比較方法で整理しています。
サーキットブレーカーには状態が増えるための検証負担もあります。AWSの技術解説は、状態による挙動の変化がテストを難しくし、復旧までの時間を延ばす可能性を指摘しています。AWSの設計上の注意点
委託先と合意する受入試験
受入試験では、成功時だけでなく次のシナリオを含めることを提案します。
- 外部APIを失敗させ、設定した条件でOpenになるか確認する。
- 遮断中の対象APIへの呼出し数と、利用者に返す結果を確認する。
- 外部APIを復旧させ、限定した試行から通常状態へ戻るか確認する。
- 復旧試行を失敗させ、再び遮断されるか確認する。
- 更新操作では、応答を失った場合も重複処理や未完了の仕事を追跡できるか確認する。
記録には状態遷移、実際に送った呼出し数、遮断による拒否数、処理時間、業務結果を残します。設定値だけを納品物にせず、障害発生から復旧までの結果を受入条件にすると、運用担当者が再開を判断する材料になります。