re:Invent 2023: NBCUniversalとAmazonが語る大規模ライブ配信の裏側
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Live video streaming with Amazon CloudFront and Peacock (NET328)
この動画では、Amazon CloudFrontとPeacockによる大規模ライブビデオストリーミングの裏側が明かされます。NBCUniversalのSimon RiceとAmazonのTal Shalomが、数百万人規模の視聴者に高品質な体験を提供するための技術的課題と解決策を詳しく解説します。embedded POPs、Origin Shield、低遅延HTTPなどの最新技術や、Common Media Client Data (CMCD)を活用したエンドツーエンドの可観測性など、ここでしか聞けない具体的な実装方法や運用ノウハウが満載です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Amazon CloudFrontとPeacockによるライブビデオストリーミングセッションの概要
ご参加いただきありがとうございます。こちらはセッションNET328、Amazon CloudFrontとPeacockによるライブビデオストリーミングについてです。私はTal Shalomと申します。Amazon CloudFrontのPrincipal Product Managerを務めています。本日のステージには、NBCUniversalのSenior Vice President, Solutions ArchitectureであるSimon Riceさんをお迎えしています。Simonさんはセッションの後半で自己紹介をし、彼とそのチームがどのようにしてPeacockプラットフォームを大規模なライブストリーミング配信向けに設計したかを共有してくださいます。このセッションでは盛りだくさんの内容をご用意しています。
まず、大規模なライブイベントの配信における課題と、視聴者の高品質な体験を実現するための影響要因に焦点を当てます。その後、Simonさんが Peacockプラットフォームのアーキテクチャを共有し、収益化や配信の最適化などの革新的な領域についてお話しします。最後に、私からAmazon CloudFrontを使用した大規模ライブイベント配信のベストプラクティスをお伝えします。それでは始めましょう。
ライブストリーミングの視聴者体験と技術の進化
スポーツファンが試合を観戦していて、司会者が「ここアリーナから生中継でお送りしています」と言うのを聞き、プレーヤーやアプリケーションにライブビデオアイコンが表示されると、彼らはスタジアムやアリーナに実際にいるのと可能な限り近い体験を期待します。つまり、ライブからの遅延が最小限で、可能な限り高品質で、イベント中に中断がないことを意味します。これはオリンピックやSuper Bowlなど、あらゆるタイプのライブストリーミングイベントに当てはまります。
長年にわたり、これらのイベントは地上波放送や衛星、ケーブルテレビプロバイダーを通じてテレビセットに配信されてきました。過去10年間で、コンテンツプロバイダーはこれらのライブイベントをインターネット経由で複数のデバイスにオンライン配信し始めました。これはOver The Top（OTT）配信と呼ばれています。初期の頃は遅延に差があり、ネタバレ効果が生じていました。試合を観戦していて、突然隣人が歓声を上げるのを聞いたのに、自分の画面ではそのタッチダウンが30秒後に表示されるといったことがありました。これは視聴者の体験の質を低下させていました。
現在では、技術が進歩し、遅延は大幅に短縮されています。ライブから数秒遅れ、時には放送よりも速いこともあります。放送とOTTの両方において、イベントは会場でビデオが撮影されることから始まりますが、処理と制作は転送方法と配信方法によって異なります。主な違いは視聴者体験の結果にあります。放送では、同じ体験を提供する単一のストリームが何百万人もの視聴者に向けて放送されます。対照的に、OTTでは個々の視聴者に向けた各ストリームがパーソナライズされた体験を提供します。
この柔軟性により、外出先やゲーム機など、好みのデバイスでコンテンツを視聴できます。しかし、この柔軟性は同時に、すべてのストリームを管理し、視聴者に可能な限り高品質なコンテンツを提供する上で課題をもたらします。ここで、視聴体験の品質に影響を与える要因について理解を深めましょう。
視聴体験の品質に影響を与える要因とAmazon CloudFrontの特徴
視聴者は、ライブ配信に近い最小の遅延、最高の映像品質、最高の音声品質を期待しています。HD、UHD、4K、8Kなど、デバイスやネットワークが対応可能な最高品質を、イベント全体を通じて中断なく視聴したいと考えています。当社の顧客は、クライアント側のさまざまなテレメトリーを用いてこの視聴体験の品質を測定しています。彼らは、視聴者が再生ボタンをクリックしても動画が始まらない「ビデオ開始失敗」を監視しています。また、イベント中の中断や動画停止（Video Play Failure、VPFと呼ばれます）もモニタリングしています。さらに、ネットワークの不具合によるジッターや損失から生じる画像の歪みも追跡しています。これは画質の低下を引き起こし、大画面でぼやけて見える原因となります。音声と映像の同期ずれの問題も監視対象です。これらの要因はすべて視聴者の体験品質を低下させ、チャンネルを変えたり別の番組に移ったりする原因となる可能性があります。
これらの問題の原因の一部は、ストリームの設定方法に関連しています。例えば、提供したい解像度あたりのビットレートが、視聴者のデバイスやネットワークが処理できるスループットと一致している必要があります。一致していない場合、解像度が下がるかネットワークでエラーが発生します。これらのエラーにより、クライアント側のバッファが不足し、ビデオセグメントの損失や動画ストリーミングの中断につながる可能性があります。多くの顧客は、クライアント側での制御は常に可能というわけではないが、ネットワーク側ではより多くの制御が可能だと言っています。
Content Delivery Network（CDN）の選択は、視聴者に提供する体験の品質に大きな違いをもたらす可能性があります。AWSのネットワークは、リージョン間を結ぶ完全に冗長化された400Gbpsの並列ネットワークと専用回線で構築されています。Amazon CloudFront Global Edge Networkは、世界中に600以上のPoints of Presence（PoP）を持ち、そのバックボーンに接続されています。このネットワークは、500以上の組み込みPoPを通じてインターネットサービスプロバイダーにまで拡張されています。これらの組み込みPoPは、インターネットサービスプロバイダー内に配置されたキャッシュ層で、より低いレイテンシーと視聴者に近い場所からのサービス提供を可能にします。SimonとI will discuss more about the benefits of this in the next slide。私たちは、顧客がクライアントからより多くの需要を見込む新しい場所にネットワークを常に拡張しています。
AWSのメディアサービスとCloudFrontの活用
このネットワークの上に、顧客がメディア向けの様々なワークフローを構築するために使用する包括的なサービスと機能のセットを用意しています。例えば、複数の試合が同時に重なるスポーツリーグのシーズンでは、キャパシティ管理が必要です。一方、eスポーツのような他のイベントでは、3〜5分の短い時間で数百万人の視聴者が一斉に押し寄せる可能性のある、特性の異なるライブイベントとなります。当社の顧客は、AWS Elemental Mediaを使用しています。これには、会場からのライブフィードをAWSクラウドに送信するためのMedia LiveやEncoderが含まれます。その後、さらなる処理と配信のためにElemental Media LiveとElemental MediaPackageを使用しています。
これから、これらのセグメントをAmazon CloudFrontにどのように接続するかについてお話しします。CloudFrontは、低レイテンシーで何百万人ものビューアーにセグメントを配信するために使用されています。一部の顧客は、配信をカスタマイズしたり、クライアントの機能をエッジに移行したりするためにedge computeを利用しています。例えば、場所に応じて異なるコンテンツを設定したい場合、クエリ文字列を使用してリクエストを異なる場所に振り分けることができます。
また、顧客はアクセス制御によってオリジンを保護するセキュリティ機能も使用しています。これにより、ビューアーや顧客がCloudFrontをバイパスしてオリジンに直接アクセスすることを防ぎます。さらに、AWS Web Application Firewallをフロントに使用して、攻撃対象をエッジまで押し出し、不正なユーザーから保護したり、そのレベルでボット対策を実装したり、エッジでallow listやblock listなどのアクセスリストのルールを追加したりしています。ここでのアイデアは、これらのサービスが同じバックボーン上で動作し、ミリ秒単位で通信し、CloudFrontを通じた配信が包括的なエンドツーエンドのソリューションとして見なされることです。
その上に、観測可能性ツールがあります。会場のエンコーダーから配信まで、エンドツーエンドで見ることができます。後ほど、クライアント側のメトリクスとCDNのメトリクスを組み合わせて完全なエンドツーエンドのビューを得る方法や、クライアント側で起こっていることとCDN側で起こっていることの相関関係を可能にする方法についてお話しします。では、Simonに引き継ぎ、Peacockがこれらのサービスを使用してライブイベントを成功裏に配信する方法について共有してもらいます。
Peacockのグローバルストリーミングプラットフォームの紹介
ありがとう、Tal。今日ここにPeacockの加入者の方はいらっしゃいますか？かなりの数の方がいらっしゃいますね、ありがとうございます。外にもたくさんの方がいらっしゃいますが、本当にありがとうございます。さて、Peacockにスポーツだけのために加入された方はいらっしゃいますか？それがきっかけだった方は多いですか？はい、よくある話ですね。今日は、Peacockで現在ライブスポーツをどのように配信しているかについてお話ししたいと思います。まず自己紹介させていただきますと、私はSimon Riceで、Peacockのソリューションアーキテクチャ部門を統括しています。私のチームは、フロントエンドアプリケーション、それらのアプリケーションをサポートするバックエンドサービス、設計から配信、そしてサービスの運用まで、ソリューション設計全般を担当しています。私たちは自分たちのことをglobal streaming technology teamと呼んでいます。
なぜ私たちは単にPeacockではなく、global streaming technology teamと呼んでいるのでしょうか。それは、私たちが世界中にいくつかのビジネスを展開しているからです。もちろん、米国国内ではPeacockを提供していますし、VUDUやFandango movie ticketsなど他のNBCのプロパティも運営しています。ヨーロッパでは、Viacom CBSと共同で22カ国にわたってSky Showtimeというサービスを展開しています。そして現在、Multi-Choiceとの合弁事業で、44のアフリカ諸国にShowmaxという新しいサービスを立ち上げているところです。これらのビジネスに対する私たちの計画は、容易に国際展開できるようにすること、そして新しい、より大きな、多様な視聴者に、いつでもどこでもどのデバイスでもプレミアムコンテンツを楽しんでいただくことです。
私たちの使命は、すべてのブランドとグローバルビジネスにおいて、まず第一に、お客様が好きなコンテンツを簡単に見つけられるようにすることです。そして、ブランドやチーム、魅力的なコンテンツとより深く、本物の形で関わることができるファンダムを提供し、常に新鮮なコンテンツを提供することで、プラットフォーム上で常に新しく興味深いものを見つけられるようにします。また、美しいインターフェースと直感的なデザイン、使いやすい操作方法で楽しい体験を提供し、本当に喜びの瞬間を生み出すことを目指しています。
では、どのようにしてそれを実現するのでしょうか？私たちが提供しているのは、「global streaming platform」と呼んでいるものです。ここでは、このプラットフォームの層を少しずつ紐解いていきましょう。
私たちは多くのサービスを提供しています。再生準備が整った動画アセットを準備、暗号化、管理、スケジューリングするサービスがあります。また、認証、認可、コマースサービスにより、お客様はさまざまなサブスクリプションオプションから選択し、適切なコンテンツにアクセスできます。コンテンツ検索とパーソナライゼーション機能により、ユーザーはコンテンツを検索でき、私たちはユーザーが楽しめそうなコンテンツをおすすめできます。広告技術サービスは、環境内で広告機会や購入可能な瞬間を提供します。
これらすべては、データと分析機能、そしてクラウドインフラストラクチャーに支えられています。このインフラは自動的にスケールアップとダウンを行うだけでなく、大規模イベントを見越して手動でスケールすることも可能です。ライブスポーツイベント中にこのプラットフォームを見ると、プラットフォームの各部分がイベントの特定の時間に異なる種類の負荷を経験することがわかります。そこで私たちは、「customer journeys」と呼ぶものを分単位で分析します。これにより、放送数字や過去のイベント、将来の予測に基づいて、イベント中にどれだけのサインイン、サインアップ、動画開始リクエストがあるか、そしてユーザーがイベント後にどのように他のタイプのコンテンツに移行するかを予測できます。これにより、様々なタイプのライブスポーツイベントがプラットフォームにどのような影響を与えるかを把握できるのです。
Peacockのライブスポーツ配信における技術的課題と目標
これは私たちにとって初めての経験ではありませんし、Super BowlやOlympicsも初めてではありません。すでに多くの大規模イベントを開催してきました。昨年は、Winter OlympicsとSuper Bowlを同じ週末に開催しました。また、men's and women's FIFA World Cupsも開催しました。しかし、私たちは大規模なスポーツイベントだけに注力しているわけではありません。毎日、プレミアムなライブコンテンツを提供しています。最近では、約50のライブイベントを1週末で開催しました。その間、最大7つの同時ライブストリームを提供しました。ライブストリーミングは私たちのDNAであり、私たちの仕事の本質なのです。
技術的な観点から見ると、複数のグローバルビジネスにわたって成長する中で、パフォーマンス、セキュリティ、信頼性を大規模に提供するプラットフォームを用意する必要があります。特にライブスポーツに関しては、いくつかの重要な点があります。まず、アプリケーションの観点から、パフォーマンスが良く、アプリケーションの読み込み時間が市場最高レベルであることを確認したいと考えています。次に、プラットフォームの信頼性を確保し、ビデオ再生の失敗をほぼゼロにまで減らすことを目指しています。
そして、可能な限り低いレイテンシーを実現するバランス調整を行っています。Talが言ったように、友達がWhatsAppでゴールを祝福するテキストを送ってきてから30秒後に画面で見るようなことは避けたいですからね。そのため、できる限り低いレイテンシーを目指していますが、同時に最高の品質も追求しています。4K ultra high definitionでゲームをホストし、HDRカラースペースを使用し、60フレーム/秒で実行しています。放送と同等かそれ以上の没入感のあるスポーツ体験を提供したいと考えています。
また、バッファリングを最小限に抑え、存在しないか気づかないレベルにすることも目指しています。最後に、クライアントデバイスからできるだけ多くのテレメトリーデータを収集し、問題が発生した場合でも、お客様がデバイスを再起動する必要もなくリアルタイムで対処できるようにしたいと考えています。従来の放送とライブOTTストリーミングの違いを見ると、共通点もあれば、OTT特有の課題もあります。
OTTストリーミングの課題とCDN選択の重要性
共通点としては、依然としてビデオのエンコード、パッケージング、配信パイプラインを通じたプッシュが必要です。放送側では、光ファイバーケーブルを通じてお客様の家庭に届き、テレビに表示されます。OTTの世界では、その戦略を模倣するために、お客様により近いCDNを経由し、インターネットサービスプロバイダーを通じて、その時々で使用しているデバイスに届けます。お客様はCDN間を移動したり、ISP間を移動したり、電車の中でサッカーの試合を見ていたりするかもしれません。そういった状況にも対応する必要があります。
もちろん、これらのCDNやISPがPeacockだけに使用されるという保証はありません。NetflixやYouTubeを見たり、自宅からZoom通話をしたりするでしょう。そのため、CDNやISPで競合が発生し、予測不可能な状況が生まれます。これに対して計画を立てる必要があります。しかし、これは数千万人の同時視聴者がいる可能性があることを意味します。
そして、その計算をすると、毎秒数百テラビットのスループットが必要になります。そのため、私たちは非常にユニークな状況に置かれています。フェイルオーバーや信頼性のためだけでなく、純粋にスループットのためにもマルチCDNを検討する必要があるのです。これらのパイプを通じて膨大なデータが流れているのです。
では、CDNプロバイダーをどのように選び、どのプロバイダーをどこで使用するかをどのように決定するのでしょうか？CDNプロバイダーを選ぶ際には、いくつかの点を考慮します。まず最も明白なのは、容量の証明です。私たちが必要とする容量を持っていることを証明し、その容量を予約でき、さらにその容量内に余裕があることを保証できる必要があります。これが恐らく最優先事項です。次に、各CDNプロバイダーの地理的な範囲を見ます。すべてのCDNプロバイダーが同じというわけではなく、カバー範囲も同じではありません。
通信業界をご存じの方なら、私たちがASNレベル、ほぼ郵便番号レベルまで掘り下げて、各地域のカバー範囲を確認し、どのCDNがどのISPに、そしてどのASNにマッピングされるかを非常に詳細に把握し、私たちのポートフォリオ内で異なるCDNをどこで使用するかという地理的な全体像を作成していることがお分かりいただけるでしょう。次に重要なのは、APIの統合のしやすさです。特にCDNがEdge computeやOrigin Shieldsのような機能を提供し、私たちを保護できる場合はなおさらです。そして最後に、しかし決して軽視できないのが、商業的・財務的な考慮事項です。当然、コストの考慮があり、それが各CDNにどれだけのトラフィックを送るかを決定する要因となる場合があります。
Peacockのビデオテレメトリとマルチリージョン構成
これらすべてを通じて、トラフィックの分散、どの場所でどのCDNを使用するか、問題や輻輳が発生した場合にどのCDNにフェイルオーバーするかなどをカバーする計画を立て、それが私たちのビジネスケースを構築します。そして最終的に、クライアントデバイスから大量のビデオテレメトリを収集できるCDN決定ソリューションにたどり着きます。ビデオの開始/停止イベントを見たり、ストリームのビットレートを上げ下げしているかを確認したり、広告挿入イベントやバッファリングの発生などを確認したりします。
これらすべてを後ほど説明するバックエンドシステムに取り込みます。そして、CDNからの信頼性統計と組み合わせます。CDNの信頼性に関する過去のデータも持っており、これらすべてを使って、再生時にクライアントに渡すマニフェストファイルを作成します。これらのマニフェストファイルは、その時点でのクライアントの位置に基づいて、ライブストリーミングに最適な安定性、スループット、信頼性を提供する優先CDNをクライアントに伝えます。
このCDN決定ソリューションシステムが私たちにとってミッションクリティカルであることは明らかです。 そして、ミッションクリティカルなものは全て、99.999%の可用性を意味します。これは私たちのシナリオでは、実質的にアクティブ-アクティブのマルチリージョン構成を意味します。そのため、少なくとも2つのAWSリージョンにまたがって運用しています。アクティブ-アクティブ構成なので、クライアント（ここでは再生デバイスを指します）がテレメトリーデータをロードする際、特定のクラウドリージョンにデータを送信し、万が一プライマリのクラウドリージョンに障害が発生した場合でも、簡単に第二のリージョンにフェイルオーバーできます。ただし、国内のどこにいるかによって、特定のクラウドリージョンにデータを送信することになります。
その後、高性能のKafkaキューを使ってテレメトリーデータを取り込み、ミッションクリティカルなテレメトリーは米国東部と西部のAWSリージョン間でリアルタイムにレプリケーションされます。次に、そのテレメトリーデータをDatabricks ETLに通します。これも高性能でイベント駆動型のETLです。そしてそのデータはApache Druidデータベースにロードされます。Apache Druidを使用している理由は、非常に高性能で、インメモリであり、ミリ秒単位でCDN決定を行うことができるからです。
例えば、特定の場所にいる顧客グループがバッファリングの問題や動画の再生失敗を経験している場合、ミリ秒単位でそれを把握できます。Druidデータベースにクエリを実行して問題の原因を特定し、自動的に別のCDNに切り替えることができます。通常、顧客がストリームを再起動する必要もありません。これにより、顧客に最高のパフォーマンスを提供するために、CDN間の切り替えを非常に迅速に行うことができます。
バックエンドでは、すべてのテレメトリーデータをデータウェアハウスで要約し、技術陣とビジネスリーダーシップの両方が、将来のイベントに関する十分な情報に基づいた決定を下せるようにしています。これにより、イベントを継続的に実行しながら、確実にカバーし、反復的に改善できるようにしています。もちろん、これらはすべてテストなしでは不可能です。テストは私たちにとって非常に重要で、意図的に取り組んでいます。
Peacockの広告技術とAd Transcode Pipeline
テストに関しては、計画的なアプローチを取っています。まず、特定のコンポーネントやマイクロサービスを大規模に実行することから始めます。次に、それらのマイクロサービス間の統合ポイントを検証し、最後に、エンドツーエンドのパイプライン全体を顧客のジャーニーとともにピーク時の大規模な規模で実行し、期待通りに動作することを確認します。また、非常に厳格なカオスエンジニアリングの哲学も持っており、大規模な障害シナリオもテストしています。さらに、AWSとパートナーシップを組み、Infrastructure Event Managementサービスを活用して、AWSのあらゆる側面でインフラストラクチャとサービスが必要な時に確実に利用できるようにしています。加えて、Talが後ほど説明するMedia Event Managementサービスを利用して、ビデオ特有のサービスを検証し、必要な規模で利用可能であることを確認しています。
実際のスポーツストリーミングに加えて、私たちはそれらのストリーム内でパーソナライズされた革新的な方法で収益化の機会と広告を提供したいと考えています。過去数年間に導入したいくつかのイノベーションを見てみましょう。まず、Pod Bounceを導入しました。これは、スポーツイベント内で特定の関連ブランドに対して高いインパクトを持つブランドレベルの認知度を可能にします。また、Highlight Adsも開発しました。これは、コンテンツ内の重要な瞬間にスポンサーシップを生き生きと表現する、中断のない魅力的なフォーマットを作り出します。例えば、Real Housewivesのファンで、どうしても欲しいGucciのハンドバッグを見かけたとします。私たちは、そのTV番組の周りにハイライトを作成し、番組内で見たアイテムを購入したり、詳細を知ることができるコマース体験を可能にします。ストリーム内でショッピング可能な瞬間を探索しているのです。
最後に、In-Scene Adsのような革新的な機能も開発しました。これにより、実際にCoke缶をPepsi缶に入れ替えたり、ショットの背景にあるビルボードを見つけて、そのビルボードに表示されているものを置き換えて、エピソードコンテンツ内に製品プレイスメントを作成することができます。これらは本当に革新的な新しい広告やコマース機能ですが、技術的にどのようにしてスケールでこれらを提供するのでしょうか？
これらすべては、Ad Transcode Pipeline（ATP）と呼ばれる単一の柔軟なアーキテクチャによって実現されています。まず、広告マーケットプレイスとして機能するComcast社のFreeWheelから広告のメザニンファイルを取得します。次に、サーバーレスパイプラインを使用してAWS Elemental MediaConvertをトリガーし、特定のビデオパラメータで広告セグメントをエンコードします。これらの広告セグメントはS3バケットに保存され、CDNにキャッシュされます。そして、高性能データベースでそれらの広告セグメントのインデックスを作成し、記録を保持します。
私たちのカスタム開発プレーヤーを実行しているクライアントアプリケーションがビデオストリームを開始すると、Video Ads Module（VAM）と呼ばれるものに呼び出しを行います。VAMは、顧客が広告を見るべきかどうか、そしてもし見るべきなら、どのようなパーソナライゼーションプロファイルを持ち、どのタイプの広告を提供すべきかを判断します。広告を全く表示しないティアもありますが、広告を表示すべき顧客に対しては、どのタイプの広告を提供するか、広告の位置、そしてそれらの広告を提供するためのマニフェストファイルを持っています。
プレーヤーがSCTE-35マーカーとして知られる広告マーカーにヒットすると、AWS Elemental MediaTailorをトリガーし、サーバーサイドでそれらの広告セグメントを挿入します。CDNからそれらを取得し、CDNにない場合はS3オリジンから取得します。その後、MediaTailorがビデオストリームに広告を挿入します。このフレームワークは、ライブストリーミングとビデオオンデマンドの両方に適用され、シーン内の製品プレイスメント、ビデオをフレーミングするハイライト広告、または広告ブレーク内の従来の広告のいずれにも対応します。
ライブスポーツストリーミングの経験と今後の展望
以前、確かAndy Jassyが「経験には圧縮アルゴリズムがない」という言葉を生み出したと記憶していますが、私たちもライブスポーツについて同じように考えています。私たちは長年にわたってライブスポーツを配信してきました。世界で最初にライブスポーツを提供したストリーミングサービスの一つです。これまでに業界で前例のない規模でイベントを配信してきました。その過程で学んだのは、これらのイベントを計画し配信するには、本当に戦略的なパートナーが必要だということです。AWSのようなパートナーをプロセスの早い段階で巻き込むことが極めて重要です。インフラを整え、スケールできることを確認し、アーキテクチャをテストし検証することが非常に大切です。
最も重要なのは、優れたチームなしには素晴らしいイベントは実現しないということです。信頼できる人々、やり方を知っている人々、何度も経験を積んだ人々、そして社内外で一貫して成果を出せる人々が本当に必要です。私たちはライブイベントストリーミングで築いてきた強みを誇りに思っており、新しいイベントをお届けできることを楽しみにしています。
2024年のParis Summer Olympicsが控えています。また、NFLのWild Cardゲームの独占配信権も獲得しました。これは史上初めて、ストリーミングサービスでしか視聴できないものです。私たちは、これがライブスポーツストリーミングのほんの始まりに過ぎないと感じており、今後どこまで発展させられるか非常に楽しみです。ここで、CloudFrontを使ってどのように具体的に配信できるかについて、Talに話を戻したいと思います。
Amazon CloudFrontのキャッシング戦略と組み込みPOP
Simon、ありがとう。Peacockのチームがこれまでに顧客の需要に応えるために構築してきたものを見るのは素晴らしいですね。次に何が来るのか楽しみです。では、高品質な視聴体験を実現するためのチューニングについて、もう少し深く掘り下げてみましょう。キャッシングとその設定、キャッシングがレイテンシーとスケールにどのように影響するかについて話し合います。また、オリジンからのコンテンツの耐障害性のある配信や、大きなスパイクからオリジンを保護する方法についても議論します。さらに、低レイテンシーのためのチューニング方法についても触れます。これはセグメントの長さと、セグメントの長さと達成しようとする視聴体験の質のバランスに関係しています。
エンドツーエンドのメトリクスと、クライアントサイドとビューワーサイドの相関関係について説明します。特定の地域やインターネットサービスプロバイダー、ASN（自律システム番号）に焦点を当て、その特定の地域でのビューワーの体験を確認する方法を見ていきます。最後に、エンドツーエンドのライフサイクルイベントの提供と推進をサポートする、当社のメディアイベント管理チームについてお話しします。
OTTで配信されるライブイベントの増加により、ピーク時と平均時の容量需要の差が拡大しています。これにより、インターネットサービスプロバイダー間のピアリングポイントや、CloudFrontなどのCDNとの接続に負荷がかかります。CloudFrontでは、マルチティアのキャッシング方式を採用しており、インターネットサービスプロバイダーに追加したティアの1つが組み込みPOPです。このキャッシングティアはサービスプロバイダーのネットワーク内でビューワーにより近い場所に配置され、インターネットサービスプロバイダーとCloudFront間のトランジット接続やピアリングにかかる負荷を軽減することができます。
これらのインターネットサービスプロバイダーは、ライブイベントの際にピアリングリンクをスケールアップする必要がなく、平均的な配信のためのアップグレードコストをかけずにピーク時の需要に対応できます。500以上の組み込みPOPを持つCloudFrontは、複数の地域で配信が可能であり、プラットフォームにSDKを統合している場合は、DNSリクエストに基づいて、ネットワーク内の特定の組み込みPOPにトラフィックをルーティングすることができます。お客様からは、これらの組み込みPOPを経由するストリームで、ファーストバイトレイテンシーとラストバイトレイテンシーの改善が見られるとの声をいただいています。Simon、Peacockが当社の組み込みPOPをどのように活用しているか、共有していただけますか？
組み込みPOPを活用する方法は複数あります。おそらく、ラストマイルの課題、ラストマイルの輻輳、ラストマイルのレイテンシーについて聞いたことがあるでしょう。これは通常、CDNとISPのネットワーク内の顧客宅の近くの間で発生します。これは実際の問題であり、特に米国内だけでなくアフリカでもストリーミングサービスを構築している我々にとっては重要です。東欧諸国では、インフラの信頼性が低い場合があり、CDNと顧客の間の輻輳が大きな課題となり、顧客体験に大きな影響を与える可能性があります。
先ほど述べたように、プレイヤーは常にビデオのテレメトリに関するイベントを生成しています。ほとんどの場合、4秒間のセグメントで作業しているため、4秒ごとにビデオプレイヤーはバックエンドに現在のビットレート、バッファリング、スループットなどの情報を送信し、すべてのテレメトリデータをフィードバックしています。同時に、CloudFront embedded POPsを使用しているため、顧客を従来のPOPからembedded POPに移動させることで利点があるかどうかを評価しています。そうすることで利点があると判断した場合、より一貫性のある顧客体験と低遅延を提供できます。
単純にHTTP 302リダイレクトを提供し、クライアントを従来のCloudFront POPからembedded POPに送信します。通常、プレイヤーを再起動する必要もなく、バッファリングイベントも発生せずにシームレスにembedded POPに移行します。素晴らしいのは、収集されるテレメトリを見ると、embedded POPには異なるタグ付けメカニズムがあることです。ログ内で異なって表示されるため、どの顧客とどのトランザクションが従来のPOPからembedded POPに移動されたか、embedded POPへの移行によってどの程度の利点があったか、そしてどの場所でそれが行われたかを明確に確認できます。
これにより、このような戦略から大きな利点が得られている場所や、将来さらなる支援が必要な場所についてAWSにフィードバックを提供し、計画を立てることができます。これは私たちに大きな柔軟性と優れた顧客体験を提供し、そのフレームワーク内での可視性と観測可能性は私たちにとって非常に重要です。
ありがとう、Simon。私たちは、あなたの視聴者のために新しい地域への拡大を続けることを楽しみにしています。Simonが言及したように、embedded POPsを利用する方法は3つあります。1つ目は、何もする必要がありません。私たちがトラフィックの一部をembedded POPsを通してルーティングします。2つ目は、SDKオプションを含むDNSベースのリダイレクトを使用することです。3つ目は、プラットフォームでSDKを使用して適切なURLを送信することです。これらのコントロールを提供しますが、そのまま使用したい場合でも機能します。
CloudFrontの高可用性設定と低遅延ストリーミング
さて、先ほど言及した他の2つのキャッシュレイヤー、2つのキャッシュ層についてですが、これは600以上のポイントオブプレゼンス（edge locationsと呼んでいます）内にあります。また、リクエストがオリジンに到達する前に、その地域内の複数のポイントオブプレゼンスからのリクエストを集約するregional edge cachesもあります。これによりキャッシュレイヤーが改善されます。最終的には、キャッシングに関して対処すべき2つの領域があります。それは、数百万のリクエストに対してスケールを維持しつつ、ビデオが続く中でセグメントが生成され、ライブビデオが続き、マニフェストが更新される際に一貫性を維持する方法です。
まず、CloudFrontとクライアント間の接続とキャッシュ設定について話しましょう。キャッシングに関して、3つの要素があります。マニフェスト、セグメント、そしてエラーをキャッシュするネガティブキャッシングです。これらの要素それぞれに異なるキャッシュ設定を行うことをお勧めします。マニフェストはセグメントのインデックスを含むファイルで、ライブストリーミングでは一貫して頻繁に更新されます。セグメントは異なるキャッシュを持つことができます。基本的に、動画が終了すると、プレーヤーで巻き戻して番組やライブショーを遡って見るオプションがない限り、もう使用する必要はありません。アプリケーションのニーズに応じて、24時間以上保持することもあるでしょう。
しかし、このマニフェストについては、キャッシングのベースラインを考える必要があります。ベースラインはセグメントの長さになります。Simonが先ほど4秒と言及したので、4秒のセグメントを例にとりました。通常、クライアントはストリーミングを開始するために、バッファに2〜3個のセグメントを保存します。バッファが常に満たされているように、これらのセグメントを継続的にクライアントに流す必要があります。
マニフェストには新しいセグメントのすべてのインデックスが含まれていると言いましたが、次に何が来るかを知るためにはそのマニフェストを更新する必要があります。しかし、常にすべてのリクエストをオリジンに送り返したくはありません。スケールを維持しながら、すべてのポイントオブプレゼンスからサービスを提供するのに十分な時間があります。アイデアとしては、セグメントサイズの半分以下、かつ半分以上の頻度でリクエストを送信することです。これにより、Amazon CloudFrontのスケールを活用しつつ、セグメントの受信に問題が生じた場合の回復に十分な時間を確保できます。
ネガティブキャッシングには別の側面があります。例えば、特定の地域で問題が発生したとします。その特定の地域での問題により、リクエストが急増する可能性があります。ネガティブキャッシングを設定していないと、これによってオリジンに過負荷がかかる可能性があります。実際にストリームを受信している他の視聴者にさらに悪影響を及ぼす可能性もあります。そこで、ネガティブキャッシングを1秒程度に設定することをお勧めします。これにより、エラーを受け取っている視聴者は、キャッシュから同じエラーを一貫して受け取りますが、その1秒後にリクエストを行えば回復する十分な時間があります。これで、タイムラインの約3秒をカバーでき、4秒のセグメント1つ分以内に収まります。このようにキャッシュ設定を整理しました。
では、Amazon CloudFrontとオリジンの間について見ていきましょう。まず、エラーが発生した場合にフェイルオーバーできるよう、高可用性を確保することが重要です。推奨されるのは、少なくとももう1つのオリジンを用意し、通常は別のリージョンに配置することです。そして、CloudFrontでオリジンフェイルオーバーグループポリシーを設定し、プライマリとセカンダリの間でエラー時にフェイルオーバーするようにします。ただし、どのようにフェイルオーバーするのでしょうか？どのくらい待ってからフェイルオーバーするのでしょうか？CloudFrontでは、十分な時間を待つけれども長すぎないように、これらの設定を最適化することができます。
全体を見てみると、オリジンからセグメントやマニフェストを受け取るまで約2秒待つことが望ましいでしょう。これは最大で4秒、つまり1つのセグメントに相当します。接続の試行回数はどうでしょうか？同じオリジンに対して2回試行すると、各待機時間が2秒なので、合計4秒になります。これで1つのセグメントを超えてしまいます。したがって、1回の再試行の後、セカンダリオリジンにフェイルオーバーするのが良いでしょう。これにより、少なくとも4秒は維持できます。5秒や6秒になったとしても、バックアップまたはセカンダリオリジンに切り替えた際に回復するには十分な時間です。このような設定により、配信の信頼性を高め、エンドツーエンドのフェイルオーバー戦略を持ちつつ、視聴者からの高いリクエストレートを維持することができます。
高いリクエストレートと言っても、複数のリージョンからオリジンへリクエストが送信されています。そのために、Origin Shieldと呼ばれる別のキャッシュレイヤーがあります。Origin Shieldは、元のエッジキャッシュのためのオリジナルのエッジキャッシュと考えることができます。これは、キャッシュヒット率（つまり、オリジンに戻るリクエストに比べてキャッシュから応答するリクエストの割合）を向上させる、もう1つの集約されたキャッシュポイントです。
この集約により、特定のリージョナルエッジキャッシュをOrigin Shieldとして指定します。ベストプラクティスとしては、オリジンと同じリージョンに設定することをお勧めします。プライマリとセカンダリのオリジンがある場合、異なるリージョンに2つの異なるOrigin Shieldを設定できます。これらは、オリジンに割り当てられているため、オリジンと一緒に自動的にフェイルオーバーします。これにより、高可用性と視聴者に高品質な体験を提供する可能性を高めることができます。
マルチCDNを使用し、他のCDNからCloudFrontにリクエストを送信している場合は、Origin Shieldを設定して有効にすることをお勧めします。これは、他のCDNからより多くのリクエストが来るため、それらのサードパーティCDNからのスパイクからオリジンを保護し、維持する必要があるからです。
では、低遅延について話しましょう。 HLS（HTTP Live Streaming）やDASHなどのプロトコルは改良され、低遅延オプションが追加されました。この例では、エンコーダーとしてAWS Elemental Live、ビデオ処理にAWS Elemental MediaLive、セグメントのパッケージングにAWS Elemental MediaPackageを使用しています。昨年5月、Elemental MediaPackageで低遅延HTTPのサポートを発表しました。CloudFrontはElemental MediaPackageをオリジンとして前面に配置し、この低遅延コンテンツを配信します。
ストリームから取得したこのマニフェストを見ると分かるように、6秒のセグメントが1秒ごとのパートに分割されています。つまり、6秒のセグメントが1秒ずつの6つのパートになっているわけです。これにより、セグメントのより多くの部分が送信されるため、先ほど話したキャッシングの管理と、スムーズな配信を維持するためのCloudFrontとオリジンの関係を管理する必要があります。
1秒のパートがあるため、キャッシングを1秒に下げたいと考えます。これにより、プレーヤーが6秒のセグメント全体を待つ必要がなく、1秒のパートをより速く受け取れるため、再生をより速く開始できます。ただし、セグメントを分割するパートの数とのバランスを取る必要があり、これが遅延に影響する可能性があります。速くなる可能性はありますが、リクエスト率が高くなり、ネットワークに問題が発生した場合にエラーを引き起こす可能性があります。そのため、クライアントからオリジンまでのコンテンツの扱い方のバランスを常に取る必要があります。
エンドツーエンドの可観測性とMedia Event Management
先ほど述べたように、この仕組みには多くのコンポーネントがあり、さまざまなユースケースがあります。トラフィックの急増への対応、素早い初回読み込み、広告と主要ストリームの間の遷移などです。では、これらすべてをどのようにモニタリングすればよいのでしょうか？
エンドツーエンドの可観測性が必要です。セッションの前半で、視聴者の体験品質に影響を与える要因について触れました。ライブストリームでは、イベント中に発生する問題を検出し、緩和し、回復するための時間が短いのです。2020年9月、CTA WAVEグループはCommon Media Client Data（CMCD）と呼ばれる標準を発表しました。現在、PlexoやAndroid、video.JS、HLS.JSなどのオープンソースクライアントを含む多くのクライアントがこの標準をサポートしています。アプリケーションがこれらのフレームワーク上に構築されている場合、CMCDを有効にすることができます。
CMCDは、ビデオ開始時間、リバッファリング率、スループット能力など、多くのパラメータを含むテレメトリをクライアントから送信し、オブジェクトのリクエストごとにそれらを送ります。CDN側では、そのデータを収集してログにストリーミングします。これらのパラメータはクエリ文字列またはヘッダーを介して送信でき、CloudFront real-time logsを使用してログファイルにまとめることができるようになりました。リアルタイムログは数秒以内に提供され、CloudFrontからのエンドツーエンドの統計と、クライアントからの統計とともに、すべてのリクエストに対するテレメトリを提供します。
これにより、配信で何が起こっているか、CloudFrontがオリジンからセグメントを受け取るのにかかった時間、プレーヤーにかかった時間の相関関係を把握できます。これにより、問題が発生した場合、それがどこで起きたのかを特定できます。特定のAutonomous System Number (ASN)で発生したのか、ラストマイルで発生したのか、それとも特定のPoint of Presence (POP)で発生したのか？そのPOPからストリームを受信する複数のクライアントから問題が発生しているのが分かるでしょう。これにより、視聴者のパフォーマンスが明確に把握でき、そこから品質体験指標を構築できます。
CMCDのソリューションを作成しました。QRコードをスキャンしてダウンロードできます。これによりダッシュボードが構築されます。CloudFront distributionを選択すると、これらのCMCDパラメータのモニタリングが開始されます。これはそのソリューションのダッシュボード画面の一つですが、トラブルシューティング画面もあり、そこでは単一の視聴者の全番組または全イベントを通じたトレースと、その間に何が起こったかを確認できます。このソリューションはダウンロード可能です。
Simon氏が言及したように、クライアント、セットアップ、広告統合など、チームが処理する必要のあるモニタリングは多岐にわたります。何百万人もの視聴者を抱える大規模イベントを計画する際には多くのことをする必要があります。これに対処するため、Media Event Management (MEM)チームを導入しました。 このチームは最初から皆さんと協力し、キャパシティの計画、ストリームの送信先の決定、セキュリティ面への対応、リスク要因の評価を支援します。彼らは発見から当日のイベントまで、これらすべての側面で皆さんと協力し、その後の振り返りも行います。
MEMチームはメディア処理やCloudFrontの配信を含むメディア側に焦点を当てています。彼らはこれらのチームのエンジニアに直接アクセスでき、問題が発生した場合にすぐに連絡を取ることができます。彼らは常に警戒を怠らず、お客様と一緒にパフォーマンスを監視します。ブリッジに参加して定期的な更新を提供することもできます。計画段階では、様々な側面の状況を示す運用準備レポートを提供し、すべてが準備完了になるまで赤から緑へと進行状況を示します。すべてが緑になるまで、状態が緑と赤の間で交互に変化するのが見られ、最終的にすべてが緑になれば準備完了を意味します。
Media Event Management（MEM）チームが提供できるサービスをより詳しく見ていくと、イベント前、イベント中、イベント後の3つのフェーズがあります。イベント前のフェーズでは、ディスカバリーとワークフローのレビューを行い、お客様の特別なニーズに対応します。例えば、コンテンツステアリングのためにedge compute機能を必要とするお客様もいます。このチームは、edge computeが必要な1秒あたりのリクエスト数を処理できるようにスケーリングを支援します。また、テスト計画や段階的な拡大戦略の立案もサポートします。
MEMチームは、Simonが言及したように、Peacockと協力して様々なイベントの準備を行いました。イベント中は、お客様と一緒にブリッジに立ち、独自のライブコールをモニタリングして異常や問題の兆候を検出します。問題に対処するために迅速に各エンジニアリングチームに連絡を取り、トラフィックのステアリングを行って、ある地域から別の地域へのオフロードを支援し、視聴者の高品質な体験を維持します。イベント後のフェーズは特に重要で、連続したイベントやシーズン中の一連のイベントでは欠かせません。ある日に問題が発生した場合、翌日にはその問題が起こらないよう対策を講じ、問題を軽減してイベントの成功を確実にします。
まとめると、 大規模なライブイベントを成功させるためのチェックリストは次のとおりです。計画の重要性について議論しました：キャパシティの計画、視聴者が使用するデバイスの計画、キャッシングを最適化するための最適なセグメント長の計画を立てましょう。エッジでの高可用性とカスタム機能を確保します。HLS、DASH、低遅延など、使用するフォーマットに基づいて最適化します。セキュアな配信は極めて重要です。コンテンツプロバイダーはスポーツの権利に多額の費用を支払っているため、コンテンツを保護し、不正アクセスを防ぐ必要があります。問題の検出、緩和、回復のためにエンドツーエンドの可観測性を設定します。最後に、ビジネス面も考慮しましょう。サブスクリプションベースであれ広告支援型であれ、イベントに合わせて広告がタイムリーに配信され、ビジネス目標を達成できるようにします。
Simon、最後に何か付け加えることはありますか？
Simonは次のように答えました。「ライブイベントの運営は簡単ではありませんが、Talが言ったように、計画とテストが重要です。AWSは私たちのパートナーとして、計画の立案、テストの実施、さらにはこの分野でのイノベーションを支援する多くのサービスを提供しています。これらのサービスの多くは相互補完的です。私からの最大のアドバイスは、早い段階でAWSチームと連携することです。Africaを構築していた時、広告挿入に使用していたAWS Elemental MediaTailorは、Cape Townが新しいリージョンだったため、まだ利用できませんでした。しかし、AWSに十分な時間的余裕を与えることで、私たちのローンチに間に合うようにそのサービスを構築し、デプロイすることができました。早期の対話、早期の機能テスト、そしてAWS内の専門知識の活用が、前例のない規模で大規模なライブスポーツイベントを提供する上で非常に重要でした。AWSにはそのことに感謝したいと思います。皆さんもぜひPeacockでライブスポーツをご覧ください。」
Simon、本日はご発表いただき、ありがとうございました。また、皆様、最後までお付き合いいただき、ありがとうございます。アンケートの記入をお忘れなく。Simon と私はこの後、ステージ横 で質問をお受けいたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion