REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン

by gree_tech

Slide 1

Slide 1 text

REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン株式会社 Wright Flyer Live Entertainment　増住啓吾

Slide 2

Slide 2 text

2 自己紹介増住啓吾株式会社Wright Flyer Live Entertainment - 2017年にGlossom株式会社に入社 - iOS/Android向けアプリの開発やデータ分析基盤の構築、広告ログ集計システムの開発・運用などを担当 - グループ内公募制度を利用し、2019年に株式会社 Wright Flyer Live Entertainmentにジョイン - Kubernates・Apache Beamなどを用いた REALITYプラットフォームのライブ配信基盤の開発を担当

Slide 3

Slide 3 text

3 REALITYとは？

Slide 4

Slide 4 text

4 2020/01/08 REALITY低遅延モードリリース

Slide 5

Slide 5 text

5 ラグなし、ギガ安、高画質

Slide 6

Slide 6 text

6 低遅延モード配信のフォーマット • REALITYの現行のメイン配信方式 • 配信・視聴ユーザーがそれぞれWebSocketサーバへ接続 • WebSocketサーバを通してデータを送受信する • 配信データの中身はモーション・音声などのデータをProtobuf形式でシリアライズしたもの

Slide 7

Slide 7 text

7 解決すべき問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存しておく必要がある • 配信音声やラベル付き配信データなどのフォーマット

Slide 8

Slide 8 text

8 ライブ配信・視聴サーバ

Slide 9

Slide 9 text

9 全体像 Kubernetes Android iOS Ingress HTTPS Streamer Kubernetes Engine Redis (StatefulSet) Kubernetes Engine Listener Kubernetes Engine Cloud Pub/Sub Archiver Cloud Dataﬂow Archive Cloud Storage Stats BigQuery

Slide 10

Slide 10 text

10 解決すべき問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存しておく必要がある • 配信音声やラベル付き配信データなどのフォーマット

Slide 11

Slide 11 text

11 ライブ配信 / 視聴サーバ - 課題 ● WebSocketサーバ ( Node.js ) を通して配信データの送受信を行う ● WebSocketサーバの冗長化はRedis Pub/Subを用いる ● ただし、一般的なWebSocket + Redis Pub/Subのパターンでは配信・視聴の負荷に耐えきれなくなる

Slide 12

Slide 12 text

12 WebSocketサーバの負荷分散方式 (1)

Slide 13

Slide 13 text

13 課題 Redis Pub/Subがボトルネックになる ○ スケールアウトができない ○ スケールアップができない ○ クラスタ化しても無意味スケーラビリティに限界がある

Slide 14

Slide 14 text

14 WebSocketサーバの負荷分散方式 (2)

Slide 15

Slide 15 text

15 課題 1.エンドポイントレベルのシャーディング 2.WebSocketサーバ * N + Redis * 1 の単位でスケール運用コストが高い

Slide 16

Slide 16 text

16 REALITYの構成

Slide 17

Slide 17 text

17 2.配信側サーバは全ての Redisインスタンスに対して分散してデータを Publishする 3.視聴側サーバは全ての Redisインスタンスに対し必要なRedis Pub/Sub ChannelをSubscribeし、来たデータを視聴者へbroadcast Redisをスケールアウト可能 1.Redis (Pub/Sub専用) をスタンドアロンでN基立ち上げる

Slide 18

Slide 18 text

18 1.Redisはk8sのStatefulSet + Headless Serviceとして立ち上げる 2.各WebSocketサーバはk8sのサービスディスカバリでRedisの各hostを認識・接続運用コストが低い 3.各WebSocketサーバやRedisは単一のk8sワークロードとなるため、 k8sのスケーリングの仕組みをそのまま活用できる

Slide 19

Slide 19 text

19 ライブ配信 / 視聴サーバ - 構成 ● k8sのサービスディスカバリを利用したRedisのスケーリング ● Redisはk8sのStatefulSet + Headless Serviceを利用 => kube-proxyを通らないのでパフォーマンスも落ちない ● Redisのスケールアウトが可能なので、構成全体のスケーラビリティを担保できる ● k8sのオートスケーリングの仕組みに乗ったスケーリングが可能なので運用工数も低い

Slide 20

Slide 20 text

20 ライブ配信 / 視聴サーバ - まとめ • 当該方式の配信・視聴サーバのリリース後７ヶ月経過 • 同時配信数・視聴者数ともに右肩上がりだが、障害なしで安定して動作 • 基本的にはk8sのオートスケーリングに任せられるので、運用コストも非常に低い • Redis Pub/Subによる遅延は、アプリ - 配信・視聴サーバ間の通信に比べて無視できる程度で安定

