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
3.2k
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
LLM翻訳ツールの開発と海外のお客様対応等への社内導入事例
gree_tech
PRO
0
660
ヘブンバーンズレッドのレンダリングパイプライン刷新
gree_tech
PRO
0
670
ヘブンバーンズレッドにおける、世界観を活かしたミニゲーム企画の作り方
gree_tech
PRO
0
660
「魔法少女まどか☆マギカ Magia Exedra」のグローバル展開を支える、開発チームと翻訳チームの「意識しない協創」を実現するローカライズシステム
gree_tech
PRO
0
660
「魔法少女まどか☆マギカ Magia Exedra」での負荷試験の実践と学び
gree_tech
PRO
0
700
「魔法少女まどか☆マギカ Magia Exedra」の必殺技演出を徹底解剖! -キャラクターの魅力を最大限にファンに届けるためのこだわり-
gree_tech
PRO
0
670
ヒューリスティック評価を用いたゲームQA実践事例
gree_tech
PRO
0
650
ライブサービスゲームQAのパフォーマンス検証による品質改善の取り組み
gree_tech
PRO
0
660
コミュニケーションに鍵を見いだす、エンジニア1年目の経験談
gree_tech
PRO
0
140
Other Decks in Technology
See All in Technology
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
20
10k
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
120
【実演版】カンファレンス登壇者・スタッフにこそ知ってほしいマイクの使い方 / 大吉祥寺.pm 2025
arthur1
1
890
「その開発、認知負荷高すぎませんか?」Platform Engineeringで始める開発者体験カイゼン術
sansantech
PRO
2
110
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの?
smt7174
4
190
LLMを搭載したプロダクトの品質保証の模索と学び
qa
0
1.1k
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
450
AWSを利用する上で知っておきたい名前解決のはなし(10分版)
nagisa53
10
3.2k
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
820
DDD集約とサービスコンテキスト境界との関係性
pandayumi
3
290
20250912_RPALT_データを集める→とっ散らかる問題_Obsidian紹介
ratsbane666
0
100
La gouvernance territoriale des données grâce à la plateforme Terreze
bluehats
0
190
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
Producing Creativity
orderedlist
PRO
347
40k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
Large-scale JavaScript Application Architecture
addyosmani
513
110k
Documentation Writing (for coders)
carmenintech
74
5k
Docker and Python
trallard
46
3.6k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
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 おわりに