はじめに

通常のライブ配信のケースでは特に意識する必要はありませんが、
同時に多数のライブ配信を行う際に注意すべき点をまとめておきます。

これは実際に私が経験した内容で、テスト配信では問題がなかったものの本番配信ではこの事象が起きたので、その様子を振り返りながら、原因や対策を整理していきます。

構成図

ライブ配信環境は以下のスタンダードな構成です。

MediaLive(Single Pipeline) -> MediaStore -> CloudFront

少し特殊だったのが、本番では同時に32チャンネルで配信する必要があったため、
これを1セットとして、32チャンネル分を用意していました。

当時の状況

同時に32チャンネルのライブ配信を行ったところ、
数秒おきに止まっては復帰を繰り返す状況がみられました。

最初は配信現場の通信環境や送出される映像ソースの問題とも考えましたが、
MediaLive Channelでは NetworkIn や Dropped Frames などの異常は確認されませんでした。

その後、MediaLive ChannelのAlertメッセージを見ると、
下記のような見慣れないメッセージが多数出力されていることが分かりました。

メッセージ内容から、MediaLiveからMediaStoreにファイルを書き込む処理で
何らかの問題が起きているようだ、と分かってきました。

以下はそのAlertメッセージの一部抜粋です。

Alert Type : Failed to Close or Finalize the Output
Message : MPEGTS muxer for mediaID [3] unable to close output or stream.

Alert Type : Failed to Create Output File or Socket
Message : MPEGTS muxer for mediaID [3] unable to open output or stream [mediastoressl://xxxxxxxxxxx.data.mediastore.ap-northeast-1.amazonaws.com/live_2m.m3u8].

Alert Type : Failed to Write to Output
Message : SegmenterAppleLive OutputData Write failed

Alert Type : Failed to Write to Output
Message : OutputDataBackground failed to send file for URL [mediastoressl://xxxxxxxxxxx.data.mediastore.ap-northeast-1.amazonaws.com/live_2m_xxxxx.ts]

Alert Type : Large Upload Cache Backlog
Message : Upload speeds slower than real time detected when uploading URL [mediastoressl://xxxxxxxxxxx.data.mediastore.ap-northeast-1.amazonaws.com/live_2m.m3u8]

原因

調べてみると、MediaStoreの PutObjectの上限(クォータ)に抵触している 可能性が考えられました。
https://docs.aws.amazon.com/ja_jp/mediastore/latest/ug/quotas.html

・PutObject – Standard Upload Availability : 100 TPS
The maximum number of operation requests that you can make per second. Additional requests are throttled.

動画が完全に視聴できない状態ではなく、止まっては復帰を繰り返す状況に当てはめても、
「上限に引っかかり、リクエストが制限されてスロットリングが発生していた」と考えると説明がつきます。

具体的な数値を計算してみます。

・同時に使用していたチャンネル数：32チャンネル
・セグメントの長さ：2秒
・ABR：5M/2M/1M/500K の計4つ

tsとm3u8がそれぞれ2秒ごとに生成されるため、TPSで換算すると

4 × 32ch = 128TPS

PutObject のデフォルト上限値は 100TPS なので、
これがどうやら上限(クォータ)を上回っているようでした。

対処

AWSコンソールの Service Quotasから利用しているリージョンを選択し、
MediaStore ページから、対象の設定項目である「PutObject」の引き上げ申請を行いました。

※実際の名称は下記となっていました。
「Rate of PutObject API requests for standard upload availability」

その後、AWSサポートから使用チャンネル数やセグメントの長さに関する情報提供の依頼があり、
サポートケースから返答を行いました。

しばらくすると、Service Quotasの引き上げリクエストが完了され、
「適用されたクォータ値」が指定した値に引き上げられていることが確認できました。

補足

MediaStoreクォータのTPSは、基本的にアカウント毎に割り当てられています。
AWSサポートに依頼することで、個々のコンテナにクォータを割り当てることも可能です。

おわりに

Service Quota の設定値は見落としがちとはいえ、
今回の事象は本番に近い状態で事前テストを入念に行うことで気づけたと反省があるため、今後に生かしたいと思います。

ABRの設定にもよりますが、計算上
ABR4本の場合は25チャンネル以上を同時に配信する際に、PutObjectの上限引き上げを事前に行っておくと安心です。

また、MediaLive ChannelのAlertメッセージはAWSコンソール上で確認できるものの、
現状では古いメッセージは表示されなくなり、後から見れなくなるという点も気をつけたいところです。

その対策として、Alertメッセージはslackに出力させて、後からでも追えるようにしています。
この仕組みだと異常に気がつきやすくなるため、トラブルシューティングの観点から設定をお勧めします。

この記事が誰かのお役に立てれば幸いです。