AWSソリューション実装「Live Streaming on AWS」でAmazon S3をライブオリジンとして使用するようになりました!

これまでシンプルな構成のライブオリジンにはAWS Elemental MediaStoreが案内されてきましたが、最新版のAWSソリューション実装ではAmazon S3をライブオリジンとして使用しています。背景含めて確認してみました。
2022.05.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。AWSのテクニカルリファレンス実装であるAWS Solutions Library/AWSソリューション実装では2種類の「Live Streaming on AWS」と題したライブストリーミング用のソリューションが公開されています。

本DevelopersIOでもこのAWSソリューション実装を試してみたエントリが公開されています。

さて、本エントリではこのAWSソリューション実装「Live Streaming on AWS」のうち、ライブオリジンにAWS Elemental MediaPackageを使わないほうを扱います。ちょっと回りくどい言い方となってしまっていますが、まずは2種類の違いをライブオリジンの視点でおさえておきましょう。

まずAWS Media Servicesを使ったライブ配信時の構成として、複数フォーマットだったりDRMやDVRなどを使用する場合はライブオリジンとしてAWS Elemental MediaPackageの使用が推奨されます。対して、シンプルなライブ動画配信であればライブオリジンにはAWS Elemental MediaStoreの利用が案内されてきました。

AWSソリューション実装でも同様に、「Live Streaming on AWS」としてライブオリジンにAWS Elemental MediaPackageを使用したもの、そして「Live Streaming on AWS with MediaStore」としてライブオリジンにAWS Elemental MediaStoreを使用したものの2種類があったわけです。これは先に挙げた本DevelopersIOでの既存のエントリを確認してもわかります。前者のライブオリジンにMediaPackageを使用するものが「AWSソリューション実装「Live Streaming on AWS」でライブ動画配信をしてみた | DevelopersIO」、後者のライブオリジンにMediaStoreを使用するものが「AWS Elemental LinkとAWSソリューション実装でライブ動画配信をしてみた | DevelopersIO」となります。

さて、上記の点を踏まえて現在のAWSソリューションのライブストリーミングのページを確認してみましょう。ななななんと!!!AWS Elemental MediaStoreをライブオリジンとして使用していたソリューション実装が、Amazon S3を使用したものに置き換わっています!

Live Streaming | AWS Solutions

ページをスクロールさせてみてもこのとおり!構成図もバッチリAmazon S3に置き換わっています。

Live Streaming | AWS Solutions

念のため、該当ページのWeb Archiveも確認しておきましょう。たしかに以前はAWS Elemental MediaStoreを使用していました。(Internet Archive Wayback Machineで2022/03/09のArchiveを確認しています。)

Live Streaming | AWS Solutions - Internet Archive Wayback Machine - 2022/03/09

ということで前置きが長くなりましたが、本エントリではこのAWSソリューション実装「Live Streaming on AWS with Amazon S3」について、使用しているオリジンがAWS Elemental MediaStoreからAmazon S3に置き換わった背景を確認しつつ、実際に利用してみたのでまとめてみます。

ライブストリーミングとAmazon S3のStrong Consistencyサポート

2017年11月末のAWS Media Servicesリリース時より、ライブ配信時のオリジンとしてはジャストインタイムパッケージングサービスであるAWS Elemental MediaPackageか、メディア向けに最適化されたストレージサービスであるAWS Elemental MediaStoreが案内されてきました。ここでストレージサービスとしてAmazon S3の使用が推奨されず、わざわざ「メディア向けに最適化」されたAWS Elemental MediaStoreが登場した背景には、当時のAmazon S3が結果整合性モデルであったことが要因であると個人的に考えています。MediaStoreについてはリリース当時から即時整合性をもち、ライブストリーミング時のプレイリストファイルの配信にも対応していました。

そんな中、2020年12月頭にAmazon S3に大きなアップデートが訪れます。上書きPUTならびにDELETE操作についてはそれまで結果整合性でしたが、強い書き込み後の読み取り整合性がサポートされるようになりました。

これまでS3をライブストリーミング時のオリジンとして利用する上で問題となっていた、更新前の古い状態のファイルを参照してしまう可能性がある点が払拭されました。技術的にはライブオリジンとしてS3が利用できる状態となったわけです。個人的にはAWSのユースケースなどでライブオリジンとしてS3が案内されていない以上、MediaStoreをライブオリジンとすることを原則とし、S3をライブオリジンとして使用するにはパフォーマンス検証等が必要などと考えていました。(実際にエントリ「AWS Elemental MediaLiveでHLS outputのVODモードを設定してみた | DevelopersIO」では検証の中でS3をオリジンとしたライブストリーミング自体ができることを確認しています。)

そんな中、今回のアップデートでAWSソリューション実装として、ライブストリーミング時のオリジンにAmazon S3を使用したアーキテクチャが案内されたというわけです。AWSソリューションのリファレンスアーキテクチャというとこで、構成の心配をせずにS3をライブオリジンとして使用することができるのではないでしょうか。MediaStoreの代わりにS3を使用することでより汎用的であることのメリット、例えば得られる情報やナレッジの多さ、豊富な設定可能なオプション項目などが得られるかと考えます。またコスト(AWS利用費)としてのメリットもあるかと考えます。(ざっと確認した限りですが、MediaStoreではIngest Optimizationの料金が発生するぶん、S3のほうが割安になるかと思います。)

今後のMediaStoreに思いを馳せる

それではAWS Elemental MediaStoreをあえてライブストリーミング時のオリジンとして引き続き利用するメリットはあるのでしょうか。1点挙げるとすれば、MediaStoreのChunked object transfer機能があるかと思いました。

オブジェクトの転送の完了を待たずに未完の状態でもオブジェクトの読み込みを可能とすることで、超低遅延のライブストリーミング配信が実現可能となります。実際はライブオリジンとなるMediaStoreのChunked object transferのほか、CDN側の同機能の対応、そしてエンコーダならびにプレイヤー側でも超低遅延に応じた対応が必要になります。こちらのPDFにも詳細がまとめられています。

このChunked object transferについては、ざっと調べてみた限りですがAmazon S3ではサポートされていないようでした。(正確には、サポートされているのか否かを私のほうではっきりと確認できなかった、というのが正直なところです。例えばここなどにchunked uploadについての記載があるようですがマルチパートアップロードのことなどかなと読み取っています。)そのため、超低遅延のライブストリーミングを行う場合には引き続き「メディア向けに最適化された」ストレージサービスであるAWS Elemental MediaStoreの出番かと考えます。ただし「Live Streaming on AWS with Amazon S3」でも利用されているように、超低遅延ではない一般的なライブストリーミングではオリジンをAmazon S3にすることができる状況になったと捉えています。

いつごろ「with MediaStore」から「with Amazon S3」に変わったのか!?

これまでの「Live Streaming on AWS with MediaStore」が「Live Streaming on AWS with Amazon S3」に変わった背景などを確認してみました。そういえば、この「with MediaStore」から「with Amazon S3」へのアップデートはいつ行われたのでしょうか、こちらも確認しておきましょう。

「Live Streaming on AWS with Amazon S3」のImplementation Guide、Revisionsの項目を確認すると2022/03の更新として、「Release v3.0.0: Updated to use Amazon S3 rather than AWS Elemental MediaStore as live streaming origin.」という記載があります。今回のアップデートはこれに該当しますね。バージョンとしてもv3.0.0となっていることがわかります。

Revisions - Live Streaming on AWS with Amazon S3

リンクされているCHANGELOG.mdについても確認します、具体的な日付として2022/03/10のアップデートということでした。

live-streaming-on-aws-with-amazon-s3/CHANGELOG.md at mainline · aws-solutions/live-streaming-on-aws-with-amazon-s3 · GitHub

Live Streaming on AWS with Amazon S3でライブ配信してみた

それでは実際に「Live Streaming on AWS with Amazon S3」を使ったライブ動画配信を確認してみましょう。以下のImplementation Guideも参考に進めていきます。

Live Streaming | AWS Solutions」のページの構成図がある箇所、「Live Streaming on AWS With Amazon S3」であることを確認して[Launch in AWS Console]ボタンで進みます。

マネジメントコンソールのCloudFormation、Create stack画面が表示されます。デフォルト状態でリージョンがバージニアになっているので使用するリージョン(今回は東京リージョン)に変更します。

Stack nameはデフォルトの「LiveStreamingwithAmazonS3」まま進めました。LIVE STREAM SOURCEの「Source Input Type」はRTMP_PUSHを選択します。またRTP_PUSH / RTMP_PUSH CONFIGURATIONの「Input Security Group CIDR Block」にMediaLive Input Security Groupで許可するIPアドレスをxxx.xxx.xxx.xxx/32の形式で入力します。ENCODING OPTIONSについてはデフォルトのまま[Next]ボタンで進みます。

Configure stack optionsの画面はデフォルトのまま[Next]で進みReview画面で内容を確認、最後にIAMリソースが作成されることの確認のチェックボックスをonにして[Create stack]を行います。

およそ5分ほどでStackがCREATE_COMPLETEになりました。

