ライブスポーツにおいて、消費者が体験する「品質（Quality of Experience）」として私たちが重視するものは、極めて重要であると確信しています。遅延（ライブとの時間差）やイマーシブオーディオの導入（または使用）といったテーマが、現在大きな話題になっていることにお気づきの方もいるかもしれません。当然のことながら、これらは世界中の視聴者にとって本当に重要な要素です。

ライブスポーツのシナリオでは、イベント開始までの準備段階の瞬間において、トラフィックのピーク負荷が発生し、プラットフォームや消費者の体験に甚大な影響を与えます。結局のところ、試合に時間通りにアクセスできなければ、どんなに素晴らしいイマーシブオーディオがあっても意味がありません。ここ数年、スポーツコンテンツを配信する大手ブランドを悩ませてきた大規模なシステム障害やサービス中断の中で、メディア配信の最終要素が原因だったことは、滅多に（あるいは一度も）ありません。

では、グローバルな展開とスケールを考慮してプラットフォームを構築する際、私たちは何に注意すべきでしょうか？

認証（Authentication）

認証サービスは、ピーク負荷の影響を最も受けやすい複数のサービスのうちの1つです。ライブイベントが開始される直前の数分間、アナリティクスデータによると、通常、メインイベントに向けてタブレット、テレビ、またはコンソールを準備しようとするユーザーの急激なアクセス集中が発生し、その結果、認証やセッション更新（トークンリフレッシュ）のリクエストが殺到します。

毎秒数千程度の同時リクエストしかピークに達しない一般的なSVOD（定額制動画配信）やTVOD（都度課金制動画配信）サービスの場合、ライブスポーツが導入されることで、この数値は大幅に倍増する可能性があります。私たちが経験した冬季大会では、イベント開始直前の数分間に、50万rps（リクエスト/秒）を超えるピークを記録しました。また、フェデレーション（連携）やSSO（シングルサインオン）のアーキテクチャシナリオにおいては、このリクエスト負荷をダウンストリームのパートナーにトンネリングすることが、根本的なボトルネックになる可能性があることにも留意すべきです。

エンタイトルメント（権利確認）

次に挙げるのは、エンタイトルメント（権利確認）サービスです。エンタイトルメントサービスは、消費者がコンテンツをリクエストした際に、コンテンツの利用可能範囲（ジオブロッキング）やオファー（パッケージ）の複雑なマトリックスルールをリアルタイムで処理します。私たちの最近のプロジェクトの1つでは、「220の国と地域 + 15のコンテンツタイプ + 曜日ごとのバリエーション + 4つのオファータイプ」という、解析に複雑で時間のかかるルールセットが存在しました。これにより、プラットフォームに多大な負荷がかかります。SSL終端や、キャッシュレイヤー、データベースシャードからのエンタイトルメント応答の取得といった処理における遅延は、すべて注意すべき要素です。

消費者がイベントを正常に開始できたからといって、安心（困難を乗り切ったと）思わないでください。イベント開始前の数分間に一度だけトラフィックのピーク負荷が発生することが多い認証とは異なり、エンタイトルメントのエンドポイントは（セキュリティが強化された環境であれば）、イベント期間中ずっと定期的な間隔でアクセスされます。

ロケーションサービスや、場合によっては同時接続管理（Concurrency）サービスと連携している場合、ユーザーがVPNを経由してトンネリングしていないか、あるいは友人や家族と認証情報を共有していないかを確認するために、プレイヤーが最長30秒の間隔でポーリングを行うことは珍しくありません。多くの環境では、エンタイトルメントチェックに失敗すると、消費者はライブストリームから切断されます。エンタイトルメントエンドポイントの100%の稼働率を維持することは極めて重要です。

クラウドスケーリング

クラウドスケーリング。これはあなたの金の卵、つまりすべての容量（キャパシティ）問題を解決するソリューションであるべきです。オートスケール（Auto-Scale）グループは素晴らしい機能であり、パブリッククラウドやプライベートクラウドプロバイダーが提供するすぐに使える（out of the box）機能の強力な支持者です。とはいえ、この記事を執筆するためのリサーチにおいて、これほど多くの有名ブランドがここで足をすくわれていることに、依然として驚かされました。

高い応答遅延やインスタンスのCPU使用率などの領域で負荷を監視するルールやポリシーが作動し、必要な追加のコンピューティング容量を生成するまでに数秒かかります。さらに、ブートストラップ（起動処理）、ロードバランサーへのインスタンスの追加、ヘルスチェックの承認にさらに数分かかり、結果としてエンドツーエンドで約3〜5分の所要時間に達してしまいます。

上記のエンタイトルメントのユースケースを例にとると、ライブイベントの重要な開始時間を見逃してしまう可能性があります。容量を追加するために使用するプロセスが、負荷が75%に達したときにのみトリガーされるようになっている場合、目標を達成できない可能性が高いです。プリウォーミング（事前ウォーミング）は、この問題を解決する優れた方法です。イベントのスケジュールを活用して、ライブイベントが開始される約1時間前に追加の容量を増やすプロセスをスクリプト化または自動化してください。

ロケーションサービス

ロケーションサービスは、エンタイトルメントのロジックに大きく依存するアーキテクチャの極めて重要な部分ですが、このコアサービスの実装方法次第で成功も失敗も決まります。

従来のIPv4アドレスは現在非常に不足しているため、TTL（Time to Live）値が数日から数時間に短縮されています。つまり、サービスプロバイダーは月曜日にある地域の一部で使用されたIPアドレスを、火曜日にはまったく異なる地域に割り当てる可能性があります。消費者にとっては、サブスクリプションを契約した時点で割り当てられていたIPアドレスが、現在は再生権限のない地域に割り当てられている可能性があることを意味します。

ロケーションサービスを展開する際は、カスタマーサービスがリアルタイムでIPアドレスをバイパス、ホワイトリスト登録、または調整して、消費者に即座にライブイベントへのアクセスを許可できるようにすることが、これまで以上に不可欠になっています。自社で保有・運営するロケーションサービスに移行することで、計り知れない柔軟性がもたらされ、クラウドベースのソリューションによる容量の制限が緩和され、間違いなくNPSスコアの向上につながるでしょう。

結論として

これらのサブシステムは、一般的な環境におけるコンポーネントのごく一部にすぎませんが、最も苦痛を伴う原因になりがちです。クラウド、さらにはオンプレミス環境を採用し、自社で構築（Build-it-yourself）している方々にとって、これは挑戦です。マルチベンダーの外部ホスト型SaaS製品を中心にプラットフォームを構築している方々にとっては、強化、スケール、堅牢化への挑戦には、もう少し熟考が必要かもしれません。