re:Invent 2024: Prime VideoがAWSで実現するNFLライブストリーミング
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Scaling Prime Video for peak NFL streaming on AWS (ARC311)
この動画では、Prime VideoがThursday Night Footballのライブストリーミング配信をAWS上でどのように実現しているかを解説しています。毎週1000万人以上の視聴者が集中する中、マルチリージョン戦略と自動スケーリングを組み合わせることで、高品質なストリーミング体験を実現しています。120以上のAWSサービスを活用し、Well-Architected Frameworkに基づいて設計されたアーキテクチャでは、Active-Activeのマルチリージョン構成を採用。Auto Scalingの最適化により、インフラコストを30%削減し、Gravitonの採用と合わせてカーボンフットプリントも43%削減しました。Prime Videoの成功事例を通じて、大規模ライブストリーミングにおけるReliabilityとCost Optimizationの両立方法が具体的に示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Prime VideoのThursday Night Football：課題と解決策
みなさん、ようこそ。本日は、Prime VideoがAWS上でストリーミングのピーク時にどのように対応しているのか、そしてその裏側でどのような魔法が起きているのかについてお話しします。まず、毎週木曜日にThursday Night Footballを視聴している方は何人いらっしゃいますか？手を挙げていただけますか？かなりの数の方がいらっしゃいますね。今回のセッションでは、まさにPrime VideoがAWS上でこれらの需要にどのように対応しているかについてお話しします。私はTulip Guptaと申します。AWSのSenior Solutions Architectで、過去3年間AWSに在籍し、主にPrime Videoをはじめとするメディアエンターテインメントアカウントを担当しています。本日は、ElliottとRalphも同席しており、後ほど自己紹介させていただきます。私たちは、課題と解決策、そしてそれらがAWS Well-Architected Frameworkとどのように結びついているかについてお話しします。
はじめに、Prime Video上のNFL Thursday Night Footballについてお話しし、その戦略についてElliottがマルチリージョンアプローチを説明し、Ralphがエラスティックスケーリングについて説明します。最後にWell-Architected Frameworkで締めくくります。皆さんの多くが視聴されているThursday Footballですが、バッファリングが発生して proper に視聴できないと本当にイライラしますよね。ライブストリーミングでは、コンテンツをリアルタイムで高品質に配信することが非常に重要です。Prime Videoは、特にTNFの試合中など、一日の特定の時間帯に需要がピークになることを想定しており、今回はそれに対するマルチリージョンとエラスティックな戦略についてお話しします。
次のスライドに移る前に、Prime VideoはAWSで何個のサービスを使用していると思いますか？手を挙げて教えていただけますか？ 実は120以上のサービスを使用しており、S3やEC2といった大規模なサービスから、SNSやSQSといった小規模なサービスまで活用しています。 木曜の試合に話を戻しますと、私たちは世界中の何百万人というSubscriberを魅了しながら、コスト効率よくスケールできることを目指しています。そしてその数は、Prime Videoが配信するシーズンごと、年々増加し続けています。課題は、これらの需要に応えるためにインフラをスケールアウトすることです - AWSでこれらの要件を満たすためにインフラをどのようにスケールできるのでしょうか？解決策は、マルチリージョンと自動スケーリングでした。
マルチリージョン戦略：Prime Videoの進化
解決戦略の説明に入る前に、Thursday Footballに関する簡単なFAQをご紹介します。2017年9月7日、これがNFLの試合がPrime Videoで初めて共同独占配信された日です。それ以来、私たちは大きく成長してきました。2022年には独占配信を行い、平均1,000万人の視聴者を記録し、2023年には1,700万人にまで増加しました。これはかなり大きな飛躍です。2024年のシーズン3の平均視聴者数は2023年比で18%増加しましたが、この数字については後ほどRalphがクイズを出すので、ここでは言いません。2024年には、Prime Video史上最大のNFLイベントも記録しました - GiantsとCowboysの試合は、NFLレギュラーシーズンで史上最も視聴されたストリーミング試合となりました。これはTNFにとってPrime史上最高の記録となりました。
では、マルチリージョン戦略についてElliottに話を譲りたいと思います。ありがとう、Tulip。皆さん、会場の様子を少し確認させてください。NFLファンの方は手を挙げてください。また、オンコールエンジニアの経験がある方も手を挙げてください。ほぼ同じくらいの人数ですね。この2つのグループが私の主要な顧客層です。 リビングでくつろぎ、フットボールが始まろうとしているところを想像してください。おそらくスナックを用意して、友達も来ていると思います。そこで再生ボタンを押したら、ぐるぐる回るスピナーが表示されたまま、何も始まらない状況になったとしたら。それはかなりがっかりする、むしろ致命的な体験になりますよね。また、その時にオンコールエンジニアだったとして、ページャーが鳴り出したら - ライブイベントが進行中で、プレッシャーの高い状況で、インシデント管理と顧客への影響の特定・軽減に責任を持たなければならない。私のチームは、このようなシナリオを回避するためのソリューションに取り組んでいます。私はElliott Nashと申します。Prime Videoのインフラストラクチャスケーリングを担当するチームを率いています。
私たちは、顧客需要の予測、ピークイベントに向けたコンピュート要件を決定するためのキャパシティプランニング、そしてスケールテストに取り組んでいます。各リージョンで毎週、顧客需要をシミュレートするピークイベントのGame Dayを実施しています。本日Tulipが言及したように、これからスタックの主要コンポーネントをマルチリージョンアーキテクチャに移行した私たちの取り組みについてご説明します。
Prime Videoは、お客様に包括的なエンターテインメント体験を提供するグローバルサービスです。SVODコンテンツと豊富な映画・TVシリーズを提供するサブスクリプションベースのサービスです。本日お話しする予定の幅広いライブスポーツコンテンツも提供しており、さらにお客様がコンテンツを購入・レンタルできるマーケットプレイスも展開しています。これらすべてがグローバルに提供されており、そのフットプリントは非常に大きなものです。そのため、効率性とパフォーマンスの最適化は、私たちのエンジニアリンググループの文化の核となっています。
2016-2017年にライブスポーツに参入した際、私たちは可用性の定義を変更する必要があると判断しました。それまでは、視聴需要パターンが非常に予測可能で大きな変動のないSVODサービスを提供していました。しかし、ライブスポーツに参入すると、試合開始時に短時間で多くの視聴者が同じようなコンテンツアクセスと再生開始のジャーニーをたどる「アポイントメント視聴」のユースケースに直面しました。これにより、急激なトラフィックスパイクが発生し、視聴者数の予測が困難になりました。
フレキシビリティの3層構造：Prime Videoのインフラ戦略
私たちはAWSと協力し、Prime Videoの可用性基準を引き上げたいという願いを説明しました。Prime Videoの最悪の日だけでなく、AWSの最悪の日でもサービスが機能する必要があることを強調しました。当時Compute Networkingの VPだったDave Brownとの議論で、3層のフレキシビリティについて概説しました。第1層はインスタンスタイプのフレキシビリティです。システムを多様な非同種のインスタンスタイプで実行できるように設計することで、利用可能なキャパシティプールを大幅に増やし、キャパシティ制約のリスクを軽減し、インスタンスタイプレベルでAWSの組み込みフォールトトレランスを活用できます。
第2層はAvailability Zoneのフレキシビリティです。リージョン内の複数のAZを活用することで、組み込みのフォールトトレランスと分離を実現します。1つのAZに問題が発生した場合、シームレスにAZ間でフェイルオーバーできます。この戦略は「卵を一つのかごに入れない」という原則に従い、リスクを効果的に分散させます。最後の層は、本日重点的に説明するマルチリージョンのフレキシビリティです。これは私たちのフレキシビリティ戦略の真髄です。アーキテクチャを複数のAWSリージョンに展開することで、リージョンの障害に対応でき、地理的位置に基づいて顧客リクエストを振り分けることでレイテンシーを最適化できる、堅牢なグローバル分散システムを構築しています。
これは私たちにとって数年にわたる journey でした。2017年に Thursday Night Football を co-exclusive イベントとして初めて開始した際、マルチリージョン対応のライブシグナル取り込みスタックをゼロから構築する機会がありました。2021年から2022年にかけて、マルチリージョン対応のライブプレイバックスタックを導入し、そして今年、プレイバックへの journey において重要となるマルチリージョン対応のストアフロント体験をローンチしました。
Prime Video では、ここにお見せしているコンポーネントの下に、大規模な分散テクノロジースタックを備えた高レベルのアーキテクチャを維持しています。
私たちのテクノロジースタックは、ここに示されているボックスの下に数百のサービスで構成されています。ストリーミングの性質上、これらのボックス内の大部分を AWS 上で運用しています。スタックの大部分を私たちが直接所有・運用していますが、エンドツーエンドでシームレスな体験を確実にするために、ISP、モバイルオペレーター、プロダクションハウス、デバイスメーカーなどのパートナーにも依存しています。
下部の四角形から始めると、これは私たちのライブシグナル配信スタックを表しています。 ここでは、プロダクションソースから制作されたコンテンツを取り込みます。TNF の場合、実際にはスタジアム外のトラックに設置されたプロダクションスタジオがソースとなります。そのプロデュースされたシグナルを取り込み、Elemental スタックに送り、エンコード、圧縮し、CDN を通じた配信用にパッケージングします。このスタックの部分は、マルチリージョン対応を前提に一から構築されました。
中央のボックスは、プレイバックスタックです。 これは、プレイバックの開始を支援し、コンテンツに対する顧客のエンタイトルメントをチェックし、ライブストリームを開始するためのビデオプレーヤーを起動するすべてのサービスを含むスタックです。最上層は、アプリケーションストアフロントと呼んでいる部分です。 このスタックの部分は、デバイスフロントエンドとストアフロントバックエンドをサポートしています。このスタック領域は、アプリの起動からホームページの読み込み、詳細ページの読み込みを経て再生ボタンに到達するまでの、コンテンツディスカバリー体験を提供します。
Prime Videoのライブストリーミング技術：制作から配信まで
Playbackとストアフロントのスタックは、どちらも当初はシングルリージョンのスタックでした。 各顧客は特定のリージョンに固定され、そのデータはリージョンごとに分割されており、その顧客のリクエストは指定されたリージョンからしか処理できませんでした。世界中の約240の国と地域をサポートしていました。
ストリーミングの利点の1つは、 高品質な映像と音声をご家庭まで届けられることです。TNFの試合は、カメラレンズから視聴者が見るHDRまで、エンドツーエンドで1080p HDRで制作されており、すべての試合はDolbyサラウンドサウンドで制作されています。
これが先ほどお話した中継車の1台です。 私たちは、このような8台の中継車で構成される移動式制作スタジオを持っています。制作ユニットは、ルーティングコアからカメラ、中継車自体、そしてスタジアム全体に張り巡らされた数千フィートのケーブルに至るまで、あらゆる面で完全な冗長性を備えています。
このような規模に対応するため、私たちは様々な制作ハブを運営し、それらを使用してすべてのフィードにわたる何千もの機器をリアルタイムでモニタリングしています。これにより、視聴者がどのデバイスで視聴していても、高品質を確保することができます。
これが私たちのシングルインジェストアーキテクチャです。 ここでは信号とフィードの健全性をモニタリングしており、必要に応じてAWSリージョン間で自動的にフェイルオーバーすることができます。これらは私たちのAWS Elementalリージョンで、必要に応じてこれらのリージョン間でフェイルオーバーが可能です。すべてのリージョンをアクティブ-アクティブモードで活用しているので、常にすべてのリージョンでトラフィックが流れています。信号処理とエンコーディングにはElemental Media Servicesを活用しています。これらのサービスは、ライブイベントに必要なリアルタイムのエンコーディング、トランスコーディング、パッケージング機能を提供します。
私たちは Elemental スタックを複数のオリジンリージョンにデプロイし、アクティブ-アクティブモードでシグナルを処理しています。このアプローチにより、異なる地理的位置にいる視聴者がライブストリームに低レイテンシーでアクセスできるようになります。そしてそのライブストリームを CDN を通じて配信します。ここでオレンジ色のボックスでハイライトされているのは、エッジレセプションおよびルーティングレイヤーと呼んでいるものです。 これは、マルチリージョンのユースケースすべてに一貫して展開している重要なコンポーネントです。これは基本的に、Elemental スタック間で行われるルーティングとフェイルオーバーの判断のための抽象化レイヤーを提供するエッジサービスです。エンコーディングパイプラインの外部にルーティングの複雑さを保持することで、特定のリージョン内のエンコーディングパイプラインをできるだけシンプルに、かつ分離された状態に保つことができます。
プレイバックスタックのマルチリージョン化：課題と成果
このマルチリージョンアーキテクチャにより、シグナルの取り込みと配信スタック全体の可用性が向上し、レイテンシーが低減され、カスタマーエクスペリエンスの改善に役立ちました。
次に、プレイバックスタックについて見ていきましょう。Thursday Night Football を視聴するために何百万人ものお客様が 同時にアクセスしてきて、再生ボタンをクリックします。ここで私たちが設定した要件のいくつかをご紹介します。 まず、アクティブ/アクティブモードで運用することを望みました。頻繁に使用されない、コールドやステールになる可能性のあるコアパスは望ましくありませんでした。冒頭で説明した可用性要件を考慮して、リージョナルフェイルオーバーをサポートする必要がありました。また、マルチリージョン戦略の要となるエッジルーティングレイヤーが必要だということも分かっていました。最後に、これを達成するためにはグローバル化が必要だと認識していました。先ほど述べたように、すべてのカスタマーコホートが異なるリージョナルスタックに分割されており、このグローバル化にはサービスのコードベースとデータレイヤーの両方の変更が必要でした。
これは、ルーティングレイヤーを通じてリージョン間で送信されるコールパスのクイックユースケースです。視聴者が再生ボタンをクリックすると、どのリージョンからでもサービスを提供できます。エッジルーティングレイヤーは、最適な利用可能なノードに接続されるよう支援します。 その間、データレプリケーションシステムが、お客様に提供される体験の一貫性を管理しています。 ここでのルーティングレイヤーは、基本的にリクエストルーターとして機能します。 設定を保存し、そのルーティングレイヤーのすべてのリージョナルインスタンスが VPC ピアリングメッシュを介して接続されています。ルーティングルールを実装しており、それらは顧客のソース国、送信先リージョン、トラフィックルートの割合などを指定します。リアルタイムでルーティングの判断を効果的に行います。必要なユースケースでは、顧客に一貫したルーティング保証を提供します。つまり、同じリージョン内で read-after-write ユースケースを処理したい場合に、顧客リクエストのリージョンルーティングの固定性を提供できます。これにより、CAP 定理の制約に対処することができます。
以上がプレイバックスタックでした。ここで実現した主な成果や利点は、レジリエンスの姿勢を強化できたことです。プレイバックのユースケースで複数のリージョンフェイルオーバーを処理できるようになりました。より低いレイテンシー、より高い可用性、そしてシームレスなフェイルオーバーを実現することができました。
スタックの最後の領域に移りましょう。これは今年立ち上げた領域です。私たちのアプリケーションストアフロントは、実施すべき作業という点でPlaybackと非常に似ています。 アプリのホームページ読み込みと詳細ページ読み込みのユースケースをグローバル化する必要がありました。 先ほどPlaybackについて説明したのと同じRoutingレイヤーを活用しました。サービスをグローバル化するために、コードベースを変更してサービスをリージョンに依存しないように改修し、異なるリージョン間で同じように動作することを確認する必要がありました。また、データレイヤーを見直し、お客様がどのリージョンから接続しても一貫した体験を得られるようにしました。これを実現するためにShadow Testingを有効にし、異なるリージョン間でAPIレスポンスの比較を行いました。また、リージョンのフェイルオーバーシナリオをシミュレートするために並行してスケールテストを実施し、段階的な展開計画を実装して、このモードに徐々に移行する際のトラフィックパターンを確認できるようにしました。
具体的な例として、Bookmarkingのユースケースを詳しく見てみましょう。これは読み取りと書き込みの両方のトラフィックを含む興味深いユースケースです。Bookmarkingとは、コンテンツを視聴している際に、ストリーム内の視聴位置を定期的に書き込むサービスです。一見シンプルに思えますが、このユースケースは、特にこの規模のマルチリージョン環境では非常に複雑です。一貫性を確保してレプリケーションを可能にするために、Amazon DynamoDB Global Tablesを使用しました。このユースケースでは、マルチマスターレプリケーションも有効にし、どのリージョンでも書き込みが可能で、最終的に一貫性のあるシステムを実現しました。さらに、データセットの移行も必要でした。Bookmarkingの場合、合計約80テラバイトのデータセットがあり、そのデータセットをグローバル化してGlobal Tableで利用できるようにするために、多くのバックグラウンド作業を行う必要がありました。
Prime VideoのThursday Night Footballをサポートするために、スタックの各領域で少しずつ異なるアプローチを採用し、主要な重要カスタマージャーニーすべてにおいてグローバルに分散したマルチリージョンアーキテクチャを実現しました。これにより、グローバルな信頼性と低レイテンシーのストリーミングをお客様に提供し、ビジネスに対して耐久性と柔軟性のあるアーキテクチャを提供することができました。 今年、このアーキテクチャをStorefrontで初めて使用し、お客様のリクエストの50%を処理しました。現在では毎週、毎週木曜日に50%のお客様がマルチリージョンを利用しており、需要の急激な増加にもかかわらず、何百万人ものお客様にスムーズなストリーミング体験を提供できるようになりました。
Elastic Scaling：Prime Videoの自動スケーリング戦略
この取り組みから得られた重要な教訓は、 まず、常時稼働のActive-Activeアーキテクチャを実現し、使用されていない重要な部分がないようにすることです。次に自動化です。プロジェクトを進める中で、特にRoutingレイヤーやその設定の調整など、重要な運用タスクを同時に自動化することが重要です。テストも非常に重要で、フェイルオーバーシナリオのテストに加えて、異なるリージョンのシナリオのスケールテストを確実に行う必要があります。なぜなら、フェイルオーバーが必要になった時点で、いわゆるThundering Herd（雷鳴の群れ）効果を引き起こす可能性があるためです。最後に、マルチリージョン戦略の反復と学習は、私たちにとって継続的な改善プロジェクトであり、まだ始まったばかりだと考えています。
それでは、Ralphに引き継ぎ、私たちのElastic Scalingの取り組みについて説明してもらいます。ありがとう、Elliott。皆さん、こんにちは。今日は私たちのElasticityへの取り組みについてご紹介できることを大変嬉しく思います。Elastic Scalingは、Prime Videoにとって非常に重要です。なぜなら、インフラストラクチャリソースを最適化し、世界中の何百万人ものお客様に高品質で途切れのないストリーミング体験を提供することを可能にするからです。私はRalph Chakerと申します。Prime Videoのプロダクトマネージャーとして、Elliottと同じ中央チームで働いており、組織全体の何百ものエンジニアリングチームが日々スケーリングと効率化のために使用する社内ツールとプロダクトのポートフォリオを管理しています。
本題に入る前に、スポーツファンの皆さんに簡単なクイズを出させていただきます。 Prime VideoでのCowboys対Giantsの Thursday Night Footballゲームのピーク視聴者数をご存知の方はいらっしゃいますか？ 正解はAです。1,800万人という数字は何を意味するのでしょうか？これは途方もない数字です。つまり、システムが確実に機能しなければならないということです。1,800万人のお客様が自宅でストリーミングを視聴しており、私たちは彼らを失望させるわけにはいきません。画面のグラフをご覧いただくと、その1,800万人がどこに位置するかおわかりいただけると思います。 グラフの左側は、Thursday Night Footballシーズン開始前の従来のビデオオンデマンドビジネスを表しています。右側では、それぞれのスパイクが毎週行われるThursday Night Footballの試合を表しています。
このグラフは、Thursday Night Footballのようなライブイベントがある日と、通常の定常的なトラフィックがある日との間のスケールの違いが如実に表れています。では、このような状況でのPrime Videoの役割とは何でしょうか？これは、Prime Video、AWS、そしてAmazonにとって非常に大きな責任を伴います。ブランドへの影響も大きく、可用性を保護するために非常に高い基準を維持しなければなりません。
そして、コスト面での責任も考慮しながら、これらのライブイベントに対して安全かつ効率的にスケールできるようにバランスを取ることが重要になります。 それによって、全国のスポーツファンの皆様に喜んでいただけるサービスを提供することができるのです。
それでは、NFLイベントのピーク時に対応する際に Prime Videoが直面した主要な課題についてお話ししましょう。まず、先ほど触れたように、全体的なスケール、社内では「peak-to-mean比」と呼んでいますが、そのグラフからわかるように、NFL Thursday Night Footballのストリーミングがある日とない日では、桁違いの差があります。これがPrime Videoの非常にユニークな特徴の一つです。日々、週ごとに見られる変動性です。このようなトラフィックパターンを理解することは、このようなイベントに対してどのようにスケールするかを理解する上で重要です。さらに、これらのピーク時は数分間しか続きませんが、コストに影響を与えます。
NFLシーズンの流れをご存知の方なら、9月から12月までのレギュラーシーズンがあり、1月にプレーオフが行われることをご存知でしょう。このような5～6ヶ月のシーズンに合わせてスケールアップする場合（グラフの赤線で示されています）、特にPrime Videoのような規模の組織では、大きなコスト影響が伴います。
2つ目の課題は、トラフィックパターンのスパイク性です。ライブスポーツの場合、非常に予測が難しいのです。画面のグラフは、Thursday Night Footballの試合における分単位のプロットを示しています。試合開始時が最も急激な上昇を示し、さらにハーフタイムで視聴者が離れ、試合再開時に戻ってくる様子が分かります。こちらは別の例で、ページロードやページインプレッションを示すメトリクスですが、最後の大きなスパイクは配信終了時で、何百万人ものお客様がThursday Night Footballの詳細ページに移動する時点を示しています。このようなスパイクに対するスケーリングとそのコストを考慮する必要があるのです。
これに対する自動スケーリングを考える際、このような急激なスパイクに対しては、シンプルなAuto ScalingやダイナミックなAuto Scalingポリシーだけでは十分ではありません。これは絶対に失敗が許されないイベントであり、イベントの前にキャパシティを確保し、スケールアップし、テストを完了しておく必要があるため、ダイナミックなAuto Scalingポリシーだけに頼ることはできません。
3つ目の課題は、調整の労力です。Elliottが講演で述べたように、Prime Videoは何百もの分散サービスチームで構成される巨大な組織です。各チームがAWSからシグナルを受け取り、キャパシティを確保し、そのキャパシティをプロビジョニングし、テストするというプロセスは、現在、毎週のThursday Night Footballの試合に向けて各チームが準備完了を宣言するために必要な、非常に手作業の多いステップとなっています。長いリードタイム、多大な労力、手作業のステップが必要なことから、Prime Videoは必要以上に長くキャパシティを保持することになっています（赤線で示されています）。
ここで、いくつかの改善の機会について話しましょう。同じグラフを見ると、白い部分がスケーリングの無駄として定義されている部分です。これは、需要やトラフィックを示す青線と、保持しているキャパシティを示す赤線との間の差と考えることができます。この2本の線の間のギャップが、私たちが最小化すべき機会です。その赤線を変換すると、多くの無駄を排除することができます。ピークスケールの日数を減らすことで、3時間のThursday Night Footballの試合に必要なキャパシティを、必要な時だけ保持して解放することができます。これにより、インフラストラクチャのコストと、毎週のスケールアップとダウンに関わるエンジニアリングの労力を削減できます。このエンジニアリングの労力を排除することで、エンジニアにとって真の意味でのハンズオフなスケーリングが実現できるのです。
Auto Scalingの自動化：設計と実装
このような機会を踏まえ、今年Prime Videoでは、この課題に取り組むためのプロダクトを構築することを目標としました。 シグナルを完全に自動化し、Auto Scalingを自動化するものを構築したいと考えたのです。
この目標を達成するために、私たちは自問自答しました：どのようにしてそのようなシステムを構築できるだろうか？これはElliottが画面で示したものと似たような図です。このプロダクトを構築する際に最も重視したのは、プロダクトに依存しない方法で構築することでした。つまり、Amazon EC2、Amazon ECS、Fargateのいずれで実行していても、そのまま動作するようにしたかったのです。なぜなら、そうすることで組織全体にレバレッジを提供し、真の力の乗数効果を発揮できるからです。
次に、今年構築したこのプロダクトのハイレベルなアーキテクチャについてご説明します。 主要なコンポーネントは3つあります：中央予測システム、シグナルを表面化するメインの中央ハブ、そしてこのソリューションを導入した各サービスチームに組み込まれているTransformationライブラリです。
まず予測システムについてですが、これはPrime Video全体を把握するナレッジだと考えてください。今後のイベント、日時、予測、そして私たちのキャパシティ戦略に必要な重要なインプットをすべて把握しています。 Prime Videoでの予測の仕組みを簡単にご説明しましょう。これは先ほどお見せしたものと似たチャートで、2023年から2024年のThursday Night Footballにかけて、ピーク同時視聴数でみたトラフィックが年々どのように成長したかを示しています。私たちは様々な機械学習技術を組み合わせ、Thursday Night Footballに関する具体的なビジネスナレッジ - 対戦チーム、選手、チームの順位や成績など - と組み合わせています。これらは予測の精度を高めるために必要な詳細なビジネス情報なのです。
なぜこれが重要なのかと思われるかもしれません。これはキャパシティプランニング全体に影響を与えるからです。ご存知の方もいるかもしれませんが、予測は非常に難しい分野です。正確な予測は不可能で、必ず誤差が生じます。問題は、その誤差をいかに最小限に抑えるかということです。予測が少なすぎると、十分なキャパシティがないため可用性にリスクが生じます。一方、予測が多すぎると、十分に活用されないキャパシティを過剰にプロビジョニングすることになります。また、信頼性という要素もあります。AWSのパートナー、社内のエンジニア、ビルダーコミュニティ、そしてISPやDNSなどの外部プロバイダーは、NFLやその他のスポーツなどPrime Videoの大規模イベントに向けてキャパシティを構築するため、これらの予測に依存しているのです。
私たちが構築したソリューションの2番目の主要コンポーネントは、セントラルハブ、つまりゲートウェイです。これは全体の頭脳のような役割を果たします。Forecasting Engineからこのコンポーネントに入ってくるすべてのリクエストをルーティングし、最終的にこのソリューションを導入した各チームに組み込まれているTransformation Libraryに提供する役割を担っています。
3番目のコンポーネントは、Transformation Libraryです。これは、このソリューションを導入したPrime Videoの各サービスチーム内に存在するコンポーネントです。CDK Constructsまたはテンプレートコードを通じて2つの機能を提供します。1つ目は、Auto Scalingに必要なスケールインとスケールアウトの操作をトリガーする役割を持つAWS Lambdaであるエージェントをデプロイすることです。2つ目は、各チームにAppConfigファイルを提供することです。このConfigファイルでは、サービスの所有者が1単位の需要を、Auto Scalingに必要な基盤リソースにどのように変換するかをカスタマイズできます。
Amazon EC2インスタンス、Fargetタスク、あるいはリードキャパシティユニットやライトキャパシティユニットを持つAmazon DynamoDBを使用している場合でも、リクエストやトランザクションの単位で需要を受け取ったとき、各チームは1単位の需要に対して必要なリソース量をより適切に判断できる柔軟性を持っています。 これがAppConfigの実際の例です。リソース自体はAuto Scaleしたいものを定義し、9行目と10行目に変換関数が存在します。この例では、Prime Video内部で使用しているTPSつまりトランザクション毎秒を使用しており、0.001という乗数は、1トランザクションあたりに必要なEC2インスタンスの数を示しています。この乗数は、シングルボックスホストでのパフォーマンステストから最適なスループットを計算して導き出されています。
このAuto Scalingの動作を示すために、 CloudWatchメトリクスダッシュボードのスナップショットをご覧ください。これは、インスタンスの希望数が4インスタンスから10インスタンスにスケールアウトする様子を示しています。これは、今年私たちが構築した製品の最初の成功例であり、エンドツーエンドで動作し、自動化されていることを実証しています。
ここまで、スケジュールされたAuto Scalingと、事前にキャパシティをシグナリングしてプリスケールする方法について説明してきました。Thursday Night Footballのような予測可能なスケジュール、つまり毎週木曜日の同じ時間に発生するイベントについては、スケジュールされたAuto Scalingを使用してキャパシティを事前にスケールします。しかし、私たちはダイナミックまたはリアクティブなAuto Scalingの使用も推奨しています。実際、これらを補完的なサービスとして併用することをお勧めしています。ダイナミックAuto Scalingの利点は、トラフィックにリアルタイムで即座に対応できることです。先ほどの予測の例に戻りますと、Taylor Swiftの予期せぬ登場や、Cowboysのような人気チームの試合で予測を超える状況が発生した場合、迅速に対応する必要があります。これこそが、ダイナミックAuto Scalingの出番です。予測できなかったキャパシティの不足を補うガードレールとして機能するのです。
次は、今年達成した成果指標とその影響についてお話ししましょう。今年取り組んだのは、あくまでもパイロットプログラムでした。Prime Videoの複数のサービスチームを選んで、この取り組みが実際に機能することを実証しようとしました。私たちは3つの重要なKPIを設定し、その改善を目指しました。まず、ピーク時のスケール日数を削減する必要がありました。3時間のゲームのために、週7日間もキャパシティを確保しておく必要はないのです。
このスナップショットでは、あるサービスのECS Taskカウントの推移を示しており、いくつかのステップ変化が見られます。 最初の変化は、Thursday Night Footballの試合に向けてサービスがスケールアウトし、試合終了後すぐにキャパシティがスケールインする様子を示しています。 そして翌週、シミュレーションによる負荷テストやGame Dayの前に再びスケールアウトし、その後スケールインしています。これにより、キャパシティの利用効率が向上し、CPUの使用率が改善され、コストも削減されました。このパイロットプログラムでは、インフラ支出を30%削減することができました。ここで強調したいのは、これはパイロットプログラムだけの結果だということです。Prime Videoの規模で考えると、この取り組みを組織全体に展開し、ピークイベントやスポーツイベントのスケーリングを完全に自動化すれば、数百万ドル単位の効果が期待できます。
次に、得られた教訓とベストプラクティスについてお話しします。まず重要なのは、トラフィックパターンとアプリケーションを深く理解することです。Prime Videoでは、ライブスポーツを配信する前は、事前にキャパシティをスケールする必要性はそれほど重要ではありませんでした。しかし、トラフィックパターンが変化したり、急激なスケールが必要なイベントがある場合、スケジュールされた Auto Scalingが必要な時と、動的なAuto Scalingに頼れる時を理解することが重要になります。私たちの場合、最も効果的だったのはその両方を使用するハイブリッドアプローチでした。シンプルに始めて徐々に拡大していくことも重要でした。今年の目標は、最大限のコスト削減を追求することではなく、この機能が実際に機能することを実証し、リーダーシップの信頼を得て、今後数年でこれを広く展開し、より多くの採用を実現できることを確認することでした。最後に、どのようなプログラムでも、早い段階でKPIを特定し、それにこだわり、継続的にモニタリングして改善を推進することが大切です。
最後に、Prime Videoがスポーツコンテンツへと展開していった道のりを示すこの図をご覧ください。2016年に始まった当初を振り返ると、視聴者数が数千人規模のライブイベントがほんの一握りしかありませんでした。それが現在の2024年では、Thursday Night Football、先週末に行われたBlack Friday footballの試合、クリケットなど、枚挙にいとまがありません。さらに2025年に目を向けると、NBAやNASCARが加わり、これらも真の自動スケーリングと弾力性を実現する絶好の候補となります。これまでの成長は、責任を持ってスケーリングを確実に行う能力なしには実現できなかったでしょう。
AWS Well-Architected FrameworkとReliabilityの実践
それでは、Tuaにバトンタッチしたいと思います。では最初からやり直しましょう。RalphとElliottの話を聞いていただきましたが、Prime Videoでは
とにかく動作するということが重要で、それこそがPrime Videoが実現したことでした。課題と解決策を振り返ってみましょう。課題は、世界中の何百万人ものファンにストリーミングを提供することで、その数は年々増加しています。非常に変動の大きいネットワーク上で、テラバイト規模のデータが流れており、Prime Videoはマルチリージョンと自動スケーリング戦略でこれを実現しました。
みなさんがどれだけ注意深く聞いていたか確認するために、Prime Videoが使用しているAWSサービスの数に関する質問の答えを確認してみましょう。この質問の答えを覚えていますか？120以上で、この数字は変わっていません。では、Prime Videoはこれをどのように実現したのでしょうか？それは、AWS Well-Architected Frameworkを採用することでした。彼らはReliabilityから始めて、Cost Optimizationへと進みました。AWSをご利用の方の多くは、Well-Architected Frameworkをご存知でしょう。Well-Architected Frameworkには6つのピラーがあります：Operational Excellence、Security、Reliability、Cost Optimization、Sustainability、そしてPerformance Efficiencyです。
Prime Videoにとって、Reliabilityとは、ビデオ品質を損なうことなく100%のアップタイムを提供することであり、同時にAWS上のインフラを効果的に運用するためのCost Optimizationにも焦点を当てることでした。Reliabilityが目標であり、Resilienceがそのアプローチでした。Reliabilityはシステムの信頼性を決定し、Resilienceは障害を回避することではなく、システムができるだけ早く完全な機能状態に戻る能力のことです。Resilientなシステムは、より高いReliabilityを持ちます。
Prime Videoが採用したReliabilityに関する設計原則を振り返ってみましょう。これには、障害からの自動回復や、回復手順が自動的かつ確実に機能することを確認するための破壊的テストが含まれます。リージョンやAZ、アプリケーションに障害が発生した場合、代替のリージョンやアプリケーションに切り替えてシステムを機能させる必要があります。Prime Videoはアクティブ-アクティブのマルチリージョン戦略を実装しました。回復手順のテストは極めて重要です - プライマリからセカンダリリージョンに切り替える場合、事前にそれが機能することを確認する必要があります。
スケーリングも重要な原則の一つです。Prime Videoへの需要が増加するにつれて、ワークロードの可用性を高めるために水平方向にスケールします。Reliabilityについて考える際、需要とピークが増加した時にできるだけスケールできるようにしたいと考えます。そして、キャパシティの推測をやめることも重要です。必要なキャパシティを推測することは避けたいのです。なぜなら、それを間違えると、プロビジョニングに長時間かかってしまうからです。Prime Videoは、NFLの配信を重ねるごとに、キャパシティニーズとファンの視聴傾向についての理解を深め、キャパシティの推測をやめ、需要に効果的に対応できるようになりました。
最後に、自動化による管理についてお話しします。 人間が行う手作業にはどうしてもエラーが発生する可能性があります。そこで、AWSのCI/CDパイプラインを活用して、変更を自動的にデプロイすることで、できる限りこうしたエラーを防ぐことが重要です。ここで、マルチリージョンのベストプラクティスについてご説明します。 物理的に離れた場所やリージョンをまたいで運用されるデータアプリケーションには、必ず課題が伴います。ワークロードに最適なテクノロジーを選択するには、整合性やレプリケーションのオプション、そしてそれぞれのメリットとデメリットを理解する必要があります。可用性とパフォーマンスの向上が設計目標の1つである場合は、テーブルやS3の非同期レプリケーションを真剣に検討すべきです。これにより、すべてのリージョンで同じデータを確保できます。Active-Activeのマルチリージョン書き込みには課題がありますが、重要なトランザクションの処理と競合の解決により、望ましくない動作を防ぐことができます。
複数のリージョンでアプリケーションを実行している場合、差分的な可観測性を確保することが重要です。ログやトレース、そしてシステムの健全性を総合的に理解するためのあらゆる情報を観察できる必要があります。なぜなら、プライマリリージョンからセカンダリリージョンに切り替える際に、セカンダリが利用できない状態でヘルスチェックが失敗した場合、その切り替えを実行したくないからです。
私が見た4つの基本原則の1つ目は、要件の理解です。お客様とのレジリエンスに関する会話の70～80%は、RTO/RPOの要件の把握から始まります。Prime Videoの場合、できる限り低い値を目指し、過去数年間に発生した障害の数、ビジネスへの影響を理解し、マルチリージョン化によってビジネスのROIが改善されるかどうかを検討しました。マルチリージョンアーキテクチャに進む前に、まずこれらの情報を収集することが極めて重要です。
次に重要なのがデータの整合性で、ここでCAPの定理が関係してきます。CAPの定理は、分散システムの設計において3つの特性のうち2つを満たす必要があるという指針を提供します。Prime Videoにとって、最も重要な要素の1つは、ユーザーセッションのリアルタイム同期のためのデータレプリケーションでした。整合性とは、2つの異なるソースから2つの異なるノードに対してリクエストが行われた場合に、すべてが同じデータを返すことを意味します。可用性は、システムが読み取りと書き込みに対応できる状態を指します。分断耐性は、パーティションの損失やネットワーク接続の遅延などの障害が発生しても、システムが継続して動作することを意味します。
整合性と分断耐性を選択した場合、整合性の検証とシステムの可用性を待つ必要があるため、パフォーマンスは低下します。 可用性と分断耐性を選択した場合、より良いパフォーマンスと結果整合性が得られますが、処理中のトランザクションについては、ゼロではないデータ損失が発生する可能性があります。3つの特性のうち2つを選択し、それに応じてシステムを設計することになります。
これにより、依存関係の理解に話を移します。サードパーティのアプリケーションを呼び出している場合、アプリケーションのレイテンシー要件を特定し、内部および外部の依存関係が判断にどのように影響するかを確認する必要があります。プライマリリージョンがサードパーティのエンドポイントに依存しており、そのエンドポイントが一時的に利用できない状況を考えてみましょう。別のリージョンに切り替えても、同じAPIリクエストを行う必要があります。レイテンシー要件を維持するために、失敗せず、以前と同じレイテンシーを保つことを確実にする必要があります。
これで、運用準備の4つ目の基本に移ります。プライマリリージョンでアプリケーションを実行していて、プライマリが不健全または利用できないためにプライマリからセカンダリに切り替える必要がある場合、アプリケーションコードには最新の変更が反映されているものの、期待通りに動作していないことに気付くかもしれません。セカンダリリージョンに切り替えると失敗する可能性があります。セカンダリリージョンに切り替える前に、十分な情報に基づいた判断を行いたいものです。
このため、アカウントの制限とクロスリージョンのヘルスチェックを把握しておく必要があります。プライマリからセカンダリに切り替える前に、クォータ制限があったり、実行中のアプリケーションが不健全な場合は、切り替えを行わないでください。十分な情報に基づいた判断を行い、復旧手順をできるだけ自動化し、実装前にテストを行ってください。
Prime Videoの成果と今後の展望
これらの考慮事項から、重要なポイントが見えてきます。Prime Videoでは、すべてを機能させ、トラフィックスパイクに対してシステムが準備できている状態にすることを目指していました。彼らが達成したのは、運用の回復力であり、TNFの日に何百万人ものユーザーの成長をサポートすることでした。彼らはReliabilityピラーから始め、徐々に最適化に向けて進んでいきました。動的にスケールできるようになったため、ピーク対平均の比率は非常に変動的でした。
彼らのピーク対平均の比率は非常に変動的で、通常日からNFLの日にかけて5倍から10倍、時にはそれ以上になることもありました。Thursday Night Footballの際には、大きなピークが見られました。コスト最適化に関しては、コストと運用で20%の削減を達成し、Ralphが言及したように、パイロットで30%の削減を実現しました。最適化の取り組みを進めるにつれて、さらなる改善が続きました。
炭素排出量の削減に関して、EC2インスタンス数の削減とGravitonの採用により、カーボンフットプリントを43%削減することができました。ここで重要なポイントは、レジリエンシーやコスト最適化を目指す際、あるいはPrime Videoの経験から学ぶ際、まず一つのことに焦点を当てることです。Prime Videoの場合、最初は信頼性を重視し、その後コスト最適化に移行しました。一つの側面に焦点を当て、その後他の信頼性の柱に進むことで、目標を達成することができるのです。
最後に、CTOのDr. Werner Vogelsの言葉を引用して締めくくりたいと思います：「すべてのものは常に故障する。私たちは故障を自然な出来事として受け入れるシステムを構築する必要があった」。これはまさにPrime Videoが実践したことです。彼らは動画が失敗する可能性、アプリケーションが失敗する可能性、その他のコンポーネントが失敗する可能性があることを認識していました。その対応として、先週のBlack Fridayフットボールを含め、ユーザーが毎週Thursday Night Footballを視聴できるよう、マルチリージョンのAuto Scalingなどの戦略を実装したのです。
これで本セッションを終了させていただきます。ご参加ありがとうございました。私たちのメールアドレスとLinkedInプロフィールを掲載していますので、ぜひつながってください。また、アプリ上にはセッションの改善点についてのアンケートもございます。会場で質問がございましたら、私たちがお答えいたしますので、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion