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

GREE Tech Conference 2020 で発表された資料です。
https://techcon.gree.jp/2020/session/Session-11

Transcript

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 おわりに