サーキットブレーカと劣化

Circuit Breaker （CB）は、障害をローカライズし、アップストリームサービスとユーザーを保護するために、劣化した依存性への呼び出しを中断するセキュリティパターンです。劣化（graceful degradation）-リソースや障害が不足している場合（たとえば、キャッシュ/不完全なデータを返す、「高価な」機能を無効にするなど）、完全なダウンタイムなしで機能を意図的に簡素化します。

主な目標は、カスケードドロップの代わりに、制御された障害を介してSLOとユーザーエクスペリエンスを維持することです。

1）いつ適用するか

依存は不安定です：p95/p99の成長、タイムアウト、誤った回答。
厳格な制限/ペナルティを持つ外部API。
「重い」バックエンド（検索、推奨、レポート）、ここでリトレイは嵐を強化します。
プール（接続、スレッド）が枯渇する危険性のある高負荷エリア。

2） CBの状態と遷移

1.クローズ-トラフィックが移動し、エラー/レイテンシーメトリックがカウントされます。

2.オープン-コールは即座に拒否され（フェイルファスト）、フォールバックに転送されます。

3.ハーフオープン-「トライアル」リクエストの数が限られており、スイッチを閉じるかどうかが決まります。

オープニングトリガー

ウィンドウごとのエラー/タイムアウトしきい値（たとえば、最後のNの50％を≥）。
待ち時間のしきい値（例：p95> target）。
組み合わせたポリシー（エラー∧タイムアウトを超えました）。

ホールドタイム（クールダウン）

固定（例えば、10-60秒）または適応性（繰り返された作動と指数関数的な増加）。

3）タイムアウト、リトリート、ジッタ

タイムアウトは常に上流のSLOより短く、期限伝播です。
Retraiはidempotent操作のみを対象としています。ほとんどの場合、1-2の試みで十分です。
バックオフ+ジッタ（フルジッタ）は反復の同期波を防ぎます。
ヘッジ（スペアリクエスト）-経済的で非常にクリティカルな読み取り専用。

4）隔壁分離および「ヒューズ」

ドメインとトラフィックタイプ（VIP、バックグラウンドタスク、パブリックAPI）で接続/ワーカー/キュープールを分離します。
「高価な」操作の同時処理のキャップ。
入場制御：キューがいっぱいのときに実行する前に簡単に失敗します。

5）フォールバックと劣化シナリオ

［オプション］

キャッシュ/スタイルの応答：'stale-while-revalidate'、キャッシュからデータL2/L3返す。
読み取り専用：書き込み/コマンドのブロック、安全な読み取りを許可します。
サロゲート応答：不完全なデータ（例えば、推奨なし/アバター）。
機能無効化：非クリティカルなウィジェット/機能を一時的に非表示にします。
フィーチャーフラグ：リリースなしで動作を素早く変更します。

ルール

フォールバックは、データから決定論的、迅速、安全でなければなりません。
logs/tracks/metricsの劣化したパスを明示的にマークします。

6）優先順位付けとトラフィックシェーピング

VIP/有料プラン-不足している場合の優先度/クォータが高くなります。
レート制限とスロットリングにより、劣化した依存関係への負担が軽減されます。
Shed load：質の柔らかい減少（例えば。より少ない結果、切り捨てられたイメージ）安定するまで。

7） Observabilityおよびシグナル伝達

CBメトリック

状態（closed/open/half-open）および状態の持続期間。
原因による失敗の共有：CBオープン、タイムアウト、5xx、再試行-疲労。
p95/p99 latency 「before」および「after」スイッチ。
フォールバックによるリクエストの数/パーセンテージ。

トレース

スパンの注釈：'circuit=open'、 'fallback=cache'、 'admission=denied'。
限界（429/RateLimit-）、キューおよび接続箇条書きとの相関。

ログ/監査

開閉の理由、しきい値、依存関係ID。

8）契約及び議定書

HTTP （HTTP）

Fail-fast： '503 Service Unavailable'と'Retry-After'（または'429'）。
部分的なコンテンツ/古い：'200'/'206'と劣化メタデータ（例えば、'X-Degraded： true'）。
キャッシュポリシー：'Cache-Control： stale-if-error、 stale-while-revalidate'。

gRPC

