なぜ Infra Study Meetup運営は配信トラブルを引き起こしてしまったのか

こんにちは。Infra Study Meetup 運営の重本です。先日 4月24日（金）夜に開催したオンライン勉強会「Infra Study Meetup #1『Infrastructure as Code』」において配信トラブルが発生し、ライブ配信開始から45分にわたり1000名を超える参加者に多大なるご不便をお掛けしてしまいました。本記事では、今回のトラブルの原因およびリカバリー方法、再発防止策についてまとめ公開いたします。

概要

本勉強会は2020年4月24日(金) 19:25より、YouTube Live を用いてオンラインで開催しました。

発表者には Zoom ミーティングを用いて画面共有および発表していただき、その様子を配信ソフトを介した上で YouTube Live で配信するという構成です。

配信開始直後の19:25〜19:35の間、YouTube Liveでのライブ視聴が不安定となる事象が発生しました。

配信者PCにおけるエンコード処理およびストリーミングサーバーでの処理にかかる負荷を最小限とするため、配信ソフトおよび YouTube Live における設定を見直し、19:40より安定した状態でライブ配信を再開しました。

その後、運営からの挨拶ののち、発表者の音声が小さくて聞こえない状態であることが発覚し、オーディオミキサーの設定を段階的に調整しましたが改善しない状態が続きました。また調整中、一時的に配信者PCシステム音や発表者音声が大音量で再生される事象がありました。

調整を続け、20:11に安心して視聴できる音声品質にチューニングが完了しました。

上記のトラブルの影響もあり、予定終了時刻を1時間以上超えての勉強会終了となりました。

経緯

当日以前に行ったこと

4月15日　Zoom × YouTube での配信テストを実施

4月18〜23日　コメントスクリーンを、各登壇者のPCで流し、そのデスクトップ全体をZoomで共有するやり方をしている勉強会にスポンサーとして参加、コメントスクリーンを有意義に感じ、導入を試みることを決めました。その後、Zoom × コメントスクリーン × YouTubeでのテストを配信者２人での実施で上手くいくことを確認しました。また、基調講演者、およびLT登壇者と事前に Zoom で登壇資料やマイクが正常に機能するかの配信テストを行いました。

4月23日　上記のリハーサルで、コメントが流れる映像しか動画として保存できないことがわかったため、コメントなしの映像を残すために配信ソフトにOBS Studioを使うことを決めました。

Zoom × コメントスクリーン × OBS × YouTubeでの配信テストを1人で行った結果、上手く配信できたため、この環境で本番を迎えることを決めました。この際、登壇者側の音声を確認する工程が抜けてしまいました。

当日の流れ

4月24日18:00　前日までに配信テストできなかったLT登壇者とZoom内だけで最終確認をしました。

19:25　配信開始。直後から、多くの視聴者から「動画の再生が安定しない」「音声、映像ともに途切れている」とご報告を受けました。同タイミングでの同時視聴者数は1,100人を超えていました。

発表者メンバーやYouTube配信経験のある視聴者よりコメントやDMで「システムおよびサーバー負荷を下げるために、YouTube Live などで低遅延モードを使わない方が良い」と助言をいただき、19:35分頃にライブ配信を終了し、配信ソフト（OBS）および YouTube Live の低遅延モードを解除し、ビットレートをできる限り下げました。また、できる限りPCリソースを開けるために、配信以外のソフトウェアを停止しました。

19:40〜　新たに YouTube の配信URLを立ち上げ、connpass、および運営TwiterよりURL変更の案内を送信しました。再開したところ視聴者より「映像が安定している」とご報告いただき、勉強会本編を開始しました。

主催・運営から配信トラブルについてお詫び申しあげた上で、勉強会の開催背景を説明するところまでは大きな問題なく進めることができましたが、勉強会の司会進行であるまつもとりー氏が発言するパートになると、視聴者から「まつもとりー氏や、他の発表者の声が聞こえない」とコメントをいただき、音声配信に問題があることが発覚いたしました。

少なからず音声は聞こえているとのことだったため、会を進行しながら、配信用PC内のオーディオミキサーソフトにて配信用PC内で流れている音声から配信ソフトへの音声入力を段階的に上げて調整し、発表者側でもマイク音声入力を上げて調整いただいたものの、視聴者より「大きくなったが、まだ小さい」とコメントいただき、最終的に最大音量である +54db まで引き上げました。

