WowzaのMedia Cache機能を使ってS3をオリジンとしたVODストリーミング配信をしてみた

Wowza Streaming Engineの機能の一つであるWowza Media Cacheを使って、Amazon S3にあるファイルをオリジンとしてWowza Streaming Engine経由でHLS配信を行ってみました。

#Amazon S3

#AWS

清水俊也

2018.06.30

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

はじめに

清水です。先日動画ストリーミングサーバであるWowza Streaming EngineのWowza Media Cacheという機能を使ってAmazon S3をオリジンとしたVODストリーミング配信を検証する機会がありました。このWowza Media Cacheという機能、配信元となるmp4などのメディアファイルをAmazon S3などのストレージサービスに保管し、配信時にはWowzaを経由してHLS形式やmepg-DASH形式などでストリーミングが行えます。構成イメージとしては下記のようになります。

通常では配信元となるmp4などのメディアファイルはストリーミングサーバのストレージ、例えばEC2上のWowzaならばEBS上に配置する必要がありますが、Media Cache機能を使うとこのストレージ部分にAmazon S3などストレージサービスが使えるわけです。Amazon S3の他、クラウドサービスならAzure Blob StorageやGoogle Cloud Storageなども使用可能とドキュメントには記載があります。ストレージとして例えばAWSならEBSではなくS3が使えることのメリットとしては、データとなるメディアファイルは堅牢性のより高く、また容量無制限であるストレージにオリジンとして格納できることが挙げられます。またメディアを1箇所で管理することができます。サーバであるWowza自体には情報（メディアファイル）を持たせない、ステートレスなサーバ状態とすることで、高負荷時のスケールアウトも容易になりますね。Wowzaの公式ドキュメントにも「VOD配信をスケールさせる方法」の一つとして紹介されている機能となります。

Scale video on demand (VOD) with Wowza Media Cache

本エントリではこのWowza Media Cacheを使った構成をAWS上で構築し、Amazon S3に配置したファイルをMedia Cache機能を使ってWowza Streaming EngineからHLS配信してみたので、まとめてみたいと思います。

Wowza Streaming EngineでMedia Cacheの設定をする

S3バケットとIAMユーザ作成

では実際にこのWowza Media Cache機能を設定してみます。まずWowzaを起動、設定する前に、S3とIAMユーザの設定を行ってしまいましょう。S3については特段特別な設定は必要ありません。マネージメントコンソールからS3バケットを作成します。Wowzaからのデータ取得は後述しますIAMユーザのアクセスキーを使用して行っているようなので、バケットまた保存するオブジェクトについてパブリックとする必要はありません。

続いてIAMユーザを作成します。WowzaのMedia Cacheの設定の際、アクセスキーとシークレットキーを入力する必要があるので「プログラムによるアクセス」を選択しキーを発行します。また権限についてはS3の対象のオブジェクトを読み取れる必要があるので、AmazonS3ReadOnlyAccessなど必要な権限を持つものをアタッチします。

Wowza Streaming Engineの起動とWowza Streaming Engine Managerへのアクセス

IAMユーザが作成できたら、Wowza Streaminig Engineを起動します。今回はAWS MarketplaeでWowzaのサブスクリプションを行い利用しました。サブスクリプションからEC2インスタンスの起動までは下記のエントリの詳細をご参照ください。

AWSのWowzaでVOD配信してみた｜ Developers.IO

本エントリでは差分を中心にご紹介します。まずMarketplaceでは従来と少し名称が変わり、BYOLではないものはPAIDという表示になりました。今回はこのLinux PAIDを使用して進めてみます。サブスクリプションの際に月額$15.00の費用が、またインスタンス使用料金とは別にソフトウェア使用料金も発生する点に注意しましょう。

サブスクリプションができたら、こちらのAWS Marketplace商品のAMIを指定してEC2インスタンスを起動します。今回は検証用途ですのでインスタンスタイプはt2.smallを使用しました。

EC2が起動できたら、Wowza Streaming Engine Managerにアクセスします。以下のURLですね、ブラウザで開きましょう。

http://[EC2のPublicDNSまたはパブリックIP]:8088/enginmanager

サインイン画面まで進め、Usernameはwowza、Passwordは起動したEC2のインスタンスID(i-XXXX)でサインインします。

Wowza Media Cacheの設定

Wowza Streaming Engine Managerへサインイン後、Media Cacheの設定を進めます。画面上部のServerタブをクリック、Server設定画面にてMedia Cacheをクリックします。デフォルトでEnableになっていますが、Sourceを選択して入力ソースの設定を行います。今回はMedia Cache SourceとしてAmazon S3を利用するので、Name欄のamazons3のリンクをクリックします。

遷移した画面で[Edit]ボタンを押して編集画面へと進みましょう。編集画面にて、アクセスキー、シークレットキーを入力します。他の箇所については今回はデフォルトのままとしました。

[Save]ボタンで編集内容を保存すると、restartを促されますので、[Restart Now]ボタンからrestartしておきます。

続いてこのMedia Cacheを使用するApplicationを設定します。画面上部のApplicationタブをクリックし、Add Application画面でVOD Edgeをクリックします。Media Cacheを使った構成ではあくまでWowzaはVOD Edgeとしての役割となり、オリジンはS3となる、という点に注意しましょう。

Application名の入力を促されます、ここではそのまま「mediacache」としました。続いて詳細編集画面に遷移します。内容を確認して[Save]ボタンでApplication作成を完了させます。

これでWowza側のMedia Cacheの設定ができました。

S3にファイルを置いてMedia Cache機能でHLS配信してみた

続いてS3にファイルをアップロード、実際にWowza経由でのHLS形式の配信を行ってみます。S3へのアップロードについては通常と変わりありません。先ほどWowza側に設定したアクセスキー、シークレットキーを持つIAMユーザがアクセス権を持っていればパブリックにする必要もありません。以下の具合でS3バケット直下にmp4というフォルダを作成、2つのファイルを配置しました。

続いてWowza側からMedia Cache機能を使って、HLS形式で配信してみます。先ほどのMedia Cacheの設定と、Media Cacheを使うアプリケーション（先ほどの例だとmediacache）の設定が完了していれば、特段なにか行う必要はありません。以下の形式のURLからHLS形式で配信が行なえます。

http://[wowza-ip-address]:1935/[Wowzaアプリケーション名]/_definst_/mp4:[WowzaPrefix]/[S3バケット名]/[mp4ファイルへのパス]/playlist.m3u8

今回、Wowzaアプリケーション名はmediacache、WowzaPrefixは（サーバ設定のMedia Cacheで設定した）amazons3としています。S3バケット名は仮でexample-wowza-mediacacheとすれば、sample1.mp4のファイルをHLS形式で取得する場合のURLは以下となります。

http://[wowza-ip-address]:1935/mediacache/_definst_/mp4:amazons3/example-wowza-mediacache/mp4/sample1.mp4/playlist.m3u8

このアドレスに対して、macOSのSafariから直接アクセスしたり、Video.jsなどのHLS対応動画プレイヤーからアクセスすることでS3バケットに格納した動画がWowzaを介してストリーミング再生することができます。

ちなみにcurlコマンドでm3u8ファイルの内容を確認すると、以下のように2段構成でtsファイルにアクセスしていることが確認できます。


$ curl http://[wowza-ip-address]:1935/mediacache/_definst_/mp4:amazons3/example-wowza-mediacache/mp4/sample1.mp4/playlist.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=2756175,CODECS="avc1.66.31,mp4a.40.2",RESOLUTION=1280x720
chunklist_w1784431111.m3u8

$ curl http://[wowza-ip-address]:1935/mediacache/_definst_/mp4:amazons3/example-wowza-mediacache/mp4/sample1.mp4/chunklist_w1784437481.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:13
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:12.012,
media_w1784431111_0.ts
#EXTINF:5.658,
media_w1784431111_1.ts
#EXT-X-ENDLIST

また今回は試していませんが、Wowzaの公式ドキュメントを確認する限り、Wowza Streaming Engineで対応している他のストリーミング形式、RTMPやHDS(San Jose)、Smooth Streaming、MPEG-DASHなどでもURLを一部変更するこにより対応可能のようです。

Media Cache機能使用時の留意事項など

Wowza側の設定をいくつか行うことで、割と簡単にMedia Cache機能が利用できた印象です。ただ、検証している中でいつくか気になった点がありましたので、まとめておきたいと思います。

キャッシュ有効期限について

