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

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

3. 3
REALITYとは？

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

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

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

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

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

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

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

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

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

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

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

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

16. 16
REALITYの構成

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

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

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

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

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

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

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

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

25. 25
ライブ配信データパイプライン - 構成
Cloud
Pub/Sub
Archiver
Cloud Dataflow
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処理で集計・
加工して保存

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

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

28. 28
Apache Beam??

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

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

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

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

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

34. 34
結果

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

36. 36
おわりに