(レポート) ARC406: エンコードアーティファクトがエミー賞を受賞:クラウドでのテラバイトスケール、1Gbps、4Kのビデオ処理を行う #reinvent

はじめに

清水です。re:Invent2016のBreakout Session、英題 "Encoding Artifacts to Emmy Awards: Taking on Terabyte-Scale, 1-Gbps, 4K Video Processing in the Cloud" のセッションレポートになります。 スピーカーはAWSのMedia and Entertainment担当のAlex Smithさんと、Amazon StudiosのCallum Hughesさんです。
本セッションではAmazonプライム・ビデオで配信されているAmazonスタジオ制作の4Kドラマ（例えばトランスペアレントなど）の配信までにおける各過程での課題と、それらをどのように解決したのかが紹介されています。

なお、以下でセッション動画も公開されています。

• AWS re:Invent 2016: Encoding Artifacts to Emmy Awards: Taking on 4K Video Processing (ARC406)

レポート

The Problem

• 4Kを扱う場合の問題点: 大きさが違う
  • 大きさが本セッションで扱うことの主題となる ｰ 処理としては同じ
  • Ingest, Storage, Processing, Distributionの4処理で扱われる

ビットレートとファイルサイズの比較

Amazonスタジオでの難問

• サイズが変わることに関してもこれまでと同様に、創造性を妨げることなくコントロールしたい
• Amazonスタジオでのワークフローの全体像
  • ファイルをS3バケットにIngest
  • EC2でS3バケットをWatch
  • メザニンファイルをS3バケットに格納
  • ELEMENTAL CLOUDと連携しトランスコード
  • 処理完了したものはAmazon Videoで配信

Ingestのスケール

• AWS
  • S3 Transfer Acceleration
  • AWS Snowball
  • AWS Direct Connect
• Parthner/Third Party
  • Aspera
  • Signiant
  • CloudBeam

Amazon S3 Transfer Accelerationの場合の考慮点

• 1つのエピソードでも数百GBの容量
• クラウドでも限界は存在する
• 予期せぬ結果が出ることもある、やってみるしかない

ELEMENTALを使用した場合

• ELEMENTALはS3からトランスコード可能
• マルチプルアップロードは1アップロード当たり10,000パートまで
• 1チャンク当たり 20MB
• 200GBのリミットが存在した

解決策

• 3ステップレイヤの構築
  • S3からのトランスコード
  • トランスコード出力をEBSへ
  • EBSからS3にアップロード
• パーフェクトではないが、効果的であった。
• 現在はELEMENTALのS3チャンク量が増えているため、この問題は回避できるとのこと。

Ingestのスケールについてのまとめ

• 大規模になることで破綻することはありうる
• APIのリミットについては確認するべき
• 代表的なデータで常にテストを

Storageのスケール

• 大容量ファイルの移動は大変
• ファイルは1箇所にまとめたい
• 配信時にCDN Origin用にファイルを移動等はなくしたい

メタデータの利用

• 分析時にも有効だが、抽出は難しい
• 処理ノードへのファイル転送などの課題

MediaInfoとLambdaを利用したメタデータの抽出

• MediaInfo
  • オープンソース
  • 各種情報参照可
  • XMLエクスポート
  • cURLとの連携
• 仕組み
  • S3にファイルを置くとLambda発火
  • LambdaはMediaInfoにURLをっこう
  • MediaInfoがメタデータをチュ出
  • DynamoDBにメタデータを格納
  • 詳細はブログにまとめられている

CloudNativeなDAM(digital asset management)

• Reach Engineを仕様
• 各種データAmazon Studio側のVPCに格納してセキュアに
• Rest APIを通じてアクセス可能に
• ELEMENTAL CLOUDともRest APIを通じて通信

Storageのスケールのまとめ

• オブジェクトをオブジェクトのように扱う
  • POSIX要件を避ける
• HTTP/cURLを使用する

Processingのスケール

AWSでのスケール方法

• 垂直スケール
  • largeインスタンスから32xlargeインスタンスなどより大きなインスタンススペックへ
• 水平スケール
  • インスタンス台数を増やす
• 対角線スケール
  • インスタンスタイプを変更 m4/c4/g2

GPUインスタンスでのスケールの検討

• GPUエンコーディングは可能か
  • G2: NVIDA GRID K520(Kepler)
  • P2: NVIDIA Telsa K80(Kepler)
• Codec Support Matrixから、KeplerはH.264 encodingは対応しているがHEVC(H.265)のエンコーディングは対応していないため、GPUエンコーディングは不可

垂直スケールの検討

• m4.largeからm4.16xlargeへ変更することで、エンコード速度は向上
• 時間辺りの単価も上がる
• ビデオエンコーディングでは特にメモリを多用する作業ではない
• c4.8xlargeがコスト面で最適
• プロセスの中断でエンコード処理が失敗してしまうため、あまり大きなインスタンスタイプにするのは良くなく、上限を設けるべき

水平スケールの検討

• Video Stream, Audio Stream と分けてエンコード
• さらにVideo Streamを複数のチャンクに分けて、チャンク毎にエンコードする
• チャンクへの分割は、例えばffmpegを活用する
  • ffmpegの-tオプションでチャンクへの分割長を決定
  • ffmpegのconcat機能で、エンコード後のファイルを結合
• これはEMRの処理と似ている
  • ファイルの分割
  • Map : チャンク毎にエンコーディング
  • Reduce : Concatで結合

Processingスケールのまとめ

• 非伝統的なワークロードに既存のツールを使用することを検討
• 並列化はスピードを向上させるだけでなく、リスクの軽減にもなる

Distribution

• プラットフォーム向けの配信はingestと同じこと
  • S3バケットからバケットへ
  • S3 Transfer Acceleration
• ユーザへの配信
  • CDNの利用
  • Adaptive Delivery (HLS/MPEG-DASH)

Adaptive Delivery

• 最上位のmanifestファイルから、各ビットレート毎のmanifestファイルを読み込ませる
• ビットレート毎にチャンクファイルが存在
• ビットレート毎のmanifestファイルとチャンクファイルを用意しておけば、Player側で自動的にビットレートを切り替えて配信される

4Kでの全世界に向けた配信の難点

• コンテンツをエンドユーザに近づける、という点は同じ考え
• キャッシュがすぐに古くなりオリジンから再度取得する必要がある
• 次のチャンクをフェッチするために、絶えず走査する必要がある

コンテンツをユーザに近づける

• S3とCloudFrontの接続は良好
• しかし、リージョンをまたいだレイテンシが発生する
  • S3はus-east-1、CloudFrontエッジはフィリピン、等

レイテンシを押さえて高速化するには

• S3クロスリージョンレプリケーションを利用して、最寄りのリージョンにあるS3にデータを取りに行くことが考えられるが、ドメイン名の制約により実現はできない

mid-tierキャッシュの仕組みを構築

• EC2 + Nginx Cacheで構築
• CloudFrontディストリビューションとS3の間にEC2を配備
• このEC2上のNginx Cacheにキャッシュさせる
• EC2は各リージョンに配備する
• さらに、マニフェストファイルを読み込み、チャンクファイルをプリフェッチ/先読みを行うことで、 mid-tierキャッシュに事前にキャッシュを配備することで、より高速な配信を実現
• 転送速度は大幅に向上

Deliveryのまとめ

• 世界中に高速に配信を行うことは難しい
• レイヤを組み合わせることで実現可能な手段を探す

まとめ

• 4K対応には課題があるが、既存のシステムを改善すれば対応はできる
• メディアとエンターテイメント産業はこれからも変わらないが、 技術としてはますます進化している
• Ingest
  • スケールが大きくなることで制限が課されることがあり、実際のサイズでテストすることが重要
• Stoarge
  • POSIXを避け、インテリジェントに処理を行う
• Processing
  • 並列化により問題を解決する
• Distribution
  • より高速に配信できるように、レイヤーの再利用を行う

まとめ

4Kでの配信までの各過程における処理も、基本的にはこれまでのHD動画のファイルが大きくなった場合と捉えることえ対応できそうですね。ただ本セッションにあった通り、ファイルサイズが大きくなることでのいくつか懸念、考慮すべき点があることも確かです。個人的には配信の際の、CDN(CloudFront)をそのまま使うのではなく、中間キャッシュを配置することが衝撃的でした。

本セッションはre:Invent2016の最終日(Day4, 2016/12/02)の最後の時間帯12:30-13:30に行われていたセッションです、さらにセッションレベルが400番台ということでそれにふさわしい深い内容のセッションでした。
しかしラスベガスにいた私は最終日当日に朝から体調を崩してしまい、本セッションを聴講してre:Invent2016を締めくくれなかったのが残念でなりません。。(そのため本エントリはYoutubeにて聴講したレポートになります)