すると、「Mac のエラー音は大音量で聞こえているが発表者の声が遠い。Zoom の音声出力のみ変更できないか？」とご提案いただいたため、Zoom のオーディオ設定を確認したところ、音声出力がオーディオミキサーソフトを介していないことが発覚し、直ちに出力先をオーディオミキサーソフトに修正しました。

しかし、Zoom における出力先を変更する前にPC内で流れている音声入力をミキサーで下げることを失念していたために、一時的に大音量で発表者の音声が再生されてしまい「音が大きすぎる。音割れしている」とご報告いただき、同時にYouTubeをモニタリングしていた運営の指示で、すぐにPC内で流れている音声および配信者マイクの音声入力を下げ調整しました。

※後日、配信者のヘッドフォンマイクから漏れた登壇者の音声を、同じヘッドフォンマイクが拾って配信されていた状態だったことがわかりました。

配信遅延が2~3分程度あったために、視聴者からの報告から対応までに2~3分、対応後視聴サイドに反映されるまで2~3分と時間を要したことに加え、視聴者から見た際に遅延していることがわからない状況が続き、不安を掻き立てました。

最終的に「今いい感じです」という多くのコメントを受けて、これ以上の調整は別のトラブルを生む可能性があると判断しチューニング完了といたしました。その際、Forkwell 運営にて基調講演をはじめからやり直していただくようお願いしました。

なお、やり直した時点でも、配信者のタイピング音が乗ってしまう問題は未解決のままだったため、配信者のZoomをミュートにしただけでなく、ハード側でもマイクをミュートにしました。しかし、タイピング音が拾われるというコメントは続きました。また、配信者がZoomから登壇者にチャットを送ろうとクリックするたびに 「ドゥン」というエラー音が鳴って拒否され、他のメンバーとコミュニケーションできない状態に陥っていました（Zoomのエラー音は視聴者にも配信されていました）。その後、配信者は、モバイルからZoom内チャットに参加しつつ、なるべく物音を立てないよう身を潜めていました。

※マイクをハード側でミュートにした後もタイピング音が聞こえるというコメントがあったのは、後日遅延の影響だったと理解しました。

※Zoomでチャットを開こうとするたびにエラー音が鳴ってチャットができなかった原因は今も不明です。

また、イベント終了時の挨拶をおえ、Zoom内のゲストが解散したタイミングで放送を終了にしたところ、遅延が生じている視聴者側の放送では終わりの挨拶の途中で放送が終了されてしまいました。

機材の設定

配信構成の振り返り

配信者PCシステムスペック

・MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports)

・OS　macOS Mojave 10.14.6（18G4032）

・プロセッサ　2.3 GHz Intel Core i5

・メモリ　8 GB 2133 MHz LPDDR3

・グラフィックス　Intel Iris Plus Graphics 640 1536 MB

通信速度

配信者の自宅マンションで有線接続しております。speedtest.net で事前に計測したところ、平均ダウンロード速度200Mbps、平均アップロード速度300Mbpsでした。

映像配信構成

・発表者画面｜各種プレゼンテーションツール → Zoom 画面共有 → OBS Studio（デスクトップ画面キャプチャ） → YouTube Live

・配信者画面｜プレゼンテーションツール → OBS Studio（デスクトップ画面キャプチャ） → YouTube Live

音声配信構成

配信当初の設定

チューニング後の設定

こうやって見ると、いかにカオスな設定をしていたかわかります…。

原因の考察

映像配信トラブルに関する3つの可能性

1. CPU負荷の可能性

・OBS Studio の負荷

・低遅延設定が負荷になっていた可能性を考慮し、解除した

・元の出力解像度は720p、2,000kbps だったものを、1,500kbpsまで下げた

・音声ビットレートを160から128に下げた

・キーフレーム間隔は推奨の2秒のまま

・CPU使用プリセットはveryfastのまま（10段階中3番目にCPU負荷が小さい設定）

・ソフトウェアエンコードの「x264」設定使っていた（これしか選択できなかった）

・Zoom 参加者増による負荷

・リハーサル時より参加者が多かった

・参加者が増えるほど、通信やCPUに負荷がかかるというコメントも

2. ストリーミングサーバー負荷の可能性

