lasciva blog

開発して得た知見やwebビジネスのストック

Facebookのライブビデオのスケーリング

海外 アーキテクチャ

最近、海外のサービスのスケーリングに関して色々勉強をしていて、面白かったのでまとめた。
動画系のバックエンドがあまり担当したことないので興味があった。動画配信と言っても、一度保存された動画を配信するのと、ライブ配信とでは考慮すべきことが異なっていて面白かった。

Scaling Facebook Live Videos to a Billion Users

www.youtube.com

2017年の発表

サービスの概要

12.3億DAU

ライブ配信と動画の違い

  • リアルタイムに即座に視聴者が見れるようにしないといけないこと
  • コミュニケーションを取れるソーシャル性

History

  • 2015年4月: ハッカソン（業務とは関係ないものを開発できる）
  • 2015年8月: Celebrityが配信できるように開放
  • 2015年12月: 全ユーザ向けにリリース

なぜライブか？

  • エンゲージメントが高い
  • 公開されたプロフィール
  • 世界をつなげる（現地の災害の人など、他のメディアでは共有できないようなコンテンツ）

ライブストリーミングインフラ

1. High Level Architecture

ライブストリーミング

f:id:hacking15dog:20200613011430p:plain

配信者はRTMPS(Real Time Messaging Protocol Secure)を使って、POP(Point Of Presence)に接続。

POPはデータセンターに接続し、データセンターはエンコーディングを行う。

データセンターはCDNや他のPOPに配信し、それ経由で視聴者に届く。

リソースの種類
  • コンピューティング
  • メモリ: ストリームのエンコード、デコード
  • ストレージ: 長期保存
  • ネットワーク: アップロードと視聴

2. Scaling Challenges

  1. 同時配信数
    • 夕方にピークが来るなど予測できる
    • Ingest Protocol, ネットワークキャパシティ、サーバのエンコーディングリソース
  2. 全ストリームの視聴者数
    • こちらも規則性があり、予測できる
    • Delivery protocol, ネットワークキャパシティ、効率的なキャッシュ
  3. 単一ストリームの最大視聴者数
    • 予想が難しい
    • キャッシュ、ストリームの分散

Facebookのライブビデオはどのように異なるか

  • 事前のキャッシュがトリッキー
  • 視聴者数の予測が困難
  • ライブイベントの計画と事前にリソースをスケールさせるのが問題
  • 世界的なイベントによる同時配信のスパイクの予測が難しい

3. Protocol

ブロードキャストプロトコルに必要なこと
  • 開発のかかる時間: リリースまで4〜8ヶ月しかない
  • ネットワークの互換性: Facebookのインフラだけでは完結しない
  • E2Eのレイテンシー: 大きいとインタラクティブなコミュニケーションが取れない
  • アプリケーションの大きさ: Facebookのアプリに搭載するので大きくはできない

f:id:hacking15dog:20200613011448p:plain

エンコーディングのプロパティ
  • アスペクト比: 1:1
  • 解像度: 400x400, 720x720 (ネットワークが十分に発達していない地域も考慮)
  • AUDIO CODEC: AAC 64KBIT
  • VIDEO CODEC: H264 500KBIT 1MBIT

4. Stream Ingestion and Processing

POPのメリットは、POPやデータセンターのネットワークが安定して速いことと、キャッシュ。

f:id:hacking15dog:20200613011507p:plain

POPは2種類のホストからなる

  • Proxygen Hosts: 配信者とのコネクションを維持し、適切なDCにデータを送る
  • BigCache Hosts: キャッシュ

データセンターは上の2つにEncodingを加えた3種類のホストからなる。配信者がネットワークを切り替えて新しいコネクションを開始しても、Encodingのホストが変わらないようにするために、ProxygenとEncodingのマッピングは重要。

Encoding Hostの役割
  • ストリームの認証
  • ストリームとホストを結びつける
  • エンコーディングの生成
  • プレイバック用の出力の生成
  • ビデオ用に保存

5. Playback: HTTP streaming (MPEG-DASH)

DASHはHTTP上のストリームプロトコル。

マニフェストの取得のフロー

クライアントがPOPにアクセスする。POPはキャッシュがあればそれを返し、なければデータセンターにアクセスする。データセンターはキャッシュがあればそれを返し、なければEncodingホストから取得してキャッシュホストに保存して、POPに返す。POPはキャッシュに保存して、クライアントに返す。

キャッシュをPOPとデータセンターを2段階に分けることで、低いコストでスケールでき、必要に応じて別々にスケールアウトできる。データセンターへのアクセス数はPOPの数と同じになる。

6. Reliability Challenges

ネットワークの問題

配信者とPOPとの間にネットワークの問題が発生すると、どうしようもない。

  • Adaptive Bit Rateで配信者と通信できるようにすることで、ネットワークが悪くなっても継続できるようにする。
  • バッファーを利用して、一時的な切断をハンドリングする
  • 音声のみ

7. New Features

  • 複数の配信者が同時に画面に登場できる: 会話がスムーズに成立するように数十ms程度のレイテンシーにしなければならない
  • ビデオタブ(一覧から探せる): 複数のストリームを扱わなければならない
  • デバイスキャスティング: apple TVなどのプラットフォームに対応
  • 360度

8. Lessons Learned

  • 大きなサービスは小さな出発点から成長できる
  • ネットワーク環境にサービスを適応させる
  • リライアビリティとスケーラビリティは設計に食い込み、後からは追加できない
  • ホットスポットと大規模なトラフィックは複数のコンポーネントで起こりうる
  • 計画されるものとされないサービスダウンに備えて設計する
  • 大きいプロジェクトを届けるためには、妥協もする
  • 将来の機能のために、柔軟性のあるアーキテクチャを保つ

Q&A

  • ポルノ対策は？ - システムと人力でモニタリングしているが、難しい問題

Scaling Facebook Live

atscaleconference.com

テスト方法

  • ロードテストサービスを構築
  • 視聴者がグローバルになるように
  • 本番環境の10倍の負荷

E2Eレイテンシーの調整

Push vs Pull

Pullモデルの場合、POPがデータセンターからキャッシュを取得した際に生じる時差がPullしたタイミングによって、レイテンシーが大きくなってしまう可能性がある。さらに、POP間でのレイテンシーの差も大きくなりやすい。

Pushモデルの場合、レイテンシーが小さく抑えることができ、POP間の差も小さくできる。