Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【TECH STAND #4】常時接続SNS時代のライブ配信基盤の安定化に向けた取り組み/yusuke_hata

【TECH STAND #4】常時接続SNS時代のライブ配信基盤の安定化に向けた取り組み/yusuke_hata

TECH STAND #4 常時接続SNS~ライブ配信基盤を支える技術~
https://standfm.connpass.com/event/211035/
にて話した資料です

B248ac938d3f455da599cec43b67a1b6?s=128

mirrativ

May 14, 2021
Tweet

Transcript

  1. STRICTLY CONFIDENTIAL TECH STAND #4
 
 常時接続SNS時代の
 ライブ配信基盤の
 安定化に向けた取り組み
 2021-05-14

    ミラティブ事業本部 技術部 インフラ・ストリーミング 漢 祐介
 © 2020 Mirrativ, Inc.
  2. 99 アジェンダ
 1. 自己紹介
 2. Mirrativとは
 3. ライブ配信基盤構成の紹介
 4. ライブ配信システムの紹介


    
 ミラティブで行っているライブ配信基盤の安定化に向けた取り組みについて、イン フラ/アーキテクチャ的な部分をざっくりご紹介させていただければなと思います

  3. 99 自己紹介


  4. 99 自己紹介
 ▪ 漢 祐介(Hata Yusuke)
 ⁃ twitter: twitter.com/octu0
 ⁃

    github: github.com/octu0
 ▪ 2018年9月 Mirrativ に Join
 ⁃ 前職: DeNA ゲーム開発エンジニア→インフラ部門マネージャ
 DeNA子会社含む複数のサービスのインフラ担当
 DeNAのライブ配信基盤も設計・運用もそのうちの業務の一つだった
 ⁃ さらに前々職は位置情報ゲームの開発やOSS活動もしてました
 ▪ ミラティブでの役割
 ⁃ インフラ・ストリーミング部門を担当
 ⁃ インフラ基盤の設計開発
 ⁃ ミドルウェア開発および次世代配信基盤の設計開発

  5. 99 Mirrativとは


  6. Mirrativのサービスについて
 • PCやカメラ・特別な配信設備なしに 
 スマホ1台、さらに数タップだけで配信が可能 
 • アバター(エモモ)を使用することで 
 「顔出し」をすることなく配信をすることができ

    る
 
 スマホのゲーム画面をそのまま配信することができ る
 
 セルフィ型の配信と違い自分の代わりにアバターが 映し出されるため顔出しをせずに配信ができる 
 スマホ1台でゲーム配信ができる 
 コミュニケーションサービス

  7. Mirrativのサービスについて
 • 好きなゲームのマルチを通じて対戦する 
 • ゲームを通じて仲間とコミュニケーションを取 り合ってわかりあう
 
 「友達の家で集まってゲームしてる感じ」 


    ミラティブが大切にしてるコンセプト 
 
 ライブ配信を通じたコミュニケーションサービス 
 スマホ1台でゲーム配信ができる 
 コミュニケーションサービス

  8. 99 Mirrativのサービスについて
 ミラティブではユーザ全体の20%のユーザさんが配信者として配信を行ったことがある人 
 スマホゲーム配信者数No.1(※当社調べ) 
 SNSのような発信者比率が特徴となっている 
 詳しくは→ 草の根から熱量を高めて配信者100万人。ミラティブが語

    る「灯火型」のコミュニティ立ち上げ論と、小さな配信の集合体が「視聴 時間の80%」を支えてる話 | アプリマーケティング研究所 

  9. 99 ライブ配信基盤の構成


  10. 99 ライブ配信基盤の構成で特に気をつけていること
 ▪ コミュニケーションが取りやすくなっていること
 ⁃ => コミュニケーションがスムーズに取れることは重要
 ⁃ => 遅延時間を低減するように出来ているか


    
 ▪ スケール性を保てるようになっていること
 ⁃ => 配信者数が多いためスケール性を保つのは重要
 ⁃ => ピークタイムにマシン台数が増減しやすくなっているか

  11. 99 ライブ配信基盤の構成(ざっくり)
 今現在のミラティブの配信基盤の構成はこんな感じ


  12. 99 ライブ配信基盤の構成(ざっくり)
 transcoderサーバに配信されてきた映像と音 声は、既存プロトコルと低遅延プロトコルに変 換してOriginサーバに配信している
 
 Originサーバは映像と音声のバッファリングや TSチャンクの生成などを行っている
 ※低遅延用のサーバでは多少アーキテクチャが違うがだいたい 同じ


    
 既存のプロトコル(RTMP)はPC配信や古い端 末などで視聴するための互換性のために残し てある

  13. 99 ライブ配信基盤の構成(ざっくり)
 プロトコルの違いは、扱うプロト コルの種類(HLSとか)によって いろいろ違いはあるが、ざっく りPull型かPush型かで違うくら い
 
 低遅延用のプロトコルに変換し たものは内製のミドルウェアで

    配信が行われている (Origin/Edge含む)
 ※一部互換性のためtranscoderを 経由しないサーバもある

  14. 99 ライブ配信基盤の構成(ざっくり)
 Originサーバから後段は、一般的な配信シス テムと同じくEdgeサーバから視聴端末に映像 と音声が配信している
 
 EdgeサーバはOriginサーバのオフローディン グの用途を担っている
 また、大量に同一の映像と音声を配信するの もEdgeサーバが担ってる


    
 ※オフローディングはストリームを束ねて、 Originから取得するストリーム数を減らして Originサーバの負荷軽減をしてる

  15. 99 ライブ配信基盤の構成(ざっくり)
 トラフィック量は配信先が増えれば増えるだけ 増加する
 また配信するプロトコルの数だけ倍々にトラ フィックは増加する
 
 ストリームは一度配信開始されると配信が終 わるまで途切れない連続したデータのため
 


    何かしらのトラブルでサーバが落ちた場合に ユーザ影響を最小限にするためにトラフィック コントロールはかなり重要になってくる
 
 => 安定化のキモとなるところ

  16. 99 冗長化の構成(前段)
 ユーザさんから配信されたストリームは、
 物理的に冗長化された物理ロードバランサに よって、Act/Stby構成の配信サーバに分散され る
 
 ホットスタンバイとなっているため、フェイルオー バ時は即座に配信が継続できる
 フェイルオーバ中もクライアント側でもバックオフ

    アルゴリズムによってリトライ制御している
 
 この他にも後述する配信システムのトラフィックコ ントロールによってメンテナンス制御もしているた めメンテナンス性も担保

  17. 99 冗長化の構成(後段)
 視聴しているユーザさんはOriginサーバの切り替 わりによる影響を受けないように、Edgeサーバで は Active側とStandby側両方を参照している
 
 クライアント側では特に再接続などを行わなくて も良いようにしている


  18. 99 Shardingの構成
 DBと同じように水平分割方式でOrigin/Edgeサー バの分割をしている
 
 shardingは配信数や負荷状況に応じてスケール させている
 
 どのshardに配信するかも配信システムによって 流量をコントロールするため、一部のサーバに偏

    りは基本的に起こらないようにしていて、負荷も 全体で均一になるようにしている
 
 shard分割しているためサーバダウンの影響範 囲は限定的になっている

  19. 99 配信システムの紹介


  20. 99 トラフィックコントロール
 ▪ 配信時にどこのOriginに配信を行うかを決定するように配信APIでコントロールしてる
 ⁃ Originサーバのメンテナンス時にもこの仕組みを使ってる(重みを0にする)
 ⁃ 有名配信や公式配信などEdgeが急増する場合もこの仕組みで分散を制御してる
 ▪ 視聴時も同様に最も空いているEdgeに視聴者が接続するようになっている


    ⁃ トラフィック量などからshard内の重みを上げ下げしてもっとも快適なサーバを選択
 ▪ 接続数やトラフィックを常時収集しているため、常にサーバ毎のWeightを更新してる

  21. 99 オートスケーリング
 水平分散のsharding構成を使っているため、特定のshard内のedgeだけ増減する 
 => 急激なトラフィック増も特定のshardだけマシンが増加できる
 => 台数がピークに合わせて増減するためコストメリットも 


  22. 99 配信基盤API
 ▪ 配信サーバはIDCFクラウド上に 構成されていて、サーバのサー ビスイン・アウトはIDCF上に構 築されたAPIサーバで提供して いる
 ⁃ ミラティブの本番サーバは

    GCP上に構成しているので、 クラウド間でAPI連携 するよう になっている
 ▪ なんらかの理由でAPIが停止し てもサービスが停止しないよう にエラーを前提としたAPI設計に なっている
 ▪ API化しているためslackでの chatopsにも対応

  23. 99 監視などについて
 ▪ 外形監視も兼ねてIDCF外の外部のクラウドから監視 を行っている
 ⁃ もちろん内部からの監視もある
 ⁃ E2E(エンドツーエンド)で、配信と視聴の遅延監視 もしている


    ▪ 外形監視はインターネットなので経路上の問題は 起こる可能性はある
 ⁃ とはいえユーザさんの環境に近い監視が実 現できる
 ⁃ 内部監視だけだと気づけない問題も気が付 ける(内側は正常だけど外からだと失敗みた いな)
 ▪ 内部監視では死活監視以外にもトラフィックの監 視も行ってる
 ⁃ 突発的にトラフィックが出ている場合は 手動 でスケールアウトさせたり
 ⁃ ネットワークの不調などもトラフィックの減衰 から検知などもしてる

  24. 99 その他、配信の安定化に向けて(クライアント)
 ▪ モバイルデバイス配信ならではのMPTCP 
 (MultiPath TCP)
 を用いた4G/Wifiのハンドオーバによって、配信が より途切れにくく、安定して配信できるように実装 を用意


    ⁃ ←弊社テックブログに書いてます
 ▪ その他にも配信者さんの通信状況に応じて NewReno(Cubic)ライクの配信ビットレート自動調 整を行うことで映像の画質も品質を維持できるア ルゴリズムに調整なども行っている 

  25. 99 まとめ
 ▪ 配信基盤の安定化はインフラだけに留まらず
 システム全体で対応している
 
 ▪ 安定して提供できる仕組み/アーキテクチャを使って
 配信基盤を構成している
 ▪

    内製で作り込んでるものがある
 
 一緒に作ってくれる仲間募集中です!

  26. 99 ありがとうございました