動画配信プラットフォームの立ち上げを一緒に始めませんか？
ハードウェアエンコーダー、専用線接続、MediaLive VPC Input、冗長化設計を活用し、放送設備からAWS上のOTT配信基盤へ複数のスポーツライブチャンネルを安定配信するための設計事例
はじめに：スポーツライブ配信は安定した映像取り込みから始まる
多くのOTT配信プロジェクトでは、映像のパッケージング処理、CDN、再生プレイヤー向けSDK、視聴分析といった要素から議論が始まることがあります。もちろん、これらはOTT配信において重要な構成要素です。
しかし、スポーツライブ配信において最も重要な問いは、もっと前段階にあります。
それは、放送設備から出力されるライブ映像信号を、いかに安定して、継続的に、かつ制御可能な形でクラウド上のOTT配信基盤へ取り込むかという点です。
言い換えると、ライブ配信の処理フローは、再生プレイヤーやCDNから始まるのではありません。放送ソース、つまり現場や放送設備から出力される映像信号から始まります。
スポーツライブ配信では、数秒の映像停止や信号断でも視聴体験に大きな影響を与える可能性があります。再生開始時間の最適化も重要ですが、その前提として、映像ソースからクラウド側の取り込みポイントまでの映像伝送が安定している必要があります。
今回のプロジェクトでは、放送設備から複数のライブチャンネルを同時にクラウド上のOTT配信基盤へ伝送する必要がありました。そのため、映像取り込みシステムには、継続性、信頼性、運用時の可視性、そしてトラブル発生時の制御性が求められました。
一方で、元々の映像処理フローは、従来型の放送環境向けに設計されており、クラウド上で動作するOTT配信システム向けの構成ではありませんでした。そのため、放送設備の出力とクラウド側の映像取り込みの仕組みの間にはギャップがありました。
この課題を解決するために、私たちは放送環境とクラウドOTT環境の間に「橋渡し」となる構成を設計しました。具体的には、放送信号をハードウェアエンコーダーでIP映像ストリームへ変換し、AWS Direct Connectによる専用線接続を通じて、AWS Elemental MediaLiveのVPC Inputへ安定的に取り込む構成です。
プロジェクトの要件と制約
スポーツライブ配信向けの安定した配信システムをクラウド上に構築するためには、技術面と運用面の両方で要件を明確にする必要がありました。
これらの要件は、単に視聴者体験から来るものだけではありません。既存の放送設備の特性や、ライブイベント運用における実務上の制約も大きく関係しています。
1. 複数チャンネルのスポーツライブ配信
システムは、合計5つのライブチャンネルを同時に処理する必要がありました。
そのため、映像取り込みと処理の構成は、複数の映像ストリームを並列に扱えるだけでなく、各チャンネルの安定性を損なわずに拡張できる設計である必要がありました。
単一チャンネルのライブ配信であれば、問題が発生した際の影響範囲は限定的です。しかし、複数チャンネルが同時に稼働するスポーツライブ配信基盤では、ネットワーク、エンコーダー、取り込みエンドポイント、処理パイプラインのいずれかに問題が起きると、複数の配信に影響が広がる可能性があります。
2. 放送設備からの安定したライブ映像取り込み
放送設備からの映像フィードは、継続的かつ中断なくクラウドへ送信される必要があります。
これは最も重要な要件でした。なぜなら、映像取り込みはライブ配信全体の出発点だからです。ここが不安定であれば、その後段にあるMediaLive、映像パッケージング、CDN、再生プレイヤーのどれを最適化しても、最終的な視聴体験は安定しません。
実際、放送設備からの信号は、放送局や制作設備の内部では比較的安定しています。しかし、その信号を外部へ出し、クラウドへ取り込む段階では、ネットワークの揺らぎ、パケットロス、ルーティングの問題、ファイアウォール設定ミス、プロトコル設定の不一致など、さまざまなリスクが発生します。
そのため、映像取り込みシステムは、これらのリスクをできる限り低減するように設計する必要がありました。
具体的には、適切なプロトコルの選定、バッファ設定、ネットワーク経路の安定性、入力断の早期検知、障害発生時の迅速な切り分けが重要になります。
3. 視聴者向けの再生開始時間の最適化
視聴者が動画を再生開始するまでの時間は、ライブ配信サービスの体験品質に大きく影響します。
特にスポーツライブ配信では、視聴者はリアルタイム性を期待しています。そのため、再生開始が遅い、途中で止まる、画質が不安定になると、サービス全体への信頼性が低下します。
ただし、再生開始時間の最適化は、再生プレイヤーやCDNだけで完結するものではありません。入力側の映像ストリームが不安定で、ネットワークの揺らぎやパケットロスの影響を受けている場合、後段の処理でも安定した配信を実現することは困難です。
つまり、視聴者の再生体験は、最初の映像伝送の安定性に大きく依存します。
4. ハードウェアエンコーダーを使った映像伝送
今回の放送ソースはHDMIで出力されるため、その信号をクラウドへ送るにはハードウェアエンコーダーを利用してIP映像ストリームへ変換する必要がありました。
具体的には、RTMPやRTPなど、クラウド側の映像取り込みに適した形式へ変換します。
このエンコーダーは、単なる変換機器ではありません。映像品質と映像取り込みの安定性を左右する重要な構成要素です。
エンコーダーは、映像と音声をエンコードする際に、ビットレート、解像度、フレームレート、GOP構造、キーフレーム間隔などの設定を担います。これらの設定は、映像品質だけでなく、取り込み映像ストリームの安定性にも直接影響します。
また、エンコーダーはシステム上のエッジ機器としても機能します。再接続処理、映像バッファリング、取り込み先エンドポイントのフェイルオーバーなどを設定できるため、ネットワークやクラウド側の映像取り込みで問題が発生した際の挙動にも関係します。
そのため、エンコーダーの選定と設定は、単なる機材選びではなく、ライブ配信基盤全体の設計の一部として考える必要があります。
適切に設定されたエンコーダーは、ネットワークや後段処理への負荷を軽減します。一方で、設定が不適切なエンコーダーは、ライブ配信システム全体に不安定要因を持ち込む原因になります。
5. クラウドへの専用線接続
今回の映像取り込み経路は、パブリックインターネットに全面的に依存することはできませんでした。
代わりに、専用線接続、つまりプライベート接続を利用し、ルーティングの安定性、パケットロスの低減、伝送経路の制御性を確保する必要がありました。
具体的には、オンプレミス側のハードウェアエンコーダーがRTMP映像ストリームを社内ネットワークへ送信し、その通信がファイアウォールとルーターを通過した後、AWS Direct Connect経由でAWSへ入ります。
その後、通信はDirect Connect GatewayとVirtual Private Gatewayを通じてVPCへ入り、プライベートサブネット内に配置されたAWS Elemental MediaLiveの取り込みエンドポイントへ到達します。
この構成により、エンコーダーからMediaLive Channelまでの映像取り込み経路全体を、制御可能なネットワーク経路上で運用できます。
パブリックインターネットで起こり得る経路変更、混雑、予測しにくいパケットロスなどの影響を避けやすくなります。
さらに、専用線接続を使うことで、ファイアウォールルールやセキュリティグループの設計もシンプルになり、ライブ運用中の監視や障害切り分けもしやすくなります。
6. 予備エンコーダーの準備
5つのライブチャンネルに対応するために、5台のメインエンコーダーを利用しました。
それに加えて、2台の予備エンコーダーも準備しました。
これにより、ライブイベント中にエンコーダーの故障や設定トラブルが発生した場合でも、速やかに予備エンコーダーへ切り替えられるようにしました。
スポーツライブ配信では、障害が起きてから機材を探したり、設定を作り直したりする時間はありません。そのため、予備エンコーダーは事前に設定を準備し、実際に切り替え手順を確認しておく必要があります。
7. ライブイベント中の運用監視と可視性
ライブイベント中、運用チームはエンコーダー、ネットワーク、クラウド側の取り込みエンドポイント、MediaLive Channel、出力映像ストリームの状態を把握できる必要があります。
そのためには、監視、アラート通知、障害切り分けの仕組みが重要です。
特にスポーツライブ配信では、問題を早期に検知し、影響が大きくなる前に対応することが求められます。入力断、ビットレートの異常、エンコーダー切断、BGPセッションの停止などを素早く検知できる設計が必要です。
全体アーキテクチャ
全体の構成は、大きく2つの領域に分かれています。
- オンプレミス側
- AWS Cloud側
処理の流れは、オンプレミス側の放送設備から始まります。放送信号はハードウェアエンコーダーによってIP映像ストリームへ変換され、専用線接続を通じてAWSへ送られ、AWS Elemental MediaLiveのVPC Inputへ取り込まれます。
この構成により、従来の放送設備とクラウド上のOTT配信基盤を安全かつ安定的につなぐことができます。
オンプレミス側の構成
オンプレミス側は、ライブ配信全体の出発点です。
ここでは、放送ソースを受け取り、クラウドへ取り込むための映像ストリームへ変換します。
今回の構成では、従来型の放送環境からOTT / IPベースの配信フローへ、安定的かつ制御可能な形で変換することを目的としました。
オンプレミス側の主な構成要素は以下の通りです。
放送設備
放送設備は、既存の制作システムまたは放送システムからライブ映像信号を提供します。
これは、OTT配信基盤へ配信されるスポーツチャンネルの元映像となる映像ソースです。
ハードウェアエンコーダー
ハードウェアエンコーダーは、放送設備からHDMI信号を受け取り、それをIP映像ストリームへエンコードします。
今回の構成では、エンコーダーはRTMP映像ストリームをクラウド側の取り込みエンドポイントへ送信するように設定しました。
このRTMP映像ストリームは、パブリックインターネットではなく、プライベートなネットワーク経路を通じてAWS側へ送信されます。
Firewall / Edge Security Gateway
FirewallまたはEdge Security Gatewayは、映像ストリームが専用線接続へ入る前に、セキュリティポリシー、通信制御、アクセス制御を実施します。
これにより、許可された通信のみが通過できるようになり、ライブ運用中の監視や障害切り分けにも役立ちます。
専用線ルーター / キャリアルーター
専用線ルーターまたはキャリアルーターは、オンプレミス環境とAWSへ向かうプライベートなネットワーク経路を接続します。
ここから通信は、パブリックインターネットではなく、専用の接続経路へルーティングされます。
このように、エンコーダーからのRTMP映像伝送は、独立した制御可能なネットワーク経路を通るため、スポーツライブ配信に必要な映像取り込みの安定性を確保しやすくなります。
AWS Cloud側の構成
AWS Direct Connect
AWS Direct Connectは、オンプレミス環境とAWSをプライベートに接続するための接続ポイントです。
今回の構成では、エンコーダーからのRTMP映像取り込み通信を、パブリックインターネットではなくAWS Direct Connect経由でAWSへ送信しました。
これにより、ルーティングをより安定させ、遅延やパケットロスの予測可能性を高めることができます。
Direct Connect Gateway
Direct Connect Gatewayは、AWS Direct ConnectとAWS側のVPCを接続するために利用します。
この構成要素は、オンプレミス側ネットワークとAWS側ネットワークの間でBGPを通じてルーティング情報を交換する中間レイヤーとして機能します。
Virtual Private Gateway
Virtual Private Gatewayは、VPCに接続され、Direct Connect Gatewayからの通信を受け取ります。
オンプレミス側のCIDRからの通信は、Virtual Private Gatewayを通じてVPCのルートテーブルへ伝播されます。
VPC Route Tables
プライベートサブネットのルートテーブルでは、オンプレミス側CIDRからの通信をVirtual Private Gateway経由でルーティングするように設定します。
これにより、オンプレミス側のエンコーダーがMediaLiveの取り込みエンドポイントへ、プライベートなネットワーク経路を通じて到達できるようになります。
Private subnets
AWS Elemental MediaLiveの取り込みエンドポイントは、プライベートサブネット内に配置します。
これにより、映像取り込みフローをインターネットへ直接公開せず、より制御されたネットワーク環境で運用できます。
Security Groups
MediaLive Inputのセキュリティグループでは、オンプレミス側のプライベートIP CIDR範囲からのRTMP通信、つまりTCP port 1935のみを許可します。
これにより、取り込みエンドポイントへ映像ストリームを送信できる送信元を制限し、システム全体のセキュリティ制御を強化できます。
MediaLive VPC Input Endpoints
MediaLive VPC Input Endpointsは、オンプレミス側のハードウェアエンコーダーから送られるRTMP映像ストリームを受け取る取り込みポイントです。
これらのエンドポイントは、VPC Inputの構成を通じて、プライベートネットワーク内で動作します。
MediaLive Channel / Media Output
MediaLiveは、取り込まれた映像ストリームを受け取り、デコード、トランスコード、出力映像ストリームの生成などのライブ映像処理を実行します。
その後、映像ストリームはMediaPackage、CDN、再生プレイヤー基盤などの後段サービスへ渡されます。
Amazon CloudFront CDN
Amazon CloudFront CDNは、最終的な視聴者へコンテンツを配信するために利用します。
世界規模でのコンテンツ配信が可能であり、再生遅延の最適化にも役立ちます。
再生プレイヤー / 視聴者
視聴者はOTT再生プレイヤーを通じてライブコンテンツへアクセスします。
再生プレイヤーはCDNから映像ストリームを受け取り、テレビ、タブレット、スマートフォンなどのデバイス上で再生します。
この設計により、オンプレミス側のエンコーダーからAWS上のMediaLive Inputまでの映像取り込みフローを、ルーティング、セキュリティ、運用可視性の観点から明確に制御できます。
なぜ専用線接続が必要だったのか
小規模なライブイベントや検証環境では、パブリックインターネット経由の映像取り込みが最初の選択肢になることがあります。
しかし、スポーツライブ配信では、映像取り込みは単なるデータ転送ではありません。放送システムの一部として扱うべき重要な処理フローです。
スポーツ中継では、数秒の中断でも視聴者体験に影響します。特に有料配信や大規模イベントの場合、映像停止や品質劣化は、サービス品質だけでなく、事業上の信頼にも関わります。
パブリックインターネットの最大の課題は、帯域そのものではなく、予測しにくさです。
ルーティングはISPやインターネット全体の経路状況に依存し、時間帯によって混雑が発生することがあります。また、パケットロスやネットワークの揺らぎも完全には制御できません。
スポーツライブ配信では、こうした不確定要素は大きなリスクになります。
ライブ映像取り込みにおける専用線接続とパブリックインターネットの比較
| 項目 | 専用線接続 / Private Connectivity | Public Internet |
| ルーティング | BGP、ASN、経路優先度、フェイルオーバーを通じて制御しやすい。経路が明確で、予期しない変更が起きにくい。 | ISPやインターネット全体の経路状況に依存する。予期しない経路変更が発生する可能性がある。 |
| 安定性 | 外部通信の混雑の影響を受けにくく、安定性が高い。 | 時間帯やISPの混雑の影響を受けやすい。 |
| パケットロス / jitter | 低く安定しやすく、測定・最適化しやすい。 | ネットワーク混雑時に急増する可能性がある。 |
| 遅延 | 一貫性があり、予測しやすい。継続的なライブ映像取り込みに適している。 | 不安定になりやすく、突発的な遅延増加が発生する可能性がある。 |
| 帯域の安定性 | 帯域が安定しやすく、時間による変動が少ない。 | 多くのネットワーク要因により帯域が変動する。 |
| セキュリティ | プライベートな経路を通るため、パブリックインターネットへ直接公開されず、攻撃面を減らせる。 | インターネット上に公開されるため、VPN、TLS、IP許可リストなど追加対策が必要になる。 |
| 障害切り分け | エンコーダー、Direct Connect、クラウドなど、レイヤーごとに問題を切り分けやすい。 | ISPや中間ルーターなど制御外の要素が多く、原因特定が難しい。 |
| 監視性 | BGP、インターフェース状態、通信量などを段階的に監視しやすい。 | 経路全体の可視性が限定的。 |
| フェイルオーバー制御 | primary / secondary pathを設計し、BGPで制御しやすい。 | フェイルオーバー動作がISP側の挙動に依存しやすい。 |
| 適した用途 | スポーツライブ配信、放送品質の映像取り込み、大規模イベント、高い安定性が求められる配信。 | 小規模イベント、重要度の低いライブ配信、検証環境。 |
安定性を確保するために、今回の構成ではAWS Direct Connectを利用し、オンプレミス側のエンコーダーからクラウドまでのプライベートな映像取り込み経路を構築しました。
これにより、パブリックインターネットのベストエフォート接続に依存せず、ルーティング、遅延、監視性をより制御しやすいネットワーク経路を実現しました。
AWS Direct Connect
AWS Direct Connectは、オンプレミスのデータセンターとAWS基盤の間に専用の高速接続を確立するサービスです。
この接続はパブリックインターネットとは分離されており、AWSリソースへ安全性、安定性、低遅延の観点でより安定したアクセスを提供します。
大容量データ転送、重要なワークロード、高い安定性が求められるシステムにおいて、AWS Direct Connectは有効な選択肢になります。
AWS Direct Connectには、主に2つの接続タイプがあります。
- Dedicated Connection
- Hosted Connection
1. Dedicated Connection
Dedicated Connectionは、AWSが直接提供する物理接続です。
オンプレミスのデータセンターとAWS Direct Connect locationの間に専用の物理接続を確立します。
大きな帯域、高い安定性、専用ネットワーク基盤の運用が必要なシステムに向いています。
2. Hosted Connection
Hosted Connectionは、AWS Direct Connect Partnerによって提供・管理される接続です。
Dedicated ConnectionではAWSが物理接続を直接提供しますが、Hosted ConnectionではPartnerが管理する共有基盤を利用します。
Partnerが物理基盤や接続の準備を担当し、利用企業はその接続を通じてAWSリソースへアクセスします。
Hosted Connectionの主な特徴
初期投資を抑えやすい
Hosted Connectionでは、物理基盤をAWS Direct Connect Partnerが管理するため、自社で専用ネットワーク機器を準備する必要がありません。
そのため、Dedicated Connectionと比べて初期投資を抑えやすい場合があります。
柔軟に拡張しやすい
Hosted Connectionでは、比較的小さな帯域から開始し、利用状況に応じて拡張することが可能です。
提供される帯域はPartnerやリージョンによって異なりますが、実際の通信量や事業要件に合わせて選択できます。
Partner管理のサービスとして利用できる
接続の準備やネットワーク側の設定をPartnerが担当するため、社内エンジニアリングチームの運用負荷を軽減できます。
複数の帯域オプション
Hosted Connectionでは、Partnerやリージョンによって、50 Mbpsから10 Gbps程度までのさまざまな帯域オプションが提供されることがあります。
比較的短期間で導入しやすい
物理基盤がPartner側で準備されているため、Dedicated Connectionよりも短期間で導入できる場合があります。
これにより、クラウドワークロードやライブ配信基盤をより早く本番環境へ移行しやすくなります。
AWS Direct Connect設定の全体手順
AWS Direct Connect Hosted Connectionを設定するには、オンプレミス基盤、AWS Direct Connect Partner、AWSの間で複数の作業を連携して行う必要があります。
以下は、設定の全体的な流れです。
Step 1: AWS Direct Connect Partnerを選定する
まず、対象リージョンで接続を提供でき、事業要件およびネットワーク要件に合うAWS Direct Connect Partnerを選定します。
AWS Direct Connect locationsや対応Partnerは、AWSの公式ドキュメントで確認できます。
Step 2: Hosted Connectionを依頼する
帯域とPartnerを選定した後、AWS Direct Connect PartnerへHosted Connectionの準備を依頼します。
Partnerは必要な基盤を準備し、自社側ネットワークからAWS Direct Connect locationまでの接続を構築します。
今回のプロジェクトでは、日本国内でNTT Communicationsが提供するAWS Direct Connect Hosted Connectionを利用し、オンプレミス環境とAWSの間に専用線接続を構築しました。
ただし、用途やリージョンによっては、他のAWS Direct Connect Partnerを利用することも可能です。
NTT FIC connectionの構成概要
NTT Flexible InterConnect、つまりNTT FICを利用した接続構成は、大きく2つの部分に分けられます。
- 企業またはオンプレミス環境からArcstar Universal Oneを通じてNTT Flexible InterConnectへ接続する部分
- FIC RouterからAWS Direct Connect Private VIFを通じてAWSへ接続する部分
1. 企業 / オンプレミスからArcstar Universal One経由でNTT FICへ接続
企業ネットワークをFIC Routerへ接続するために、NTT側ではArcstar Universal One、略してUNOをプライベートなL3ネットワーク経路として利用します。
これは、利用者拠点とFlexible InterConnect基盤を接続するためのプライベートネットワーク経路です。
主な構成要素は以下です。
- UNO routing group
- Primary/secondary connection
- BGP peering
- Customer ASN
- VPN / routing information
- 企業ネットワークとFIC Router間のroute advertisement
2. FIC RouterからAWS Direct Connect Private VIF経由でAWSへ接続
FIC RouterからAWSへ接続する部分には、以下のような構成要素が含まれます。
- AWS Direct Connect Hosted Connection
- Private Virtual Interface、つまりPrivate VIF
- BGP peering
- ASN configuration
- Direct Connect Gateway、つまりDXGW
- Virtual Private Gateway、つまりVGW
NTT側で準備が完了し、Private VIFが作成された後、エンジニアはAWS Direct Connect Consoleにアクセスし、Virtual Interfaceを承認する必要があります。
この承認が完了して初めて、BGP接続が完全に機能する状態になります。
また、本番運用前には、primaryとsecondaryの2つのVIF経路が正しく利用可能な状態になっていることを確認する必要があります。
Step 3: Direct Connect Gatewayを作成する
Hosted ConnectionとPrivate VIFの準備が完了した後、AWS側でDirect Connect Gatewayを作成します。
大まかな手順は以下です。
- AWS Direct Connect Consoleを開く
- Direct Connect gatewaysへ移動する
- Create Direct Connect gatewayを選択する
- 必要な情報を入力する
- Direct Connect Gatewayを作成する
主な設定項目は以下です。
- Name： Direct Connect Gatewayを識別するための名前
- Amazon side ASN：BGPセッションでAmazon側に利用するASN
Amazon side ASNは、AWSがサポートする範囲内で指定する必要があります。たとえば、64,512〜65,534、または4,200,000,000〜4,294,967,294の範囲が利用できます。
Step 4: Virtual Private Gatewayを作成する
Direct Connect Gatewayを作成した後、Virtual Private Gatewayを作成し、対象のVPCへ接続します。
大まかな手順は以下です。
- AWS Management Consoleを開く
- VPCへ移動する
- Virtual Private Gatewaysを選択する
- Create Virtual Private Gatewayを選択する
- nameとASNを入力する
- 対象のVPCへVirtual Private Gatewayを接続する
ASNは、64512のようなdefault valueを使うこともできますし、ネットワーク設計に応じてcustom private ASNを指定することもできます。
Virtual Private Gatewayを作成した後は、MediaLive VPC Inputを配置するVPCへ接続します。
Step 5: プライベートサブネットのルートテーブルを更新する
ルートテーブルを更新することで、オンプレミス基盤とAWSサービス間の通信がパブリックインターネットではなく、AWS Direct Connectを通るようにします。
大まかな手順は以下です。
- Amazon VPC Consoleを開く
- Route Tablesへ移動する
- 対象のVPCまたはプライベートサブネットに関連付けられたルートテーブルを特定する
- Edit routesを選択する
- オンプレミスネットワークのCIDR block向けrouteを追加する
- targetとしてDirect Connectに関連付けられたVirtual Private Gatewayを選択する
例：
- Destination：オンプレミスネットワークのCIDR block、例：192.168.0.0/16
- Target： Direct Connectに関連付けられたVirtual Private Gateway
ルートテーブルが正しく設定されると、オンプレミス側のエンコーダーネットワークとAWS側のプライベートサブネット間の通信がDirect Connect経路を通るようになります。
エンコーダー選定：放送設備とOTT配信をつなぐ橋渡し
市場には多くのエンコーダーがあります。
海外では、ATEMEのTITANやKyrion、Harmonic、Haivision、VIDEONなどが知られています。日本国内では、NTT Innovative DevicesやFujitsuなどのメーカーも選択肢になります。
今回のプロジェクトでは、いくつかのエンコーダーを実際にテストし、OTT配信基盤へ映像ストリームを送信する検証を行いました。その結果、技術要件と運用要件に最も適していたVIDEONを採用しました。
65インチのテレビ画面で安定した映像品質を確保するためには、少なくとも1080p、ビットレートは約5.4 Mbps以上のエンコード設定が必要でした。
エンコーダーは、HDMIをRTMPへ変換するだけの機器ではありません。
映像伝送フローにおいて、映像品質、取り込みの安定性、障害発生時の復旧能力に直接関わる重要な構成要素です。
MediaLiveへのVPC経由の映像取り込み
AWS Elemental MediaLiveは、AWS上のライブ映像処理サービスです。
さまざまな映像ソースから入力を受け取り、OTT配信に適した出力へエンコードまたはトランスコードできます。
今回の構成では、MediaLiveがライブ配信システムの中心的な役割を担いました。MediaLiveはハードウェアエンコーダーからのRTMP映像ストリームを受け取り、設定されたプロファイルに基づいて映像処理を行い、その後MediaPackage、CDN、再生プレイヤー基盤などの後段サービスへ出力を渡します。
スポーツライブ配信では、プライベートかつ安定した映像取り込みが必要でした。そのため、MediaLiveはVPC経由で映像を取り込む構成にしました。
この方式により、映像伝送の通信をパブリックインターネットへ出さず、プライベートなネットワーク経路内に維持できます。
MediaLive VPC Input設定の全体手順
Step 1: AWS Elemental MediaLive Inputを作成する
まず、AWS Elemental MediaLive上でMediaLive Inputを作成します。
大まかな手順は以下です。
- AWS Management Consoleを開く
- AWS Elemental MediaLiveへ移動する
- Inputsを選択する
- Create inputを選択する
- input nameを入力する
- 適切なinput typeを選択する
今回のプロジェクトでは、オンプレミス側のエンコーダーからRTMP pushを受け取る構成を採用しました。
主な設定項目は以下です。
- Input type： RTMP push
- Input network location： AWS
- Network mode： VPC
- Private subnet： MediaLive Input Endpointを配置するsubnet
- Security group：オンプレミス側のprivate IP CIDR rangeからTCP port 1935を許可
- Role ARN： MediaLive Input用のIAM role
Input destination
MediaLive Inputを作成する際には、STANDARD_INPUTまたはSINGLE_INPUTを選択できます。
STANDARD_INPUT
STANDARD_INPUTでは、MediaLiveが2つの取り込みエンドポイントを作成します。
それぞれのエンドポイントは、異なるパイプラインに対応します。通常、異なるサブネットまたはAvailability Zoneに配置され、冗長化と高可用性を実現します。
この方式は、安定性が求められるライブ配信に適しています。一方で、二重パイプライン構成になるため、SINGLE_INPUTよりもコストは高くなります。
SINGLE_INPUT
SINGLE_INPUTでは、MediaLiveは1つの取り込みエンドポイントのみを作成します。
この方式は、取り込みパイプラインの冗長化を持たない一方で、コストを抑えやすい構成です。
重要なスポーツライブ配信では、冗長化された映像取り込み構成を作れるSTANDARD_INPUTの方が適していることが多いです。
Step 2: AWS Elemental MediaLive Channelを作成する
MediaLive InputとVPC経由の取り込み設定が完了した後、ライブ映像処理を行うためにAWS Elemental MediaLive Channelを作成します。
このstepでは、主に以下を設定します。
- ChannelのInput source
- Channel class、例：STANDARDまたはSINGLE_PIPELINE
- 映像・音声のエンコードプロファイル
- Output group
- MediaPackageまたは後段の配信先
- ログと監視設定
- MediaLive用IAM role
MediaLive Channelの設定には、エンコードプロファイル、出力先、パイプライン動作など多くの要素が関係します。
そのため、AWSの公式ドキュメントを参照しながら、システム要件に合わせて調整する必要があります。
VPC modeにおけるOutput Deliveryの注意点
MediaLive VPC modeを利用する際に注意すべき点の一つが、Output Deliveryです。
MediaLiveの出力をプライベートサブネット内に配置し、MediaPackageや外部CDNのようなパブリックなエンドポイントへ映像ストリームを送信する場合、通信はパブリックサービスのエンドポイントへ到達するためにNAT Gatewayを通る必要があります。
この場合、NAT Gatewayの処理料金が発生します。特に、ライブ配信のように帯域が大きく、長時間稼働するシステムでは、このコストが無視できない規模になる可能性があります。
今回の構成では、コスト最適化とネットワーク経路の簡素化のため、以下の方式を採用しました。
- MediaLive Output用にpublic Elastic IPを作成する
- Output Deliveryをpublic subnetに配置する
- Elastic IPをOutput Delivery interfaceへ直接割り当てる
この方式により、MediaLiveからMediaPackageへの出力通信は、NAT GatewayではなくInternet Gateway経由でルーティングされます。
この構成には以下の利点があります。
- NAT Gatewayの処理コストを削減できる
- 出力経路上のネットワークホップを減らせる
- 後段サービス側で許可する送信元IPを制御しやすい
重要な点として、Output Deliveryがpublic subnetに配置されていても、MediaLiveとMediaPackageのようなAWS管理サービス間の通信はAWS global network backbone上を通ります。
つまり、一般的な意味でのパブリックインターネットを経由するわけではありません。
多層的な冗長化設計
スポーツライブ配信システムでは、冗長化は単一の構成要素だけに持たせるものではありません。
エンコーダー、ネットワーク接続、MediaLiveの処理パイプライン、監視、運用手順など、映像取り込み経路全体にわたって設計する必要があります。
エンコーダーの冗長化
オンプレミス側では、以下の構成を採用しました。
- 5つのライブチャンネルに対応する5台のメインハードウェアエンコーダー
- 障害時に利用する2台の予備ハードウェアエンコーダー
予備エンコーダーは、メインエンコーダーで問題が発生した際に速やかに置き換えられるよう、必要な設定を事前に準備しました。
これにより、停止時間を減らし、稼働中の映像取り込みへの影響を抑えることができます。
ただし、実際の運用では、予備エンコーダーを用意するだけでは不十分です。
フェイルオーバー手順やエンコーダー交換手順を、ライブイベント前にリハーサルしておく必要があります。
ネットワークの冗長化
ネットワークの冗長化は、AWS Direct Connectを通じて以下の形で構成しました。
- active modeで動作するprimary Private VIF
- standby modeで待機するsecondary Private VIF
この2つの接続は、オンプレミス側ネットワークとAWS Direct Connect Gateway間のBGP peeringを通じて動作します。
primary pathに障害が発生した場合、通信はsecondary pathへフェイルオーバーし、AWSへの映像取り込み接続を維持できます。
ネットワーク設計では、以下の点にも注意が必要です。
- オンプレミスとVPCのCIDR重複を避ける
- BGP session statusを監視する
- route propagationと通信経路を確認する
- firewall policyとrouting policyを明確に管理する
メディアパイプラインの冗長化
AWS側では、MediaLiveをSTANDARD_INPUTおよびSTANDARD channel classで構成しました。
この設定により、以下の構成になります。
- MediaLiveが2つの取り込みエンドポイントを作成する
- それぞれのエンドポイントが別の取り込みパイプラインまたはENIに対応する
- エンコーダーは両方のパイプラインへ映像ストリームを同時に送信できる
- 片方のパイプラインまたはAvailability Zoneに問題が発生しても、もう片方のパイプラインで処理と出力を継続できる
この設計により、映像取り込みパイプラインとエンコード処理の安定性が向上します。
特に、イベント中に高可用性が求められるスポーツライブ配信では重要です。
本番前の検証
ネットワーク設定、AWS Direct Connect設定、MediaLive Input、エンコーダー設定が完了した後、本番運用に入る前にエンドツーエンドの接続性を検証しました。
検証の目的は、単にシステムが動作するかを確認することではありません。
実際のライブイベントに近い条件下で、システムが安定して運用できるかを確認することです。
ネットワーク接続検証
最初に、オンプレミス側のエンコーダーネットワークとAWS VPCの間で到達性を確認しました。
AWS側では、MediaLiveの取り込みエンドポイントと同じ経路を通るプライベートサブネット内にEC2 instanceを作成し、基本的なネットワーク検証を実施しました。
主な検証項目は以下です。
- エンコーダーまたはオンプレミスネットワークからAWS private subnetへのping
- AWS VPC内のEC2 instanceからオンプレミスCIDRへのping
- Direct Connect GatewayとVirtual Private Gatewayからのroute propagation確認
- firewall ruleとsecurity group ruleの確認
これらの検証により、通信がパブリックインターネットではなく、AWS Direct Connect経由で正しく流れていることを確認しました。
ICMPによる接続性が確認できた後、次にRTMPの映像取り込み経路を検証しました。
エンコーダーとMediaLive VPC Input Endpoint間でTCP port 1935を確認し、以下を検証しました。
- RTMP portがSecurity Groupで正しく許可されていること
- オンプレミス側のfirewall policyが正しく設定されていること
- エンコーダーがMediaLiveの取り込みエンドポイントとRTMP sessionを確立できること
ネットワークとRTMP接続が確認できた後、正式な開始前に長時間の連続配信テストを実施し、映像取り込みパイプラインの安定性を検証しました。
映像と取り込み安定性の検証
連続配信テスト
長時間映像ストリームを送信し続け、エンコーダー、ネットワーク経路、MediaLiveの取り込みパイプラインが実際の負荷に近い条件で安定するかを確認しました。
ビットレートの安定性
エンコーダーの出力ビットレートを監視し、映像ストリームが異常に変動しないか、急激に低下しないか、視聴体験に影響する揺らぎが発生しないかを確認しました。
音声と映像の同期
配信中に音声と映像の同期が保たれているかを確認しました。
音声遅延や映像とのズレは、スポーツライブ配信の視聴体験に大きく影響します。
入力断の検知
映像信号断を意図的に再現し、MediaLiveが入力断を正しく検知できるか、監視とアラート通知が期待通りに動作するかを確認しました。
再起動時の挙動確認
エンコーダーや映像取り込み処理を再起動し、復旧と再接続の挙動を確認しました。
後段の配信処理への影響を最小限に抑えられるかも検証しました。
エンコーダー交換テスト
ライブイベント中にメインエンコーダーを予備エンコーダーへ切り替える想定で検証し、フェイルオーバー手順が設計通りに機能するかを確認しました。
予備エンコーダー起動テスト
メインエンコーダーに問題が発生した場合に、予備エンコーダーを起動し、MediaLiveの取り込みエンドポイントへ映像ストリームを送信できるかを確認しました。
これらの検証により、運用チームはネットワーク経路の安定性だけでなく、実際の障害発生時の対応能力も確認できました。
運用準備の検証
ネットワークと映像処理の検証に加えて、ライブイベント当日の運用を想定した検証も実施しました。
監視ダッシュボード
監視ダッシュボードが、エンコーダー状態、ネットワーク接続、MediaLive Input、ビットレート、配信状態をリアルタイムで表示できることを確認しました。
アラート通知
入力断、ビットレート異常、エンコーダー切断、BGPセッション停止などが発生した場合に、アラートが正しく通知されるかを確認しました。
これにより、運用チームが問題へ迅速に対応できる状態を整えました。
ライブイベント当日の運用手順書
ライブイベント当日の運用手順書を準備し、内容を確認しました。
手順書には、本番前のシステム確認、障害切り分け手順、フェイルオーバー手順などを含めました。
エスカレーションフロー
放送、ネットワーク、クラウド基盤、OTT運用など、関連チーム間のエスカレーションフローを明確にしました。
障害発生時に、誰が何を確認し、どのチームへエスカレーションするかを事前に決めておくことで、対応時間を短縮できます。
ロールバック手順
ライブ配信中にメインシステムで問題が発生した場合に備え、予備構成への切り替えやロールバック手順も確認しました。
これらの運用検証により、技術システムだけでなく、運用プロセスとしても本番のスポーツライブ配信に対応できる状態を整えました。
運用から得られた学び
構築と検証を通じて得られた重要な学びは、安定したスポーツライブ配信基盤は、単一の技術やサービスだけでは実現できないということです。
AWS Direct Connectは映像取り込み経路を安定させるうえで非常に有効です。しかし、実際の信頼性は、エンコーダー、ネットワーク、MediaLiveの映像取り込み、監視、運用手順まで含めた全体の配信フローが一貫して設計されて初めて実現します。
もう一つの重要な学びは、放送の処理フローとクラウド基盤の処理フローでは、前提や考え方が大きく異なるということです。
そのため、映像フィード、入力、パイプライン、エンドポイント、チャンネルといった用語や概念を、プロジェクト初期段階で関係者間で揃えておく必要があります。
これを怠ると、ライブイベント中の運用や障害切り分けで認識のズレが発生します。
また、映像取り込み経路は本番ネットワークとして管理すべきです。
IP範囲、ルートテーブル、セキュリティグループ、ファイアウォールポリシー、担当範囲、フェイルオーバー手順などは、個々のエンジニアの知識として残すのではなく、明確にドキュメント化する必要があります。
さらに、冗長化は実際に検証して初めて意味を持ちます。
予備エンコーダー、secondary VIF、MediaLiveの冗長入力を用意していても、運用チームが本番前にフェイルオーバー手順をリハーサルしていなければ、実際の障害時に十分な効果を発揮できません。
最後に、VPC経由の映像取り込みはセキュリティと制御性の面で大きな利点がありますが、その分ネットワーク設計は慎重に行う必要があります。
特に、CIDR設計、ルート伝播、サブネット構成は、初期設計の段階で十分に検討する必要があります。
まとめ
スポーツライブ配信基盤の構築は、視聴者へ映像を届けるだけの話ではありません。
それと同じくらい重要なのが、ライブ映像ソースをクラウドへ安定して取り込むことです。
今回の構成では、ハードウェアエンコーダー、専用線接続、MediaLive VPC Input、多層的な冗長化を組み合わせることで、複数チャンネルのスポーツライブ配信に対応できる安定した基盤を構築しました。
AWS Direct Connectは制御可能なネットワーク経路を提供し、MediaLive VPC Inputは映像取り込み通信をプライベートネットワーク内に維持します。また、エンコーダー、ネットワーク、MediaLiveパイプラインにまたがる冗長化により、ライブイベント中の障害にも備えやすくなります。
スポーツライブ配信における信頼性は、単一の構成要素によって実現されるものではありません。
設計、検証、運用を含めた配信フロー全体を、最初から本番品質のシステムとして扱うことが重要です。