サーキットブレーカーライブラリ
外部サービスの障害を検知し、自動的にリクエストを遮断して障害の連鎖を防ぐライブラリ
サーキットブレーカーライブラリとは
サーキットブレーカーは、外部サービスの障害を検知し、一定回数の失敗後にリクエストを自動的に遮断するパターンである。電気のブレーカーと同じ原理で、障害の連鎖 (カスケード障害) を防ぐ。
3 つの状態
3 つの状態を図で示す。
Closed (正常) → 失敗が閾値を超える → Open (遮断)
↓ タイムアウト後
Half-Open (試行)
↓ 成功 → Closed
↓ 失敗 → Open
| 状態 | 動作 |
|---|---|
| Closed | リクエストを通す、失敗をカウント |
| Open | リクエストを即座に拒否 (外部サービスに送らない) |
| Half-Open | 少数のリクエストを試行し、回復を確認 |
TypeScript での実装
TypeScript での実装のコード例を示す。
class CircuitBreaker {
private failures = 0;
private state: 'closed' | 'open' | 'half-open' = 'closed';
private nextRetry = 0;
constructor(private threshold = 5, private timeout = 30000) {}
async call<T>(fn: () => Promise<T>): Promise<T> {
if (this.state === 'open') {
if (Date.now() < this.nextRetry) throw new Error('Circuit is open');
this.state = 'half-open';
}
try {
const result = await fn();
this.reset();
return result;
} catch (error) {
this.failures++;
if (this.failures >= this.threshold) {
this.state = 'open';
this.nextRetry = Date.now() + this.timeout;
}
throw error;
}
}
private reset() { this.failures = 0; this.state = 'closed'; }
}
上のコードは最小構成で、Half-Open に入ったあとに試行数を絞る仕組みは入っていない。そのままだと待たされていたリクエストが一斉に流れ込み、復旧しかけの相手をもう一度倒しかねないので、Half-Open 中は 1 件だけ通して結果を見る、といった制限を足しておきたい。
Lambda は実行環境が再利用されるため、同一インスタンス内ではサーキットブレーカーの状態が保持される。ただし状態はその実行環境の中だけのもので、同時実行で別のインスタンスが立てば失敗カウントは共有されない。同時実行数が多いほど遮断が効き始めるまでに外部サービスへ流れる失敗リクエストの総数は増えるため、厳密に絞りたい場合は DynamoDB や ElastiCache など外部ストアに状態を置く。
リトライとの組み合わせ
リトライとの組み合わせを図で示す。
リクエスト → リトライ (3 回) → 全て失敗 → サーキットブレーカーが Open
→ 以降のリクエストは即座に 503 を返す (外部サービスに負荷をかけない)
→ 30 秒後に Half-Open → 1 件試行 → 成功 → Closed
AWS での代替手段
AWS ではサーキットブレーカーライブラリの代わりに、Step Functions のリトライ + Catch でエラーハンドリングを行ったり、API Gateway のタイムアウト設定を活用したりできる。App Mesh の Envoy プロキシでも同じことができたが、App Mesh は 2024 年 9 月 24 日に新規顧客の受付を終了しており、2026 年 9 月 30 日にサポート終了が予定されているため、これから選ぶ手段には含めない (ECS なら Service Connect が公式の移行先として案内されている)。
実務での活用方法は関連書籍にも詳しい。
この記事は役に立ちましたか?
関連用語
リトライパターン
一時的な障害だけを選んで再試行し、間隔を指数的に広げつつ乱数で散らして、回復途中の相手に負荷を集中させない設計パターン
グレースフルシャットダウン
処理中のリクエストを完了させてからプロセスを安全に停止する終了手法
ヘルスチェックパターン
サービスの稼働状態を定期的に確認し、異常を検知したらトラフィックを切り離す仕組み
サービスメッシュ
マイクロサービス間の通信を透過的に管理するインフラ層で、トラフィック制御・認証・監視を提供する
キューワーカー
メッセージキューからタスクを取り出して非同期に処理するバックグラウンドプロセス
指数バックオフとは - リトライ間隔の設計とジッター付き実装例
指数バックオフはリトライ間隔を 2 倍ずつ増やして障害時の負荷集中を防ぐ戦略。ジッター追加の理由と Go/Python/TypeScript での実装パターンを解説
関連する記事
技術書の読む順番戦略 - 複数冊を組み合わせて理解を加速させる
技術書を 1 冊ずつ読むのではなく、複数冊を戦略的に組み合わせることで、1 冊では届かない理解の深さと広さに達する方法を解説します。
技術書の知識を定着させる間隔反復法 - 読んだのに忘れる問題を解決する
技術書を読んでも内容を忘れてしまう原因を認知科学の観点から分析し、間隔反復法を使って知識を長期記憶に定着させる具体的な方法を紹介します。
Linux 本ガイド - コマンドライン / しくみ / 性能の 3 層で選ぶ技術書
Linux を学ぶ技術書の選び方を 3 層 (コマンドラインの操作 → カーネルのしくみ → 性能と運用) で整理。新しい Linux の教科書や [試して理解] Linux のしくみなどの定番書の使い分けと、学ぶ順番を解説します。