Facebookはどうやって80万人が同時にライブ放送を視聴することを実現したのか？

世界規模の配送サービスを提供する方法を知っている企業はほんの一握りしかなく、それは現在核兵器を保有している国の数よりもさらに少ない。 Facebook もその数少ない企業の 1 つであり、同社の新しいライブ動画ストリーミング製品である Facebook Live は、飛躍的な配信サービスの代表例です。

Facebook CEO マーク・ザッカーバーグ:

ライブストリーミングは過去5年から10年のオンラインビデオモデルとは異なる新しいモデルであるため、私たちは最終的にビデオサービスの焦点をライブストリーミングに移すことを決定しました。私たちはビデオ開発の黄金期に入ろうとしています。 5年後には、Facebook で人々が見るもののほとんどが動画になるでしょう。

Facebook Live の威力は、2 人が輪ゴムを使ってスイカに圧力をかけ、最終的に爆発させるという 45 分間のビデオで披露されました。この動画は80万人が視聴し、30万件以上のコメントが寄せられている。この驚くべき統計は、Facebook の 15 億人のユーザーベースに基づいています。

2015年のスーパーボウルが米国で放送された際、11億4千万人が試合を視聴し、約236万人が生中継で試合を視聴しました。 Twitch プラットフォームでは、2015 年の E3ゲームイベントの視聴者数がピーク時に 84 万人に達しました。 9月13日の共和党討論会では、ライブ視聴者数が92万1000人に達した。

現在の技術的状況では、Facebook はライブストリーミングの分野でも大きくリードしています。 Facebook では同時に多くのライブ ショーが開催されていることを無視することはできません。

Facebook のプロダクト ディレクター、クリス コックス氏:

Wired の記事では、Facebook のプロダクト ディレクターである Chris Cox 氏の発言が引用されており、Facebook にはライブ ストリーミングを担当する 100 人以上の部門がある (当初は 12 人未満だったが、現在は 150 人のエンジニアにまで成長している) とされています。

Facebook は、何百万もの同時ライブ放送を障害なく提供し、ライブ放送を視聴する何百万もの視聴者をサポートし、さまざまなデバイスとサービス プロバイダー間のスムーズな接続の問題に対処する必要があります。 「これは多くのインフラを必要とする非常に難しい技術的問題だ」とコックス氏は語った。

これらのインフラストラクチャの問題がどのように解決されるのか興味がありますか?

Facebook のコンテンツ配信ネットワークとグローバル負荷分散システムを支える超高速キャッシュ ソフトウェアの開発に携わってきた Facebook のトラフィック チームの Federico Larumbe 氏が、素晴らしい講演を行いました。彼はスピーチの中で、ライブ放送がどのように実現されたかを詳しく紹介した。このスピーチは実に素晴らしかったです。

ライブ放送技術の原点

Facebook には、ユーザーが録画したビデオをリアルタイムで共有できる新しい機能があります。ライブストリーミングサービスは2015年4月に開始され、当初はメンションアプリを通じて有名人のみが主にファンと交流するために利用できました。翌年、サービス内容が強化され、製品契約も変更されました。ライブストリーミングやハイパーテキスト転送の利用を開始し、iPhone のサポートを得て CDN 構造を利用できるようになりました。同時に、Facebook は、携帯電話からライブ ブロードキャスト サーバーにライブ ビデオやオーディオを送信できる、伝送制御プロトコルに基づくリアルタイム メッセージング プロトコル (RTMP) の研究を開始しました。

利点: RTMP はストリーマーと視聴者にとってリスクが低くなります。従来の放送方法とは異なり、ライブ放送プラットフォーム上で人々は互いにコミュニケーションをとることができます。リスクとレイテンシが低いため、ユーザー エクスペリエンスが向上します。

デメリット:元のデバイスは HTTP に基づいていないため、まったく新しい構造が必要になります。新しいリアルタイム メッセージング プロトコルが開発され、規模が拡大するには時間がかかります。

FacebookはMPEG-DAH（HTTP経由のダイナミックアダプティブストリーミング）にも取り組んでいる。

利点:ストリーミングと比較して、15% のスペースを節約できます。

デメリット:ビットレート要件がより柔軟です。エンコード品質はネットワークスループットによって異なります。

ライブビデオは多様であり、疑問が湧く

ライブストリーミングでは、スイカのようなトラフィックパターンが発生します。開始後、トラフィックが急激に増加します。数分後には、1秒あたり100件を超えるリクエストが発生し、ライブストリーミングの終了まで増加し続け、その後トラフィックが急激に減少します。つまり、トラフィックの変化は非常に劇的です。

ライブ ストリーミングは、非常に極端なトラフィック パターンを生成するという点で、一般的なビデオ プログラムとは異なります。ライブ放送はより多くの注目を集め、通常、通常の動画よりも 3 倍多くの人が視聴します。ニュースフィードで上位にランクされたライブ放送は通常、視聴者が多く、ライブ放送に関する通知が各ページのすべてのファンに送信されるため、より多くの人がビデオを視聴します。 ただし、トラフィックが多すぎると、キャッシュ システムやグローバル負荷分散システムに問題が発生する可能性があります。

キャッシュの問題

