Amazon CloudFrontとPeacockによるライブ・ビデオ・ストリーミング

Pulisher : Cloud Technology Center イ・ギョンソン
Description：メディアストリーミングワークロードとCloudfrontの組み合わせの紹介セッション

はじめに

今年、Amazon CloudFrontがリリースされてから15年になります。CloudFrontは、短い遅延時間、高いデータ転送速度、長期的なコミットメントなしで、エンドユーザーにコンテンツを配信する簡単な方法を提供する便利で安価なサービスです。最初はS3をOriginに置いてキャッシュのために始まりましたが、今では多くの機能が追加されたContent delivery Networkに発展しました。

単純な静的コンテンツキャッシュではなく、メディア及びエンターテイメント(M&E)業界にとってCloudFrontは非常に必要不可欠なサービスです。最近2017年にはNASAがCloudFrontを使用して初めて宇宙でライブ4Kストリーミングまで行いました。

参考リンク : https://www.youtube.com/watch?v=TnG-rGj8r6k

メディアストリーミングワークロードとCloudFrontの組み合わせに関するインサイトを得たいと思い、このセッションを申し込みました。

セッションの概要紹介

大規模なライブイベントの提供に関連する課題と、視聴者に質の高い体験を提供するために影響を与える要因の分析、Peacockというプラットフォームのアーキテクチャを共有し、収益化と配信の最適化を含むイノベーションへの道のり、そして最後にAmazon CloudFrontを通じて大規模なライブイベントを提供するためのベストプラクティスを説明するセッションです。

Live Video Streamingの核心は、ライブを行う競技場に「直接いる」ような体験を提供することだそうです。 つまり、レイテンシーが短く、品質が良く、中断することなくストリーミングする必要があるそうです。

オリンピックのようなイベントは、伝統的に地上波で放送されたり、衛星やケーブルを経由してテレビに配信されました。 しかし、過去10年間、コンテンツプロバイダーは様々なデバイスを通じてインターネットのライブイベントをオンラインで配信するようになり、これが私たちが最近楽しんでいるOver-The-Top OTTです。

初期には、ストリーミングごとにレイテンシーの差がありましたが、最近では、テクノロジーが向上し、レイテンシーが低くなり、非常にポジティブな評価を受けています。 また、移動中に見たり、好きなデバイスで見たりなど、パーソナライズされたOTTストリームは非常に柔軟になりました。 そのため、ストリームを管理する管理会社は、それだけ多くの悩みを抱えていました。

視聴者は、ライブストリーミングのレイテンシーは短く、ビデオ品質は高く、音質は良いものを期待し、何よりも、途切れのない部分を多く望んでいます。

しかし、何かが正しく動作しない原因の一つは、ストリーム設定によるもので、解像度の低下やネットワークエラーの発生を防ぐために、視聴者-ネットワークデバイス間のスループットを一致させる部分が重要だと言われています。

しかし、そのスループットが不一致することで、Client側のbuffer under runを発生させ、損失を引き起こす可能性があり、セグメンテーションによりビデオストリーミングが中断される可能性があります。

AWS Networkは、冗長化された400 GbEネットワークリンクとリージョン間のプライベート通信で設計されています。 特に、Amazon Cloudfront、グローバルネットワーク、グローバルエッジロケーションは、世界中の600以上のPoPとバックボーンに接続されています。各リージョンのpopを通じてキャッシュされ、ダッシュ時間を短縮し、視聴者にコンテンツをより速く提供します。

AWS ElementalサービスとCloudFrontを通じてライブイベントを成功裏に提供したそうです。

事例としては、スポーツリーグの複数の試合があるスポーツリーグシーズンの場合、試合が同時に重なってその試合時間中に人員管理が必要で、e-sportsの場合は3～5分の短い時間のイベントも発生したそうです。

エンドユーザーはOriginに直接アクセスしてはいけないので、これを保護するために前面にAWS WAFを置くとか、Cloudront-s3のOAC機能とか、また、アクセスする位置によって異なるコンテンツを提供するためにクエリ文字列を通じた分岐を使うとか、AWSのモニタリングサービスとも組み合わせてコンテンツ転送過程まで確認することができます。

放送とOTTの2つの共通点もあり、OTTならではの特徴の長所もあります。

やはりどちらもパッケージをエンコードし、配信パイプラインを通じてプッシュを行います。

放送は光ファイバーケーブルを介して視聴者の自宅にダイレクトに接続されて表示されますが、OTTはCDNを経由してISPを経由して使用する機器に接続されます。

このため、CDNやISPは当該配信者の所属であるpeacockに限定されないため、予測不可能性を念頭に置き、障害対策や安定性のために多くの検討が必要です。

そのため、Peacok側は、CDN Provierを選択する際、次のような点を考慮したそうです。

