障害シナリオ
- プロバイダ障害: Anthropic / OpenAI 全停止（過去にも数時間規模あり）
- リージョン障害: Bedrock Tokyo 単独停止
- レート制御: TPM/RPM 上限突破
- セルフホスト障害: GPU 故障、ネットワーク分断
- 上流障害: VPC 内の DB / キャッシュ停止
マルチリージョン構成
``` LiteLLM Proxy (Tokyo) ├ primary: Bedrock Tokyo (Claude Sonnet 4.6) ├ secondary: Anthropic 公式 API └ tertiary: Tokyo セルフホスト Qwen3-72B ```
primary 障害時は secondary、secondary も障害時は tertiary に降格しつつ警告を出す。
サーキットブレーカ
```ts class CircuitBreaker { failureCount = 0; state: 'closed' | 'open' | 'half' = 'closed';
async call(fn: () => Promise<any>) { if (this.state === 'open') throw new Error('circuit open'); try { const r = await fn(); this.failureCount = 0; return r; } catch (e) { if (++this.failureCount > 5) this.state = 'open'; throw e; } } } ```
LiteLLM Proxy には組み込みで cooldown_time が設定でき、明示的な実装が不要なケースも多い。
バルクヘッド
テナント単位 / ジョブ種別単位でリクエスト枠を分離。1 テナントの暴走が他テナントに波及しないようにする。Redis ベースの token bucket で実装。
フォールバックモデルの品質
primary が Opus 4.5、tertiary が Qwen3-72B、と品質差が大きいケースでは「フォールバック発火時はクライアントに警告」「機密処理はフォールバック禁止」など別立てのポリシーが必要。
観測
- 各 fallback level の発火率
- リクエストの分布（primary / secondary / tertiary）
- p95/p99 レイテンシ（fallback 含む）
- SLA 計算: 月次レポート
カオステスト
- 月 1 回: 計画的にプロバイダ X を遮断し、フォールバックを実地検証
- 半年に 1 回: フェイルオーバ訓練 + ランブック更新
まとめ
LLM 推論の HA 設計は、従来の Web アプリ HA に加えて「品質の異なるフォールバック」を扱う点が特殊。マルチプロバイダ・マルチリージョン・サーキットブレーカ・バルクヘッドの 4 点セットを最初から組み込むことで、本番運用の安心感が大きく変わる。