「ライブ配信を開始」を押すと実際に何が起きているのか：配信の舞台裏

「ライブ配信を開始」は、ボタンを押せばライブになる、ひとつの操作に見えます。しかしその裏では、短い一連の実際の手順が動いており、その一つひとつが成功または失敗しうるポイントです。おおまかな流れを理解しておくと、トラブルの原因探しがずっとわかりやすくなります。

ステップ1：配信ではなく、リクエスト

「ライブ配信を開始」をクリックしても、それだけで映像が動き出すわけではありません。「このアカウントのこの配信を開始してください」というリクエストがバックエンドの処理に送られます。その処理の最初の仕事は配信ではなく検証です。このアカウントに、今もう1つライブ配信を始められる有効なプランがあるか。送り先となる有効な配信先（ストリームキーや連携済みのYouTubeチャンネル）があるか。プレイリストの準備は本当にできているか（すべての動画の処理が終わっているか）を確認します。

そのため、この段階での失敗はたいてい即座に、具体的な内容で表示されます。「先にストリームキーを追加してください」「プランの同時配信数の上限に達しました」といったもので、あいまいなクラッシュではありません。うまくいかないとわかっているものを、リソースを使って試す前に、システムが開始を断っているのです。

ステップ2：ワーカーへの引き渡し

検証が終わると、映像を送り出す実際の仕事は別のプロセスに引き渡されます。この種のシステムでは一般に「ワーカー」と呼ばれ、1つの配信のエンコードと送信のループを動かすことだけが役割です。これをリクエスト処理の段階と分けておくことには意味があります。「ライブにできるか」を検証する部分と、そのあと何時間も何日も動き続けなければならない部分が別になるので、どこか1か所が故障してもシステム全体が影響を受けにくくなります。

ステップ3：RTMP接続を開く

ワーカーは配信先（RTMP URLとストリームキー）を受け取り、その配信先への継続的な接続を開きます。これはRTMPの解説記事で詳しく説明しているのと同じ仕組みです。ここから先はライブのパイプになり、何かが止めるまで映像データが一方向に流れ続けます。

ステップ4：準備済みの映像を送る

動画がアップロード時にそろった形式へ正規化されていれば（この瞬間に初めて処理されるのではなく）、このステップの負荷は比較的軽くなります。ワーカーは重いエンコード作業をリアルタイムで行うのではなく、すでに正しい形式になったファイルを読み込んで送り出しているだけだからです。プレイリストの変更が配信を再起動せずに反映されるのもこのためです。ワーカーは接続全体を切って組み直す必要はなく、次のクリップの切れ目で更新された順番を読み込むだけです。

ステップ5：継続的なヘルスチェック

よく作られたシステムは、接続を始めたらそれで終わりではありません。ワーカーのプロセスが本当にまだ動いているか、データを正常に送り続けているかを確認し続けます。そのため何かが失敗しても、人が気づくまで止まったままになるのではなく、検知されて自動再起動につなげられます。

二度と考えることがなくても、これが役立つ理由

ほとんどの場合、こうしたことは何も見えません。「ライブ配信を開始」をクリックすれば、1分後にはライブになっています。これが役に立つのは、うまくいかないときです。問題が上流（検証の段階で、ストリームキーがない、プランの上限など）にあるのか、下流（実際の接続で、ネットワークの問題、止まったワーカーなど）にあるのかを見極めようとするとき、1つの見えないブラックボックスではなく実際の手順があると知っていれば、原因をより早く突き止められます。

よくある質問

なぜ一瞬ではなく、ライブになるまで数秒かかるのですか？

検証とワーカーへの引き渡しには、わずかですが実際に時間がかかります。プランの上限の確認、プレイリストの準備の確認、RTMP接続の確立が、映像が実際に流れ始める前にすべて行われます。

配信がすぐに失敗した場合、映像は一度でも送信されようとしたのですか？

たいていはされていません。プランの上限やストリームキーの未設定のように、即座に具体的な内容で失敗する場合は、ワーカーのプロセスやRTMP接続が関わる前に、検証の段階でリクエストが拒否されたということです。

手動で貼り付けたストリームキーと連携済みのYouTubeアカウントで、この流れは違いますか？

基本的な流れは同じです。連携済みのアカウントでは、その前に、YouTubeのAPIを通じて配信そのものを（タイトル、説明、サムネイルとともに）作成するステップが加わります。そこで得られたストリームキーは、手動で貼り付けたものと同じように使われます。