Top Trends in Cybersecurity for 2024 | 
1:1レベルでパーソナライズされた視聴体験がテレビ体験を変革している。 視聴者は、1つのサイズに合わせた広告ではなく、ターゲットを絞った関連性の高い広告、カスタマイズされたコンテンツ、新しいプログラムの推奨事項、正確なDRM /ブラックアウト管理を、視聴者のデバイスタイプ、場所、履歴、人口統計、その他のデータに基づいて取得できる。
しかし、パーソナライズされたビデオストリームを数百万人の視聴者に拡大することは、特にスポーツなどのライブ番組の場合は、野球のサイクルを狙うのと同じくらい難しい。 視聴者数はキックオフ、残業、近親試合などの必見の瞬間に数十万人急増する可能性がある。 パーソナライゼーションをサポートするインフラストラクチャが、適応性と拡張性に欠けているとしよう。 その場合、パーソナライズされた体験はゲームオーバーになり、OTTの世界ではビジネス全体が危険にさらされる可能性がある。
パーソナライズにおけるマニフェストサーバーの中心的な役割
OTTパーソナライゼーションは、コンテンツ、広告、再生指示のユニークなプレイリストを生成するマニフェストサーバーのパフォーマンスに依存する。 マニフェストサーバは、次の依存関係と競合する必要がある。
- 広告サーバーのレイテンシー—広告サーバーとの通信により、特に複数のホップが関係する場合には、ワークフローに考慮する必要があるレイテンシーが追加される。
- 収益化/レポート—広告が再生されたら、広告インプレッションを測定し、収益化を可能にするために、ビーコンを広告サーバーに送り返す必要がある。
- インターネットのステートレスな側面—パーソナライズされたマニフェストが大規模に機能するためには、各視聴者に対して複数のリクエストにわたってステートを維持しなければならない。
- DRM/authentication—マニフェストサーバーは、デジタル著作権管理(DRM)、セッションレベルの暗号化、および認証を監視する必要がある。
- ブラックアウト/コンテンツの権利と制限—ユーザーの場所に応じて、ストリーミングコンテンツはさまざまなブラックアウトルールの対象となる可能性があり、それらはすべて正確に管理されなければならない。
- コンテンツのおすすめ—オンライン視聴者は、コンテンツを知っていることを期待し、おすすめをパーソナライズして、検索と発見のプロセスを支援する。
- コンテンツのローカリゼーション—大規模なイベントでは、オーディオトラック、クローズドキャプション、字幕など、適切な地域のバリエーションをユーザーに提供することが重要である。
リアルタイムでのストリームのパーソナライズ
このブログシリーズのパート1で説明したように、ライブまたはVODフィードは、Slicerソフトウェアアプリケーションによって取り込まれ、エンコードされ、パッケージ化される。 コンテンツ所有者が視聴者の体験をカスタマイズできるように、広告境界を挿入することができる。 広告が取り込まれると、クラウド上で実行されるスライサーを介して処理され、よりブロードキャストのような再生体験が得られる。
スライサーはライブストリームまたはVODストリームの取り込みを開始すると、バックエンドインフラストラクチャと継続的に通信し、利用可能なセグメント数についてデータベースを更新し続ける。 マニフェストサーバーはそのデータを使用して、各視聴者のエクスペリエンスをパーソナライズする。 プレーヤーがストリームを要求すると、マニフェストサーバーは、どのビデオセグメントとオーディオセグメントをマニフェストファイルにリストするかを決定し、マニフェストファイルはプレイリストとして機能する。 マニフェストをユーザーごとに動的に変更またはカスタマイズする機能により、視聴体験をカスタマイズすることが可能になる。 ライブ動画の場合、数秒ごとに新しいマニフェストが要求され、表示条件の変化に応じてマニフェストサーバーによって動的に調整が適用される。
動画ストリームのパーソナライズにおけるマニフェストサーバーの中心的な役割
上に示すように、マニフェストパーソナライゼーションの中核はコミュニケーションである。 OTTビジネス要件のほとんどでは、ターゲットを絞ったパーソナライズされた広告をリアルタイムで提供するために、広告サーバーとの通信を意味する。 視聴者のIPアドレス、位置情報、デバイスタイプなどの個人データは、厳密なPIIルールや規制を遵守しながら取得できる基本的なすべての情報であり、広告決定システムに提供される。 その結果得られたソリューションは、ライブストリーム中に広告を配信するときに視聴者に関連するものを学ぶのに十分な堅牢性を備えている。 また、ブラックアウトの制限やユーザーごとのコンテンツ権利の管理などの課題にも対応できる堅牢性を備えている一方で、コンテンツの推奨やその他のローカライズなどの重要なパーソナライゼーション機能もサポートしている。
拡張するマニフェストインフラストラクチャの設計
私たちのビデオプラットフォームでは、マニフェストサーバーは、各ビューアのカスタムストリーミングマニフェストを生成する責任がある。 また、コンテンツの制限や推奨事項など、上記の他の要件も認識する必要がある。 このモデルでは、1つの統合ストリームを送信する。つまり、クライアントがストリームの途中で広告がロードされるのを待っている間、「バッファホイール」の問題は発生しない。
レジリエントなマニフェスト配信システムを構築するために、世界中の異なる地域に分散したマニフェスト生成サーバーのクラスターをクラウドに維持する。 たとえば、米国では、これらのサーバーは全国5つの地域に編成されている。 米国に拠点を置くプレイヤーから新しいストリームのリクエストが入ってくると、そのリクエストは米国のゾーンの1つにランダムにルーティングされる。
「雷鳴の群れ」の挑戦
これは直感に反するように見えるかもしれないが、カスケード故障モードを防ぐために行われている。 アメリカの視聴者の大半は東部に住んでいる。 もし私たちがそれらを最も近いゾーンにルーティングし、クラウドプロバイダーがその地域で障害を経験した場合、私たちの視聴者の大部分はその障害を経験するだろう。 この問題をさらに複雑にするのは、もし視聴者全員がストリームを更新し、視聴者を次に近い健康ゾーンに誘導しているならば、「雷の群れ」問題が発生するだろう。失敗したゾーンから視聴者全員が次の最も近いゾーンにドッグパイルする。 結果として生じる予期しないトラフィックスパイクは、新しいゾーンのシステムが追加の需要を満たすためにスケールアップできるようになるまで、二次障害を引き起こす可能性がある。
代わりに、米国の視聴者をランダムに配信することで、初期障害の影響を軽減し、正常なゾーンの残りの部分にフェールオーバートラフィックを均等に分散させることができる。
ストリーミングプラットフォームでは、マニフェストサーバーの負荷をゾーン間で分散する。 これにより、視聴者の急増時に特定のゾーンが過負荷になるのを防ぐ。特に、フェイルオーバー時に視聴者が隣接するゾーンに突然移動した場合には、
各ゾーンには、関連するセッションデータを保存する専用の個別のデータストアがある。 ビューアーがゾーンにルーティングされたら、そのビューアーのセッションを作成し、ゾーンのセッションクラスタに保存する。 セッションは、ビューアに関するデータと、そのビューアのセッションをどのようにカスタマイズしたいかについて、お客様から提供されたパラメータの束である。 インターネットのステートレスな性質がもたらす課題を克服するために、マニフェストサーバはプレイヤーに返されるマニフェストに含まれる各セッションのURLを構築する。 プレイヤーからの後続のリクエストは、視聴者のセッションが作成され保存されたゾーンに直接ルーティングされる（他のゾーンの1つにランダムにルーティングされるのではなく）。
下の3つのグラフに示すように、異なるイベントは、聴衆の規模や聴衆が地域的であるか地理的に分散しているかによって、多くの異なる要件を持つことができる。 放送局がライブイベントをサポートする上で直面するインフラの課題を示す3つの例を見てみよう。
最初のシナリオでは、フードイーティングコンテストを特集している(そう、ライブストリーミングはしている)。これは、分散しているが小規模な視聴者を示しているからだ。 食のコンテストが主流になる日が来るかもしれないが、今のところは広い地域で少数の視聴者を引き付けるニッチなイベントであり続けている。 マニフェストサーバの負荷は、複数のゾーンおよびマニフェストサーバクラスタに容易に分散される。 そこで、各地域に適した広告を簡単に挿入できるようにし、権利や停電を管理できるようにすることで、パーソナライゼーションの価値が明らかになる。
テキサス州サッカー選手権では、同じ地理的条件で多くの視聴者がいるため、状況はかなり変化する。 我々はこれを2つの方法で扱う。 前述したように、視聴者の体験に影響を与えることなく、目下の地理的範囲外のゾーンにあるマニフェストサーバーに視聴者を割り当てることができることがわかった。 さらに、各ゾーンの視聴者レベルを監視し、必要に応じてマニフェスト生成サーバをゾーン単位で自動起動できるシステムもある。
NBAファイナルのような大規模イベントでは、予想される視聴率に基づいて事前にスケールする可能性がある。 それでも、自動スケーリングシステムが温暖化前に何も必要とせずに100万人近くの視聴者を処理したイベントが複数あった。 スケーラビリティの向上に加えて、ゾーンにとらわれない方法で負荷をマニフェストサーバに瞬時に分散する機能により、ネットワーク全体の信頼性と冗長性が大幅に向上する。
プレイヤーのリクエストと広告ビーコン
業界全体のさまざまな変化とトレンドにより、クラウドの拡張がこれまで以上に重要になっている。 主な要因は、プレイヤーからのリクエストの間隔の縮小である。 標準のライブリニア8秒の「次のプレイヤー」リクエストは5秒に設定されており、低レイテンシが重要なストリームでは2秒ごとに設定できる。 サーバは4倍のリクエストに応答しなければならないため（8秒間隔と比較して2秒間隔）、これはCPU使用率に大きな影響を与える。 さらに、ブラックアウトとコンテンツの推奨事項も、エラーを避けるために、以前よりも頻繁にチェックする必要がある。
同様に、アドテックの世界はより複雑で要求の厳しいものになっている。 ストリームに挿入されるすべての広告について、広告サーバーは少なくとも5つのビーコンを報告目的に使用する。 サーバーサイド広告挿入(SSAI)ソリューションは、ビーコンを送信して顧客が広告主から支払いを受けるようにするために必要である。 ビーコンは5つ以上あるが、より多くのビーコンが存在する可能性がある。 実際には、1つの広告に30から100のビーコンがある場合に報告する。
さらに、広告サーバーの複雑なネットワークは、顧客のキャンペーンでより一般的になっている。 複数のアドネットワークホップがレイテンシーの問題を引き起こし始める可能性がある。 例えば、ネットワーク#1が「この休憩中の広告のリストはここにあります」と言うかもしれないが、その休憩中の広告#2が別のネットワークへの要求を必要とすることを発見するだけである。 広告#3ではさらに2つのホップが導入され、以下同様に続く。
上記の例では、広告ブレークはCPU使用率を2倍または3倍にすることができる。 ライブビデオプレーヤーのリクエストはこの要因を10-30%複雑にする。
先を見据えて—マイクロサービスとスケーラビリティ
複雑さが増す中で、マニフェストサーバーで処理されていたさまざまなワークロードをより小さなマイクロサービスに分離することが、我々がとったステップの1つである。 最初のステップは、広告サーバーの通信とビーコンを自社のサービスに移行し、広告サーバーのレイテンシという課題に対処することである。 この広告プロキシサービスはいくつかの高度な機能を提供しており、今後のブログ記事で詳しく説明する。
今後、マニフェストサーバからより多くの作業を取り除き、スケーラビリティに対するよりターゲットを絞ったアプローチを提供するために、他のマイクロサービスを開発し続ける。 まもなく、複数のクラウドプロバイダーからゾーンを追加して、単一のプロバイダーの障害に回復できるようにする予定だ。
スケーラブルなSSAIとマイクロサービスを組み合わせることで、サーバーコスト、コードベースの構造、および広告トラフィック固有のその他の特性を最適化できる。 さらに、広告サーバーのレイテンシー、ブラックアウトの制限、収益化など、いくつかの重要な課題を克服できる。 同時に、処理負荷を複数のゾーンに分散することで、当社のライブ動画配信サービスは、広範に拡張し、重要な課題を克服することができ、配信ネットワークに負担をかけることなく、数百万の同時パーソナライズストリームを確実に配信できる。
