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
動画配信サービスを支える基盤の内部
Search
Mirrativ
November 30, 2022
Technology
1
840
動画配信サービスを支える基盤の内部
以下イベントでの登壇資料となります。
https://mirrativ.connpass.com/event/261269/
Mirrativ
November 30, 2022
Tweet
Share
More Decks by Mirrativ
See All by Mirrativ
ミラティブ「採用候補者さまへの手紙」 / mirrativ letter
mirrativ
4
430k
デザイナーのお仕事(UI/UX GRAPHIC GROUP)
mirrativ
0
330
Go Conference 2023|Goのtestingパッケージにコミットした話
mirrativ
0
380
【ミラティブ】行動理念/行動指針/わかりあおうとし続けるガイドライン
mirrativ
2
18k
ミラティブエンジニア向け会社紹介資料/Engineer's Handbook
mirrativ
17
500k
【ミラティブ】24卒エンジニア向け_本選考説明資料
mirrativ
0
870
CEDEC2022_ミラティブでのモバイル×ライブゲーミングへの取り組みと挑戦
mirrativ
0
1.5k
ミラティブ ロゴガイドライン / Mirrativ Logo Guideline
mirrativ
1
900
Go + Clean Architecture
mirrativ
1
2.3k
Other Decks in Technology
See All in Technology
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
160
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
1
6.4k
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
180
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
2
8.6k
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
3
390
「クラウドコスト絶対削減」を支える技術—FinOpsを超えた徹底的なクラウドコスト削減の実践論
delta_tech
4
150
Delta airlines®️ USA Contact Numbers: Complete 2025 Support Guide
airtravelguide
0
340
Claude Code に プロジェクト管理やらせたみた
unson
6
3.1k
ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring
visional_engineering_and_design
1
110
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
1
15k
「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある / 2025.07.01 LLM品質Night
smiyawaki0820
1
520
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
240
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
BBQ
matthewcrist
89
9.7k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
RailsConf 2023
tenderlove
30
1.1k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
GitHub's CSS Performance
jonrohan
1031
460k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Speed Design
sergeychernyshev
32
1k
Transcript
Go Tech Talk 動画配信サービスを支える 基盤の内部 2022-11-30 ミラティブ事業本部 基盤開発技術部 インフラ・ストリーミング 漢
祐介 © 2022 Mirrativ, Inc.
1. 自己紹介 2. Mirrativのマルチクラウド構成について 3. Mirrativのライブ配信基盤について 4. CPU/メモリとGoとcgo 5. (おまけ)マイクロアーキテクチャサポート
「Go x スケーラビリティ」 Mirrativではバックエンド・基盤開発・インフラ管理の幅広い範囲でGoを利用して いるのでその紹介と Goそのものもつスケーラビリティの高さ以外にインフラ的な視点から工夫している ところなどを紹介できればと思っています アジェンダ 2
自己紹介 ▪ 漢 祐介(Hata Yusuke) ⁃ twitter: twitter.com/octu0 ⁃ github:
github.com/octu0 ▪ 2018年10月 Mirrativ に Join ⁃ OSS活動、スタートアップを経てDeNAへ入社し、ゲームの大規模トラ フィックやSHOWROOMのライブ配信サービスの基盤設計・運用に携わ る。2018年にミラティブへ入社し、インフラ・ストリーミング領域のマ ネージャーとしてライブ配信基盤/インフラ基盤に携わる。 ▪ ミラティブでの役割 ⁃ インフラ・ストリーミング部門のMGR ⁃ インフラ基盤・ストリーミング基盤の設計開発 ⁃ ミドルウェアおよびもろもろ整備 3
Mirrativのマルチクラウド構成
Mirrativのマルチクラウド構成 ▪ ミラティブのインフラは複数のクラウドで構成 している ⁃ Mirrativ本体のインフラ基盤はGCP ⁃ ストリーミング配信基盤はIDCF ⁃ どちらもIaaS管理+コンテナ化された環境
▪ Mirrativ本体は 大小さまざまなサイズのVMが数百単位で稼働 ▪ ストリーミング配信基盤はベアメタルサーバと VMサーバの組み合わせで稼働 5
Mirrativのマルチクラウド構成と開発チーム ▪ Mirrativ本体はAPI/Batchプロセスの集合 ⁃ PerlからGoに移行しているところ ⁃ バックエンドチームが本体の機能開発 ⁃ 基盤開発チームおよびインフラチームが 基盤となる部分の設計開発
▪ CI/CDなどは Cloud Build + α WAF は Cloud Armorを使ってたりする ▪ 構成管理ツールや監視は開発環境でテストし たバイナリをそのまま本番に持っていってる 6
Mirrativのマルチクラウド構成と開発チーム ▪ 映像/音声のライブ配信はIDCFクラウドで受けてい る ⁃ iOS/Androidのライブラリおよび配信サーバは ストリーミングチームが設計開発 ⁃ ベアメタルなサーバと VMなサーバのハイブリッドな環境
▪ ハードウェアロードバランサを使用していたり、ク ラウド<->物理サーバ間のL2/L3接続などネット ワーキングに特徴がある → 今回紹介するのはこのストリーミング周辺です 余談 配信サーバは長年Wowzaという製品を使っていたが Goに移行した 7
Mirrativのマルチクラウド構成 ▪ マルチクラウドで構成 ⁃ より最適なところで稼働させるため ⁃ 拠点単位での動作/複数拠点による相互監視 ⁃ コスト最適化 •
オートスケーリング • トラフィックコントロール • ベアメタルの活用 ▪ ベンダーロックインを避けるために ⁃ コンポーネント間の依存関係を薄く小さく ⁃ 密結合を避ける ⁃ シンプルを保つ 8
Mirrativのライブ配信基盤 (Goの話までもう少しあります)
Mirrativのライブ配信基盤 ▪ Origin/Edge 構成 ⁃ ストリーミング版Pub/Subのイメージ ⁃ 以前はPolling方式だった 今はPush方式になっている ⁃
水平分散(sharding)している ▪ Originは配信者さんから映像/音声を 最初に受けるところ ▪ Edgeは視聴者さんに映像/音声を届 けるところ 10
Mirrativのライブ配信基盤 - Origin ▪ OriginはハードウェアLBにて冗長化 ⁃ Active/Standby構成 ⁃ LB自体も冗長化されてる ▪
Originで処理すること(*1)が増えてきたので ベアメタルサーバを利用 ⁃ 基本的にCPU処理だけで完結するように設 計しているので、VMでもベアメタルでも 可搬性のあるプログラムである必要がある ⁃ GPU搭載マシンは使っておらず汎用サーバ で構成しているので調達はしやすい • とはいえ突発的な受け皿として利用するよ うなキャパシティ確保には不利 *1 サーバサイド通知ぼかし(画像処理)や 直近では音量解析(音声処理)をサーバサイドで行ってる 11
Mirrativのライブ配信基盤 - Edge ▪ EdgeはActiveとStandbyに接続 ⁃ OriginのFailoverの影響を受けない ⁃ Push方式なのでEdgeはtopicを待ち続け るだけ
▪ EdgeはOriginへのOffloading用途 ⁃ Originへの接続を束ねて大量の視聴者接 続を受け持つのが役目 ⁃ そのため複雑な機能はなく Clientに映像/音声のPushくらい ▪ キャパシティ面やコスト面からクラウド上に オートスケールするようにしている 12
CPU/メモリとGoとcgo
CPU/メモリとGoとcgo ▪ ライブ配信基盤のサーバミドルウェアはGoにて記述 ⁃ GPUなどを搭載しない汎用サーバを利用しているのでCPU処理が主体 ⁃ Goはメインロジックの他、通信関連、Pub/Subのロジックを書いている ▪ 画像のトランスコーディングや音声処理を扱う場面では cgo
を経由して、 C/C++のロジックが走る ⁃ 高いリアルタイム性が求められる場面 ⁃ SIMD化したい箇所をOSSなライブラリを使えばGoでもできるが アルゴリズムとスケジューリング分離を行うためにHalide 言語(C++のDSL)で書いてる ⁃ 音声処理もHalideで書いたりしている => 続く 14
CPU/メモリとGoとcgo - CPU ←Halideで書いたコード ↓Goで呼び出すとき(抜粋) 15
CPU/メモリとGoとcgo - CPU ▪ 普通にGoのコードを書いていればマルチコアなサーバでスケールできる ⁃ vCPU 8のサーバでも vCPU 64
のサーバでも同じバイナリでスケールする ⁃ VMでもベアメタルなサーバでも同じ ▪ Halideでナイーブにチューニングをしてしまうとスケールしない ⁃ 並列数や L2,L3 cacheサイズの違いを意識しないといけない ⁃ 実行環境毎にバイナリを用意することになるので少しイケてない ⁃ とはいえ高速な処理を書きやすいので、使い所は限定的に 16
CPU/メモリとGoとcgo - メモリ ▪ ライブ配信ではメディアデータ(映像/音声)を扱うため、テキストデータと比 べてメモリ管理がシビア ⁃ 30fpsの映像だと1秒間に30枚の画像がパラパラ漫画のように送られてくる ⁃ 一度どこかで
allocate したものは、コピーを作らず最後まで使い回す 17
CPU/メモリとGoとcgo - メモリ ▪ allocateしたものは基本的に使いまわし ⁃ leaky bufferな実装で必要な分だけbufferする(sync.Poolでも良いがコントロールしずらい) ⁃ 大きな値は
mmap を使用することもある ←Pool ↓使うとき 18
▪ 非同期処理ではgoroutineを “直接”使わずワーカプール ⁃ メモリ管理 / goroutine leak を検出するため ⁃
一度起動した goroutine の再利用で起動コスト低減も CPU/メモリとGoとcgo - メモリ 余談 ▪ goroutine leakの検出はとても難しい... ⁃ 予期せぬところで刺さって閉じられないまま だったり ⁃ 空っぽの channel を待ち続けていたり ⁃ capが埋まってる channel に書き込もうとしてた り 19
(おまけ)マイクロアーキテクチャサポート
(おまけ)マイクロアーキテクチャサポート ▪ Go1.18 からGOAMD64フラグを使ってビルドすることで、より最適化したバイナリを 作ることができるようになった ⁃ GOOS=linux GOARCH=amd64 GOAMD64=v3 go
build -o a.out cmd/main.go ⁃ 例えば • v1 では math/bits.OnceCount(popcnt) や math.FMA 等は最適化されないが • v2 では popcnt は最適化 / math.FMA は最適化されない • v3 では popcnt / math.FMA などが最適化される ⁃ GOARCH=amd64 GOAMD64=v3 go tool compile -S main.go しながら runtime.x86HasXXX の 最適化具合で追いかけれる • (v4はAVX512系なので省略) ▪ 試しに、前述の音声処理を GOAMD64=v2, v3 でそれぞれでベンチマークを取ると ⁃ GOAMD64=v2版 46.978µs ⁃ GOAMD64=v3版 31.94µs ⁃ とちょっと早くなる。ちなみに(慣れているので)Halideで書いたものが 1.87us になるのでHalideを使っている 21
まとめ
まとめ ▪ Goはバックエンド・インフラ・ストリーミングのどの領域でも活用している ▪ システム全体としてスケーラビリティがある状態を作っていく ⁃ マシンの調達も性能もスケーラビリティがある状態は重要 ⁃ スケールできるようにシステムアーキテクチャの設計は大事 ▪
一緒に作ってくれる仲間を募集しています! 23
ありがとうございました