Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

More Related Content

More from gree_tech

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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

  1. 1. REALITY低遅延モード配信を支える リアルタイムサーバと データパイプライン 株式会社 Wright Flyer Live Entertainment  増住 啓吾
  2. 2. 2 自己紹介 増住 啓吾 株式会社Wright Flyer Live Entertainment - 2017年にGlossom株式会社に入社 - iOS/Android向けアプリの開発やデータ分析基盤 の構築、広告ログ集計システムの開発・運用などを 担当 - グループ内公募制度を利用し、2019年に株式会社 Wright Flyer Live Entertainmentにジョイン - Kubernates・Apache Beamなどを用いた REALITYプラットフォームのライブ配信基盤の開発 を担当
  3. 3. 3 REALITYとは?
  4. 4. 4 2020/01/08 REALITY低遅延モードリリース
  5. 5. 5 ラグなし、ギガ安、高画質
  6. 6. 6 低遅延モード配信のフォーマット • REALITYの現行のメイン配信方式 • 配信・視聴ユーザーがそれぞれWebSocketサーバへ接続 • WebSocketサーバを通してデータを送受信する • 配信データの中身はモーション・音声などのデータをProtobuf形式 でシリアライズしたもの
  7. 7. 7 解決すべき問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存して おく必要がある • 配信音声やラベル付き配信データなどのフォーマット
  8. 8. 8 ライブ配信・視聴サーバ
  9. 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. 10 解決すべき問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存して おく必要がある • 配信音声やラベル付き配信データなどのフォーマット
  11. 11. 11 ライブ配信 / 視聴サーバ - 課題 ● WebSocketサーバ ( Node.js ) を通して配信データの送 受信を行う ● WebSocketサーバの冗長化はRedis Pub/Subを用いる ● ただし、一般的なWebSocket + Redis Pub/Subのパ ターンでは配信・視聴の負荷に耐えきれなくなる
  12. 12. 12 WebSocketサーバの負荷分散方式 (1)
  13. 13. 13 課題 Redis Pub/Subがボトルネックになる ○ スケールアウトができない ○ スケールアップができない ○ クラスタ化しても無意味 スケーラビリティに限界がある
  14. 14. 14 WebSocketサーバの負荷分散方式 (2)
  15. 15. 15 課題 1.エンドポイントレベルのシャー ディング 2.WebSocketサーバ * N + Redis * 1 の単位でスケール 運用コストが高い
  16. 16. 16 REALITYの構成
  17. 17. 17 2.配信側サーバは全ての Redisインスタ ンスに対して分散してデータを Publishす る 3.視聴側サーバは全ての Redisインスタ ンスに対し必要なRedis Pub/Sub ChannelをSubscribeし、来たデータを視 聴者へbroadcast Redisをスケールアウト可能 1.Redis (Pub/Sub専用) をスタンドアロ ンでN基立ち上げる
  18. 18. 18 1.Redisはk8sのStatefulSet + Headless Serviceとして立ち上げる 2.各WebSocketサーバはk8sのサービ スディスカバリでRedisの各hostを認識・ 接続 運用コストが低い 3.各WebSocketサーバやRedisは単一 のk8sワークロードとなるため、 k8sのス ケーリングの仕組みをそのまま活用でき る
  19. 19. 19 ライブ配信 / 視聴サーバ - 構成 ● k8sのサービスディスカバリを利用したRedisのスケーリング ● Redisはk8sのStatefulSet + Headless Serviceを利用 => kube-proxyを通らないのでパフォーマンスも落ちない ● Redisのスケールアウトが可能なので、構成全体のスケーラ ビリティを担保できる ● k8sのオートスケーリングの仕組みに乗ったスケーリングが 可能なので運用工数も低い
  20. 20. 20 ライブ配信 / 視聴サーバ - まとめ • 当該方式の配信・視聴サーバのリリース後7ヶ月経過 • 同時配信数・視聴者数ともに右肩上がりだが、障害なしで安定して動 作 • 基本的にはk8sのオートスケーリングに任せられるので、運用コストも 非常に低い • Redis Pub/Subによる遅延は、アプリ - 配信・視聴サーバ間の通信 に比べて無視できる程度で安定
  21. 21. 21 ライブ配信 / 視聴サーバ - その他 • シンプルな構成なので横展開が楽 • 事例1: コラボ配信サーバ • 「アバタービデオチャット」的な機能を提供するコンポーネント • ボイスチャット用の音声のミキシングも行う • 事例2: ゲーム配信サーバ • ゲームサーバ + ゲーム配信の視聴サーバの機能を提供する
  22. 22. 22 解決すべき問題点 (再掲) • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保 存しておく必要がある • 配信音声やラベル付き配信データなどのフォーマット
  23. 23. 23 ライブ配信データパイプライン
  24. 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. 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. 26 ライブ配信データパイプライン - 概要 ● 配信サーバはCloud Pub/Sub Topicへラベル付き配信データ をPublish ● Cloud DataFlow Job ( Apache Beam Java ) がCloud Pub/Sub Subscription経由でデータを読み出す ● 読み出した配信データをApache Beam Pipelineで処理 ● ラベル付き配信データ、監査用音声アーカイブファイル、分 析用統計情報などを生成 ● 生成したデータをCloud Storageへ書き込む
  27. 27. 27 ライブ配信データパイプライン - インフラ ● Cloud DataFlow Streaming Engineを使用 ● Streaming処理とオートスケーリングを両立 ● Worker Machineの分だけ自動でスケールしていく ● キャパシティプランニングもほぼ不要 ● deployもJavaのビルドだけで完結するので楽
  28. 28. 28 Apache Beam??
  29. 29. 29 ライブ配信データパイプライン - Apache Beam ● バッチ・ストリーミング処理を統合して実行できる分散処理 フレームワーク ● REALITYではApache Beam Javaを使用 ● 基本的にはJavaアプリケーションなのでできることの範囲が 広い ● 当然JNIも使えるのでネイティブコードも利用可能 ● その上でさらに分散処理のメリットを享受できる ● Apache Sparkなどと比較すると、Cloud DataFlowとの連携 のメリットが非常に大きい
  30. 30. 30 ライブ配信データパイプライン - 処理グラフ
  31. 31. 31 ライブ配信データパイプライン - データ保存 ● Streaming Pipelineにラベル付き配信デー タが流れてくる ● 取り出したデータを10秒単位でWindow化 ● データをPOJOに変換 ● データとそのタイムスタンプから、1時間 ごとのディレクトリに分割した一意なファ イルパスを生成 ● 生成したファイルパスへデータをAvro フォーマットで書き出す
  32. 32. 32 ライブ配信データパイプライン - 音声アーカイブ ● Streaming Pipelineにラベル付き配信 データが流れてくる ● データを配信ごとにグルーピング し、時系列に並びかえ音声データ (Opus圧縮) を抽出 ● その音声データをOggコンテナに格 納する ● 生成したOggコンテナをバイナリ ファイルとして配信IDごとの時系列 順にCloud Storageに書き出す
  33. 33. 33 ライブ配信データパイプライン - まとめ • 同時配信数の増加に伴い比例して処理データ量も増えていったが、全て Cloud Dataflow側で吸収してくれるので特に追加のオペレーションの必要 はなかった • データロストの発生もなし • サーバ費用の面では当然それなりのコストは発生するものの、想定通りにお さまる
  34. 34. 34 結果
  35. 35. 35 解決された問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存して おく必要がある • 配信音声やラベル付き配信データなどのフォーマット
  36. 36. 36 おわりに

×