20のリソースが作成されていますが、ライブストリーミングに必要な情報はOutputsにまとまっていますね。

このOutputsの「MediaLiveConsole」の項目からMediaLiveのマネジメントコンソールに遷移し、該当ChannelをStartさせます。

またStreaming Softwareで「MediaLivePushEndpoint」に対して映像を打ち上げます。そして「LiveStreamUrl」をHLS対応のプレイヤーで開いてライブストリーミングを再生します。プレイヤーは今回macOSのSafariブラウザを使用しました。(CORS設定がないようで、VideoJS HTTP Streamingではエラーとなりました。)

curlコマンドでプレイリストファイル、セグメントファイルのヘッダ情報も確認しておきましょう。server: AmazonS3がライブストリーミングでは新鮮な感じがします!

% curl -I https://d1jjxxxxxxxxn7.cloudfront.net/stream/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 795
date: Mon, 30 May 2022 16:06:12 GMT
last-modified: Mon, 30 May 2022 16:00:20 GMT
etag: "56a2xxxxxxxxxxxxxxxxxxxxxxxx8f1d"
x-amz-server-side-encryption: AES256
cache-control: max-age=2
x-amz-version-id: 3mD.xxxxxxxxxxxxxxxxxxxxxxxxRKtq
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 28ccxxxxxxxxxxxxxxxxxxxxxxxx4154.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P3
x-amz-cf-id: o751xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxow==
% curl -I https://d1jjxxxxxxxxn7.cloudfront.net/stream/index_1280x720.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 564
date: Mon, 30 May 2022 16:06:14 GMT
last-modified: Mon, 30 May 2022 16:06:14 GMT
etag: "0603xxxxxxxxxxxxxxxxxxxxxxxx7f1f"
x-amz-server-side-encryption: AES256
cache-control: max-age=2
x-amz-version-id: MSlExxxxxxxxxxxxxxxxxxxxxxxxLFuq
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 7067xxxxxxxxxxxxxxxxxxxxxxxxe480.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P3
x-amz-cf-id: R6NMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxdA==
% curl -I https://d1jjxxxxxxxxn7.cloudfront.net/stream/index_1280x720_160545__00086.ts
HTTP/2 200
content-type: video/MP2T
content-length: 210748
date: Mon, 30 May 2022 16:06:16 GMT
last-modified: Mon, 30 May 2022 16:05:50 GMT
etag: "e8a3xxxxxxxxxxxxxxxxxxxxxxxxea22"
x-amz-server-side-encryption: AES256
cache-control: max-age=21600
x-amz-version-id: 1lXpxxxxxxxxxxxxxxxxxxxxxxxxBTYO
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 2e09xxxxxxxxxxxxxxxxxxxxxxxx3d06.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P3
x-amz-cf-id: 6IzNxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-A==

当然、これらプレイリストファイル、セグメントファイルはS3に書き出されているわけです。MediaLiveの設定では古いセグメントファイルを削除できますが、この設定も問題なく動作しているようでした。(以下スクリーンショットで最古のものは00092.ts、最新が00112.tsとなっています。)ただ、このバケット自体にバージョニングが設定されており、削除された(削除マーカーがついた)オブジェクトも参照は可能なようです。

まとめ

使用するライブオリジンがAWS Elemental MediaStoreからAmazon S3にアップデートされた「Live Streaming on AWS with Amazon S3」について、その背景などを確認しつつ、実際にソリューション実装を使ってライブストリーミングを行ってみました。

AWSソリューション実装としてはこれまでの「Live Streaming on AWS with MediaStore」のときと同様、CloudFormationを用いてすぐに環境がデプロイでき、またカスタマイズする際の参考にもなるかと考えます。そしてなによりAWSのリファレンス実装として、ライブストリーミング時のオリジンにAmazon S3を使用したアーキテクチャが案内されたことが大きいかと思います。AWS Elemental MediaStoreも個人的に大好きなサービスなのですが、ストレージサービスとしてAmazon S3に一本化できればそれに越したことはないかと考えます。例えばアーカイブ用にS3を構築し、ライブ用にMediaStoreを構築するといった場合、類似している点はあれど2つのサービスについての知識習得が必要になりますよね。またどうしてもS3のほうが汎用的なストレージであるぶん、公開されている情報やナレッジ、設定可能な項目なども多くなります。Chunked object transferを利用した超低遅延配信を行うといった場合にはまだAWS Elemental MediaStoreに分がある状況かと思いますが、それ以外の汎用的なライブストリーミング配信用途であればS3オリジンの使用で良いのかなと考えています。