キャッシュの有効期限については、Server > Media Cache > Sourceの設定箇所で変更が可能です。IAMユーザのアクセスキー、シークレットキーを入力した箇所の下にTTL（Time To Live）設定箇所がありますね。ここでこのTTLカウント開始のタイミングについては、「コンテンツを再生している最後のクライアントが停止したとき」から始まる点に注意しましょう。例えばひっきりなしにクライアントが対象動画を再生しているような状況だと、S3側の動画を更新してもなんかなかTTLが切れず、Wowza側のCacheが更新されないこととなります。

また「クライアントが再生を停止した」というタイミングですが、手元で確認した限りではHLS配信の場合、再生を停止してからMinimum TTL + 1分がキャッシュ更新のために必要でした。おそらくHTTPのコネクションなどが1分ほどで切断され、そこから再生が停止されたと判断、TTLのカウントダウンがスタートするのではないかと推測しています。

S3へのアクセス方法について

今回、S3へのアクセスのためにIAMユーザの作成、アクセスキーとシークレットキーの発行、Wowzaへの登録を行いました。可能であればここはIAMロールをEC2に設定し、アクセスキー、シークレットキーはWowzaへ登録させてたくないですよね。私が確認した限りでは、このIAMロールを使用する方法は残念ながらできませんでいした。（実際にIAMロールをアタッチして、アクセスキーとシークレットキーなしで設定、動作確認しましたが、うまく動作しませんでした。）ドキュメントにもIAMロールについての記載がないので、おそらく現状ではIAMロールは使用不可と考えます。機能アップデートで使用できるようになると良いですね！

またS3についてパブリックアクセス可能、もしくはS3バケットのWowzaからアクセスするオブジェクトについてパブリックアクセス可能であれば、アクセスキー、シークレットキーを設定しない状態でも、Media Cacheが動作しました。

東京リージョンへS3バケット作成直後のアクセス不可問題

最後に私が検証時にハマったポイントについても記載しておきます。検証用にS3バケットを東京リージョンにて新規作成し、Media Cacheを設定してアクセスしたのですが、うまくアクセスできませんでした。

原因を探ってみたところ、Wowza側でアクセスしているS3のURLで307 Temporary Redirectを返していたことが原因でした。具体的には、本エントリで先ほど紹介したMedia Cacheの設定、「Use Amazon S3 bucket name in domain」の項目をonにした状態だと、Wowzaはhttp://mybucket.s3.amazonaws.com/mypath/sample.mp4の形式でS3のファイルにアクセスします。

このURLをのレスポンスを確認してみると307 Temporay Redirectを返し、http://mubucket.s3-ap-northeast-1.amazonaws.com/mypath/sample.mp4にリダイレクトされました。ドメインにs3-[リージョン名]が含まれるかたちのURLですね。おそらくこのリダイレクトにWowza側が対応できなく、アクセスが不可だったと考えられます。

このS3バケット作成直後の307 Temporay Redirectを返した点については、S3ドキュメントに記載がある、一時的なリクエストのリダイレクトが発生したのかと考えています。具体的にはカウントしていませんが、1時間程度したら307 Temporay Redirectを返さなくなりました。

リクエストのリダイレクトと REST API - Amazon Simple Storage Service

なお、307 Temporary Redirectを返している間でも、「Use Amazon S3 bucket name in domain」をoffにし、Base Pathをhttp://mybucket.s3-ap-northeast-1.amazonaws.com/とすれば最終的にアクセスするURLはリダイレクト先と同一となるため、アクセスが可能となります。

まとめ

Wowza Streaming Engineの機能の一つであるWowza Media Cacheを使って、Amazon S3にあるファイルをオリジンとしてWowza Streaming Engine経由でHLS配信を行ってみました。WowzaとS3の連携として非常に力強い機能ですね。メディアファイルは容量が大きくなりがちで、動画配信サービスなどを企画するときもファイル総容量は推定し辛いものかと考えます。そこに容量無制限のS3が利用でき、Wowzaサーバ側のメディアファイル保存容量を気にしなくてよいのは大きな利点ですね。ただ簡単にWowzaで使用するストレージをEBSからS3に変更できる！とも考えられるのですが、あくまでキャッシュであるため、TTLやファイル更新時の挙動などには注意しましょう。