Facebookのライブ配信構築の課題

Facebook Liveが始まったのは2年前のハッカソンで、その8ヶ月後にユーザーに披露された。難しかったのが一つのストリーミング配信に対する予測できない視聴者数への対処であり、この数は広くバラついている。Sachin Kulkarni氏はQCon Londonでのプレゼンで、acebook live開発の設計上のチャレンジについて語った。

このサービスのインフラを高い視点から見ると、まず、ストリームはクライアントがもっとも近いPoP(Point of Presence)に接続するところから始まる。PoPはその接続をエンコーディングがされている完全なデータセンターにフォワードする。そして、ストリームはデータセンターから異なるPOPへフォワードされ、クライアントに再生される。Facebookの動画インフラ部門のディレクターであるKulkarni氏によれば、PoPの責務は、クライアントからのコネクションをキャッシュし終端となり、それを、Facebookの自前のネットワークを経由してデータセンターへ渡すことだ。この自前のネットワークはより信頼でき、ラウンドトリップが少ない。

スケールの難点について、Kulkarni氏は、同時に接続するユニークなストリームの数と全てのストリームの視聴者の数は予測可能であるため、限定的な問題にすぎない、と言う。本当の問題は一つのストリームの視聴者数だ。本当に少数の場合もあれば、かなり大規模な数の場合もある。これは予測できないため、計画が立たない。彼らはキャッシュとストリームの分散でこの問題を対処した。

普通の動画と比べ、ライブ配信には次のような難点がある。

• キャッシュが作れない。コンテンツがリアルタイムで作成されるので。
• 生のイベントとリソースのスケールを事前に計画するのは不確実。
• 世界で起きるイベントが誘発するうストリーム/視聴者の急増を予測するのは難しい。

信頼性に関するライブ配信の課題の一つがネットワークの問題だ。この問題に対処するため、Kulkarni氏は3つの解決策を提案する。

• アダプティブ・ビットレートを使って低帯域に適応する。これは画質の低下を招くが、一般的には再生側で利用される方法だ。しかし、Facebookでは動画の採取側でも使っている。
• 一時的な接続断はクライアント側の一時バッファでしのぐ。
• 帯域が十分でない時の最悪のシナリオでは、音声のみの再生と配信に切り替える。見えることより聞こえることの方が重要だ。

このプロジェクトで氏は次のことを学んだ。

• 大規模なサービスは小さな一歩から生まれる。永遠に設計の議論をするよりコードを書くことが重要だ。
• 計画停止、不慮の停止に対する設計を含む、信頼性と拡張性は設計に盛り込まなければならない。
• 大規模なプロジェクトをリリースするために妥協する。
• 将来の機能のために設計を柔軟にしておくこと。これによってチームはインフラが変更可能になる前に素早く動ける。