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
680
動画配信サービスを支える基盤の内部
以下イベントでの登壇資料となります。
https://mirrativ.connpass.com/event/261269/
Mirrativ
November 30, 2022
Tweet
Share
More Decks by Mirrativ
See All by Mirrativ
ミラティブ「採用候補者さまへの手紙」 / mirrativ letter
mirrativ
4
390k
デザイナーのお仕事(UI/UX GRAPHIC GROUP)
mirrativ
0
120
Go Conference 2023|Goのtestingパッケージにコミットした話
mirrativ
0
330
【ミラティブ】行動理念/行動指針/わかりあおうとし続けるガイドライン
mirrativ
2
14k
ミラティブエンジニア向け会社紹介資料/Engineer's Handbook
mirrativ
17
470k
【ミラティブ】24卒エンジニア向け_本選考説明資料
mirrativ
0
780
CEDEC2022_ミラティブでのモバイル×ライブゲーミングへの取り組みと挑戦
mirrativ
0
1.4k
ミラティブ ロゴガイドライン / Mirrativ Logo Guideline
mirrativ
1
710
Go + Clean Architecture
mirrativ
1
2k
Other Decks in Technology
See All in Technology
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.3k
Building Products in the LLM Era
ymatsuwitter
10
5.4k
MC906491 を見据えた Microsoft Entra Connect アップグレード対応
tamaiyutaro
1
540
OpenID BizDay#17 KYC WG活動報告(法人) / 20250219-BizDay17-KYC-legalidentity
oidfj
0
240
30分でわかる『アジャイルデータモデリング』
hanon52_
9
2.6k
Helm , Kustomize に代わる !? 次世代 k8s パッケージマネージャー Glasskube 入門 / glasskube-entry
parupappa2929
0
250
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
500
組織貢献をするフリーランスエンジニアという生き方
n_takehata
1
1.3k
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
7.1k
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
960
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
2024.02.19 W&B AIエージェントLT会 / AIエージェントが業務を代行するための計画と実行 / Algomatic 宮脇
smiyawaki0820
12
3.1k
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Thoughts on Productivity
jonyablonski
69
4.5k
Raft: Consensus for Rubyists
vanstee
137
6.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
A Modern Web Designer's Workflow
chriscoyier
693
190k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Writing Fast Ruby
sferik
628
61k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Faster Mobile Websites
deanohume
306
31k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
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
ありがとうございました