タッチダウン! Paramount+が歴代最高の”大一番”のゲームをYugabyteDBを使ってライブ配信

本記事は、The Distributed SQL Blog にて2024年2月11日に公開された ”Touchdown! Paramount+’s Record-Setting “Big Game” Live Stream with YugabyteDB”を翻訳および一部編集と訳注を追加しております。最新情報は英語版の記事を参照してください。

Paramount+ は今期のNFLシーズンにおける視聴記録を塗り替えました！今年のスーパーボウルがライブ・イベントとして最も視聴された番組だと知ってましたか？また、それがどれくらい大変なことかも想像できますか？最終的なデータが出る前に、Paramount+がスーパーボウルに先立って公開した(訳注1)契約者数の集計を見ていきましょう。

• CBSにて放映されたNFL ON CBSが、最も視聴者数の多かったAFC Championshipゲームの記録を更新し、平均で5547.3万の視聴者を集め、2011年1月23日に行われたJets対Steelersの試合(ET:アメリカ東部時間 6:42PMから9:54PMの遅い時間帯にて実施)における5485万人を上回りました。
• NFLが開催された週末は、2週連続で5000万人以上の視聴者が開催された週末で試合観戦していたことになります。
• この2024年1月28日に行われた試合はCBSの過去30年間において、スーパーボウルを除いて最も視聴者数の多かった放送であり、1994年の冬季オリンピック以来の快挙となります。

このように圧倒的な視聴者数を実現するためのシステムを設計するためには、スケーラブルであることはもちろん、堅牢性と回復性の高いアーキテクチャが求められます。このような厳しい要件を満たすために設計されたParamount+のソリューションにYugabyteとして貢献できたことは、身の引き締まる想いであると同時に誇りでもあります。全てを詳細にお伝えするには記事として収まらないので、本ブログではParamount+の全体ソリューションにおいてYugabyteDBが担った役割についてのサマリーをご紹介いたします。

ストリーム配信の拡大のためには、データベースのスケール、性能、可用性が必要

Paramount+の利用者数は2021年3月時点で1650万人だったのに対し、2023年9月においては、6340万人となり、約4倍近い増加が、利用者数とWebとモバイルアプリからのアクセス数のいずれにも見受けられました。ユーザのアクティビティとしては、取り上げるにはあまりに大きすぎる数ですが、ログインの試行回数やアカウントの更新、コンテンツアクセスやライブストリーミングなどが含まれます。

メジャーなイベントが開催される直前 (Super Bowlなど)になると, 非常に大きな数の同時接続者数をこなすべく、システム全体の各レイヤーとコンポーネントが極度に大きなプレッシャーにさらされて、インフラストラクチャの様々なレイヤーにアクセスとストレスが発生します。データベースレイヤーに影響を及ぼすであろうリクエスト数を予見しておくことは非常に難しく、データベースのほとんどはスパイク時にスケールできるようには設計されておらず、また、通常運用に戻った場合にスケールバックをする必要もあります。

この点がまさに、YugabyteDBの差別化要素となります。つまり、水平方向のスケーラビリティはYugabyteDBのDNAであり、スモールスタートを初めて、必要に応じてスケールアップ/アウト、イン/ダウンが実現できます。YugabyteDBは、増え続けるデータセットに対してよりスペースを提供するという、よくあるミスコンセプトなデータベースに留まりません。スペース自体が問題ではないからです。エンドユーザ数が増えることは、よりバックエンドへのコネクションが増えることでもり、あるいは読み書きが増えることでもあり、その両方でもあるかもしれません。

最も重要なことは、24時間365日で配信されるストリーミングにおいては、ダウンタイムは許されず、高い可用性が必要となることです。

データの地域性を確保しつつ、マルチリージョンアーキテクチャでこれまでにないユーザ体験を

みなさんが対峙するお客様は、あらゆるところに存在しており、インターネットへ接続さえできれば世界中の至る所からログインしてくる、という前提にいる必要があります。

