REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン
•
0 gefällt mir•2,945 views
GREE Tech Conference 2020 で発表された資料です。 https://techcon.gree.jp/2020/session/Session-11
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン
Ähnlich wie REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン (20)
Mehr von gree_tech
Mehr von gree_tech (20)
REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン
- 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とは？
- 6. 6 低遅延モード配信のフォーマット • REALITYの現行のメイン配信方式 • 配信・視聴ユーザーがそれぞれWebSocketサーバへ接続 • WebSocketサーバを通してデータを送受信する • 配信データの中身はモーション・音声などのデータをProtobuf形式 でシリアライズしたもの
- 7. 7 解決すべき問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存して おく必要がある • 配信音声やラベル付き配信データなどのフォーマット
- 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のパ ターンでは配信・視聴の負荷に耐えきれなくなる
- 13. 13 課題 Redis Pub/Subがボトルネックになる ○ スケールアウトができない ○ スケールアップができない ○ クラスタ化しても無意味 スケーラビリティに限界がある
- 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程度 • パトロール・監査のため、配信データを参照可能な方式で保 存しておく必要がある • 配信音声やラベル付き配信データなどのフォーマット
- 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との連携 のメリットが非常に大きい
- 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 おわりに