多くの人が同時にライブビデオを視聴したい場合があります。これは典型的な「群れをなして大群が集まる問題」です。極端なトラフィック パターンはキャッシュ システムに大きな負担をかけます。ビデオは秒単位のファイルに分割されており、極端なトラフィックが発生すると、これらのファイルをキャッシュするサーバーが過負荷になります。

グローバル負荷分散の問題

Facebook は世界中に拠点を持ち、そのトラフィックは世界中のさまざまな国に分散しています。したがって、Facebook が解決しなければならない問題は、アクセス ポイントが過負荷になるのをいかに防ぐかということです。

全体的なアーキテクチャ

ライブコンテンツはどのようにして何百万人もの視聴者に配信されるのでしょうか? アンカーが視聴者の携帯電話でライブビデオ放送を開始します。携帯電話は RTMP ストリーミング ビデオをライブ ブロードキャスト サーバーに送信します。サーバーはビデオをデコードし、複数のビットレートに変換します。次に、各ビット レートに対して 1 秒の MPEG-DASH セグメントのセットが生成されます。これらのフラグメントはデータ キャッシュ処理センターに保存され、その後、ネットワーク ポイント オブ プレゼンスのキャッシュ ハード ディスクに送信されます。視聴者は、デバイス内のプレーヤーが POP キャッシュから 1 秒あたり 1 つの速度でクリップを抽出し、ライブ ブロードキャストを受信できます。

どのように機能しますか?

データ キャッシュ センターと多数のポイント オブ プレゼンスにあるキャッシュの間には乗法的な関係があります。ユーザーはデータ センターではなくポイント キャッシュにアクセスし、これらのポイント キャッシュは世界中に分散されています。

プレゼンスポイント内では、別の乗算関係が発生します。プレゼンス ポイントには、プロキシ サーバー レベルとキャッシュ レベルの 2 つのレベルがあります。視聴者はプロキシ サーバーからクリップを取得するための要求を送信します。サーバーは、フラグメントがキャッシュ内に存在するかどうかを確認します。存在する場合はクリップが視聴者に送信され、存在しない場合はリクエストがデータ センターに送信されます。異なるフラグメントは異なるキャッシュ ハード ディスクに保存されるため、異なるキャッシュ ホスト間で負荷分散を実現できます。

雷鳴のような群集効果からデータセンターを保護する

すべての視聴者が同時に同じクリップをリクエストするとどうなりますか? クリップがキャッシュにない場合、各視聴者のリクエストはデータ センターに送信されるため、データ センターを保護する必要があります。

プルリクエスト

リクエストをポイントオブプレゼンス キャッシュに統合することで、リクエストの数が削減されます。最初に行われたリクエストのみがデータ センターに送信されます。最初のリクエストが応答されるまで他のリクエストは処理されず、その後データが各ビューアーに送信されます。ホット サーバーの問題を防ぐために、プロキシ サーバーにキャッシュ レイヤーが追加されました。関連するすべてのリクエストがキャッシュ ホストに送信され、フラグメントが返送されるのを待機すると、ホストに過負荷がかかる可能性があります。

グローバル負荷分散ソリューション

データ センターは大規模な侵入から十分に保護されていますが、侵入ポイントには依然としてリスクが存在します。ライブ ストリーミング トラフィックが非常に大きい場合、プレゼンス ポイントでの負荷検出がバランスに達する前に過負荷になる可能性があります。

各プレゼンス ポイントには、限られたサーバーと接続があります。アクセス ポイントの過負荷を防ぐにはどうすればよいのでしょうか? Cartographer マップと呼ばれるシステムは、この問題をうまく解決できます。各ネットワークとプレゼンスポイントのレイテンシ、つまりレイテンシ測定を測定します。各ユーザーは最も近い POP に送信され、各 POP の負荷を測定できます。 サーバーには、受けている負荷の量を測定するためのカウンターがあります。これらのカウンターのデータを組み合わせることで、各アクセス ポイントの負荷を知ることができます。

容量制約とリスク削減を伴う最適化問題

制御システムのため、測定と動作に遅延が生じます。負荷測定ウィンドウを 90 秒から 3 秒に変更しました。この問題の解決策は、負荷が発生する前にそれを予測することです。以前の負荷と現在の負荷に基づいて各ポイント オブ プレゼンスの将来の負荷を推測するための容量推定機能が組み込まれています。

推定値はどのように負荷を予測しますか? 現在の負荷が増加した場合、減少する可能性はありますか?

3 次スプライン関数は、線形補間関数よりも複雑な交通パターンを予測できます。3 次スプライン関数を使用して補間関数を解き、最初に 1 次導関数と 2 次導関数を取得します。速度が正の場合、負荷は上昇しています。加速度が負の場合、速度が低下し、最終的にはゼロになることを意味します。

ショックを避ける

補間関数は振動の問題を解決することもできます。

測定と対応の遅れはデータが古いために発生しますが、補間機能を使用するとエラーを減らし、より正確な予測を行い、振動を減らすことができます。この方法により、負荷は容量目標に近づきます。現在の予測は、ほぼ瞬時に過負荷となった過去 3 回の 30 秒間隔に基づいています。