ライブ配信サービスの インフラのジレンマ -マルチクラウドに至ったワケ-

「インフラアーキテクチャ選択のジレンマ」（https://findy-tools.connpass.com/event/362401/） の登壇資料です。内容は、2025年8月7日(木)登壇時のものです。

Transcript

1. 2025-08-07 インフラアーキテクチャ選択のジレンマ Yusuke Hata, Mirrativ inc. ライブ配信サービスの インフラジレンマ -マルチクラウドに至ったワケ-
2. 自己紹介 • 2018年10月 株式会社ミラティブにJoin ◦ OSS活動、スタートアップを経てDeNAへ入社し、ゲームの 大規模トラフィックやSHOWROOMのライブ配信サービス の基盤設計・運用に携わる。2018年にミラティブへ入社 し、インフラ・ストリーミング領域のマネージャーとして ライブ配信基盤/インフラ基盤に携わる • ミラティブでの役割 ◦ インフラ・ストリーミング部門のMGR ◦ インフラ基盤・ストリーミング基盤の設計開発 ◦ 基盤ミドルウェア設計開発 2 Yusuke Hata (漢 祐介) 株式会社ミラティブ 基盤開発部 インフラ・ストリーミンググループ MGR
3. 1. 適材適所 2. コスト最適化(転送費用や従量課金) 3. マルチクラウド 3 目次
4. Mirrativの紹介 4
9. Mirrativの インフラアーキテクチャ 9
10. 10 主に2つのクラウドサービスを利用
11. よく訊かれること • 「Google Cloudだけじゃないんですね?」 • 「AWSは使ってないんですか?」 • 「複数のクラウドって管理大変じゃないですか?」 Mirrativ ではマルチクラウドとハイブリッドクラウドの組み合わせのような構成 を取っていて、単一のクラウドサービスにこだわらず 最適なところで動かす = 適材適所のインフラアーキテクチャ 11
12. クラウドサービスには色々な特色がある • SaaS的な機能が豊富だったり、サービス連携が容易だったり • 料金体系もクラウドサービスごとにさまざま Mirrativでは、クラウドの機能に完全に乗っからないようにしている • IaaS 利用がメイン • クラウドの機能も基本的なものだけ、複雑なものは避ける (何かあったときに代替可能なものにする) ロックインを避ける目的と、よりよいクラウドが出てきた時に 機能に依存せずに移し替えれるようにしている 12
13. スケーラビリティだけじゃない クラウドを利用する利点の一つは “スケーラビリティ” Mirrativでは物理マシンも積極的に利用 • スケーラビリティの代わりに 高可用性とパフォーマンスを重視 ◦ ハードウェアロードバランサー ◦ ベアメタルサーバ ◦ 性能が安定して出せる チューニング次第ではマシン性能を使い切れる • プライベートクラウドも導入してる ◦ 開発環境のように予測可能な環境に導入 ◦ サイジングを工夫してコスト最適化 (CPU overcommit 等) • ただしスケーラビリティが必要な場面(Edge)ではクラウドも活用 ◦ オートスケールなども活用 13
14. Compute Engineはライブマイグレーションが優れてる GCPのCompute Engineにはライブマイグレーション という機能がとても優秀 • データベースのような継続して動かし続けるサー バではとてもメリットがある • 突然死はありえるが、サーバのメンテナンスを大 幅に減らせる 少数のチームで運用する場合、メンテナンスの手間は大 きな課題。サーバの台数が多い場合は特に課題。 またメンテナンスイベント情報が事前に取得出来るので メンテナンス予告が発生したらサービスアウト対応もで きるので便利。 一方で、性能が安定しない問題は避けられない 余裕を持ったキャパシティプランニングは必要 14
15. 適材適所 • 全部物理マシン vs 全部クラウドではなく 長所を活かした選択 ◦ 安定した高い性能を出したい = ベアメタルサーバ ◦ サイジングを工夫できる = プライベートクラウド ◦ 柔軟な構成やスケーラビリティを確保 = パブリッククラウド • GCP / IDCF Cloud / プライベートクラウド どこでも動かせれるインフラ構成にするのが大事 15
16. 16 コスト最適化 (転送費用や従量課金)
17. ライブ配信はトラフィックが大きい Webアプリケーションの場合は、API通信に 数十B/s~数百B/s 程度のトラフィックになるが ライブ配信の場合は、映像と音声を通信するため 200KB/s~1MB/s 程度のトラフィックが発生する 加えてライブ配信では配信者さんが送ったものと 基本的に同じデータを視聴者さんに送る そのためこの例のように 配信者さんが 1人の IN 1MB/s でも 視聴者さんが 3人いれば OUT 3MB/s のように増幅する 17
18. 一般的なクラウドサービスでは従量制の課金形態になって いて、 N円/GB の一般料金と一定以上の転送量になった場 合に割り引きが行われる形態が多い IDCF Cloud には帯域ごとの定額オプションがあるので トラフィック量が大きい場面では活用する (95%ile 従量なので突発的な超過も抑えれる) 18 定額帯域のネットワークを使う 料金体系のイメージ
19. インターネットのトラフィックに乗せることなく、 可能な限り内部NWで必要な機能の実装をしてる • 配信文字起こし • 動画のプレビュー配信 (CDN は Fastly) • 動画の録画・アーカイブ (S3互換ストレージを内製化) トラフィックは内部NWだけなのでトラフィック量 は大幅にカット CDNはFastlyのOriginShieldも活用して、Originへ の負荷もトラフィックも軽減 19 トラフィックを内部ネットワークに
20. 20 マルチクラウド構成
21. 21 お互いのクラウドを監視出来る 単一のクラウドだけでお互いのクラウドを 外側から相互監視することができる (内部だけの監視ではどうしても何かに引っ張られがち) • 外形監視 • E2E監視 • 死活監視 E2E/死活監視の通信はインターネット経路を使 うことで実際の利用中のユーザさんと同じよう な状態を作り、正確な監視を用意 別拠点からも死活監視も行っていると経路の問 題なども切り分けがしやすい
22. 疎結合・シンプルさの追求 お互いのクラウドに干渉しすぎない APIではシンプルな情報のみでやりとりする クラウド内(拠点内)で完結するように構成する • 疎結合にする • シンプルにする • 拠点内に閉じる 無意識のうちにコンポーネント間の依存関係を 強く作ってしまいがち マルチクラウドに限らず 密結合を避け・シンプルさを維持する 22
23. まとめ 23
24. 適材適所 どのクラウドサービスにも強み弱みはある 適材適所で良い所を最大限活かす • コスト最適化 • パフォーマンス最大化 リードタイムが大きくなりがちな物理サーバも適切なキャパシティ管理を行うこと でサービスに影響が出ないようにするのが重要 日頃からサービスの特性をしっかりと把握 コンポーネント同士は疎結合・シンプルさを追求する 代替可能な仕組みを用意できるといざという時にも乗り換えにも対応しやすくなる 24
25. わかりあう 願いをつなごう 25