LIVEの負荷対策と監視について / About LIVE load countermeasures and monitoring

リアルタイムに参加者が入れ替わる音声配信プラットフォームでの、負荷対策と異常を検知するためのモニタリングの苦労についてです。

2021年05月14日に開催したstand.fm主催 『TECH STAND #4 常時接続SNS~ライブ配信基盤を支える技術~』で登壇した内容です。
https://standfm.connpass.com/event/211035/

Transcript

1. エンジニア 稲田修也 2021/05/14 TECH STAND #4 常時接続SNS ~ライブ配信基盤を支える技術 ~ LIVEの負荷対策と監視について
2. stand.fmの紹介

3. stand.fm

4. stand.fm
 LIVEで気軽に楽しく配信
 アイテムやハートをもらったり、
 リアルタイムでリスナーとコミュニケーションをし ながら配信できます。 
 リスナーをゲストに招待して最大５人で 
 一緒に配信する事も可能です。 
 
 ※ゲストで参加できるのは現在iOSアプリのみです 

5. 自己紹介
 - Shuya Inada @inatonix 
 
 - 研究したいと思ってたのに気付いたらスタートアップ沼にズブズブ 
 
 - ３年くらい起業して放浪して現職 
 
 

6. 負荷対策 and 監視

7. 負荷対策

8. 負荷？？
 Live配信
 App (Host Speaker) CDN HLS Proxy WebSocket
 サーバー RTMP App (Guest Speaker) シグナリング サーバー

9. 負荷？？
 Live配信
 App (Host Speaker) RTMP App (Guest Speaker) シグナリング サーバー
 App (Listener)
10. 負荷？？
 Live配信
 App (Host Speaker) RTMP App (Guest Speaker) シグナリング サーバー
 App (Listener) ここの負担が大きい 

11. 課題意識
 課題：音声ストリームをまとめてアップロードする分、ホストスピーカーの端末負荷が大きい 
 
 - 端末が重くなると、音声のアップロードが滞る 
 
 - 画面が固まってコラボ相手を選ぶなどの各種操作に支障をきたす 

12. 対策
 負荷試験して計測して１つ１つ改善 

13. 対策
 負荷試験して計測して１つ１つ改善 
 めっちゃ地道

14. 負荷試験
 Harvest（社内ツール） 
 
 liveIdを指定するとlocustという負荷試験ライブラリが 
 k8s上で動いて、ライブに大量リクエストを飛ばす 
 
 locustはpythonでテストケースが記述できるのでXML形式で書く ものなどより柔軟
 複数コンテナで連携して動かすためのhelmも用意されてる 
 
 ※負荷対策を施す前の動画 
 - リクエストが大量に飛んでくるとJSスレッドのfpsがどんどん下がる　20くらいを下回り始めると、リクエストを 捌ききれなくなってくる 
 
 - さらに大量に飛んでくると、UIスレッドのfpsも落ちていって画面が固まり始める 

15. 計測
 React Dev tools
 
 Reactのコンポーネントのレンダリング状況 などを可視化できる 
 
 
 負荷試験をしながら、こちらのツールを使っ て不必要にレンダリングされているものをあ ぶり出していく
 ※ locustにはデフォルトでエンドポイントごとのレスポンスタイムが計測できるダッシュボードがついているが、今回 locustから送っているリクエストはwebsocket通信のもののみで、今回のケースだと使用できなさそうでした 

16. 修正
 計測フェーズで炙り出した無駄なレンダリング を、1つ１つ削っていく 
 
 
 具体的には、リスナーの数を更新するタイミン グで、コメント欄などの関係ないコンポーネン トも再レンダリングされていたりしたのでそう いう修正を積んでいく 

17. 監視

18. 課題
 - 「たまに落ちるな...」
 
 - 「たまに音聞こえなくない？...」 
 
 課題意識: リアルタイム複数人同時配信サービスでのエラーの検知が難しい 
 
 理由: 手元では気付きづらいケースが多い（音声インターフェイス、ネットワーク環境、状態遷移...） 

19. 課題
 どれくらいの頻度でその現象が発生しているのか捕捉できていない 
 
 
 → あるリリースがきっかけでその不具合が増えていても分かりづらい 
 
 → 「たまたまユーザのネットワークが悪かっただけではないか、、」という邪念がちらつく 
 
 → 実際には少なくないユーザが不具合を被っていても対応が遅れる 

20. 実際の監視
 1. 各問題のボリュームを把握する 
 
 - 「Liveの失敗」の分類 
 - Liveが接続終了してしまった 
 - Liveの音声が一定時間聞こえなくなった 
 
 - それぞれの「失敗」の原因点で分類 
 - webRTCが悪そう？
 - メディアサーバ (wowza)が悪そう？ 
 - playerが悪そう？
 
 - 失敗の中でも分類
 - 最初から最後までずっと聞こえない 
 - 途中で一瞬聞こえなくなる 
 - 入った直後だけ聞こえない 
 - 配信者同士は会話できているがリスナーに聞こえない 
 - ホストの声だけ全員に聞こえない 
 - 特定のリスナーだけ聞こえない 
 - etc...
 Live配信
 App (Host Speaker) RTMP App (Guest Speaker) App (Listener)
21. 実際の監視
 2. 原因を探るためのログ・メトリクス収集 
 
 - live/userに紐づく全体的な行動ログ 
 - backgroundにいった？ 
 - AudioSessionの設定が変わった？ 
 - ...etc
 - パフォーマンスメトリクス 
 - cpu usage / fps
 - network latency
 - その他エラー発生メトリクスも 
 

22. 実際の監視
 3. 1つ１つのliveログを追いながら仮説を増やす 
 
 - この時音声では「アラームが鳴った」と言っていた 
 - この時networkの速度がガクッと下がっていた 
 - この時Live画面のあるモーダルを開いていた 
 - etc…
 
 １で分類した中で、同じ事象が発生してそうなLiveをまとめて複数サンプル照らし合わせたりしています 
 
 
 例：通話などのインタラプションが入るとAudioSessionを一時的に変える設定が入っていたが、コラボライブ中に それを起こされるとソロライブと同様のAudioSession設定に戻ってしまって、ホストの声しか聞こえなくなる 
 

23. まとめ
 - 地道だが、負荷を疑似的にかけて・計測して・コードと照らし合わせて修正していく作業が負荷対策を進 める上でとても効く
 
 - 地道だが、エラーが発生してそうなLiveの音源を聞きまくると事象を良く把握できて、LIVEモニタリング体 制を強化する上でとても効く 
 
 - 1つのエラー発生事象だけからログを見て修正できることは多くなく、まずはボリュームの監視を入れてエ ラーサンプルが複数ある状態で細かい行動ログを追っていくと原因判明することが多くな 
 った（はず）
 
 

24. We are hiring! エンジニア積極的に募集中です https://corp.stand.fm/recruit 詳細はこちら • CTO候補 • VPoE候補 • クライアントエンジニア • バックエンドエンジニア • 機械学習エンジニア • 配信基盤エンジニア • QAエンジニア • エンジニアリングマネージャー • UI/UXデザイナー 積極募集しているプロダクト開発メンバー