そのため、データアクセスはログイン認証と視聴条件の確認を素早く行う必要があります。 読み込みと書き込みのレイテンシーを低減するため、ユーザに近いところにデータを配備しないとなりません。これはYugabyteDBアーキテクチャのコアな部分でもある、YugabyteDBをマルチリージョンにデプロイをすることで実現可能となります。

よく大手企業においては、シングルクラウドのリージョンか一箇所のデータセンターアーキテクチャから実装をはじめます。その後、ユーザ数が4倍に膨れ上がって、スケールしようにも、再設計するにも時間がないといった重大な課題に直面することになります。

もし、みなさんのサービスがステートレスで、簡単にスケールできるものであれば、問題にはなりません。それでもデータベースレイヤのスケーリングという難しい課題は残ります。幸運なことにParamount+において、そのニーズが発生した際にはYugabyteDBはシームレスにGoogle Cloud(GCP)の3つのリージョンにスケールしていました。そのため、 Super Bowlの試合中に、視聴者のトラフィックに突発的なスパイクがあったにも関わらず、十分な対処ができるような準備ができていました。これは従来のモノリシックなデータベースでは実現できなかったでしょう。もし実現出来たとしても、追加のレプリケーションやオブザーバビリティといった技術と、より大規模な運用チームへの莫大な投資が必要となります。

以下の図においては、YugabyteDBも含まれたデプロイメントトポロジーを表しております。より詳細はShiva Paranandi氏の blog post をご確認下さい。

Multi-region database architecture with YugabyteDB

データベースの課題を克服するため、Paramount+ は新しいマルチリージョンセットアップのための目標を定義しました。

• Paramount+のユーザ自身が、どこのリージョンからアクセスしてるかを決して意識することなく、すべてのリージョンは同じとみなす。もちろん、バックグラウンドジョブや、特殊なケースが発生するかもしれないが、ユーザが直面する操作は、マルチリージョンにシームレスにスケールすることが必要。
• レプリケーションを除いた、リージョン間で直接のコミュニケーションは発生させない。
• 実際のマイグレーションにおいて、ダウンタイムかデータロスが発生しないというのは、ユーザベースを広げるには非常に重要なことであり、24時間365日流れているストリーミングを運用するといった場合においても必要な要件とする
• セキュリティポリシーも全てのリージョンで同等に実装されるべきで、監査や監視も必要。

PostgreSQL互換性による迅速な開発

もう少しバックグラウンドの実装についてご紹介します。Paramount+のゴールはTier 1と呼ばれるクリティカルなアプリケーションを、より堅牢で、パワフルで、柔軟なテクノロジースタックに拡張することでした。ただし、コードの書き換えは望んでませんでした。より迅速な革新と、ハイパフォーマンス、スケーラブルで、高可用性のあるデータベースを優先度高く設定しました。

ステートレスで、水平方向にスケールするマイクロサービスにスイッチすることで、マイグレーションプロセスの多大な恩恵にあやかることができ、データベースとORM(Object Related Mapping)レイヤーの最適化にフォーカスできるようになります。ORMレイヤーは旧来のデータベースでもYugabyteDBともシームレスに連携する必要があり、レガシーデータベースからの脱却が進むまでは、入れ替え出来るようにしておく必要があります。これは、rip-and-replaceと呼ばれるアプローチに比べると難しい方法となります。これは別のブログポストあるいはWebinarにてご紹介させてください！

スーパーボウルレベルのスケールを実現するには

グローバルなデータアーキテクチャにおいて、大規模にスケールし、回復性があり、マルチリージョンに展開したアプリケーションに必要な要素を知りたいですか？今後のワークショップに期待してください！

訳注1: ブログ公開時点(2024/3/11)では、日本からの当該コンテンツへのアクセスが許可されておりません。

今年も年次イベントDistributed SQL Summit Asiaが2024年4月に開催されます。最新情報はブログまたはこちらまで