AWS MediaServices を使用したライブ配信基盤の可用性について理解する
こんにちは、大前です。
突然ですが、以下の構成図を見てください。
撮影した映像を MediaConnect に打ち上げ、MediaLive + MediaStore/MediaPackage でエンコード&パッケージを行い、CloudFront 経由でライブ配信を行うよくあるアーキテクチャかと思います。（MediaConnect を使用するケースが一般的かはさておき）
検証であればこの構成図のまま構築を行い、配信を実施すれば良いと思いますが、本番運用を行う環境の場合、考慮すべき事がいくつか増えてきます。
そのうちの１つが、可用性です。
もう一度先ほどの構成図に戻りましょう。
この構成において、例えば AZ 障害が発生したらどうなるでしょうか。
また、ライブ配信は撮影現場の機材トラブルが発生する事も考えられます。機材トラブルが発生したらライブ配信は中断するしかないのでしょうか。
当然そんな事はなく、MediaServices にも可用性を高めるための機能や仕組みが備わっています。
しかし、そういった仕組みを理解しないまま本番運用を始めてしまうと、いざ障害や機材トラブルが発生した際に対応できず、そのままライブ配信が中断、という最悪の結果に繋がってしまう可能性もあります。
本記事では、ライブ配信基盤においても障害が発生する事を前提としたアーキテクチャが構成できる様、MediaServices が持つ可用性を高める仕組みについて書いていきたいと思います。
では、早速各コンポーネントについてみていきましょう。
MediaConnect の可用性
MediaConnect は入出力に関する設定を フロー と呼ばれる単位で作成・管理します。
このフローは、作成時に AZ を指定する事が可能です。（指定しない事も出来ます）
そのため、フローを複数 AZ に作成する事で、MediaConnect における可用性を高める事が出来ます。
複数フローを作成する場合の留意点は以下です。
- 各フローに対して映像を送出する
- 各フローからの出力を MediaLive の入力として取り込む
MediaLive の可用性
MediaLive は映像の入力ソースを指定する Input（入力） と、エンコードや映像の送出先の設定などを行う Channel（チャネル） のセットで構成されます。
MediaLive には Channel Class という設定があり、この設定を STANDARD にする事により、MediaLive の冗長性を確保する事が出来ます。（デフォルト値は STANDARD）
RDS でいうマルチAZ 設定の様なイメージを持つとわかりやすいかもしれません。
Channel Class を STANDARD した場合、Input の入力と Channel の出力はそれぞれ 2つ指定する必要があります。
例えば、MediaConnect からの入力を受け付けたい場合は、作成した各フローを指定します。
MediaLive 内部の挙動としては、以下になります。
- Channel 設定を元に、2つの Input を別々の AZ で処理
- 別々の AZ で処理が行われるが、MediaLive 内部で処理状態を同期
- 各 AZ 毎にそれぞれ出力を生成（計2つの出力）
MediaLive において使用される AZ は、2020年9月時点では指定出来ません。MediaLive 側でよしなに処理される様です。
構成図に落とし込むとこんな感じ。段々とマルチ AZ 構成っぽくなってきましたね。（Channel はあくまで設定なので AZ を意識するコンポーネントではありませんが、イメージのしやすさを優先し、分割して図にしています）
MediaPackage の可用性
MediaPackage は、明示的に可用性に関する設定を行う必要はありません。
MediaPackage はデフォルトで 2つの入力を受け取り、複数 AZ に跨ってパッケージング処理やオリジンの役割を行ってくれます。
仮に特定の AZ で障害が発生した場合でも、MediaPackage は自動で正常な入力を選択し、各種処理を実施してくれます。
サービス側でデフォルトで冗長化の仕組みを持っていてくれるのはありがたいですね。
構成図は以下の形になります。MediaLive からの 2つの出力を MediaPackage の入力として設定すれば、あとは冗長化の仕組みは特に気にする必要はありません。
MediaStore の可用性
MediaStore は S3 をベースとしたサービスとなっているため、S3 と同等の耐久性を提供しています。
そのため、MediaStore についても可用性を意識して何かしらの設定を行う必要はありません。
MediaLive 等のエンコーダーからの出力先を MediaStore に向ければ OK です。
2020/10/30 追記
MediaStore 自体の可用性は考慮する必要はありませんが、エラー等が発生し、MediaLive 側で片方の入力が停止するとアプリケーション側で待機系のマニフェストファイルを取得する様に切り替える必要があります。
もしくは、以下ブログを参考に MediaLive 側の設定で親マニフェストファイルを生成し、正常なマニフェストファイルを自動で取得させる様な設定を実施ください。
Build a reliable HLS live channel with AWS Elemental MediaStore
撮影部分の可用性
さて、MediaServices における可用性を高める仕組みについて一通り記載しましたが、ライブ配信においては現場の機材トラブルも考える必要があります。
いくら AWS 側でしっかりと冗長構成をとっていても、大元の撮影部分が壊れてしまったら水の泡です。
一方で、MediaServices は上記の様な入力側のトラブルに対する冗長化の仕組みも提供しています。
具体的には、MediaConnect と MediaLive では各入力について主系・副系の映像ソースを設定する事ができます。
文字だとわかりづらいので、MediaConnect を例にあげて図にしてみます。
上記ブログにも図を載せていますが、下図の様に、各フローに対して異なる入力ソースから映像を送る事ができます。
これにより、仮に Live Input A のソースが何らかのトラブルで映像を送れなくなったとしても、AWS 側で自動的に Live Input B のソースにフェイルオーバーを行い、ライブ配信を継続する事ができます。
AWS 上の冗長化だけでなく、ライブ配信においては入力ソースの冗長化も考慮すべきという事、AWS で入力ソース側の冗長化をサポートする仕組みが提供されている事は頭に入れておきましょう。
まとめ
ここまでの話を構成図に落とし込むと、以下になります。
また、ポイントとしては以下になります。
- 入力ソース（撮影機材など）の冗長化を考慮する
- MediaConnect、MediaLive の機能で冗長化可能
- MediaConnect のフローを複数 AZ に作成する
- MediaLive の Channel Class は STANDARD に設定する
- MediaPackage、MediaStore については冗長化に関する設定は特に考慮不要
おわりに
MediaServices を使用してライブ配信を行う際、可用性がどの様に担保されているのか、またどの様な機能が用意されているのかについて紹介しました。
一方で、ここで紹介した仕組みを全て取り入れる必要はありません。
当然、入力ソースやリソースが増える事により、管理コストや AWS 費用の増加に繋がります。
そのため、本番環境であっても、コストを優先して可用性をある程度落とす事を許容するケースも有り得るかと思います。
例えば、MediaLive の Channel Class を SINGLE_PIPELINE（STANDARD ではない設定）にすると、当然可用性は落ちますが MediaLive のコストが 3〜4割 削減されたりします。
ライブ配信のワークロードにどの程度の可用性が求められているのかを検討した上で、コストとのトレードオフを考慮しながら各仕組みを取り入れるか判断する事が大切だと思います。
以上、AWS 事業本部の大前でした。
![[update] AWS Elemental MediaLiveがbandwidth reduction filterをサポートしました！](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-67b7665ae5d1345fda4a806167cf3e15/f0bea672c2be37596ad375443efc5822/aws-elemental-medialive)
![[UPDATE] AWS Media ServicesがAV1エンコードでのライブ配信をサポートしました！](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e924faf7705c83b73111cb0e9c63db29/f9e726b3d65bfffe9523b4bb410153a5/media-services)
