Facebook Liveにおける世界規模のイベントによるトラフィックスパイクの処理

Facebook Liveのエンジニアたちが、予測範囲内のイベントと予想外のイベントの両方のトラフィックを処理するために、自分たちのシステムをスケールアップした方法について講演した。後者は同社のグローバル分散アーキテクチャによって処理されるのに対して、前者は事前の周到な計画と負荷テストを必要とする。

FacebookのLive機能は、ビデオなどのメディアをリアルタイムで共有可能にするもので、世界的なイベントに対して多く利用されている。このようなスケールをサポートするために必要なアーキテクチャには、過去の講演で紹介されてきたような特殊な要件がある。最新の記事ではPeter Knowles氏が、大晦日のライブ機能に関する計画と負荷テストについて紹介する。まず最初に重要な領域 — ネットワーク、CPU、ストレージ — を明らかにした上で、戦略の一部としてシャドウトラフィック生成を採用した負荷予測と負荷テストについて説明している。

スケーリングの必要性は、サイトのセクションによってまちまちだ。例えば、大統領就任式のためのライブアップデートフィードのスケールアップでは、キャッシュとダークローンチが使用された。しかしFacebook Liveではキャッシュのプリロードが使えない(ライブなので)ため、スケーリングの視点はおのずと異なってくる。視聴者数を予測したり、それを基に必要なリソースを事前計算したりすることは容易ではないのだ。世界規模のイベントでは、同時ストリーム数や視聴者数を正確に予測することも不可能だ。

スポーツや選挙、自然災害、ソーシャルメディア現象など世界規模のイベントは、トラフィックのスパイクを引き起こす可能性がある。帯域幅を必要とするライブビデオでは特にそれが顕著だ。利用パターンの変化による負荷の変化には３つのパターンがある — ルーチン、自然発生(spontaneous)、計画的、である。ルーチンパターンは予測可能である — 週末には低下する、というような既知のモデルに従う — ため、対処方法はインフラストラクチャに前もって組み込まれている。予想外の世界的イベントや災害といった自然発生的なトラフィックには、管理が難しい部分がある。また、大晦日のように事前に分かっているイベントには、特別な計画が必要だ。

Facebookのライブビデオストリーミングアーキテクチャは、世界各地にある同社データセンタへのPoP(Points-of-Presence/PoP)にまでクライアントアプリの範囲を広げている。クライアントアプリがビデオストリームを生成し、RTMPS(セキュアソケット上のストリーミングメディアプロトコル)を介して最寄りのエッジPoPにそれを送信する。PoPへの送信は、クライアントデバイスに可能な限り近いストリームを終端する。各PoPがそのインプットをデータセンタに送信すると、それがFacebook Liveセンタで処理される。Facebookのデータセンタは世界中に広がっており、このアーキテクチャもFacebookの他のサービスと共有している。データセンタ内では、サービス間のすべての通信はFacebookのバックボーンネットワークを経由して行われており、今回の講演によれば、そのRTT(Round Trip Time)は30ms以内である。PoPはコンテンツが生成されると同時にそれをキャッシュして、以降の要求に対するデータセンタへの通信を回避している。

Facebook Liveサーバのビデオストリームは複数のオーディオビデオ形式にトランスコードされた上で、FacebookのCDN経由で配信される。ビデオストリームの処理は、パイプライン中のCPU集約的な部分である。変換された各形式は、以後の要求に備えて保持される。

イメージ提供 : https://www.facebook.com/atscaleevents/videos/1682898791983218/スライド

大晦日のようなイベントに対する計画には、過去情報を基にした負荷予測や負荷テストが含まれている。負荷予測ではブロードキャストの総数、同時ブロードキャスト数のピーク値、Facebook Liveシステム上の負荷の結果として他システムで発生する負荷などが考慮される。計画には生産エンジニアリング、キャパシティプランニング、データサイエンスなど、複数のチームが協力する。対応策としてまず考えられるのは、ハードウェアの増強であろう。プロセスをより効率的にするという方法もある — ただし記事では、メディアセグメントをより長いものにまとめることで、書き込みをより効率にするという一例を紹介するに留めておく。着信トラフィックを複製するシャドウトラフィック生成(shadow traffic generation)と呼ばれるテクニックで、個々のホストやクラスタに負荷を与えることであらゆる側面をテストする。ただしこれは新しいテクニックではなく、他でも使用されているものだ。

スケーリングに共通して問題になるのは、大量の要求がひとつのイベントを待機している場合に、処理可能なのは一度にひとつのみで、他はすべて待機せざるを得ないということだ。これはThunder Herd問題と呼ばれるもので、イベントが発生する度に待機中のすべての処理が起動するため、不要なスラッシングが発生する。Facebook Liveの例では、キャッシュ上になく、バックエンドのデータセンタから取得しなければならないビデオ要求が単一PoPに多数集中した場合に、この現象が発生する。Liveのアーキテクチャでは、要求を結合(request coalescing)してデータセンタにヒットする要求数を削減することで、この問題に対処している。PoPにヒットした同じビデオセグメントに対するすべてのクライアント要求に対して、そのセグメントがキャッシュに存在しなかった場合、データセンタに送信する要求は高々ひとつで、その他の要求は応答が返るまで保管される。これによって、ストレージバックエンドにヒットしてリソース消費する複数の要求によって、データセンタがあふれ返る事態を回避することが可能になる。PoPがエンドユーザによるトラフィックの矢面に立つ状況には変わりないが、これは世界規模のロードバランサが処理してくれる。Cartographerと呼ばれるシステムが各PoPの負荷を監視し、それに従ってユーザを処理能力のある最も近いPoPに転送するのだ。

Facebookでは数日前のものを含めて、サイトのさまざまな部分で過去に何度となく、サービス停止を経験している。