Recommended
More Related Content
What's hot
What's hot (20)
Similar to NABShow報告：マルチCDNと最新ストリーミングプロトコル
Similar to NABShow報告：マルチCDNと最新ストリーミングプロトコル (20)
Recently uploaded
Recently uploaded (8)
NABShow報告：マルチCDNと最新ストリーミングプロトコル
- 1. マルチCDNと最新 ストリーミングプロトコル NABShow報告会 Streaming Conference #7 松澤 友弘： CyberAgent, Software Engineer
- 3. ライブインジェスト
- 4. ライブインジェスト伝送の種類 長所 短所 衛星通信 最高のパフォーマンス 莫大なコスト RTMP TCPの信頼性 長距離通信に弱い 大容量伝送に弱い 遅延 UDP + ARQ 映像配信には十分な信頼性 TCPの短所を補う 標準プロトコルが存在しな い
- 5. トップ３候補 ● 2018年にVSFが仕様策定 2019年 オープンソース版 ● RIST Forumが支援 20以上のメンバーと10程 度の実装 ● VSF TR-06-1 & オープンソース ● 2013年にHaivisionが開発 2017年にオープンソース化 ● SRT Allianceが支援 200以上のメンバー、50以 上がSRT Ready、700以上 の顧客に展開、 Microsoft Azure ● オープンソース ● 2008年にZixiが開発 ● 500以上の顧客に展開、50 以上のパートナーと協調体 制、AWS MediaConnect ● 商用
- 6. RIST ● 仕様ベースのプロトコル (複数の実装が存在) ● RTP/RTCPベース ● 標準の仕様を組み合わせる(SMPTE 2022-1, 2, 7) ● RISTを理解できないデコーダも、RTPとして受信できる ● AWS MediaConnectもサポート予定 ● Zixi、Net Insight、Cobalt Digital、VideoFlowなどのエキスパートが主要メン バー ● プロファイルを４つに分けて、簡単なところから始める Simple Profileが完成。Main Profileは今年中の見込み
- 7. RISTプロファイル ● SIMPLE PROFILE ○ ARQ ○ MPEG-TS転送 (SMPTE 2022-2) ○ ボンディング ○ FEC (SMPTE 2022-1) ● MAIN PROFILE ○ シングルポイントからマルチポイント への転送 ○ 暗号化 ○ VPNトンネリング ○ NAT traversal ○ Nullパケット抑制 ○ 自動ストリームコンフィグ ● ENHANCED PROFILE ○ 自動ビットレート調整(ABR) ○ Capability communication ● SCALABLE PROFILE ○ (非圧縮等の)高帯域ストリーム転送 ○ スケーラブルビデオ符号化(H264 annex G)
- 8. 特徴と機能の比較 Firewall travesal FEC サポート 暗号化 パス保護 フォーカス 有、両サイド 無 （サポート予定） 有 AES 128/256 無 (2022-7予定) 全てのUDPフロ ー 有、送信のみ （両サイド予定） 有 SMPTE 2022-1 無 （サポート予定） 有 (オプションでボ ンディング) ビデオ しかし、他も送 れる 有、両サイド 有、独自 コンテンツを意識 有 AES 128/256と DTLS 有、2022-7、 ボンディング、 プライマリ／スタ ンバイ ビデオ しかし、全ての UDPで動作
- 9. 試験設定 ケース１：ダウンリンクでドロップ、理想的なリターンパス ● 一回の実行で８分間測定 ● 全プロトコルで３回試行する ● 全プロトコルで遅延バッファは、200msecに設定 ● リンク容量は10Mbpsで、ビデオフィードは7Mbps CBR ● ポアソン分布でフォワードパスにドロップを設定し、 0%から8%の間で2%ずつ増加させていいく SRT 1.3.2 最新版 Zixi 1.10.0.33.198 R 1.12.xが最新 RIST プレリリース 2019-03-21.0 ビルド
- 11. 試験設定 ケース２：ダウンリンクとリターンパスでドロップ ● 一回の実行で８分間測定 ● 全プロトコルで３回試行する ● 全プロトコルで遅延バッファは、200msecに設定 ● リンク容量は10Mbpsで、ビデオフィードは7Mbps CBR ● ポアソン分布でフォワードパスにドロップを設定し、 0%から8%の間で2%ずつ増加させていいく ● ポアソン分布でリバースパスに3%固定のパケットド ロップを設定 SRT 1.3.2 最新版 Zixi 1.10.0.33.198 R 1.12.xが最新 RIST プレリリース 2019-03-21.0 ビルド
- 14. ベンチマークからの結論 ● SRTは低パケットロス率の環境では、最高のパフォーマンス ● RISTとZixiは、高パケットロス率の環境で、より良い結果を示した。特にリ バースパスに障害がないときは、Zixiはかなり良い結果を示した。 ● RISTがプレリリースで、新しいプロトコルであることを考慮すると、かなり 良い結果だと言える
- 15. 低遅延ストリーミング プロトコル
- 16. ライブストリーミングプロトコルの遷移 RTSP：90年代の主流。Netscape、Real Networks RTMP：Flashの普及と共に主流に。Appleがbanして廃れていく HTTP + ABR：HLS、MPEG-Dash等。遅延が問題 独自のプロトコル： WebRTC、WebSocket：ベンダーロックインの可能性 HTTP Chunked Transfer：CMAF CTE、LHLS、HESP
- 19. HTTP Chunked transfer encoding事例 ● Periscope (LHLS) 2016年 https://medium.com/@periscopecode/introducing-lhls-media-streaming-eb6212948bef ● FRESH Live (LHLS) 2017年 https://medium.com/freshdevelopers/implementing-lhls-on-hls-js-4fc4558edff2 ● YouTube Live 2017年 ● Twitch (LHLS) 2018年 https://www.nabshow.com/session/streaming-summit/track-case-study-how-twitch-achieves-low-latency-live-streaming-scale チャレンジ ● エンコーダー、Origin、プレイヤーの開発 ● ABR ● 暗号化
- 20. AWS MediaStore + NexPlayer CMAF CTEデモ
- 21. Bitmovin Player (CMAF CTE) ブースで質問：ABRはどうですか？ 回答：We are still working on it. Bitmovinのセッションで気になる発言 ● TwitchはLHLSを一度試したが、スケールの問題でロールバックした。小さなユースケースで動作 しているが、本当にうまくいっているというのは聞いたことがない。100万の同時接続でうまくい くかは、まだ分からない。 Twitchは現在LHLSを使用。しかしTwitchは専用のCDNを使用
- 22. THEOplayer - HESP High Efficiency Streaming Protocol ● 対話可能なレベルの超低遅延 ● 帯域オーバーヘッドを10-20%削減 ● HTTPベースCDNによるスケール ● 瞬時のストリーム切替が可能（即時再生開始） シークレット：再生開始時のみ、全てのフレームがキーフレームになる？？？ （特許申請中） ベンダーロックインは？
- 23. HESP Pieter-Jan（THEOplayer CTO）： Also, our next step is to open up the protocol for all the industry to enjoy. We don't like the proprietary way either. （次のステップは、このプロトコルを全業界が楽しめるよう、オープンにするこ と。我々も私有にする方法は好きではない）
- 24. クライアントベース マルチCDN
- 25. なぜマルチCDN？ 品質： ● 地域/地理/ISPのサービス区域を増やす ● 全体的パフォーマンス向上 ● 冗長性/フェイルオーバー コスト/柔軟性： ● ベンダーロックインを防ぐ ● より良いコミット契約の管理 ● 値段交渉に利用
- 27. ステップ２CDN切替戦略の計画 地理 / ビジネスルール コミット契約ベースルール QOSベースルール ● CDNメトリクス vs プレイヤーメトリクス ● データソース
- 28. ステップ２CDN切替戦略の計画 グローバル集約データベース パブリッシャー顧客データベース 視聴者ごとのローカルデータ たくさんのビデオプラットフォームと地域からの CDNおよび/または視聴者からのデータ 自分のCDNおよび/または視聴者からのデータ クライアントサイド、個々のユーザーの 端末からのデータを使用
- 29. ステップ２CDN切替戦略の計画
- 30. ステップ３CDN切替ツールの選択 ● DNSマルチCDNソリューション ● プロキシでマニフェストをオンザフライで書き換える ● サーバーサイドCDNスイッチャー ● クライアントサイドCDNスイッチャー
- 31. ステップ３CDN切替ツールの選択
- 32. ステップ３CDN切替ツールの選択
- 33. ステップ３CDN切替ツールの選択
- 34. ステップ３CDN切替ツールの選択
- 35. ステップ３CDN切替ツールの選択
- 36. ステップ３CDN切替ツールの選択
- 37. ステップ３CDN切替ツールの選択
- 38. ステップ３CDN切替ツールの選択
- 39. ステップ３CDN切替ツールの選択
- 40. ステップ３CDN切替ツールの選択
- 41. ステップ３CDN切替ツールの選択
- 42. クライアントサイド DNSベース マニフェスト書換 サーバーサイド ストリームの 途中での切替 可 不 ❌ ライブコンテンツの み ▲ 不 ❌ 冗長性 単一障害点がない ある条件下で単一 障害点になり得る ▲ 書換が単一障害点に なり得る。さらに、 マニフェスト書換の バグは危険 ▲ ある条件下で単 一障害点になり 得る ▲ QOSメトリク ス リアルタイム、個々 の端末メトリクスご と 集約グローバルデ ータ ❌ ストリーム単位 集約グローバル データ ❌ 遅延 & 反応性 セグメントごとなの で、遅延なしでCDN 切替 DNSエントリの TTLに依存した遅 延。通常は５分以 上 ❌ 遅延の可能性：サー バーがCDN障害、画 質劣化を認識するの に数秒以上かかり得 る ❌ ページロード時 に多少遅延が入 る ❌
- 43. クライアントサイドマルチCDN製品 Streamroot Compass ● 2018年8月リリース ● Webのみサポート ● iOS、Androidは開発中 ● 各CDNとの契約は顧客が行い、StreamrootのマルチCDNに追加 Peer5 MultiCDN ● 2019年2月リリース ● Webサポート ● iOS、AndroidはDNSベースマルチCDNとして動作、マニフェスト書換に変更予定 ● Peer5があらかじめ15のCDNと契約しており、顧客はすぐにマルチCDNを使用可能
Editor's Notes
- こんばんは、CyberAgentでストリーミングエンジニアをしている松澤と申します。 先日ラスベガスで開催されたNABShowに行かせていただいたのですが、その中でライブストリーミング関連の情報をいくつか共有させていただきます。 タイトルは、マルチCDNと最新ストリーミングプロトコルです。
- こちらが発表内容です。 ライブストリーミングのシステムは大きくこのようなコンポーネントに分割されます。 まず、ライブフィードからエンコーダへ映像pデータを送信する、ライブインジェストで主流になりつつある３つのプロトコルについて話します。 次に、サーバーからプレイヤーへ映像データを低遅延で配信するための本命となりつつあるChunked Transfer Encodingをベースとしたプロトコルについて話します。 最後にクライアントベースマルチCDNについて話す予定ですが、時間的に間に合わない可能性が高いので、その時は割愛させていただきます。後でスライドはシェアさせていただこうと思います。
- まずライブインジェストです。
- 現在ライブインジェストでは、主にこの３つの方法が使われていると認識しています。 一つは衛星通信で、これは最高のパフォーマンスを発揮しますが、莫大なコストがかかるという欠点があります。 もう一つは、TCPベースのRTMPを使った伝送方法です。既存のインターネットの資源を利用でき、コストを大幅に削減できます。TCPではパケット再送が保証されるため、信頼性のある通信が可能です。しかし長距離通信に弱い、大容量伝送に弱い、劣悪な環境で大幅な遅延が発生するという問題があります。 この弱点を補った方法として、UDPとARQを組み合わせた方法があります。ARQではある閾値を越えるとパケット再送を諦めるため、時々パケットロスが発生しますが、映像配信には十分な信頼性を確保します。しかし、各社が独自にプロトコルを開発して、標準のプロトコルが存在しないという問題があります。
- 各社で別々のソリューションが作られてきたARQベースのプロトコルですが、現在３つのプロトコルが飛び抜けつつあります。 まずRISTですが、まだ広く利用されているわけではありませんが、Video Services Forumが仕様を作成しており、大きなポテンシャルを持っています。 RIST Forumには20以上のメンバーが加入しており、すでに10個程度のRIST実装が存在しています。 オープンソースのRIST実装もGStreamerの一部としてリリースされました。 次にSRTですが、2017年にオープンソース化され、700以上の顧客がいると言われています。FRESH LiveでもiOSからのインジェストプロトコルとして採用しています。 最後にZixiですが、これはもっとも歴史があり2008年に開発されました。多くの顧客が存在し、Abema TVでも採用しています。 他の２つと大きく異なるのは、商用であり、お金はかかりますが、問題があればサポートを受けられるという利点があります。
- ここでRISTは初めて聞く方も多いと思うので概要を説明します。 これは仕様ベースのプロトコルです。私が知る限りSRT、Zixiには一つの実装しか存在していません。しかし、RISTは仕様が先にあり、各社がその仕様に準じて実装するので、複数の実装が存在します。例えばZixiのRIST実装、NetinsightのRIST実装、オープンソースのRIST実装といった具合です。そしてそれらの別の実装に相互互換性があるというのがRISTの最大の特徴です。これによりある会社の機器と別の会社の機器が繋がらないというような問題が解消されます。 これはRTP/RTCPベースのプロトコルです。 SMPTE 2022-1, 2, 7などの標準仕様を出来るだけ使用して互換性を重視しています。 RISTを理解できないデコーダも、RISTのストリームをRTPとして理解可能です。 AWS Media Connectもサポートに動いています。 Zixi、Net Insight、Cobalt Digital、VideoFlowなどの業界を代表するエキスパートが主要になり仕様を作成しています。 いきなり複雑な仕様を作らずに、プロファイルを４つに分けて簡単なところから始めるという手法を取っています。 Simple Profileはすでに完成しており、現在Main Profileの仕様を作成中で、今年中にはリリースされる予定です。
- これがRISTの４つのプロファイルです。 SIMPLE PROFILEでは、ARQ、MPEG-TS転送、FECのような基本機能以外に、ボンディングも入っています。例えばiPhoneでLTEとWi-Fiコネクションを結合（つまりボンディング）して一つの映像を伝送することにより、より安定した配信が可能になるかもしれません。 今年リリース予定のMAIN PROFILEで様々な機能が追加される見込みです。
- 特徴と機能を比較します。 Firewallは、通常アウトバンドは通過させますが、インバウンドをブロックします。それでも通信可能にするのがFirewall traversalですが、SRT、Zixiとも実装されており、RISTでもMain Profileで追加される予定です。 FECサポートについては、SRTは将来サポート予定です。RISTは標準のSMPTE 2022-1がオプションとして入っています。Zixiは独自のFECで相互互換性を持ちませんが、IフレームのみFECを使うという賢い方法を採用しています。 暗号化については、SRT、Zixiはサポートしており、RISTはMain Profileで追加予定です。 パス保護とは、Fail overやbondingのことです。SRTは2022-7のFail overを実装予定です。RISTはSimple Profileですでにbondingが入っています。ZixiはFail Over、Bonding、プライマリ/スタンバイをサポートしています。
- Net insightの方のセッションで、SRT、Zixi、RISTの性能比較試験について話されていたのですが、それについて紹介します。 SRT、Zixiでは出来るだけ最新のものを使用したそうです。 RISTはNet insightのRIST実装のプレリリース版を使用したそうです。SRT、Zixiでは唯一の実装しかないのに対し、RISTは仕様ベースのため各ベンダーのRIST実装で異なるパフォーマンスを示すかもしれないところが興味深いところです。 このような条件で試験を行い、このケースではフォワードパスだけパケットロスさせています。
- パケットロス率2%までは、全プロトコルで同じ結果でパケットロスを完全に回復しています。 4%を越えると、RISTとZixiで回復後のパケットロス率が増えてきます。 SRTでは、8%までパケットロスを完全に回復しました。
- 次に、リターンパスにも3%のパケットロスを挿入して他は同じ条件で試験をしたそうです。 リターンパスでパケットロスが発生すると、ARQでの再送依頼パケットがドロップすることになるため、パケットロス回復の難易度が非常に高くなります。
- 4%からどのプロトコルでも回復後のパケットロス率が増加します。 最初のケースに比べて、１.５倍程度のパケットロス率になりました。
- このテストケースで、SRTは素晴らしい結果を示しました。 Net insightでSRTの結果が良い原因を探ろうとしたそうです。 調査の結果、SRTは5分間で、Zixi、RISTより8%多くのパケットを送信しているが、2%しかデータレートが増えていないことが分かりました。 つまり、SRTは全体的に小さなサイズのパケットを送信していることになります。 ソースコードまでは解析しておらず、仕組みは分かりませんが、SRTで何か面白いことをやっているはずです。 SRTでは10%以上のパケットロスを挿入すると、回復後のパケットロス率が13%になりました。回復後の方がパケットロス率が増えたのでバグのように見えました。 RISTでも同様の現象が16%のパケットロスで発生し、原因を解析中ですが、時間がかかりそうです。 中間の伝送装置でバッファサイズを1024kに設定して試験を行っていましたが、32kに変更したところ、パケットロスを挿入しなくてもSRTで4%のパケットロスが発生するという現象も観測されました。
- ベンチマークからの結論としては、SRTは低いパケットロス率では、最高のパフォーマンスを示しました。 高いパケットロス率では、RISTとZixiでより良い結果となりました。 ZixiはRistより少しよく、特にリバースパスが正常なら、Zixiはかなり良い結果となりました。 ここで使ったRIST実装はプレリリースであることを考慮すると、かなり良い結果だと言えます。
- 次にトピックが変わって、低遅延ストリーミングプロトコルです。
- まず、ライブストリーミングプロトコルの歴史を少し見てみます。 90年代は、Netscape、Real Networksが中心に標準化が行われたRTSPが主流でした。 その後Flashの普及と共に、Adobeが開発したRTMPがよく使われるようになりました。しかし、AppleがFlashを採用しなかったのをキッカケに廃れていきます。 現在は、HTTPベースのHLS、MPEG-Dashがもっともよく使われています。しかし10秒から30秒程度の大きな遅延が問題になってきています。 遅延の問題を解決するために、WebRTC、WebSocketなどをベースにした様々なプロトコルが各社で作られてきましたが、ベンダーロックインの可能性という問題があります。 このような状況で、HTTP Chunked Transferという技術を使った低遅延とスケールの両方を備えた方式が、本命になりつつあります。
- 既存のHLSやMPEG-DASHでは、数秒から10秒程度のセグメント単位で、エンコーダからオリジンへHTTPで送信し、プレイヤーはCDNを介してセグメント単位で取得するということを行うため、多くの遅延が発生します。 このHTTP GETとPOSTをHTTP 1.1で導入されたChunked Transfer Encodingで、Chunkと呼ばれるより細かい単位でビデオを伝送するのが、この方式の基本です。
- これをAkamaiのWill氏が分かりやすくセッションで説明していました。 このビデオをご覧ください。 これがエンジニアではないCEOにchunked encodingを説明するためのアニメーションです。 水道から出てくる水をモンキーに飲ませます。 これはエンコーダを表しています。 水がエンコーダに入り、通常は6秒間ためて、CDNに流し込みます。 ここで6秒間たまります。 そしてプレイヤーに流し込みます。 プレイヤーで6秒間溜めます。 実際、標準HLS、DASHでは３つのバケツを持っています。 chunked transferを例えるとすると、それぞれのバケットに穴が空いています。 データ転送はこのように、パイプに入ると、すぐに出てきます。 これは正確な例えではありませんが、遅延を減らすためにどうすれば良いかを理解するのには十分です。 低遅延のためには、少なくともセグメント長を１秒にしなくてはなりません。
- HTTP Chunked transfer encodingはすでにいくつかのサービスで使われています。 PeriscopeがLHLSを2016年に導入し始めました。 2017年に私も以前開発していたFRESH LiveでもLHLSを使った低遅延モードを導入しました。 同じ頃にYouTube LiveでもChunked transfer encodingを使った超低遅延モードを導入しました。 Twitchでも2018年にはLHLSを使った低遅延モードを導入しています。 しかしながら、Chunked transferに対応した、エンコーダー、Origin、プレイヤーの製品は少なく、通常は独自に開発する必要がありました。 ABR、暗号化も標準HLSと同じ方法は使えず、敷居はかなり高いです。 それで今回のNABShowでChunked transferに対応した製品がないか見てみようと思っていました。
- まず目に入ったのは、AWSブースでの、MediaStoreとNexPlayerを使ったCMAF Chunked Transfer Encodingのデモでした。 MediaStoreは、AWS ElementalのLive Origin製品ですが、以前からこれがChunked Transferに対応するという噂を聞いていました。 NABShowの少し前に、Chunked Transfer対応をリリースしたそうです。 デモではNexPlayerと呼ばれるChunked transfer対応のプレイヤーを使って、２、３秒の遅延を実現していました。 MediaStoreの良いところは、書き込まれたセグメントがそのままS3に転送されるところで、アーカイブの実装も必要なライブストリーミングサービスの実装をシンプルにすることができると思います。
- 次に、以前から気になっていたBitmovin Playerについて、ブースで話を聞いてきました。 一番きになるABRについて質問してみました。 しかし、「We are still working on it」という正直な回答が返ってきました。 またBitmovinの方が発表していたセッションで気になる発言がありました。 「TwitchはLHLSを一度試したが、スケールの問題でロールバックした。小さなユースケースで動作しているが、本当にうまくいっているというのは聞いたことがない。100万の同時接続でうまくいくかは、まだ分からない。」とのことです。 この発表内容は少し古いはずで、現時点でTwitchは今でもLHLSを使用していることを確認しています。しかしTwitchは、自力で開発した専用のCDNを使用していますし、YouTube Liveも同じだと思うので、信憑性の高い情報だと思われます。
- 最後の低遅延ストリーミングプロトコルとしてTHEOplayerのHESPについて紹介します。 これはTHEOplayerが開発したChunked Transferベースのプロトコルで、High Efficiency Streaming Protocolと呼ばれます。 同じChunked Transferを使ったCMAF Chunked Transfer Encodingに比べても、低遅延を実現できるとのことです。 CMAFに比べて10から20%ほど帯域オーバーヘッドを削減しています。 HTTPベースのCDNを使えます。 瞬時に別のストリームに切り替えることができます。つまり再生開始までのローディングがほとんど起こりません。 この秘密は何かをTHEOplayerの方に訪ねてみたところ、「再生開始時のみ、全てのフレームがキーフレームになる」という自分の常識を超えた回答が返ってきました。特許申請中だそうです。 しかしながら、ベンダーロックインはどうなのという疑問が出てきます。
- しかし、video-devというSlackグループにおいて、THEOplayer CTOのPieter-Janがこのような発言をしていました。 「次のステップは、このプロトコルを全業界が楽しめるよう、オープンにすること。我々も私有にする方法は好きではない」 今後の動きが非常に楽しみです。
- 最後のトピックはクライアントベースマルチCDNです。
- どうしてマルチCDNを使いたいのでしょうか？色々な理由があります。 まず、品質です。地域/地理/ISPのサービス区域を増やすことができます。それぞれの地域、ISPで最適なCDNを選択すれば全体的なパフォーマンスを向上することにもなります。 もちろん冗長性、フェイルオーバーという利点もあります。 コストと柔軟性の観点での理由もあります。 ベンダーロックインを防いでくれます。毎月決まった額をの料金を支払い、月額最低利用料のコミットがあるCDNもうまく管理することが可能です。 それぞれのCDNとの値段交渉に役にたつかもしれません。
- マルチCDNを導入するにはどうしたら良いでしょうか？ まず全てのワークフローをマルチCDNに対応させる必要があります。 パッケージング、DRMなどの全てが、全てのCDNで動作するようにする必要があります。 そして、全てのCDNが一つのオリジンに向くようにします。
- 次に、CDNを切り替えるための条件を決定します。 一つは地理/ビジネスルールで、このCDNは、この地域で良いパフォーマンスを示すなど。 次にコミット契約ベースルールで、あるCDNでコミットに到達したら、別のCDNを使うなど。 最後にQOSベースルールですが、色々なQOSメトリクスがあります。CDNのエラーレートなどCDNから取得できるメトリクス、バッファリングのようにプレイヤーから取得するメトリクスがあります。
- これらのメトリクスをどこから取得するかという問題があります。 これらの情報を提供するたくさんのQOSプロバイダーが存在しています。 しかし、これらのグローバルデータは、自分のユーザーのものではないので、適切ではない場合も多いです。 そこで、プレミアムサービスを使って、自分のCDNと視聴者からのデータだけを使うようにしてもらいます。これでかなりよくなりますが、まだ平均値を使っていることになります。 最後の方法は、再生している個々の視聴者から直接データを取得することで、これは最も正確なデータになるはずです。
- 最後にこれらの条件に優先順位をつけていきます。 まずは地域ベースルールを優先して、次にコンテンツタイプ、QOSベースルールを使うといった具合です。
- 次にマルチCDNの実装法について見ていきます。
- まずDNSマルチCDNソリューションです。 クライアントは、セグメントに対するGETリクエストを発行します。この時DNS解決が行われ、mycdn.comのIPが返されます。そしてCDN1からセグメントをダウンロードします。
- CDNを切り替えたい時は、右上にあるCDN SwitcherがDNSエントリを更新します。
- 次のリクエストからは、CDN2からセグメントがダウンロードされます。この方法はクライアントサイドにあまり関係がないので、簡単に実現できます。 しかし、DNSの更新に最低でも５分ほどかかります。そして、CDN Switcherが単一障害点になります。つまり、CDN Switcherがダウンして、一つのCDNが落ちたら、何もできなくなります。
- 次の実装法の候補がマニフェスト書換です。 ユーザーとCDNの間にProxyを設置します。
- CDNを切り替えたい時は、Proxyがマニフェストを書き換えます。
- そして、クライアントは、別のCDNからセグメントをダウンロードします。 この方法はライブ配信でうまく動作します。クライアントは頻繁にマニフェストをダウンロードするため、ストリームの途中でもCDNを切り替えることが可能です。 しかしマニフェスト書換プロキシが単一障害点になります。もしこれに問題が発生すると全てのシステムが動作しなくなります。
- 次に紹介するサーバーサイドCDN切り替えが、今ではよく使われています。 ユーザーが再生ページを開きます。
- すると、Multi-CDNサーバーへどのコンテンツを再生するかを伝えます。サーバーはその時の最適なCDNを返します。
- 別の地域からの問い合わせなら、別のCDNを返すかもしれません。 この方法の問題は、ストリームの再生中にCDNを切り替えることができないことです。 特に大規模配信で問題です。一つのCDNが突然ダウンしたら、例えば２秒後に、再生ページをリロードすることになります。これが大量のユーザーで同時に起こるとさらなる問題を引き起こします。
- 次の実装法がクライアントサイドCDN切り替えです。 クライアントに、CDNスイッチャーを組み込みます。そしてサーバーサイドCDNスイッチャーと協調して動作します。 まずMulti-CDN ServerへのAPIで切り替えルールと各CDNからのスコアを得ます。 一番良いスコアのCDNからセグメントをダウンロードします。
- クライアントでのパフォーマンス計測でスコアが変わったら、リアルタイムで別のCDNに切り替えます。
- まとめるとこのようになります。 この表を見て分かるように、全ての面で問題がないのは、クライアントサイドのみです。
- クライアントサイドマルチCDNを提供するサービスがいくつかリリースされています。 一つがStreamrootのCompassです。これは去年の8月にリリースされました。現在Webのみのサポートで、iOS、Androidは開発中とのことです。 顧客があらかじめ契約しているCDNを、Streamrootのmaruti CDNへ追加する形になります。 これに対してPeer5もマルチCDNサービスを今年の2月にリリースしました。 これはWebはクライアントサイドマルチCDNとして動作しますが、iOS、AndroidはDNSベースMulti CDNとして動作するそうです。これをマニフェスト書換に変更してモバイルでも高速に切り替えるようにする予定とのことです。 これの最大の特徴は、Peer5があらかじめ15のCDNと契約しており、このサービスを使えば各CDNとの契約無しにすぐにマルチCDNを使えるという点です。