サーキットブレーカー（サーキットブレーカー）

概要

サーキットブレーカー（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 に戻る

主要実装（2026 年）

Java / Kotlin

Node.js / TypeScript

.NET

Python

Go

Service Mesh（自動適用）

opossum（Node.js）の例

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));

主要パラメータ

• 失敗閾値: 50-80%（高負荷でも誤発火しない範囲）
• 連続失敗回数: 5-20 回
• タイムアウト: 1-10 秒（依存サービスの正常レスポンス時間 ×3）
• リセット時間: 30 秒-5 分（依存サービス復旧見込み時間）
• HALF-OPEN 試験回数: 1-3 回
• 半開状態の試験成功必要数: 1-3

関連デザインパターン

適用すべき場面

• 外部 API 呼び出し: 決済 / 認証 / 地図 API 等
• DB 接続: スレーブ落ち時にマスターを保護
• マイクロサービス間通信: 1 サービスの障害がカスケード波及するのを防ぐ
• 第三者サービス: SendGrid / Stripe / Twilio 等

メトリクス（2026 年標準）

• State Transitions: CLOSED → OPEN の発生頻度
• Success Rate: 成功率（CLOSED 状態の比率）
• Mean Latency: 平均レスポンス時間
• Open Duration: OPEN 滞在時間（短いほど健全）
• Trip Count: ブレーカー発動回数

PC 自作 / 個人開発との接点

• 個人 SaaS の堅牢性: Stripe / OpenAI API へのアクセスに opossum 適用
• ホームサーバ: 複数 Container 間の通信に circuit breaker 設計
• 学習リソース: Microsoft の Cloud Design Patterns ドキュメント、Resilience4j 公式

関連用語との違い

よくある質問

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 点セットで、ユーザー体験が大幅向上。

まとめ

• 分散システムで 障害伝播を防ぐデザインパターン
• 2026 年は Resilience4j / Polly / opossum が言語別主流
• マイクロサービス + Service Mesh の組合せで自動適用が標準