CDN

視聴者が増えた途端に配信が止まる。更新したはずの字幕ファイルが古いまま表示される。動画配信で起きるこの2つの症状は、どちらもCDNの設定に原因があることが多いです。CDNは視聴者に近いサーバーにファイルの写しを置いて返す仕組みで、動画配信では「どのファイルを何秒写しておくか」の決め方が品質を左右します。

CDNが動画配信で使われる場面

いまのネット動画の大半は、HLSやMPEG-DASHのように映像を数秒ずつのファイルに刻み、HTTPで配る方式で動いています。セグメントはただの静的ファイルなので、Webページの画像と同じようにCDNに載せられます。1万人が同じセグメントを取りに来ても、オリジンが返すのはCDNへの1回ぶんで済みます。

使われる場面は次の通りです。

• 見逃し配信や動画配信サービスのVOD。人気の番組ほどキャッシュが効き、転送の大半をエッジが返す
• スポーツや式典のライブ配信、放送の同時配信。開始直後に視聴が集中しても、オリジンの前でCDNが受け止める
• 大規模イベントでは複数のCDNを併用し、1社の障害で配信が止まるのを避ける

どの配信方式がCDNと相性が良いかは、配信プロトコルを遅延で比べたコラムでも整理しています。

CDNの仕組み

視聴者のリクエストは、DNSやAnycastによって地理的・ネットワーク的に近いエッジサーバーへ誘導されます。エッジが目的のファイルを持っていればそのまま返し（キャッシュヒット）、持っていなければオリジンから取ってきて、返すと同時に一定時間保存します。オリジンへの問い合わせをさらに減らすため、エッジとオリジンの間に中間のキャッシュ層（オリジンシールド）を置く構成もよく使われます。

どれくらいの時間保存するかは、オリジンが返すCache-Controlヘッダーか、CDN側の設定で決めます。ライブ配信では、数秒ごとに書き換わるプレイリスト（m3u8やMPD）と、一度作られたら変わらないセグメントとで、適切な保存時間がまったく違います。

低遅延の配信では、CMAFのチャンクをエッジがためこまずに中継できることが条件になります。DASH-IFの指針では、パッケージャへの入力からCDNのエッジまでHTTPのchunked transfer encodingに対応していることが求められており、エッジがセグメント1本を受け取り終えてから返す作りだと遅延は元に戻ります。

CDNの設定で間違えやすい点

動画配信のトラブルでよく見るのは次のような設定です。

• ライブのプレイリストを長く保存すると、視聴者に古い一覧が返り、映像が止まったり進まなかったりする。プレイリストはセグメント長より短く、セグメントは長く保存するのが基本
• まだ作られていないセグメントを取りに行って返った404が保存され、しばらく同じ番号のファイルが取れなくなる
• 視聴者ごとのトークンをクエリ文字列に付けたまま保存の単位にすると、全員が別ファイル扱いになりヒット率が落ちる
• ブラウザのプレイヤーが別ドメインからファイルを取るのに、CORSのヘッダーが返っておらず再生できない
• 字幕やサムネイルを同じファイル名で差し替え、キャッシュの削除（パージ）を忘れて古いものが出続ける

差し替えが多いファイルは、名前にバージョンを含めて別ファイルとして置くほうが、パージの手間もかかりません。

よくある質問

CDNとは簡単に言うと何ですか

配信元のファイルを各地のサーバーに写しておき、視聴者に近い場所から返す仕組みです。配信元の負荷を減らしつつ、遠くの視聴者にも速く届けられます。

CDNを使うとライブ配信の遅延は短くなりますか

通信の距離が縮むぶん少しは速くなりますが、HLSやDASHの遅延の大部分はセグメントを数本ためてから再生する方式そのものから来ています。遅延を大きく縮めたいなら、LL-HLSのような低遅延の方式とそれに対応したCDNの組み合わせが必要です。

CDNの料金は何で決まりますか

多くの事業者は、視聴者へ送ったデータの量とリクエストの数で課金し、地域によって単価が変わります。動画は転送量が大きいので、ビットレートの設計やキャッシュヒット率がそのまま費用に響きます。