Momento と Valkey によるライブイベント向けリアクティブインフラストラクチャ
Momento と Valkey を活用したリアクティブインフラストラクチャは、CDN 規模のイベントストリームを数秒以内にユーザー体験の変化につなげます。
サービスが再生上の問題に対応し、視聴者の行動にリアルタイムで適応するようになるにつれて、メディア体験はますます動的で魅力的になっています。
リアクティブインフラストラクチャとは、流入する観測情報を視聴者の体験の変化につなげる、共通のパターンを指します。フィードのパーソナライズ、体感品質（QoE）の監視、不正視聴の検知といった具体的な機能は、ライブメディアシステムの異なる部分に関わりますが、いずれも何らかのクライアントの行動を適時の判断につなげます。
共通の課題は、CDN を使わずに、変動の大きい CDN 規模のトラフィックを取り込むところから始まります。テレビ、ブラウザー、モバイル端末は、観測した情報を収集エンドポイントに直接送信します。視聴者の急増は取り込みトラフィックの急増につながり、受け付けたイベントはすべて、そのエンドポイントより先でも処理を発生させます。そして、データの収集は出発点にすぎません。生データを数秒以内に活用できる状態にし、別の場所で利用できるよう届ける必要があります。
この作業を整理するのが、取り込み → 処理 → ストレージ → 意思決定という4段階のパターンです。収集する情報、データのグループ分け、利用するストア、導き出す判断を変えることで、各段階をそれぞれのユースケースに合わせられます。段階ごとの責任を明確にすると、各段階で特に重要な設計上の選択肢を見極めやすくなります。
4つの段階でフィードバックループを閉じる
リアクティブなアーキテクチャは、クライアント上での観測からデータパイプラインを経て、クライアントの体験の変化に戻る閉じたループを形成します。その変化から新たな観測情報が生まれ、サイクルが再び始まります。
このアーキテクチャは、次の4つの段階で構成されます。
- 取り込みはクライアントのイベントを受け付け、流入するトラフィックを整えます。
- 処理はイベントの断片を、整理された検証済みのストリームにまとめます。
- ストレージは、データを利用する側に適した形式で、分析に使えるよう提供します。
- 意思決定は、そこから得た情報を製品の動作につなげます。
共通の4段階のパターンが、クライアントの行動をメディア体験に影響する判断につなげます。
各段階のクラウドコンポーネントは、それぞれの責任に集中します。インターネットに公開されたゲートウェイが、クライアントからビーコンを受信します。その背後では Valkey（コミュニティが支える Redis のフォーク）が共有の収集プールを提供し、軽量な関数とコネクターが下流のストア向けにデータを準備します。判断を行うコンポーネントは、必要な情報を使い、ビジネスロジック、エッジ関数、またはオペレーターの操作を通じて体験に働きかけます。
図中の Gateway or CDN の経路は、視聴者に体験を届ける外向きの方向、つまりエグレスを表しています。クライアントの観測情報がアーキテクチャに入る内向きの経路、つまりイングレスと対になるものです。
データはこのアーキテクチャを取り込みから意思決定へと流れますが、設計のプロセスは実際に導き出したい判断から逆算すべきです。その判断にはどの情報が必要か。どれほど迅速に体験へ反映する必要があるか。データ損失をどこまで許容できるか。これらの答えが、各段階の選択を決めます。
取り込みはクライアントのトラフィックから下流サービスを保護する
取り込みの段階は、インフラストラクチャと数百万人の視聴者をつなぐ接点です。そのゲートウェイは、公開インターネット上の端末からの接続を処理し、トラフィックの急激な変動を吸収して、その変動が内部サービスを圧迫しないようにする必要があります。
HTTP ビーコンは、最終的にユーザー体験に関する判断につながる情報を運ぶ手段です。ビーコンのサイズと頻度は、ゲートウェイの負荷に直接影響します。判断に必要な情報を選び、各ペイロードを小さく保ちます。判断に新たな観測情報が必要となる速さに合わせてビーコンの送信間隔を設定し、必要以上に収集することなく、有用な更新情報をシステムに届けます。
ゲートウェイは、トラフィックをバックエンドへ安全に届ける方法を制御します。流入したイベントを短時間保持してまとめて転送し、大量に押し寄せる個別リクエストを、より扱いやすいマイクロバッチに変えます。データの流れを整えることで、ゲートウェイは下流のインフラストラクチャを保護し、負荷に備えた過剰な容量確保の必要性を減らします。
バッファリングの時間が判断のレイテンシ予算に対して小さい場合、マイクロバッチ処理による短い遅延は、エンドツーエンドのレイテンシの中では無視できるほど小さいものです。ただし、データ損失が起こる機会はわずかに増えます。バッファー内のイベントにはコピーが1つしかないため、転送前にゲートウェイのノードが停止すると、それらは失われます。最終的に、バッチ処理の方針は、データ損失リスクのわずかな増加と引き換えに、全体の信頼性を大幅に高め、インフラストラクチャのコストを削減します。
Momento Valkey Router は、この境界でコネクションプーリング、認証、スロットリング、シャードを考慮したルーティングを提供します。これらの仕組みは、アーキテクチャ上のビーコンのバッチ処理とともに、ゲートウェイによる保護を支えます。バックエンド接続を再利用することで、収集層はクライアントごとに上流への接続を個別に維持せずに、はるかに多くの端末を扱えます。
判断に許容されるレイテンシと損失の範囲内で、ゲートウェイがトラフィックをまとめて制御し、下流の処理能力を有用な作業に振り向けます。
処理はイベントを整理し、利用する側に振り分ける
バッチは異なるゲートウェイのノードを経由して到着するため、関連する行動の断片が別々のバッファーに残ります。処理の段階では、その断片を Valkey を基盤とする複製された共通の収集プールに集め、下流で使えるように準備します。軽量な関数と非同期コネクターが変換と振り分けを担います。
ストリームは、セッション ID や地域など、ビーコンの何らかの属性によって識別されます。ストリームキーが関連するイベントを適切なシャードに送ると、そこで断片が整理されたストリームにまとめられます。この整理の段階を経ることで、下流の利用先は、ストレージへの保存と分析に使える、関連する行動の一貫した流れを受け取れます。
この段階では、準備の処理を軽量に保つ必要があります。稼働中の利用先に届く前にレコードを検証し、データの形式を少し調整して、適切な出力先に振り分けます。負荷の高い結合、探索的なクエリ、複雑な分析は、それらの作業に適した下流システムで行います。生データのアーカイブはリアルタイムの検証処理とは独立して保持し、不正な形式のレコードも調査や再処理に利用できるようにします。
Momento の軽量な WASM 関数は、このような短時間の検証や変換をバッチで実行します。非同期のシンクコネクターは Valkey からデータを取り出し、完成したファイルを S3 などの送信先に書き出します。これにより、その転送処理をクライアントリクエストから切り離します。
大量のイベントを扱う処理層を分析エンジンに変えることなく、イベントを集約し、検証して、振り分けます。
ストレージは利用する側に合わせてデータを提供する
イベントを整理したら、次に考えるのはその使い方です。1つのデータベースですべての問いに答えようとするのではなく、利用する側のアクセスパターンに合わせてストレージを選びます。同じイベントの流れを利用していても、クエリの形、必要な応答時間、保持期間は大きく異なる場合があります。
QoE 監視は、この違いをよく示しています。数秒以内に作動させるべき自動アラームには、Valkey の移動時間窓のカウンターを利用します。一方、インシデントを調査するオペレーターには、1分未満でアドホッククエリを実行するために ClickHouse などの分析用ストアが必要です。それと並行して、イベントを Parquet 形式の S3 アーカイブに送り、過去の分析、再処理、監査に利用します。範囲を限定したカウンター参照、探索的なクエリ、過去データのスキャンでは、ストレージに求めるものが大きく異なります。
パーソナライズでは、クエリの形がさらに変わります。ユーザーやコンテンツの表現に対する類似検索には、ベクトルを扱うストレージが必要です。データの表現と検索方法を変えても、アーキテクチャ上のストレージの責任は変わりません。具体的な保存先は、利用する側の要件に合わせて選びます。
Valkey は、収集と高速な運用データストレージの両方の役割を担います。この2つの役割は、異なる作業を行いながら、同じ層で実現しても構いません。処理の段階で導入した非同期コネクターがアーカイブ用ストレージへの独立した転送経路を提供する一方、稼働中の利用先は、それぞれのニーズに合わせて用意されたビューを使います。
カウンターの参照やクエリの実行にかかる時間は、クライアントの行動から結果が反映されるまでの時間の一部にすぎません。ビーコンの送信間隔、バッファリング、準備の処理、判断のタイミングも影響します。必要な情報が遅れて届くパイプラインは、高速なストアを選ぶだけでは補えません。
利用する側のクエリ、必要な情報の鮮度、保持期間に合わせて、ストアを選び、組み合わせます。
意思決定は体験を妨げずに結果を反映する
意思決定は、準備された情報をメディアシステムの動作につなげます。ポリシーエンジンやオペレーターなど、判断を行う側がその情報を評価し、実行するアクションを選びます。製品のビジネスロジックやエッジ関数が、順位付け、配信経路、セッションポリシーなどのアプリケーションの動作に結果を適用します。
分析のワークロードは、稼働中のリクエスト処理のクリティカルパスから外します。視聴者のリクエストごとに複雑なクエリを必須にすると、製品の応答時間と可用性がそのクエリシステムに依存します。視聴者のリクエスト経路の外で判断を計算し、その結果をリクエスト処理のロジックから利用できるようにします。そのロジックは、リクエストごとに新たな分析クエリを待たずに結果を適用します。判断が影響を与えるべき結果に合わせて、判断を更新する頻度を選びます。
不正視聴の検知は、このタイミングの関係を示す例です。セグメントのリクエストと次のリクエストの間にポリシー分析を行い、その後の制御に使う結果を用意します。セグメントの応答ごとに同じ分析を加えずに、判断のための時間を確保できます。既存のアクセス認可は、引き続き配信システムの一部です。
パーソナライズでも、タイミングを意図的に決める理由があります。関心を示すデータが継続的に更新されても、画面を更新するたびに異なる順位付けを返す必要はありません。裏側で分析を続けながら、公開済みの順位付けを一定に保ちます。どちらの場合も、判断の更新頻度は体験に必要な条件に合わせます。
製品が判断を反映すると、その後のクライアントの観測情報が効果を示します。その観測情報は取り込みを経由して戻り、サイクルが再び始まります。
分析をリクエスト処理のクリティカルパスから外しながら、求める結果に必要なペースで判断を反映します。
判断に合わせてアーキテクチャを調整する
このリアクティブなアーキテクチャの4つの段階が連携することで、CDN 規模の観測情報を数秒以内にユーザーが体験する変化へとつなげます。
ゲートウェイのバッチ処理は、内部サービスにデータが届く前にリクエストのオーバーヘッドを減らします。収集プールは関連する行動の情報を整理されたストリームにまとめ、下流の利用先ごとに適切なデータストアへ送ります。その情報を分析エンジンが判断につなげ、アプリケーションのビジネスロジックが判断を反映することで、ユーザー体験に変化をもたらします。
フィードのパーソナライズ、QoE 監視、不正視聴の検知など、さまざまなユースケースで、少し調整するだけで同じアーキテクチャを活用できます。求める結果から始め、アーキテクチャをさかのぼりながら、判断を適用する方法を決め、それに伴う制約を各段階に反映することが大切です。データによってユーザーの体験が変わるとき、このループはリアクティブに機能します。
CDN を使わずに CDN 規模のトラフィックを処理するシステムの構築は、専門家にとっても難しい課題です。Momento のエンジニアは、ミッションクリティカルな状況でシステムがどのように障害を起こすかを理解し、毎秒数百万件のリクエストを処理できるように Momento プラットフォームを設計しました。このプラットフォームは、FOX、Paramount、Warner Bros. Discovery などの主要なプロバイダーで、サッカーワールドカップ、スーパーボウルをはじめとする世界規模のメディアイベントのライブ体験を支えてきました。
製品をよりリアクティブにする方法を検討したい方は、お問い合わせください。