Live Stream API

解決する課題

• ライブ映像をリアルタイムにエンコードし、視聴者の回線に合わせたアダプティブビットレート（ABR）配信を提供したい
• 自前のエンコーダ群を立てず、マネージドにライブトランスコード基盤を運用したい
• 1 つの入力から HLS と DASH など複数フォーマット、複数解像度を同時に生成したい
• 配信中に静止画やテロップなどのオーバーレイを差し込んだり、**広告挿入（SCTE-35）**の目印を扱いたい

主要概念と用語

• チャンネル (Channel): ライブ配信の中心となるリソース。入力をどのフォーマット・解像度・ビットレートに変換し、どこへ出力するかを定義する。配信の「設定一式」にあたる
• 入力エンドポイント (Input Endpoint): エンコーダや配信元が映像を送り込む受け口。RTMP / RTMPS / SRT などのプロトコルを受け付ける
• イベント (Event): 配信中のチャンネルに対して実行する操作。広告挿入の目印、スレート（差し替え静止画）、オーバーレイの表示・非表示などをタイムライン上で指示する
• エレメンタリストリーム / Mux ストリーム: 個々の映像・音声トラックを定義するエレメンタリストリームと、それらをまとめて 1 本のセグメントにするMux ストリーム。ABR の各画質はこの組み合わせで表現する
• マニフェスト (Manifest): 各画質セグメントへの索引となる **HLS（m3u8）/ DASH（mpd）**の再生リスト。プレーヤーはこれを見て回線に応じた画質を切り替える
• 出力先 (Output): 生成したセグメントとマニフェストを書き出す Cloud Storage バケット。視聴者へはこのバケットを起点に CDN 経由で届ける

仕様・制限・クォータ

• 入力は RTMP/RTMPS/SRT などのライブプロトコルを受け付け、出力は HLS と DASH のアダプティブ配信を生成する。1 入力から複数解像度・複数ビットレートを同時出力できる
• 出力セグメントとマニフェストは Cloud Storage へ書き出される。視聴配信そのものは Live Stream API ではなく、その先の CDN が担う
• チャンネルはリージョナルなリソースとして作成し、利用可能なリージョンは限られる。入力エンドポイントはチャンネルと同一プロジェクト・リージョンで扱う
• 同時チャンネル数や入力数にはプロジェクト単位のクォータがあり、必要に応じて引き上げを申請する。具体的な上限値は変動するため公式ドキュメントで確認する
• SCTE-35 による広告挿入の目印、スレート差し替え、画像オーバーレイなどの運用操作に対応する

内部の仕組み

Live Stream API は、入力エンドポイントで受け取ったライブ映像をマネージドなトランスコードパイプラインに流し込み、チャンネル定義に従って複数のエレメンタリストリーム（解像度・ビットレートの異なる映像、音声）へ並列に変換します。変換結果は Mux ストリーム単位で短いセグメントに分割され、各画質への索引である HLS/DASH マニフェストとともに出力先の Cloud Storage バケットへ継続的に書き出されます。

プレーヤーはまずマニフェストを取得し、視聴者の回線品質に応じてセグメント単位で画質を切り替えます（アダプティブビットレート）。配信中のイベント（広告マーカー、スレート、オーバーレイ）はチャンネルのタイムラインに対して非同期に適用され、出力されるセグメントやマニフェストに反映されます。エンコード基盤のスケールや冗長性は Google 側で管理されるため、利用者はチャンネルと入力の設定に集中できます。

設計パターン / ベストプラクティス

• 入力（RTMP/SRT）→ Live Stream API → Cloud Storage → CDN → プレーヤーの経路を基本構成にする。エンコードと配信のレイヤを明確に分ける
• ABR は複数の解像度・ビットレート段を用意し、低速回線でも視聴が途切れないようにする。段数は配信品質と出力コストのトレードオフで決める
• 入力の冗長性が必要な配信では、バックアップ入力を用意して主入力の途切れに備える。プロトコルは安定性重視なら SRT も選択肢になる
• 広告挿入は SCTE-35 の目印をイベントとして挿入し、サーバーサイド広告挿入（SSAI）の仕組みと連携させる
• 配信前に必ず短時間のリハーサル配信で入力到達・マニフェスト生成・プレーヤー再生まで通しで確認する

運用・監視

• Cloud Monitoring / Cloud Logging でチャンネルの状態、入力の接続状況、エラーを監視する。入力が途切れるとセグメント生成が止まるため、入力到達の監視が最優先
• チャンネルには開始・停止のライフサイクルがあり、配信していない間は停止しておくとリソースとコストを抑えられる
• 出力先 Cloud Storage に新しいセグメントが書き出され続けているかは、配信が健全かどうかの実用的な指標になる
• 障害時に切り分けやすいよう、入力プロトコル・ビットレート・チャンネル設定を標準化し、再現可能なテンプレートとして管理する

コスト

• 課金は概ねチャンネルが稼働している時間と、出力する解像度・ビットレート段の構成に依存する。高解像度・多段の ABR ほど処理量が増える
• 配信していないチャンネルは停止しておくことが最も効くコスト最適化。常時起動は必要な時間だけに絞る
• これに加えて、出力先 Cloud Storage の保管・読み出しと、視聴者への**配信トラフィック（CDN）**の費用が別途かかる。総額はエンコード単体では決まらない
• 具体的な単価は変動するため、断定せず料金ページで最新の体系を確認する

セキュリティ

• API 呼び出しやチャンネル操作は IAM で最小権限に制御する（AWS の IAM ロール相当）。チャンネルの作成・更新・配信操作を担うサービスアカウントには必要な権限のみを付与する
• 入力エンドポイントは推測されにくいエンドポイント情報の管理と、可能なら RTMPS / SRT など暗号化・認証に対応したプロトコルの利用でなりすまし配信を防ぐ
• 出力先 Cloud Storage バケットへの書き込みは Live Stream API のサービス権限に限定し、公開範囲は CDN 経由の配信に必要な最小限にとどめる
• 保存データは Google 管理鍵で既定暗号化され、要件に応じて **CMEK（顧客管理鍵, Cloud KMS）**の適用を検討する

Well-Architected の観点

• 信頼性 (reliability): エンコード基盤は Google がマネージドに冗長化する。利用者側はバックアップ入力や入力監視で、配信元（カメラ・エンコーダ・回線）の単一障害点を減らすことに注力する
• パフォーマンス効率 (performance): ABR の段構成を視聴環境に合わせて設計し、配信は CDN にオフロードしてオリジン負荷とレイテンシを抑える。解像度・ビットレートはエンドユーザの体感とコストの両面から最適化する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 前提: livestream.googleapis.com を有効化済み、出力先バケットを用意済み

# 1) ライブ入力エンドポイント（RTMP）を作成
gcloud livestream inputs create my-input \
  --location=us-central1 \
  --type=RTMP_PUSH

# 2) 入力に紐づくチャンネルを JSON 定義から作成（出力先は Cloud Storage）
#    channel.json に elementaryStreams / muxStreams / manifests / output を定義
gcloud livestream channels create my-channel \
  --location=us-central1 \
  --input-attachments=my-input \
  --channel-from-file=channel.json

# 3) 配信を開始（チャンネルを起動）
gcloud livestream channels start my-channel --location=us-central1

# 4) 状態と入力エンドポイント情報を確認（このURLにエンコーダから送出する）
gcloud livestream channels describe my-channel --location=us-central1
gcloud livestream inputs describe my-input --location=us-central1

# 5) 配信終了後はチャンネルを停止してコストを抑える
gcloud livestream channels stop my-channel --location=us-central1