'UNAVAILABLE'、 'DEADLINE_EXCEEDED'、クライアント/プロキシポリシーによるセマンティクスのリトレイ。
リクエストコンテキストの締め切り/タイムアウト。締め切りを広げています。

Idempotency

'Idempotency-Key'は、POST操作、国境での重複排除のためのものです。

9）典型的な実装（擬似コード）

pseudo onRequest(req):
if circuit. isOpen(dep):
return fallbackOrFail(req)

with timeout(T):
try:
resp = call(dep, req)
circuit. recordSuccess(dep, latency=resp. latency)
return resp except TimeoutError or 5xx as e:
circuit. recordFailure(dep)
if circuit. shouldOpen(dep):
circuit. open(dep, coolDown=adaptive())
return fallbackOrFail(req)

ハーフオープンサンプル

pseudo onTimer():
if circuit. state(dep) == OPEN and coolDownExpired():
circuit. toHalfOpen(dep)

onRequestHalfOpen(req):
if circuit. allowTrial (dep): # e.g. 1 try: call -> success => close catch: reopen with longer coolDown else:
return fallbackOrFail(req)

10）しきい値の設定

観察ウィンドウ：N秒/クエリのスライド。
エラーしきい値：ウィンドウの20-50％（プロファイルによって異なります）。
レイテンシのしきい値：p95 ≤ターゲットSLO（例えば、300-500ミリ秒）；過剰はCBの「エラー」としてカウントされます。
アダプティブクールダウン：10s→30s→60sと繰り返された作動。

11）テストとカオスの実践

カオス：レイテンシー/依存性エラーインジェクション、DNSブレークダウン、パケットドロップ。
ゲームの日：戦闘のような環境でスイッチの「開始」を開始し、フォールバックを確認します。
カナリア：トラフィックの1〜5％のPOC/劣化ポリシーを最初に有効にします。
SLO予算：エラー予算が使い果たされるまで実験を許可します。

12）マルチテナンシーとの統合

CB状態は、負荷プロファイルに応じて、テナントごと（騒々しいテナントの場合）またはグローバルに依存関係ごとに保存することができます。
フォールバックデータとキャッシュを'tenant_id'でセグメント化します。
優先順位/クォータ-計画に従って（VIPはスターターの動作に苦しむべきではありません）。

13）売り上げ前のチェックリスト

• タイムアウトと締め切りはエンドツーエンドで一貫しています。
• リトレイは、バックオフ+ジッタを使用したidempotent操作でのみ制限されます。
• CBスレッショルドは負荷テストデータによって正当化されます。
• フォールバックパスが存在し、高速かつ安全です。ポリシーキャッシュが定義されています。
• 隔壁分離：独立したプール/キュー/リミット。
• Metrics/trails/logsフラグの劣化とCB状態。
• レスポンス契約文書（HTTP/gRPC）とサンプルヘッダー/コード。
• カオスシナリオとゲームの日は定期的に行われます。ランブックがある。

14）典型的なエラー

タイムアウト→「すべての道」を後退させ、カスケードを落とすことはありません。
選択的（エンドポイント/メソッドによる）ではなく、単一のグローバルCB-不要な障害。
劣化したUXではなく、フォールバック→「空」画面のないスイッチを開きます。
ジッタのないレトライ→リクエストの同期嵐。
短期間の故障または短すぎる安定した「フリップフロップ」状態で長いクールダウン。
隔壁の欠如-共有プールの枯渇と「ヘッド・オブ・ライン・ブロッキング」。

15）クイック戦略の選択

重要度の高い読み取り：古い応答のCB+キャッシュ+ヘッジ（経済的）。
レコード/支払い：厳格なタイムアウト、最小リトレイ、idempotencyキー、汚れたフォールバックはありません。
外部API：積極的なしきい値を持つCB、アダプティブクールダウン、厳格なスロットリング。
脈動負荷マイクロサービス：隔壁、同時性ごとの帽子、VIPの優先順位付け。

結論

Circuit Breakerと管理された劣化はアーキテクチャの「保険」です。タイムアウトのクリア、ジッタのリトリートの制限、孤立したプール、思慮深いフォールバックパス、およびテレメトリーにより、システムは依存性の障害に耐えやすく、ピークやクラッシュ時でもSLOを保持できます。