１．capacityの証明
希望する容量に対して予約をし、その容量内にheadroomが保証されなければならないからです。 また、CDN providerの地理的なリーチ範囲を調べ、ASNレベルについて調べ、(さらには郵便番号の住所…!)どのようなCDNがASNとマッピングされるのかについて確認が必要だそうです。

２．API統合の容易性
特に、CDNを通じて保護できるエッジコンピューティングとか、Origin shieldのような機能を提供する場合、より良いです。

３．商業的、財政的な考慮
コストに関しては、CDNに送るトラフィックの量を決定することができます。

このすべての考慮事項を通じて、トラフィックの分散、使用する場所、障害に対する措置など、ビジネスに対する計画を立てるそうです。

また、peacock側では、カオスエンジニアリングの重要性を強調し、失敗シナリオに対する大規模なテストを実施するそうです。

コードを配布するコードパイプラインのように、このワークロードにもAd Transcode Pipelineという用語があります。

このパイプラインについて簡単に説明します、

・AWS Elemental MediaConvertをトリガーする
・広告セグメントをエンコードするための動画パラメータを入力します。
・その広告セグメントはS3バケットに保存され、CDNにキャッシュされます。
・その広告セグメントをインデックス化し、記録を保持する高性能データベースに保存します。
・開発したカスタムプレーヤーを実行しているクライアントアプリケーションがビデオストリームを開始すると、peacockのビデオ広告モジュールと呼ばれるものを呼び出します。
・視聴者に広告が表示されると、その視聴者のパーソナライズされたプロファイルを考慮して、どのタイプの広告を表示するかどうかを決定します。
・Scutti 35 markerと呼ばれる広告マーカーに到達すると、サーバー側でその広告セグメントを挿入するElemental MediaTailorをトリガーし、CDNから取得します。 CDNにない場合は、S3ソースから取得します。広告を取得し、ビデオストリームに挿入して進みます。

ライブストリーミング、VODにも同じようなパイプラインが適用されるそうです。

この章表を通して、チューニングについて簡単にお話ししました。

マルチレイヤーキャッシングアプローチを採用しており、ISPに追加されたレイヤーの1つは組み込みPoPです。 このキャッシングレイヤーは、エンドユーザーに近いサービスプロバイダネットワークに配備され、伝送接続間の接続、またはそのインターネットサービスプロバイダーとCloudFront間のピアリングの負荷を軽減します。これらのISPは、ライブイベント時にリンクを拡張する必要がないため、平均的な伝送のためにアップグレードに費用をかけることなく、ピークを維持することができます。

500以上の組み込みPoPを持つCloudFrontは、デフォルトで複数の領域で提供可能であり、SDKと統合してネットワーク内の特定の組み込みPoPにトラフィックをルーティングする場合、DNSリクエストに基づいて設定することができます。

Clinent – CloudFront間の接続とキャッシュ設定について、3つの要素について、それぞれの要素に対して異なるキャッシュ構成を使用することをお勧めします。

・マニフェスト：セグメントとライブストリーミングのindexを持つファイルで、一貫して頻繁に更新されます。
・セグメント
・キャッシュエラーと呼ばれるネガティブキャッシング。

また、Cloudrontを通じて障害発生時に障害措置(フェイルオーバー)ができるように高可用性を確保することができます。

一般的に、他の地域でフェイルオーバーを実行できるように、最低限別のoriginを設定します。

CloudFrontを使用すると、あまりにも長くならないように十分な時間を待ってフェイルオーバーを試みることができるようにすべての設定を最適化することができます。

最後に、Originを保護するための方法です。

・Origin Shield
・他のCDNからCloudFrontにリクエストを送るように、マルチリージョンに対してMulti CDNを通じて保護することができます。

HLS、HTTP Live streaming、DASHのような低遅延のプロトコルにより、低遅延に対する性能を改善しました。

CloudFrontはendtoend統計とすべてのリクエストに対する分析とclientの統計が提供されます。

オリジンからセグメントを受信するのにどれくらい時間がかかったか、playerがどれくらい時間がかかったか、問題が発生した場合、その問題が発生した場所を把握することができます。

下記のgithubアドレスから、このダッシュボードを簡単にプロビジョニングして使用することができます。

参考リンク : https://github.com/aws-samples/cloudfront-cmcd-realtime-dashboard

最後に、1時間のセッションの総括を最後に締めくくりたいと思います。

セッションを終えて

普段触れたことのないMedia & Entertainmentのワークロードの方なので心配していましたが、思ったより理解できるセッションでした。Cloudfrontも今まで本当にシンプルに使っていましたが、このようなメディアサービスとの連携事例を知るきっかけとなりました。 また、Cloudfrontについて一歩近づくことができ、他の用途以外でもたくさん使えそうです。