・YouTube Live での超低遅延設定による負荷

「超低遅延設定を解除し、デフォルト設定にしたほうが安定する」と視聴者コメントやDMからアドバイスをいただき、実際にデフォルトにしたところ、安定した配信ができるようになった。

3. エラー表示

・OBS Studio側上ではグリーン（安定配信できている状態）だった。

・YouTube：「動画の出力が低すぎます。YouTubeで受信している動画が少ないため滑らかなストリーミングを維持できません。視聴者側でバッファが発生します。」というエラーがでた

音声配信トラブルに関する2つの可能性

1. 音声配信構成の誤認識

・Zoom からミキサーに音声を送り出す設定が抜けていた（PC内で流れている音声を拾うようにしたら大丈夫だと思っていた。別のビデオチャットツールでは動作していたため、確認を怠った）。

・ヘッドフォンマイクの音声（配信者の声）をミキサーが取り込む設定にしていたが、ヘッドフォンからの出力（登壇者の音声）もそのマイクが取り込んで配信されている状態だった・

2. ヒューマンエラー

・事前テストが本番環境に即していない形で行われた。

・リハサール時に問題を見つけ設定を変えたが、その後の確認が十分にできていなかった。

・音声品質が改善されない状態で、本編と調整を並行して行う意思決定をした結果、突然大音量での音割れにつながった。

・配信者同士がリモートであることで生ずるコミュニケーションの取りづらさを考慮していなかった。

・別のPCでも配信できる状態がなかったため、長時間イベントが遅延した。

学習した13のこと

1. リハーサルで設定を変更した場合には、もう一度新しいリハーサルを行うこと

・リハーサルで設定を変更したあとに再度複数人でのリハーサルをしていなかった。また、これまであまり面識のなかった登壇者らに再度リハーサルの依頼をすることに対して、遠慮してしまった。わざわざ時間を作ってもらうまでもないだろう、という意識だった。

・配信者と、参加者では、音声・映像の取得経路が異なるので、両方でのテストが必要。

・最終リハーサルも兼ねて、YouTube Live の配信は本番30分前くらいから開始しておくと安心。発表者メンバーも含めた配信テスト、音声バランス、Zoomのフル稼働でCPU耐えられそうか、ライブ配信安定するか、最も本番に近い状況で確認ができる。

2. 安定配信を前提とした設定を作っておくこと

・通信、CPU負荷、ストリーミングサーバー負荷を考慮して、妥協可能な品質レベルの設定を準備しておき、いつでもこの状態に切り替えられるようにしておくこと。

3. 構成図を自分で書くこと

・配信者自らが、構成図を書くことで、思い込みだけで設定している箇所・理解できていない箇所が多々あることに気づいた。参考サイトを模倣するだけではなく、自分で何も見ずに書くことで理解できる。

4. オフラインイベントでのリハーサル体験に引きづられないこと

・オフラインイベントの場合は、登壇場所で、PCとスクリーンの接続確認レベルのリハーサルが一般的。オンラインでのリハーサルもそのレベルの温度感で進めていた。オンラインのほうが、その場でリカバリーできないことを意識して準備すること。

5. 遅延を前提としたコミュニケーションを設計すること

・低遅延モードを利用しても、当日のPC、YouTubeなどのコンディションや、参加者数によっては、遅延が生じる（または配信が止まる）ことがある。

・配信者と、視聴者で2~3分程度の遅延が生じる状態では、コメントスクリーンのような同期ツールが機能しにくい。

・2分前の発言に対する投稿が、流れてきて、それに対してコメントすると、2分後に視聴者に伝わる状況は、当初の目的を満たさない。

・OBS（と音声ミキサー）はコメントスクリーンを用いた相互コミュニケーション目的で導入したが、本番では遅延が生じて機能しなかった。遅延があってよい前提なら、ZoomとYouTubeを直つなぎだけで複雑な設定にならずよかった。ただ、OBSならウィンドウ配置を工夫できるなどのメリットもあるので、経験を糧に使いこなせるようになりたい。

・リアルタイムコミュニケーションについては、今後の課題。

6. 視聴者が、遅延を認知できる状況を作ること

・遅延していることが伝わる状態を作ると視聴者側が安心できる。

・「時計を表示しておくとよい」というコメントをいただきました。

