マルチCDN戦略で可用性を高める

動画でマルチCDNが効く理由：体感品質と事業継続の両立

動画は、瞬間風速のトラフィック変動と地域差の影響を強く受けます。単一CDNに依存すると、特定地域の障害や混雑だけで再生開始の遅延やバッファリングが一気に悪化し、同時接続が高い時間帯ほど被害が拡大します。マルチCDNは、複数の配信網を組み合わせて「常に最も良い経路」へ誘導することで、可用性と体感品質（再生開始時間、リバッファ率、ABRの画質安定）を底上げします。ライブは特に恩恵が大きく、HLS/DASHのセグメント配信で2〜6秒ごとに選択肢があるため、経路切り替えが秒単位で効きます。VODでもロングテール地域やモバイル回線でのテールレイテンシが縮み、解約率やカスタマーサポート問い合わせを抑えやすくなります。

設計の要点：ルーティング、認証、キャッシュ、監視を揃える

ルーティング：速く壊れる前提で、秒単位に切り替える

入口の基本はDNSベースのスティアリングです。加重分散（Weighted）で普段はA:60%/B:40%などに振り、地域やAS（通信事業者）ごとの上書きルールを持ちます。ヘルスチェックはHTTP 200だけでなく、セグメント実体の取得、Rangeリクエスト、TLSハンドシェイク時間まで見ると誤検知が減ります。RUM（実ユーザー計測）をプレイヤーSDKに仕込み、再生開始時間・エラー率・リバッファ率を10〜30秒ごとに集計して、しきい値越えでフェイルオーバー。DNSのTTLは30〜60秒、プレイヤーはマニフェスト/セグメント単位でフェイルオーバー可能にして、DNS収束待ちをカバーします。

認証と配信保護：鍵と時刻の一貫性が命

URL署名（JWTやクエリシグネチャ）は全CDNで同じアルゴリズム・鍵・許容時差を使います。時刻ずれは典型的な障害要因なので、署名の有効期間は再生時間＋余裕30〜60秒、オリジンとエッジのNTPも厳密に。DRM（FairPlay/Widevine/PlayReady）キー配布はCDN非依存にし、マニフェスト改変やキーローテーションはCDNごとのEdge関数差分が出ないよう最小限に統一。TLS証明書はSNI単位で全CDNに同一ワイルドカード/マルチSANを配布し、OCSPステープリングやHTTP/2・HTTP/3(QUIC)を有効化。CORS/キャッシュ制御ヘッダーも揃えないとブラウザ差異で事故が起きます。

キャッシュとオリジン：鍵設計と“壊れにくさ”の作法

キャッシュキーはクエリやヘッダーのうち本当に効かせたいものだけをキー化し、ABRのbitrate、字幕、オーディオ言語を明示。セグメントはRangeリクエスト対応で分割取得してもヒットするようにし、stale-while-revalidate/stale-if-errorで短時間のオリジン不調を吸収。オリジンは二重化＋シールドを置き、CDNごとにバックソースを分離して「同時に殴らない」設計にします。Low-Latency HLS/CMAFは一部CDNが取りこぼしやすいので、パートの長さ・プリロードヒント・チャンクサイズを標準寄りに統一。エッジ関数はベンダーごとの差異が出やすい箇所なので、ルールは最小化し、テストをCDN横断で自動化します。

監視とSLO：再生品質KPIで意思決定する

• 候補KPI例：エラー率≤0.2%、平均再生開始≤1.8秒、95パーセンタイル・リバッファ率≤0.3%、視聴完走率の中央値
• シンセティック監視（地域×ISP×時間帯）とRUMを併用し、CDN別に分解
• ログは共通スキーマで集約し、障害時は対CDNの差分を即比較

オンコール運用では、ChatGPTやClaudeで長文ログの要約や暫定影響範囲の整理を行い、Copilotでスティアリング関数の修正を安全に適用、Geminiでダッシュボードの異常相関を可視化すると復旧が速まります。AIは意思決定の補助に限定し、切り替え基準はSLOに紐づく数値で自動化しておくのが現場では有効です。

コストと契約のリアル：高可用と単価の両立

マルチCDNは高くつく、は半分正解で半分誤解です。単価は確かに足し算になりがちですが、以下を押さえると総額は最適化できます。

• コミットの組み合わせ：主力CDNは月間転送量コミットを抑えめに、サブは従量課金でスパイク対応
• 地域別単価差：南米・中東・豪州などは大きく差が出るため、地域ピンポイントの優先度設定で圧縮
• 請求メトリクス：95パーセンタイル帯域課金、リクエスト課金、WAF/ボット対策の追加料金を洗い出し
• キャッシュ効率：キャッシュヒットが5ポイント上がるとオリジン/ストレージの出口課金が目に見えて下がる
• トラフィック整形：キャンペーンや大型ライブは事前に重みを調整し、コミットを無駄にしない

コストの“にぎり”はSLOと連動させます。例えば「ライブ時の開始≤1.5秒を死守、VODは≤2.0秒で十分」など目的別に優先CDNを切り替えるだけで、画質とコストのバランスが取りやすくなります。

身近な企業活用例：会員制フィットネス動画（社員40名）の失敗と改善

月額会員向けにライブ配信とVODを提供する中規模サービス。単一CDNで運用し、平日夜のライブで視聴集中が発生。ある月曜日、特定ISP経由でパケットロスが増え、平均再生開始3.8秒、リバッファ率12%に悪化、チャット欄は苦情で溢れ、解約率が翌週にかけて上振れしました。

対策として、2週間でマルチCDNへ移行。DNSの加重分散にRUMスコアを加味する仕組みを実装し、プレイヤーはマニフェストとセグメントで別経路のフェイルオーバーを可能に。URL署名鍵を共通化し、LL-HLSのパート長を1秒から1.5秒へ統一。ログは共通スキーマで集約し、障害時の差分比較を自動化。運用手順はChatGPTで初稿を作り、Claudeでチェックリスト化、Copilotでスティアリング関数のテストコードを補強、Geminiで地域×ISPの品質ヒートマップを可視化しました。

結果、翌月の大型ライブでは平均再生開始1.6秒、リバッファ率0.7%に改善。7分以上の全停止はゼロ、局所劣化が出ても60秒以内に自動で別CDNへ退避。コストは主力のコミットを見直し、サブの従量を活用して総額で8%減。カスタマーサポートの問い合わせはライブ当日比で42%減り、NPSも回復しました。技術的なキーは「鍵・ヘッダー・マニフェストの統一」と「RUM駆動の秒単位切り替え」でした。

動画プラットフォーム事業は、視聴体験の数値がそのまま解約率とLTVに跳ね返ります。マルチCDNは冗長化だけでなく、品質とコストを状況に応じて最適化するための“ハンドル”です。ルーティング、認証、キャッシュ、監視を現実解で揃え、事業のリズム（配信スケジュール、プロモ、地域展開）に合わせて運用を磨くほど、可用性は数字で語れる武器になります。