Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン
Search
gree_tech
PRO
September 18, 2020
Technology
1
2.8k
REALITY低遅延モード配信を支えるリアルタイムサーバとデータパイプライン
GREE Tech Conference 2020 で発表された資料です。
https://techcon.gree.jp/2020/session/Session-11
gree_tech
PRO
September 18, 2020
Tweet
Share
More Decks by gree_tech
See All by gree_tech
コミュニケーションに鍵を見いだす、エンジニア1年目の経験談
gree_tech
PRO
0
120
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
1.7k
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
550
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
560
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
520
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
610
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
970
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
630
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
750
Other Decks in Technology
See All in Technology
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
4
560
AWS テクニカルサポートとエンドカスタマーの中間地点から見えるより良いサポートの活用方法
kazzpapa3
2
570
Witchcraft for Memory
pocke
1
480
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
780
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
3
1.3k
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
140
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
480
より良いプロダクトの開発を目指して - 情報を中心としたプロダクト開発 #phpcon #phpcon2025
bengo4com
1
3.1k
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
4k
A2Aのクライアントを自作する
rynsuke
1
210
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
17
5.8k
解析の定理証明実践@Lean 4
dec9ue
0
180
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
660
Scaling GitHub
holman
459
140k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Raft: Consensus for Rubyists
vanstee
140
7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Producing Creativity
orderedlist
PRO
346
40k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
800
Practical Orchestrator
shlominoach
188
11k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
KATA
mclloyd
30
14k
Transcript
REALITY低遅延モード配信を支える リアルタイムサーバと データパイプライン 株式会社 Wright Flyer Live Entertainment 増住 啓吾
2 自己紹介 増住 啓吾 株式会社Wright Flyer Live Entertainment - 2017年にGlossom株式会社に入社
- iOS/Android向けアプリの開発やデータ分析基盤 の構築、広告ログ集計システムの開発・運用などを 担当 - グループ内公募制度を利用し、2019年に株式会社 Wright Flyer Live Entertainmentにジョイン - Kubernates・Apache Beamなどを用いた REALITYプラットフォームのライブ配信基盤の開発 を担当
3 REALITYとは?
4 2020/01/08 REALITY低遅延モードリリース
5 ラグなし、ギガ安、高画質
6 低遅延モード配信のフォーマット • REALITYの現行のメイン配信方式 • 配信・視聴ユーザーがそれぞれWebSocketサーバへ接続 • WebSocketサーバを通してデータを送受信する • 配信データの中身はモーション・音声などのデータをProtobuf形式
でシリアライズしたもの
7 解決すべき問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存して
おく必要がある • 配信音声やラベル付き配信データなどのフォーマット
8 ライブ配信・視聴サーバ
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 解決すべき問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存して
おく必要がある • 配信音声やラベル付き配信データなどのフォーマット
11 ライブ配信 / 視聴サーバ - 課題 • WebSocketサーバ ( Node.js
) を通して配信データの送 受信を行う • WebSocketサーバの冗長化はRedis Pub/Subを用いる • ただし、一般的なWebSocket + Redis Pub/Subのパ ターンでは配信・視聴の負荷に耐えきれなくなる
12 WebSocketサーバの負荷分散方式 (1)
13 課題 Redis Pub/Subがボトルネックになる ◦ スケールアウトができない ◦ スケールアップができない ◦ クラスタ化しても無意味
スケーラビリティに限界がある
14 WebSocketサーバの負荷分散方式 (2)
15 課題 1.エンドポイントレベルのシャー ディング 2.WebSocketサーバ * N + Redis *
1 の単位でスケール 運用コストが高い
16 REALITYの構成
17 2.配信側サーバは全ての Redisインスタ ンスに対して分散してデータを Publishす る 3.視聴側サーバは全ての Redisインスタ ンスに対し必要なRedis Pub/Sub
ChannelをSubscribeし、来たデータを視 聴者へbroadcast Redisをスケールアウト可能 1.Redis (Pub/Sub専用) をスタンドアロ ンでN基立ち上げる
18 1.Redisはk8sのStatefulSet + Headless Serviceとして立ち上げる 2.各WebSocketサーバはk8sのサービ スディスカバリでRedisの各hostを認識・ 接続 運用コストが低い 3.各WebSocketサーバやRedisは単一
のk8sワークロードとなるため、 k8sのス ケーリングの仕組みをそのまま活用でき る
19 ライブ配信 / 視聴サーバ - 構成 • k8sのサービスディスカバリを利用したRedisのスケーリング • Redisはk8sのStatefulSet
+ Headless Serviceを利用 => kube-proxyを通らないのでパフォーマンスも落ちない • Redisのスケールアウトが可能なので、構成全体のスケーラ ビリティを担保できる • k8sのオートスケーリングの仕組みに乗ったスケーリングが 可能なので運用工数も低い
20 ライブ配信 / 視聴サーバ - まとめ • 当該方式の配信・視聴サーバのリリース後7ヶ月経過 • 同時配信数・視聴者数ともに右肩上がりだが、障害なしで安定して動
作 • 基本的にはk8sのオートスケーリングに任せられるので、運用コストも 非常に低い • Redis Pub/Subによる遅延は、アプリ - 配信・視聴サーバ間の通信 に比べて無視できる程度で安定
21 ライブ配信 / 視聴サーバ - その他 • シンプルな構成なので横展開が楽 • 事例1:
コラボ配信サーバ • 「アバタービデオチャット」的な機能を提供するコンポーネント • ボイスチャット用の音声のミキシングも行う • 事例2: ゲーム配信サーバ • ゲームサーバ + ゲーム配信の視聴サーバの機能を提供する
22 解決すべき問題点 (再掲) • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 •
パトロール・監査のため、配信データを参照可能な方式で保 存しておく必要がある • 配信音声やラベル付き配信データなどのフォーマット
23 ライブ配信データパイプライン
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 ライブ配信データパイプライン - 構成 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 ライブ配信データパイプライン - 概要 • 配信サーバはCloud Pub/Sub Topicへラベル付き配信データ をPublish •
Cloud DataFlow Job ( Apache Beam Java ) がCloud Pub/Sub Subscription経由でデータを読み出す • 読み出した配信データをApache Beam Pipelineで処理 • ラベル付き配信データ、監査用音声アーカイブファイル、分 析用統計情報などを生成 • 生成したデータをCloud Storageへ書き込む
27 ライブ配信データパイプライン - インフラ • Cloud DataFlow Streaming Engineを使用 •
Streaming処理とオートスケーリングを両立 • Worker Machineの分だけ自動でスケールしていく • キャパシティプランニングもほぼ不要 • deployもJavaのビルドだけで完結するので楽
28 Apache Beam??
29 ライブ配信データパイプライン - Apache Beam • バッチ・ストリーミング処理を統合して実行できる分散処理 フレームワーク • REALITYではApache
Beam Javaを使用 • 基本的にはJavaアプリケーションなのでできることの範囲が 広い • 当然JNIも使えるのでネイティブコードも利用可能 • その上でさらに分散処理のメリットを享受できる • Apache Sparkなどと比較すると、Cloud DataFlowとの連携 のメリットが非常に大きい
30 ライブ配信データパイプライン - 処理グラフ
31 ライブ配信データパイプライン - データ保存 • Streaming Pipelineにラベル付き配信デー タが流れてくる • 取り出したデータを10秒単位でWindow化
• データをPOJOに変換 • データとそのタイムスタンプから、1時間 ごとのディレクトリに分割した一意なファ イルパスを生成 • 生成したファイルパスへデータをAvro フォーマットで書き出す
32 ライブ配信データパイプライン - 音声アーカイブ • Streaming Pipelineにラベル付き配信 データが流れてくる • データを配信ごとにグルーピング
し、時系列に並びかえ音声データ (Opus圧縮) を抽出 • その音声データをOggコンテナに格 納する • 生成したOggコンテナをバイナリ ファイルとして配信IDごとの時系列 順にCloud Storageに書き出す
33 ライブ配信データパイプライン - まとめ • 同時配信数の増加に伴い比例して処理データ量も増えていったが、全て Cloud Dataflow側で吸収してくれるので特に追加のオペレーションの必要 はなかった •
データロストの発生もなし • サーバ費用の面では当然それなりのコストは発生するものの、想定通りにお さまる
34 結果
35 解決された問題点 • 配信データのボリュームが大きい • チャット等に比べデータ量が非常に多い • 128〜256kbs程度 • パトロール・監査のため、配信データを参照可能な方式で保存して
おく必要がある • 配信音声やラベル付き配信データなどのフォーマット
36 おわりに