7. 配信者の負荷を分散すること

・配信者が、OBS Studio配信、コメントスクリーン、Zoomのホスト、Zoomのレコーディング、ゲスト対応、会の中での挨拶などを行う状態だったので分散できるものは分散させる。

・何かあった際に対応できる空き容量を設けておくこと。

8. 代替手段を持っておくこと

・配信者以外が、すぐに配信できる状況を作っておくこと。

・配信者の自宅のネット状態が常に良いとは限らない。

9. モニター役を設けること

・本番からのフィードバックを、視聴者の声に委ねてしまった。

・実際に配信されている映像を、別の機体でモニタリングし続ける役を置き、その役の人が遅延のない状態で配信者とコミュニケーションできる状態を作ること。

・その人が配信終了を見届けるまで、配信を終了しないこと。

10. 問題が起きた場合は、その設定のまま進行を続けるか、止めて設定を見直すかのどちらかを選ぶこと

・極端な設定にしないといけない状況は、根本的な設定が間違っている可能性が高く、止めたほうが良い。

・止めたなら、最低限の音質・画質を満たした状態になるまで再開しない（どのタイミングで中止するか決めておく）。

・今回はバックアッププランを持たずに行ったので、続けるか辞めるかの判断ができるレベルでもなかった。プランBをもって、それを全て試してもだめなら中止とする、といった基準のもたせ方が望ましい。

例）プランAはOBS経由配信、プランBはZoomからの直配信、それでもダメなら配信者を変えて…等

・進行中の設定変更は、場数を踏んだ猛者だけに許された特権。

11. 配信者を含む運営スタッフは、同じ物理空間にいることが望ましい

・配信者全員がリモートで、チャットしかコミュニケーションできない状況では、迅速なコミュニケーションができず、判断が遅れる・間違える。また今回のように機材トラブルで連絡手段を断たれることもある。

・物理的に集まれない場合は、Slackチャネルなどで運営全員が集まれる状況を作っておき、配信者は、配信用PCとは別の連絡用PCを持っておくと安心。

12. 障害発生時に、意思決定者とオペレーターを分けること

・オペレーターが、自分で情報収集して、自分で判断している状況が良くなかったので、問題が起きた時点で判断する人と、実行する人を切り分けたところ、復旧スピードがあがった。

13. イヤフォンマイクなどの機種は、よく慣れたものを使うこと

・配信に向かないイヤフォンを用いていた（3000円台の製品）。

・購入がイベント1週間前で、マイクの特性を十分に理解するための時間がなかった。

・イヤフォンから出た音声が、イヤフォンマイクが拾ってしまう現象がなければ、登壇者の声が視聴者に聞こえないため、会を進めることはなかった。

振り返りは以上です。

映像・音声トラブルのない動画を YouTube にアップしましたので、配信トラブルで諦められた方はぜひご覧ください。登壇者の方々の発表は本当に素晴らしいものでした。

次回イベントのご案内

このようなトラブルがあったにも関わらず、次回イベントには既に1000人以上の方から参加申込をいただいております。ご期待いただき、本当にありがとうございます。

上記の反省をしっかり踏まえて、配信します。

Infra Study Meetup #2「VM時代の開発とCloud Native時代の開発」

謝辞

本投稿は、Forkwell で配信に携わった重本、赤川にて執筆しましたが、その際、技術顧問である松本亮介氏に振り返りへ同席、および助言をいただきました。また、本番中、視聴者の皆様より非常に多くの方からコメント・助言をいただいたことで、運営だけでは気づけないことを多々教えていただきました。最後まで本番をやり遂げられたのは、ご登壇頂いた方々と、コメントで応援し続けてくださった皆さんのおかげです。本当にありがとうございました。

Forkwell 運営：重本 湧気、赤川 朗

Forkwell 技術顧問：松本 亮介

追記　2020/05/01 00:35

マシンスペック、eGPUの存在、帯域の確保、アプリケーションの同時起動についてなど、いくつかコメントをいただいております。また、超低遅延モードで配信できなかった原因が究明できていない、アンチパターンではあるがベストプラクティスではない、といったご指摘もいただきました。

いただいたご意見を参考にしながら、1ヶ月後の配信に向けて、運営として用意できる範囲において機材の準備や専門家への相談、YouTube Live でのリハーサルを行うよう努めます。