Slide 21

Slide 21 text

21 ライブ配信 / 視聴サーバ - その他 • シンプルな構成なので横展開が楽 • 事例1: コラボ配信サーバ • 「アバタービデオチャット」的な機能を提供するコンポーネント • ボイスチャット用の音声のミキシングも行う • 事例2: ゲーム配信サーバ • ゲームサーバ + ゲーム配信の視聴サーバの機能を提供する

Slide 22

Slide 22 text

22 解決すべき問題点 (再掲) • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存しておく必要がある • 配信音声やラベル付き配信データなどのフォーマット

Slide 23

Slide 23 text

23 ライブ配信データパイプライン

Slide 24

Slide 24 text

24 ライブ配信データパイプライン - 構成 Cloud Pub/Sub Archiver Cloud Dataﬂow Archive Cloud Storage Stats BigQuery Kubernetes Streamer Kubernetes Engine Ingress HTTPS Redis (StatefulSet) Kubernetes Engine Listener Kubernetes Engine

Slide 25

Slide 25 text

25 ライブ配信データパイプライン - 構成 Cloud Pub/Sub Archiver Cloud Dataﬂow Archive Cloud Storage Stats BigQuery Kubernetes Streamer Kubernetes Engine Ingress HTTPS Redis (StatefulSet) Kubernetes Engine Listener Kubernetes Engine 1.配信データをCloud Pub/Sub TopicへPublish 2.Cloud Dataflow Jobが Cloud Pub/Sub Subscription 経由で配信データを読み出す 3.配信データを Streaming処理で集計・加工して保存

Slide 26

Slide 26 text

26 ライブ配信データパイプライン - 概要 ● 配信サーバはCloud Pub/Sub Topicへラベル付き配信データをPublish ● Cloud DataFlow Job ( Apache Beam Java ) がCloud Pub/Sub Subscription経由でデータを読み出す ● 読み出した配信データをApache Beam Pipelineで処理 ● ラベル付き配信データ、監査用音声アーカイブファイル、分析用統計情報などを生成 ● 生成したデータをCloud Storageへ書き込む

Slide 27

Slide 27 text

27 ライブ配信データパイプライン - インフラ ● Cloud DataFlow Streaming Engineを使用 ● Streaming処理とオートスケーリングを両立 ● Worker Machineの分だけ自動でスケールしていく ● キャパシティプランニングもほぼ不要 ● deployもJavaのビルドだけで完結するので楽

Slide 28

Slide 28 text

28 Apache Beam??

Slide 29

Slide 29 text

29 ライブ配信データパイプライン - Apache Beam ● バッチ・ストリーミング処理を統合して実行できる分散処理フレームワーク ● REALITYではApache Beam Javaを使用 ● 基本的にはJavaアプリケーションなのでできることの範囲が広い ● 当然JNIも使えるのでネイティブコードも利用可能 ● その上でさらに分散処理のメリットを享受できる ● Apache Sparkなどと比較すると、Cloud DataFlowとの連携のメリットが非常に大きい

Slide 30

Slide 30 text

30 ライブ配信データパイプライン - 処理グラフ

Slide 31

Slide 31 text

31 ライブ配信データパイプライン - データ保存 ● Streaming Pipelineにラベル付き配信データが流れてくる ● 取り出したデータを10秒単位でWindow化 ● データをPOJOに変換 ● データとそのタイムスタンプから、1時間ごとのディレクトリに分割した一意なファイルパスを生成 ● 生成したファイルパスへデータをAvro フォーマットで書き出す

Slide 32

Slide 32 text

32 ライブ配信データパイプライン - 音声アーカイブ ● Streaming Pipelineにラベル付き配信データが流れてくる ● データを配信ごとにグルーピングし、時系列に並びかえ音声データ (Opus圧縮) を抽出 ● その音声データをOggコンテナに格納する ● 生成したOggコンテナをバイナリファイルとして配信IDごとの時系列順にCloud Storageに書き出す

Slide 33

Slide 33 text

33 ライブ配信データパイプライン - まとめ • 同時配信数の増加に伴い比例して処理データ量も増えていったが、全て Cloud Dataflow側で吸収してくれるので特に追加のオペレーションの必要はなかった • データロストの発生もなし • サーバ費用の面では当然それなりのコストは発生するものの、想定通りにおさまる

Slide 34

Slide 34 text

34 結果

Slide 35

Slide 35 text

35 解決された問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存しておく必要がある • 配信音声やラベル付き配信データなどのフォーマット

Slide 36

Slide 36 text

36 おわりに