CloudFrontがリリースされてから15年になります。CloudFrontは、短い遅延時間、高いデータ転送速度、長期的なコミットメントなしで、エンドユーザーにコンテンツを配信する簡単な方法を提供する便利で安価なサービスです。Networkに発展しました。単純な静的コンテンツキャッシュではなく、メディア及びエンターテイメント(M&E)業界にとってCloudFrontは非常に必要不可欠なサービスです。最近2017年にはNASAがCloudFrontを使用して初めて宇宙でライブ4Kストリーミングまで行いました。https://www.youtube.com/watch?v=TnG-rGj8r6kメディアストリーミングワークロードとCloudFrontの組み合わせに関するインサイトを得たいと思い、このセッションを申し込みました。CloudFrontを通じて大規模なライブイベントを提供するためのベストプラクティスを説明するセッションです。Streamingの核心は、ライブを行う競技場に「直接いる」ような体験を提供することだそうです。レイテンシーが短く、品質が良く、中断することなくストリーミングする必要があるそうです。オリンピックのようなイベントは、伝統的に地上波で放送されたり、衛星やケーブルを経由してテレビに配信されました。初期には、ストリーミングごとにレイテンシーの差がありましたが、最近では、テクノロジーが向上し、レイテンシーが低くなり、非常にポジティブな評価を受けています。移動中に見たり、好きなデバイスで見たりなど、パーソナライズされたOTTストリームは非常に柔軟になりました。そのため、ストリームを管理する管理会社は、それだけ多くの悩みを抱えていました。視聴者は、ライブストリーミングのレイテンシーは短く、ビデオ品質は高く、音質は良いものを期待し、何よりも、途切れのない部分を多く望んでいます。何かが正しく動作しない原因の一つは、ストリーム設定によるもので、解像度の低下やネットワークエラーの発生を防ぐために、視聴者-ネットワークデバイス間のスループットを一致させる部分が重要だと言われています。runを発生させ、損失を引き起こす可能性があり、セグメンテーションによりビデオストリーミングが中断される可能性があります。GbEネットワークリンクとリージョン間のプライベート通信で設計されています。Cloudfront、グローバルネットワーク、グローバルエッジロケーションは、世界中の600以上のPoPとバックボーンに接続されています。各リージョンのpopを通じてキャッシュされ、ダッシュ時間を短縮し、視聴者にコンテンツをより速く提供します。ElementalサービスとCloudFrontを通じてライブイベントを成功裏に提供したそうです。事例としては、スポーツリーグの複数の試合があるスポーツリーグシーズンの場合、試合が同時に重なってその試合時間中に人員管理が必要で、e-sportsの場合は3~5分の短い時間のイベントも発生したそうです。WAFを置くとか、Cloudront-s3のOAC機能とか、また、アクセスする位置によって異なるコンテンツを提供するためにクエリ文字列を通じた分岐を使うとか、AWSのモニタリングサービスとも組み合わせてコンテンツ転送過程まで確認することができます。放送とOTTの2つの共通点もあり、OTTならではの特徴の長所もあります。どちらもパッケージをエンコードし、配信パイプラインを通じてプッシュを行います。放送は光ファイバーケーブルを介して視聴者の自宅にダイレクトに接続されて表示されますが、OTTはCDNを経由してISPを経由して使用する機器に接続されます。このため、CDNやISPは当該配信者の所属であるpeacockに限定されないため、予測不可能性を念頭に置き、障害対策や安定性のために多くの検討が必要です。Provierを選択する際、次のような点を考慮したそうです。希望する容量に対して予約をし、その容量内にheadroomが保証されなければならないからです。providerの地理的なリーチ範囲を調べ、ASNレベルについて調べ、(さらには郵便番号の住所...!)どのようなCDNがASNとマッピングされるのかについて確認が必要だそうです。shieldのような機能を提供する場合、より良いです。3.商業的、財政的な考慮コストに関しては、CDNに送るトラフィックの量を決定することができます。このすべての考慮事項を通じて、トラフィックの分散、使用する場所、障害に対する措置など、ビジネスに対する計画を立てるそうです。peacock側では、カオスエンジニアリングの重要性を強調し、失敗シナリオに対する大規模なテストを実施するそうです。Pipelineという用語があります。MediaConvertをトリガーする・広告セグメントをエンコードするための動画パラメータを入力します。・その広告セグメントはS3バケットに保存され、CDNにキャッシュされます。・その広告セグメントをインデックス化し、記録を保持する高性能データベースに保存します。・開発したカスタムプレーヤーを実行しているクライアントアプリケーションがビデオストリームを開始すると、peacockのビデオ広告モジュールと呼ばれるものを呼び出します。・視聴者に広告が表示されると、その視聴者のパーソナライズされたプロファイルを考慮して、どのタイプの広告を表示するかどうかを決定します。MediaTailorをトリガーし、CDNから取得します。CDNにない場合は、S3ソースから取得します。広告を取得し、ビデオストリームに挿入して進みます。ライブストリーミング、VODにも同じようなパイプラインが適用されるそうです。この章表を通して、チューニングについて簡単にお話ししました。マルチレイヤーキャッシングアプローチを採用しており、ISPに追加されたレイヤーの1つは組み込みPoPです。このキャッシングレイヤーは、エンドユーザーに近いサービスプロバイダネットワークに配備され、伝送接続間の接続、またはそのインターネットサービスプロバイダーとCloudFront間のピアリングの負荷を軽減します。これらのISPは、ライブイベント時にリンクを拡張する必要がないため、平均的な伝送のためにアップグレードに費用をかけることなく、ピークを維持することができます。500以上の組み込みPoPを持つCloudFrontは、デフォルトで複数の領域で提供可能であり、SDKと統合してネットワーク内の特定の組み込みPoPにトラフィックをルーティングする場合、DNSリクエストに基づいて設定することができます。CloudFront間の接続とキャッシュ設定について、3つの要素について、それぞれの要素に対して異なるキャッシュ構成を使用することをお勧めします。・マニフェスト:セグメントとライブストリーミングのindexを持つファイルで、一貫して頻繁に更新されます。・セグメント・キャッシュエラーと呼ばれるネガティブキャッシング。Cloudrontを通じて障害発生時に障害措置(フェイルオーバー)ができるように高可用性を確保することができます。一般的に、他の地域でフェイルオーバーを実行できるように、最低限別のoriginを設定します。CloudFrontを使用すると、あまりにも長くならないように十分な時間を待ってフェイルオーバーを試みることができるようにすべての設定を最適化することができます。最後に、Originを保護するための方法です。CDNを通じて保護することができます。streaming、DASHのような低遅延のプロトコルにより、低遅延に対する性能を改善しました。CloudFrontはendtoend統計とすべてのリクエストに対する分析とclientの統計が提供されます。オリジンからセグメントを受信するのにどれくらい時間がかかったか、playerがどれくらい時間がかかったか、問題が発生した場合、その問題が発生した場所を把握することができます。下記のgithubアドレスから、このダッシュボードを簡単にプロビジョニングして使用することができます。https://github.com/aws-samples/cloudfront-cmcd-realtime-dashboard1時間のセッションの総括を最後に締めくくりたいと思います。Entertainmentのワークロードの方なので心配していましたが、思ったより理解できるセッションでした。Cloudfrontも今まで本当にシンプルに使っていましたが、このようなメディアサービスとの連携事例を知るきっかけとなりました。Cloudfrontについて一歩近づくことができ、他の用途以外でもたくさん使えそうです。