分散システムで障害伝播を防ぐデザインパターン。失敗回数が閾値超で OFF(短絡)→一定時間後 HALF-OPEN で再試行→成功で復旧の状態遷移。Netflix Hystrix 由来。
サーキットブレーカー(Circuit Breaker)は、分散システム / マイクロサービスにおいて、障害の伝播を防ぐデザインパターンである。電気系のブレーカー(過電流で自動遮断)からの命名で、依存サービスの失敗回数が閾値超で OPEN(短絡 / 即時エラー返却) → 一定時間後 HALF-OPEN(試験的に 1 リクエスト通す) → 成功で CLOSED(正常) に復帰する状態遷移を持つ。Netflix の Hystrix(2012-、現廃止)が業界に普及させ、2026 年現在は Resilience4j(Java)/ Polly(.NET)/ opossum(Node.js)/ tenacity(Python)が言語別の主流実装である。
[CLOSED 正常]
↓ 失敗回数 ≥ 閾値
[OPEN 短絡] ← 即時エラー返却(依存先呼ばない)
↓ タイムアウト経過(30秒等)
[HALF-OPEN 試験]
↓ 成功 → CLOSED に復帰
↓ 失敗 → OPEN に戻る
| ライブラリ | 形態 | 特徴 |
|---|---|---|
| Resilience4j | OSS | Netflix Hystrix の後継、業界標準 |
| Spring Cloud Circuit Breaker | OSS | Spring 統合、Resilience4j バックエンド |
| Failsafe | OSS | 軽量、Java 8+ |
| ライブラリ | 形態 |
|---|---|
| opossum |
| OSS、Red Hat 由来 |
| cockatiel | OSS、Microsoft 由来 |
| ライブラリ | 形態 |
|---|---|
| Polly | OSS、業界標準 |
| Microsoft.Extensions.Resilience | .NET 8+ 公式 |
| ライブラリ | 形態 |
|---|---|
| tenacity | OSS、リトライ + サーキットブレーカー |
| pybreaker | OSS、Hystrix インスパイア |
| circuitbreaker | OSS、シンプル |
| ライブラリ | 形態 |
|---|---|
| sony/gobreaker | OSS |
| afex/hystrix-go | OSS、Hystrix 移植 |
| 製品 | 機能 |
|---|---|
| Istio | CircuitBreaker DestinationRule |
| Linkerd | retry + timeout 統合 |
| Consul Connect | 統合制御 |
| AWS App Mesh | リトライ + ブレーカー |
import CircuitBreaker from 'opossum';
async function callExternalAPI(userId: string) {
const response = await fetch(`https://api.example.com/users/${userId}`);
return response.json();
}
const breaker = new CircuitBreaker(callExternalAPI, {
timeout: 3000, // 3秒タイムアウト
errorThresholdPercentage: 50, // 50% 失敗で OPEN
resetTimeout: 30000, // 30 秒後 HALF-OPEN
});
breaker.on('open', () => console.log('Circuit OPENED!'));
breaker.on('halfOpen', () => console.log('Circuit HALF-OPEN, testing...'));
breaker.on('close', () => console.log('Circuit CLOSED, recovered'));
// 使用
breaker.fire('123').then(user => console.log(user)).catch(err => console.error(err));
| パターン | 目的 |
|---|---|
| Retry | 一時的失敗を再試行、ブレーカーと併用 |
| Bulkhead | リソース分離、影響範囲限定 |
| Timeout | 待ち時間制限、ハングアップ防止 |
| Fallback | 失敗時の代替応答 |
| Rate Limiter | リクエスト数制限 |
| Circuit Breaker + Retry + Timeout + Bulkhead | 4 大耐障害性パターン |
| 用語 | 違い |
|---|---|
| リトライ | 失敗時に再試行、ブレーカーは遮断 |
| タイムアウト | 待ち時間制限、ブレーカーは状態管理 |
| Rate Limiter | リクエスト数制限、ブレーカーは失敗ベース |
| Bulkhead | リソース分離、補完関係 |
Q1: Netflix Hystrix が廃止された理由は? A: 2018 年に Netflix 自身が「メンテナンスモード」へ移行宣言。コミュニティは Resilience4j に移行、Resilience4j は Hystrix 設計を改良し Java 8+ ネイティブ対応。
Q2: マイクロサービスでサーキットブレーカーは必須? A: 推奨。3 サービス以上の依存関係があれば、1 サービスの障害が他に波及するリスクが高まる。Service Mesh(Istio / Linkerd)で自動適用するのが 2026 年の標準。
Q3: 個人 SaaS で必要? A: 重要外部 API(Stripe / OpenAI / SendGrid 等)を呼ぶなら必要。タイムアウト + リトライ + ブレーカーの 3 点セットで、ユーザー体験が大幅向上。