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
770
動画配信サービスを支える基盤の内部
以下イベントでの登壇資料となります。
https://mirrativ.connpass.com/event/261269/
Mirrativ
November 30, 2022
Tweet
Share
More Decks by Mirrativ
See All by Mirrativ
ミラティブ「採用候補者さまへの手紙」 / mirrativ letter
mirrativ
4
410k
デザイナーのお仕事(UI/UX GRAPHIC GROUP)
mirrativ
0
230
Go Conference 2023|Goのtestingパッケージにコミットした話
mirrativ
0
360
【ミラティブ】行動理念/行動指針/わかりあおうとし続けるガイドライン
mirrativ
2
16k
ミラティブエンジニア向け会社紹介資料/Engineer's Handbook
mirrativ
17
490k
【ミラティブ】24卒エンジニア向け_本選考説明資料
mirrativ
0
830
CEDEC2022_ミラティブでのモバイル×ライブゲーミングへの取り組みと挑戦
mirrativ
0
1.5k
ミラティブ ロゴガイドライン / Mirrativ Logo Guideline
mirrativ
1
810
Go + Clean Architecture
mirrativ
1
2.1k
Other Decks in Technology
See All in Technology
コードや知識を組み込む / Incorporating Codes and Knowledge
ks91
PRO
0
160
ここはMCPの夜明けまえ
nwiizo
32
13k
2025-04-14 Data & Analytics 井戸端会議 Multi tenant log platform with Iceberg
kamijin_fanta
0
160
生成AIのユースケースをとにかく集めてまるっと学ぶ!/ all about generative ai usecases
gakumura
3
350
新卒エンジニアがCICDをモダナイズしてみた話
akashi_sn
2
280
AndroidアプリエンジニアもMCPを触ろう
kgmyshin
2
540
バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform
convto
4
880
Azure Maps Visual in PowerBIで分析しよう
nakasho
0
180
Perl歴約10年のエンジニアがフルスタックTypeScriptに出会ってみた
papix
1
250
Oracle Cloud Infrastructure:2025年4月度サービス・アップデート
oracle4engineer
PRO
0
280
AIと共に乗り越える、 入社後2ヶ月の苦労と学習の軌跡
sai_kaneko
0
180
ガバクラのAWS長期継続割引 ~次の4/1に慌てないために~
hamijay_cloud
1
570
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Designing Experiences People Love
moore
142
24k
Embracing the Ebb and Flow
colly
85
4.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
690
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Optimizing for Happiness
mojombo
378
70k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
A better future with KSS
kneath
239
17k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Speed Design
sergeychernyshev
29
920
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
ありがとうございました