詳解！Streaming Technology CDN（Content Delivery Network）の仕組み

CDNとは、コンテンツデリバリーネットワーク（Content Delivery Network）の略称で、インターネット上でコンテンツ配信を高速かつ効率良く行なう技術・サービスのことです。具体的には、動画や画像、WEBページなどのコンテンツを、世界中に分散配置されたサーバを利用して、ユーザに近い場所から配信します。通常、WEBサイトにアクセスする場合、ユーザのブラウザはWEBサイトのサーバに対してリクエストを送信し、サーバから応答を受け取ってコンテンツを表示します。しかし、この方式ではユーザが遠く離れた場所にいる場合や、コンテンツに多数のユーザがアクセスする場合に、通信の遅延やサーバの負荷が問題となります。

そこでCDNでは、世界中に分散配置された多数のサーバにコンテンツを複製・キャッシュし、ユーザからのリクエストに対し、近い場所にあるサーバからコンテンツを配信します。これにより、通信の遅延やWEBサイトのオリジンサーバ（コンテンツを保持するサーバ）の負荷を軽減し、コンテンツの高速かつ安定した配信を実現します。

近年ではコンテンツ配信だけでなく――世界中に配置されたコンピューティングリソースやネットワークを活用し、WAF（Web Application Firewall）やDDoS防御といったセキュリティ機能を提供したり、エッジコンピューティングとしてIoTデバイスから収集されたデータを一度CDNのエッジサーバで処理し、その結果をCDN経由でクラウドに送信することでクラウド側の処理負荷を軽減する、さらには、CDNのエッジサーバにAIモデルを搭載してリアルタイムに画像や音声の解析を行なう――など、CDNの用途は大きく広がっています。

インターネットの動画配信には、おもにHLS（Apple HTTP Live Streaming）やMPEG-DASH（Dynamic Adaptive Streaming over HTTP）などのHTTPベースのストリーミングプロトコルが使用されます。これらのプロトコルは動画を小さなファイル（セグメント）に分割し、各セグメントを順番に配信することでユーザが動画をリアルタイムで視聴できるようにします。

以前はAdobe Flashの技術がインターネット動画配信では主流で、RTMP（Real-Time Messaging Protocol）というストリームプロトコルと専用の配信サーバを用いて配信されていましたが、HLSやMPEG-DASHなどのビデオセグメントをHTTPプロトコルで配信するストリーミングプロトコルの登場により、WEB向けのCDNを活用できるようになりました。

WEB向けのCDNは、動画配信プロトコル専用のCDNと比べて低コストで、大容量のデータを高性能に送信できるため、動画という比較的容量の大きなコンテンツを扱う配信において、配信速度を向上させ、安定した視聴を実現するうえで重要な役割を担っています。

NHKプラスや在京テレビ局の同時再配信など、地上波放送と同じ内容がインターネットでも視聴できるサービスが増えてきましたが、地上波の放送と見比べると、インターネット配信では10秒以上の遅れが見られます。特にサッカーなどのスポーツ映像をインターネット配信で見ていると、ゴールの瞬間を地上波で見ていた人のSNS投稿が先に目に入ることさえあります。インターネットのライブ配信にはつきものの遅延ですが、この遅延はどうして発生するのでしょうか？

動画配信においては、各工程でさまざまな遅延が発生します。

1. （1）カメラで撮影された映像がスイッチングなどを経てエンコーダに入力されるまでの遅延。
2. （2）エンコーダにおけるエンコード、トランスコード、パッケージングなど、インターネット配信に向けた処理にかかる遅延。
3. （3）エンコードされた動画ファイルがCDNを介してクライアントプレーヤーに配信されるまでの遅延。
4. （4）クライアントプレーヤーが動画ファイルを受信してから再生するまでの遅延。

これらの工程でかかる時間が動画の再生遅延として現れるのですが、なかでも（4）における配信方式に起因する遅延が大きな割合を占めています。

一般的にHLSやMPEG-DASHを用いたライブ配信では、10秒～45秒程度の遅延が発生します。HLSでもMPEG-DASHでも、仕組みとして動画ファイルを数秒単位の小さなセグメントに分割して、HTTPプロトコルを用いて配信し、クライアントプレーヤーはそれら小さなセグメントを順次ダウンロードして再生していきます。HLSでは通常6秒のセグメントを使用するため、オリジンサーバは映像ストリームを受け取ったあと、6秒間分バッファリングしたあとで動画ファイルに変換するため、この時間分、遅延が発生します。また、ほとんどのプレーヤーは安定した再生のために3つ以上のセグメントをバッファリングするため、「6秒×3＝18秒」の遅延が再生時に発生するのです。

もちろん低遅延化を望む声は多く、これらのパラメータを短くするといった調整のほか、Apple Low Latency HLS（LL-HLS）やLow Latency MPEG-DASH（LL-DASH）といった1秒～5秒程度の低遅延を実現する方式、さらにHigh Efficiency Stream Protocol（HESP）といった1秒未満の超低遅延を実現する方式もあります。これらはHTTPベースのまま低遅延を実現するので、既存のCDNを利用できるため、効率的な大規模配信を行なえます。

ただ、現時点でこういった低遅延配信が広く使われているとは言いがたいのも事実です。先に説明した通り、遅延の大部分はバッファリングによって発生しますが、これらはモバイル回線やインターネットという不安定な伝送路を用いて、動画をカクつきなく、止まらないように、安定して再生するための工夫もしくは“余裕”になります。低遅延配信はこの余裕を削ったぶんを再生の低遅延化に振り分けるため、単純に低遅延化を進めれば、逆に視聴体験が損なわれることになりかねません。

目下、より高圧縮なエンコード方式、より高精度な回線品質の推定技術など、動画を低遅延で安定的に配信する技術開発が進んでおり、インターネットでのライブ動画配信の再生遅延は、徐々に削減されていくと考えています。