動画配信障害事例と復旧戦略
配信で本当に起きる障害と初動の型
DNS/CDN/エッジでのつまずき
急増トラフィック時に目立つのは、エッジ配信の部分的な劣化です。症状は「再生開始が遅い」「特定地域だけ失敗率が跳ねる」。初動は数値で切るのが実務的です。1分移動平均で再生開始失敗率>1% or 初回再生開始時間>5秒で重大判定。対処は段階的シフトが定石で、マルチCDNならDNS重みまたはAPIで30%→60%と移行、同時にプレイヤー側でABR上限を3.5Mbpsなどに制限して輻輳を緩和します。地域偏差があるときは、リージョン単位で切替えられる設計か、プレイヤーに複数ベースURLを渡してフェイルオーバーを自律化しておくと復旧時間が一桁短縮します。
オリジン/ストレージの詰まり
オリジンが5xx連発になる典型は「キャッシュキーの過剰分散」「署名URLのTTL不一致」「スパイクでコネクション枯渇」。初動はオリジン5xx>2%で即時アラート、エッジミス比率と照合してキャッシュ効率が50%未満なら緊急ワークアラウンドとしてキャッシュキー正規化ルールを一時適用します。オリジンは読み取り専用のスレート映像（告知画像つき音声）を返せるよう事前に用意し、書き込み系を切り離すと延焼を防げます。I/Oがボトルネックのときはスロットリングとバックプレッシャーで守りを固め、プレイヤーへの最大ビットレート制限で帯域を下げるのが現実的です。
エンコード/パッケージングの破綻
ライブではインジェスト途絶やトランスコード遅延が致命傷になります。症状はタイムシフトの穴、セグメント欠損、音ズレ。検知は「セグメント遅延>8秒」「連続欠損3セグメント」で重大。初動はデュアルインジェストへ自動切替、冗長エンコーダのホットスタンバイ起動、GOP長とキーフレームを緊急プロファイルに切替え（ABRラダーの段数を削減）で復帰時間を短縮します。パッケージャ障害時はHLS/DASHのどちらか片系でも出せるように分離し、プレイヤーにプロトコル優先度を持たせると「完全停止」を避けられます。
プレイヤー/DRM/認証の落とし穴
DRMライセンスの配布遅延やトークン検証の過負荷は、全体の健全性は問題なくとも体感品質を壊します。「ライセンス取得>1.5秒」「403/401急増」をトリガーに、ライセンス発行のバックエンドを水平分割、キューの最大同時処理を引き上げ、プレイヤーは再生開始時だけ低ビットレートを優先する設定に変えてTTFFを縮めます。ピーク時は視聴権限チェックをキャッシュする戦術も有効です。
復旧戦略の設計図：検知→切替→緩和→再発防止
- 検知設計：SLI/SLOを明確化。例）TTFF p95 < 3秒、エラー率 < 0.5%。アラートは「1分で連続N回」を条件に誤検知を抑制。
- 切替の準備：マルチCDN、オリジン冗長（読み取り専用レプリカ）、デュアルインジェスト。トラフィックシフトは10%刻みで5分観察、プレイヤー多URLで端末側も自律。
- 緩和の手筋：ABR上限/下限の動的変更、ラダースリム化、チャンク長延長、スレート配信への自動退避、サムネイル先出しでUXを守る。
- デプロイ戦略：カナリア配信（視聴者1〜5%）、ブルー/グリーンで一括切替のリスクを回避。パイプラインごとにロールバック手順をRunbook化。
- 振り返り：タイムライン/根本原因/防止策/検知力評価をテンプレに記録。メトリクスと当時の意思決定をセットで残し、トレーニングに再利用。
インシデント中の情報整理は人手だけでは追いつきません。ChatGPTやClaudeはアラートとログの要約、Geminiは大量メトリクスからの異常時系列の抽出、CopilotはRunbookの整備やクエリの雛形化に向きます。機密情報取り扱いは社内ポリシーに沿い、匿名化・要約前提で活用すると安全です。
運用で効くチェックリスト（事前に仕込む）
- プレイヤー設定：ABRの初期ビットレート、最大/最小、再試行ポリシー、複数ベースURLの優先順。
- キャッシュ戦略：キャッシュキー正規化、セグメントとマニフェストのTTL差、プリウォーム手順。
- ライブ固有：デュアルインジェスト、エンコーダ監視（温度/CPU/ネット）、スレート自動切替。
- 可観測性：地域別エラー、端末/OS別のTTFF、オリジンの同時接続、パッケージャのキュー長。
- 意思決定：トラフィックシフトの権限、判断のタイムボックス（例：5分で暫定策→15分で恒久策に移行）。
身近な活用例：小売のライブコマース配信で起きた障害と改善
全国にECと実店舗を持つ小売事業（従業員300名規模）が、週末のライブコマースを自社の動画基盤で配信。最大同時視聴は4.5万人、平均ビットレートは4Mbps。開始10分で一部地域のエラー率が8%に急騰し、再生開始もp95で9秒まで悪化しました。
原因は二重でした。第一に、HLSのキャッシュキーに動的トークン全体が含まれ、エッジのキャッシュヒットが20%未満まで低下、オリジンがスパイクで飽和。第二に、エンコードのABRラダーが細かすぎて（12段）パッケージャの負荷が想定の1.7倍になっていました。
当日の復旧は次の順で実施。1）プレイヤーに設定済みの上限を一時的に3Mbpsへ下げ、2）DNSでトラフィックの40%を別CDNへシフト、3）キャッシュキーを正規化ルールに置換、4）パッケージャは6段ラダーへ切替、5）オリジンの読み取りレプリカを増設。15分でエラー率は0.9%、TTFF p95は3.1秒まで回復。
翌週の恒久対策として、ライブ前のプリウォーム（前日と直前30分の2段）、トークンは一部だけをキャッシュキーに採用、エンコードはイベント規模で段数を可変化、プレイヤーに多URLとプロトコル優先度を導入。さらに、ChatGPTとClaudeで障害タイムラインを自動整形、Geminiで地域×端末の異常検知を補助、CopilotでRunbookの更新を日次CIに組み込みました。結果、次回配信では同時視聴5万人でもエラー率0.6%、TTFF p95は1.8秒を維持できました。
動画配信の障害はゼロにはできませんが、検知と切替の速度、そして「緩やかに劣化させる設計」で事業インパクトは大きく変わります。動画プラットフォーム事業では、可用性と体感品質のバランスをとる設計と運用の積み重ねが、配信そのものの信頼と売上の土台になります。
