機械学習サービスを使ってメディアファイルを処理するワークロードを簡単に構築できるフレームワーク「AWS Media Insights Engine」を触ってみた
こんにちは、大前です。
AWS が提供するソリューションのひとつである、AWS Media Insights Engine(以下 MIE)を触ってみましたので紹介します。
AWS Media Insights Engine | 実装 | AWS ソリューション
AWS Media Insights Engine とは
概要
AWS は機械学習サービスなどを提供しており、これらを活用する事でビデオや画像、音声などの分析や変換処理を行うことが可能です。
一方で、これらのサービスをアプリケーションに組み込もうとすると、処理の状態を管理する DB が必要になったり、複数の処理をつなぎ合わせてワークフローを作成する必要があったりと、なかなか大変です。
こういった課題を解決するのが、今回紹介する MIE になります。MIE は各種機械学習サービス等からワークフローを作成するためのフレームワークで、API が提供されるためアプリケーションへの組み込みもしやすい形になっています。
構成図
以下は MIE のソリューションガイド に添付されている構成図です。MIE を展開すると、以下リソースが作成される形になります。
(引用 : AWS Media Insights Engine)
MIE は大きく分けて コントロールプレーン と データプレーン の 2つの要素に分かれます。
コントロールプレーン は、ワークフローに対する作成・管理・実行などの操作を行うための基盤です。ここでいう「ワークフロー」は、"MediaConvert で動画から音声を抽出し、Transcribe でテキスト変換を行う" のような一連の処理の事を指していると考えてください。
データプレーン は、各種メディアファイルの実体や、ワークフローの状態などの情報を格納するための基盤です。また、MIE を展開する際のオプションによっては、データプレーンの情報を外部アプリケーションに連携するための Kinesis Data Streams を作成することも可能です。
料金
MIE の GitHub リポジトリの README に、発生する費用の参考値が記載されています。
AWS Service | Quantity | Cost |
---|---|---|
Amazon API Gateway | 1 million workflows | $3.50 / mo |
Amazon Dynamo DB | 1 million workflows | $.025 / mo |
AWS Lambda | 100 workflows | $4.75 / mo |
Amazon Kinesis | 100 workflows | $12.56 / mo |
Amazon SQS | 1 million workflows | $0.40 / mo |
Amazon SNS | n/a | No charge |
Amazon S3 | 100 workflows | $2.3 / mo |
AWS Xray | 100 workflows | $.0005 / mo |
参考 : aws-solutions/aws-media-insights-engine - Cost
上記の情報では、ひと月に約 20 ドル発生する計算になりますが、大半が Kinesis の課金であることがわかります。Kinesis はオプションで作成しないようにできるため、検証目的でコストを抑えたい場合は Kinesis を作成しない形で MIE をデプロイすると良さそうです。
やってみた
では、実際に MIE を展開し、ワークフローをひとつ作成して動かすところまでやってみます。以下の流れで進めていきます。
- 事前準備
- MIE を展開する
- ワークフローのステージを作成
- ワークフローを作成
- ワークフローを実行
0.事前準備
MIE が提供する API を利用して操作を進めていきますが、MIE が提供する API を利用するためには SigV4 を利用してリクエストを署名する必要があります。
SigV4 でリクエストを署名する方法はいくつかあると思いますが、MIE の API ドキュメント ではサンプルとして awscurl を利用しているため、これを使いたいと思います。
参考 : okigan/awscurl
awscurl は pip や brew でインストールできます。
pip install awscurl
無事にインストールできたら OK です。
1.MIE を展開する
MIE のデプロイは、下記リンクに CloudFormation のスタックを展開するためのリンクを利用する方法や、ソースコードを Clone してきてビルドする方法が紹介されています。
参考 : aws-solutions/aws-media-insights-engine - Install
今回はコストを抑えるために Kinesis を作成しない形でデプロイしたいので、AWS Media Insights Engine から CloudFormation テンプレートを DL し、それを少し修正してデプロイするようにします。
(CloudFormation スタック展開のためのリンクからでも Kinesis を作成しないためのオプションを指定できますが、エラーが発生し展開できなかったため、テンプレートを直接修正する手順としています。 *1)
こちら のリンクを開き、画面中部の「CloudFormation テンプレート」をクリックし、テンプレートファイルをダウンロードします。
ダウンロードされた media-insights-stack.template
というファイルをエディタで開き、1891行目付近の下記部分をコメントアウトします。
## --before-- AnalyticsStreamArn: Description: Arn of the dataplane pipeline Value: !GetAtt Analytics.Outputs.analyticsStreamArn Export: Name: !Join [":", [!Ref "AWS::StackName", AnalyticsStreamArn]] ## --after-- #AnalyticsStreamArn: # Description: Arn of the dataplane pipeline # Value: !GetAtt Analytics.Outputs.analyticsStreamArn # Export: # Name: !Join [":", [!Ref "AWS::StackName", AnalyticsStreamArn]]
テンプレートを修正したら、マネジメントコンソールから「スタックの作成」に進み、修正後のテンプレートをアップロードして進みます。東京リージョンはまだサポートされていないようなので、バージニア北部を利用します。
スタックの名前はなんでも良いですが、今回は mie-stack
としました。MIE 側の制限で 12文字以内にする必要がある ので、気をつけましょう。
参考 : aws-solutions/aws-media-insights-engine - Limitations
その他のパラメータは下図のとおりですが、DeployAnalyticsPipeline
のみ false としています。これにより、Kinesis が作成されなくなるためコストが抑えられます。他の項目はデフォルト値のままです。
それぞれチェックを入れて、「スタックの作成」を実行します。
少し待機すると、ネストされたスタックを含む複数のスタックが作成完了になっていることが確認できます。
スタック(今回は "mie-stack")の出力部分を確認すると、WorkflowApiEndpoint
というものが確認できるかと思います。これはこの後の手順で利用するため、メモしておきます。
2.ワークフローのステージを作成
続いて、ワークフローのステージを作成していきます。
ステージとは、1つ以上の並行して実行されるオペレーターを含んだグループ の事を示します。
オペレーターとは、Lambda 関数を利用してメディアファイルの分析や変換などを行う 1つのステートマシンを示します。オペレーターは自作することも可能ですが、MIE にはビルトイン済みのオペレーターが提供されているので、最初はこれらを使うのが良さそうです。具体的にどのようなオペレーターが提供されているのかは下記を参照ください。
参考 : aws-solutions / aws-media-insights-engine - Architecture components
また、GET /workflow/operation
を利用することで、定義されているオペレーター一覧を取得することができます。API のエンドポイントは MIE をデプロイした際にメモした WorkflowApiEndpoint
の値を利用します。
WORKFLOW_API_ENDPOINT=<メモしたエンドポイント> awscurl -X GET --region us-east-1 $WORKFLOW_API_ENDPOINT/workflow/operation | jq -c '.[].Name' | sort
以下の結果が返ってきます。
"ComprehendEntities" "ComprehendKeyPhrases" "CreateSRTCaptions" "CreateVTTCaptions" "GenericDataLookup" "Mediaconvert" "Mediainfo" "MediainfoImage" "Polly" "PollyWebCaptions" "Thumbnail" "TranscribeAudio" "TranscribeVideo" "Translate" "TranslateWebCaptions" "Wait" "WebCaptions" "WebToSRTCaptions" "WebToVTTCaptions" "celebrityRecognition" "celebrityRecognitionImage" "contentModeration" "contentModerationImage" "faceDetection" "faceDetectionImage" "faceSearch" "faceSearchImage" "labelDetection" "labelDetectionImage" "personTracking" "shotDetection" "technicalCueDetection" "textDetection" "textDetectionImage"
ステージを作成するには、POST /workflow/stage
を利用します。ステージに含めるオペレーターとして、今回は Mediaconvert
を指定します。ステージ名は任意なので、今回は my-stage-01
としました。
WORKFLOW_API_ENDPOINT=<メモしたエンドポイント> STAGE_NAME="my-stage-01" awscurl -X POST --region us-east-1 -H "Content-Type: application/json" --data '{"Name":"'$STAGE_NAME'", "Operations": ["Mediaconvert"]}' $WORKFLOW_API_ENDPOINT/workflow/stage
下記は整形後ですが、JSON が返却されれば OK です。これは、作成されたステージの情報を表しています。長いので省略しましたが、Definition
配下には Step Functions の定義が格納されます。
{ "Name": "my-stage-01", "Operations": [ "Mediaconvert" ], "Configuration": { "Mediaconvert": { "MediaType": "Video", "Enabled": true } }, "Definition": "(省略)", "Version": "v0", "Id": "34bb9182-xxxx-xxxx-xxxx-4ce88cffe2bf", "Created": "1649126368.369242", "ResourceType": "STAGE", "ApiVersion": "3.0.0" }
3.ワークフローを作成
ステージが作成できたら、ステージを元にワークフローを作成します。ワークフローは 1つ以上のステージを含んでいて、かつステージの処理順序を定義します。ワークフローが作成されると、ワークフローの定義に基づいて Step Functions のステートマシンが作成されます。
API としては、POST /workflow
を利用します。ワークフロー名は任意のものを指定します。今回は my-workflow-01
としました。STAGE_1_NAME
には先ほど作成したステージの名前を指定します。
WORKFLOW_API_ENDPOINT=<メモしたエンドポイント> WORKFLOW_NAME="my-workflow-01" STAGE_1_NAME="my-stage-01" awscurl -X POST --region us-east-1 -H "Content-Type: application/json" --data '{"Name":"'$WORKFLOW_NAME'", "StartAt": "'$STAGE_1_NAME'", "Stages": {"'$STAGE_1_NAME'":{"End":true}}}' $WORKFLOW_API_ENDPOINT/workflow
ステージの時と同様に、ステートマシンの定義を含んだ JSON が返却されるかと思います。
ワークフロー作成後に Step Functions のステートマシン一覧を確認すると、作成したワークフローの名前でステートマシンが作成されていることが確認できます。
作成されたステートマシンの中身は下記のようになっています。今回はオペレーターひとつ、かつステージもひとつだけなので Mediaconvert
オペレーターに関するステートマシンのみ展開されています。
my-stage-01
として Parallel state が指定されていることから、ステージに複数のオペレーターを追加した場合は Parallel state によって並行処理が追加されることがわかります。
また、ステージを複数定義した場合には Complete Stage my-stage-01
の後ろにステージが増えていくような形になりそうです。
4.ワークフローを実行
ワークフローを作成したので、このワークフローを動かしてみます。ワークフローを実行するには、POST /workflow/execution
を利用します。MIE をデプロイした際に <スタック名>-dataplane-<ランダムな文字列>
という名前で S3 バケットが作成されているはずです。デフォルトでは、処理したいメディアファイルはこのバケットに格納することになります。
今回は Big Buck Bunny の動画を入力としてワークフローを実行してみます。
WORKFLOW_API_ENDPOINT=<メモしたエンドポイント> DATAPLANE_BUCKET=mie-stack-dataplane-xxxxxxxx WORKFLOW_NAME="my-workflow-01" aws s3 cp bbb_sunflower_1080p_60fps_normal.mp4 s3://$DATAPLANE_BUCKET/ awscurl -X POST --region us-east-1 -H "Content-Type: application/json" --data '{"Name": "'$WORKFLOW_NAME'", "Input": {"Media": {"Video": {"S3Bucket": "'$DATAPLANE_BUCKET'", "S3Key": "bbb_sunflower_1080p_60fps_normal.mp4"}}}}' $WORKFLOW_API_ENDPOINT/workflow/execution | jq
無事実行に成功すると、ワークフローに紐づくステートマシンが実行中になることが確認できます。
少し待つとステータスが成功になりました。
MIE が作成するデータプレーン S3 バケットを見にいくと、音声ファイルが出力されていることも確認できます。
また、MIE はワークフローの状態などを格納するための DynamoDB を用意しており、メディアファイルの追加やワークフローの実行と合わせて DynamoDB のテーブルも更新されていることが確認できます。
おわりに
AWS が提供するソリューション、AWS Media Insights Engine を触ってみました。メディアファイルを処理するワークロードを作成・管理するためのフレームワークを API 経由で扱えるため非常に便利、かつ活用の幅は無限大だなと感じました。
実際に、Content Localization on AWS や AWS Content Analysis など、AWS は MIE をベースとしたより具体的なソリューションを公開しています。
機械学習サービスを利用したメディアファイルの処理を行いたい場合、まずは MIE を検討してみると良さそうです。また、今まで機械学習サービスを組み合わせた処理を頑張って Step Functions で自作していた・・・という方は、もしかしたら MIE を使うことで幸せになれるかもしれません。
いろいろ面白そうなことができそうなので、引き続き触ってみたいと思います。
以上、AWS 事業本部の大前でした。
参考
- AWS Media Insights Engine | 実装 | AWS ソリューション
- How to rapidly prototype multimedia applications on AWS with the Media Insights Engine | AWS Media Blog
- aws-solutions/aws-media-insights-engine
- okigan/awscurl
- 並行 - AWS Step Functions
- Big Buck Bunny
脚注
- Issues · aws-solutions/aws-media-insights-engine を見ると沢山の Issue が上がっているようですので、こういった細かい不具合はいろいろありそうです ↩