【レポート】 AWS Media Services とメディアワークフローの最新事例 #AWSSummit

はじめに

清水です。5月30日(水)から6月1日(金)の3日間の日程で行われましたAWS Summit Tokyo 2018、少し間が空いてしまいましたが、2日目に行われたセション「AWS Media Services とメディアワークフローの最新事例」についてレポートします。

本セッションですが、モデレータの安司 仁氏（アマゾン ウェブ サービス ジャパン株式会社 技術統括本部メディアエンターテインメント・ソリューション部 ソリューションアーキテクト）によるAWS Media Services全般やメディアワークフローにおけるAWSの利用価値の解説からはじまり、全5社の事例紹介で構成されました。盛りだくさんの内容でしたが、セッションの時間も通常の1枠40分ではなく倍以上の100分（16:00-17:40）で行われました。

事例紹介についての概要は各項目にて記載しております。本セッション自体の概要は以下となります。 AWS Media Services（AMS）は昨年 re:Invent でリリース以降、国内でも多くのお客様でご利用いただいております。本セッションでは、AMS 並びにメディアワークフローにおける最新事例を実際に導入したお客様よりご紹介いたします。 https://www.awssummit.tokyo/tokyo_session/session/

本レポートも内容が膨大になりましたので、以下に目次を記載します。

レポート目次

• AWS Media Servicesについて
• 【クックパッド株式会社】
  • クッキングライブアプリの高速開発 ～クックパッドがしかける新規事業～
• 【株式会社テレビ朝日】
  • AWS Media Services と Amazon Rekognition による映像アーカイブと自動メタデータ付与
• 【株式会社IMAGICA】
  • MediaConvert はじめました
• AWS Media Servicesによる海外事例の紹介
• 【株式会社フォアキャスト・コミュニケーションズ】
  • Media Asset Management on AWS 日本テレビとしてのメディアワークフロー
• 【株式会社フジテレビジョン】
  • フジテレビが構築した「 24×365 クラウドプレイアウトシステム」

　

AWS Media Servicesについて

まずはモデレーターである安司 仁氏（アマゾン ウェブ サービス ジャパン株式会社 技術統括本部メディアエンターテインメント・ソリューション部 ソリューションアーキテクト）からAWS Media Serivces全般についての解説がありました。

メディアワークフローの課題とAWSの利用価値

• コンテンツの増加、AWSならストレージサービスで対応可能
• マルチデバイス、OTT強化
• イベント対応＆24x365、マネージドサービス、すばやい環境構築がAWSなら可能
• パーソナライゼーション、機械学習ソリューションの利用
• 新しいビジネスモデル
• コア・コンピタンス

AWS Media Services

• 5つのサービス
  • AWS Elemental MediaConvert
  • AWS Elemental MediaLive
  • AWS Elemental MediaPackage
  • AWS Elemental MediaStore
  • AWS Elemental MediaTailor
• メディアフローをより高速に構築できるように、AWS Elemeneltaが開発したサービスをAWS マネージメントコンソールから利用可能に

• 動画配信フロー

  • オンデマンド
    • MediaConvert
  • ライブ配信
    • MediaLive
    • MediaPackage、DRM,見逃し配信など
    • MediaStore、ライブ配信最適化オリジン
    • 3つでライブ配信は可能
    • 広告を挿入したい
      • サーバサイドで行いたい => MediaTailor
  • これらのサービスを使うことで、迅速にメディア・サービスを構築可能
  • 5つすべてのサービスが東京リージョンでローンチ済み

メディアワークロード

• さまざまな領域でAWSが利用可能
• インジェスト
  • 映像素材を効率幼駒AWSに受け渡すためのオプション
    • ネット回線、VPN接続。
    • AWS Global回線、S3 Transfer Accelarator
    • DX専用線、閉域ネットワークで安定、社内ネットワークに閉じた配信
    • Snowball、オフラインストレージ転送
• 制作＆ポスプロ
  • AWSの大量リソースを活用した映像編集
  • クラウド編集、高速画面転送で、サーバはAWS側に
  • クラウドレンダリング、AWSにJOいｎしたThinkbox、レンダリングジョブのディスパッチ
  • 従来のワークフローを変えずに、クラウドを利用してもらう
• DAM＆アーカイブ
  • セキュアかつスケーラブルなアセット管理
  • ストレージはAWSの強み
  • 容量無制限の階層化ストレージ、S3、Glacier、保管コストの最適化
  • DAM製品群、専用閉域NWで立ち上げをDALET、evertz、vidisping、などのDAM製品群
• メディアサプライチェーン
  • 対応製品ラインナップと安価で選択しの多い仮想サーバ
  • AWS Marketplaceで3rdパーティ製品も利用可能
  • 映像共有のハブとして。あらゆるフォーマットへの変換を
  • ワークフローの自動化、AWS Step Functions
• 送出/配布/OTT
  • 用途に合わせハイブリッドおよびオンライン連携
  • 配信サービス、AMS、CloudFront、
  • DX
  • 放送波に映像伝送も可能
• 分析
  • 分析基盤を活用し、サービス品質の向上とオートメーション
  • パーソナライゼーションして新サービス、サービス改善
  • ログだけではなく、映像素材そのものの解析、メタ情報の高機能化

　

【クックパッド株式会社】 クッキングライブアプリの高速開発 ～クックパッドがしかける新規事業～

続いてクックパッド株式会社 渡辺 慎也氏（クックパッドTV株式会社 CTO）、岩間 雄太氏（クックパッド株式会社 技術部開発基盤グループ エンジニア）から事例が紹介されました。

セッション概要は以下となります。 クッ クパッドでは新規事業の創出に力を入れており、その中の一つに料理動画事業があります。素早いサービスのリリースが求められる状況で、意思決定のスピード を上げるため、CookpadTV 株式会社を立ち上げました。その中でクッキングライブ視聴アプリである「cookpadTV」を開発する上で AWS Media Services を活用し開発を行いました。このセッションでは、cookpadTV の概要およびライブ配信システムの技術的な詳細についてご紹介します。 https://www.awssummit.tokyo/tokyo_session/session/

まずは渡辺氏よりクックパッドとサービス、ならびにアーキテクチャ全体について、次に岩間氏からライブ動画配信基盤について紹介いただきました。

クックパッドとサービスについて

• CookpadTV株式会社、
  • レシピ動画事業中力のため、子会社を設立
  • 独立事業として運営
• 目指す3つのNo.1 = ３つの新サービス
  • cookpad studio
  • storeTV
  • cookpadTV
• cookpad studio
  • 2時間で誰もが驚く1分動画を
  • 料理作成、動画編集して1分動画を作成
• storeTV
  • スマホなしでレピシが決まる
  • レシピ動画広告No1.を
  • スーパーで料理動画を流すサービス
  • スーパーに置いてあるデジタルサイネージ
  • レシピ動画を流す
• cookpadTV
  • レシピ動画課金No.1を目指す
  • クッキングライブで新しい料理体験
  • 料理を見ながら、質問したり、ソーシャルがつながる

アーキテクチャ全般について

• 全体アーキテクチャ
  • RTMP -> HAProxy -> ライブ動画配信基盤
• MediaLive
  • すぐに配信できるようにならない
    • 配信日時が決まったタイミングで、リソース作成
    • 1週間前ぐらい
    • 制限緩和した
  • Security Groupが編集不可だった
    • 現在は改善された
    • HAProxy使って回避
    • 1週間前だとスタジオが決まっていない
    • つまりグローバルIPも決まっていない
    • HAPProxyでRTMPをリバースプロキシする構成
• APIサーバのAutoScaling
  • ユーザがライブ配信で増える
  • 事前にAutoSclainさせる必要あり
  • 番組によって、決めた。人気のあるなし
  • min capasityを上げる。 desired countではなく。放送開始時にmin capacityを戻す。
    • クックパッド開発者ブログに詳細がある
    • （筆者注:cookpadTV ライブ配信サービスの”突貫” Auto Scaling 環境構築 - クックパッド開発者ブログ）
• コメント、ハート配信
  • ライブの盛り上がり、コミュニケーション音要
    • 気軽にコメント、ハートを連打、Golang
    • こちらもクックパッド開発者ブログに詳細がある
    • （筆者注:クッキングLIVEアプリcookpadTVのコメント配信技術 - クックパッド開発者ブログ）

ライブ動画配信基盤

• ライブ動画基盤の責任
  • ライブ配信
  • アーカイブ動画
• 設計方針
  • よくスケールして運用が楽であること
  • 配信部分はS3/MediaStoreなどマネージドサービスにまかせる
• 避けたいこと
  • 人気番組あるからサーバ増強
  • 予想外のアクセスがあって落ちる
• AWS Elemental MediaLiveの採用理由
  • Wowzaと比較
    • 想定した設計を素直に構築できる
    • S3やMediaStoreとの連携
    • AWSほかサービスとの連携、マネージドサービスであること
• ライブ配信の構成
  • 番組情報を受け取って、MediaLiveなどのリソースを作成
  • 開始時間になったら、MediaLiveをrunningの状態へ。CloudWatchのアラームも設定する
  • MediaStoreに出力して、CloudFront経由で視聴
• アーカイブ配信
  • MediaLiveのArchive出力を使用
  • S3で配信
• 工夫した点
  • MediaLiveの状態遷移
    • なかなからrunningにならないケースがあった
    • 一定時間runningにならなければ、Channelを作り直す（再作成）することで回避
  • 配信検知
    • 配信検知用のデーモンを実装
    • 開始検知はアーカイブが作成されたら。S3 EventをSQSへ
    • 終了検知はMediaLiveのNetwork Outを利用する。Network Outがなくなれば放送終了
  • MediaLiveのArchive出力とグループのフォーマット
    • 数秒ごとのtsファイルを生成
    • S3に保存、まとめて結合、変換する

　

【株式会社テレビ朝日】 AWS Media Services と Amazon Rekognition による映像アーカイブと自動メタデータ付与

次の事例は小林 剛氏（株式会社テレビ朝日 技術局設備センターサイバーメディアシステムグループ）から、テレビ朝日でのAWS Media ServicesならびにAmazon Rekognitionの活用例となります。

セッション概要は以下となります。

映像のメタデータを作成することは、検索・編集・制作・再利用・分析など様々な用途に必要な要素である。

今回、AWS Media Services を利用しインターネットLIVE配信された映像をアーカイブしながらメタデータを自動で生成する実験を行った。

https://www.awssummit.tokyo/tokyo_session/session/

背景

• インターネットLIVE配信の増加
  • 視聴デバイスの増加
  • 通信の高速化
• 放送素材からインターネットオリジナル素材へ
• インターネットオリジナル素材の課題
  • メタ情報が少ない
    • 増やしたくても人がいない
    • 膨大な情報がほしい
  • 映像自体の管理
    • 再利用のためにも高画質で保管したい

AWS導入の理由

• 導入の容易さ
• 拡張性
• 安全性
• 以上の３つだが、実績もあることからAWSの利用を決定
  • AMSが非常に有効だった

構成

要望

• 配信した映像にメタ情報をつけたい
  • 自動的に出演者を判断する
• 配信したLIｖE映像を再確認したい
  • 一定期間データを保持する
• 任意時間の映像を取り出したい
  • タイムコードを利用
  • 再利用しやすいコーデックに変換

設計思想

• フルマネージドで構築
• インフラ管理はしたくない、避ける
• AWS Media ServicesとAmazon Rekognitionの利用

AWS Media Services

• 動画テクノロジーにおけるフルマネージドサービス
• AWS Elemental MediaLiveとAWS Elemental MediaConvertを利用
• 東京ローンチ、2018/02

Amazon Rekognition

• 画像分析と動画分析のフルマネージサービス
• 2018/2に東京リージョンローンチ
• シーン、物体認識のほか、有名人認識が可能（セレブリティ認識）
  • セレブリティ認識、日本人はどうか？

実験構成

• Elemental Live → AWS Elemental MediaLive → TSファイルを出力 → Lambda Function経由でMediaConvertで変換
• プレビュー用動画と、学習用動画を作成、
• プレビュー用動画はタイムコードを焼き付ける

メタ情報抽出

• S3 → Lambda → Rekognition→ > DynamoDB
• API Gatewayを経由してDynamoDBからデータ取り出し

切り出し

• MediaConvertでタイムコードを指定して、mp4に変換、S3へ格納
• mp4はCloudFront経由でダウンロード

Webアクセス

• CloudFront経由でアクセス
• AWS WAFでアクセス制限
• WebページはS3でホスティング

2月末に展示会、年明けに構築準備して、1ヶ月半で展示できるまでに。スピード感がでた。

Amazon Rekognitionの結果の一例

• 日本人も認識することが可能。思っていた以上にできた。日本人はアルファベット表記。
• 高いconfidence値(信頼性)、高い認識。有名アナウンサーなら認識可能だった。

• 評価が難しい。誰か認識できなかった、という判断が難しい。

• 間違えることもある、という前提で仕組みを作る必要。

まとめ

• インターネット配信素材が増加
• AWS Media Servicesを利用することで1ヶ月半でトライアル環境の検討から構築まで
• Amazon Rekognitionは日本人の識別でも有効

今後の課題

• コストコントロール
  • MediaLiveはアイドルでも課金発生
  • 一時的な利用はdeleteが必要、JSONで保存かCLIでつくる
• メタ情報の収集と有効利用
  • 音声メタ情報、テロップ情報
  • 検索、分析の利用へ
• 本運用実施へ、検討を重ねたい

　

【株式会社IMAGICA】 MediaConvert はじめました

続いては工藤 隆朗氏（株式会社IMAGICA 開発本部技術開発室）によるAWS Elemental MediaConvertについての事例紹介です。

セッション概要は下記となります。 MediaConvert ついて検証した結果とポストプロダクションでの導入に関する情報をケーススタディを交えて紹介します。 https://www.awssummit.tokyo/tokyo_session/session/

なぜMediaConvert?

• 目的
  • さまざまなメザニンファイルからプレビューファイルを使いたい
• 結果
  • 600h分のコンテンツを6時間でプレビューファイルにコンバート
• これまで
  • プロフェッショナルコーデック使う場合、EC2に頑張ってインストールする必要があった
  • S3からEC2へのファイルコピーも大変
• MediaConvert
  • MediaConvertはElasticTranscoderと比べて、プロフェッショナルコーデックに多く対応。EC2を使う必要がない

よいところ（運用）

• サーバ管理不要
• ソフトウェア・ライセンス不要
• 実装なしでS3アクセス可能
• 作業に合わせたスケーリング（上限緩和が必要な場合も）
• 優先度のの異なるパイプラインを作り込み処理が可能（キュー機能）

よいところ（いろいろできる部分）

• タイムコードベースでのクロッピング
• タイムコードのburn-in
• 音声の入れ替えが可能
• プロフェッショナルコーデックの対応
  • Inputの種類が多い、
• 普通の人は使わないであろう部分までトランスコードの設定が可能
  • 画質の追い込みができる

コツとポイント

• 普通の人が使わないであろう部分までトランスコード設定が可能
  • 映像、コーデックの知識がないと求めているものにならない
• 前後のワークフローと連携、自動化することで効果を発揮

Next Step

• 前後のワークフローと連携、自動化することで効果を発揮
• ワークフローの自動化と創意工夫で高速化にチャレンジ中

TASKEE（サービス紹介）

• クラウドファーストのデータ管理・共有ソリューション
• 内部をMediaConvetに入れ替えることを検討中

デジタイズ・アップロード代行作業

• 数百テラバイトの動画データ移行の実績多数
• 急ぎのデータはDirect Connect経由で
• まとめて転送する場合はSnowballを利用

　

AWS Media Servicesによる海外事例の紹介

ここで一度モデレーターの安司 仁氏に戻り、日本国外でのAWS Media Servicesの事例について紹介がありました。

AWS Elemental MediaTailor活用事例

• fuboTV
  • 既存構成にMediaTailorを導入することでパーソナライズされたサーバサイド広告による収益化

その他AWS Media Servicesの活用事例

• Sky News Royal Wedding：Who’s Who
  • イギリス王室のロイヤルウエディングの配信サービス
    • 2,300万人へのライブ配信の基盤
  • キャッチアップ再生（追いかけ再生、MediaPackage→S3）、DRM処理にMediaPackageを利用
  • 機械学習を組み合わせ、ゲストと関連情報をリアルタイム識別、配信
  • Elemental Live → AWS Elemental MediaLive → AWS Elemental MediaPackage → S3/CloudFront
  • サイトはまだあるので、視聴して体験してほしい
    • Who's Whoで検索を
    • （筆者注: Harry & Meghan Royal Wedding: Who’s Who Live）
• AWS Media Servicesについては昨年末にリリースされたサービス群だが、既に商用利用の事例がある。是非ご検討、ご活用を

　

【株式会社フォアキャスト・コミュニケーションズ】 Media Asset Management on AWS 日本テレビとしてのメディアワークフロー

続いて岩田 雅也氏（株式会社フォアキャスト・コミュニケーションズ システムサービスディビジョン リーダー（兼） 日本テレビ放送網株式会社インターネット事業局インターネット事業部）より、Media Asset Management on AWS 日本テレビとしてのメディアワークフローと題して日本テレビでの動画配信事例について紹介がありました。

• ビジネス背景
  • 動画配信サービスの素材が増加傾向にある
• メディアワークフロー前夜
  • これまでは手動運用が基本だった
• 地上デジタル放送用マスター設備を刷新
  • テープからファイルベースシステムに変更
  • ファイルベースなので、物理媒体を介さずエンドユーザまでいけるのでは？
  • メディアフローを改善
• 新しいメディアワークフロー
  • HARBORというIMAGICAさんのサービスでファイル転送
  • TradisというシステムでAWSに転送、日テレオンデマンドやHulu
  • ほとんど人の手を介さずに実現
• どう変わったか
  • テープおよびHDDからファイル転送に変更
  • ファイル転送はHARBOR
  • Tradisに情報集約
  • Tradisから各動画配信サービスにシームレスで展開
    • S3からファイルコピーして連携
• HARBOR is 何
  • 大容量の映像素材を安全にファイル転送するプラットフォーム
• Tradis is 何
  • transfer distributionを語源とした配信素材システム
  • 素材とメタデータを一元管理できるシステム
  • DX、閉域網でセキュリティを担保
  • 日テレの動画配信サービスとシームレスに結合
• Why Cloud, Why AWS
  • 当初予定
    • シームレスに結合するためのAWS
    • セキュリティ考慮してDX利用
    • 人件費の節約
  • 実際運用してみて、どうなったか
    • 移行が容易かつスピード感を持って実施できた
    • テープ搬入の時間及び経費節約になった（テープ代など）
• 課題
  • まだすべてのワークフローが自動化されていない
  • AMSローンチ前に設計/開発したので、外部ソリューションを一部使用している箇所があるので、プラッシュアップの余地がある
• 結論
  • AWS最高！！

　

【株式会社フジテレビジョン】 フジテレビが構築した「 24×365 クラウドプレイアウトシステム」

最後にフジテレビのクラウドプレイアウトシステムについての事例紹介がありました。スピーカーは関 克哉氏（株式会社フジテレビジョン 技術局IT推進センター配信技術推進部 兼 総合事業局コンテンツ事業センター コンテンツ事業室ペイTV事業部 兼 株式会社サテライト・サービスシニアマネージャー）です。

セッション概要は以下となります。

こ れまでの放送インフラの概念を払しょくする、”クラウド上の放送局”。「設備投資の抑制」、「シンプル・オペレーション」、「人的リソースのミニマム 化」、「ランニングコストの低減」、「容易なチャンネル追加」の全てを実現。本システムは「コンテンツ管理」、「編成・管理」、「プレイアウト」の ３ つから構成され、ほぼすべての作業をPC経由で可能にした、いわばカバンで持ち運べる放送局とも言い換えることができます。本セッションでは開発に至るま での経緯や設計指向、運用管理など、具体例を交えて紹介します。 https://www.awssummit.tokyo/tokyo_session/session/

• フジテレビのCS放送のサイマル配信
  • CS放送のサイマル放送、同時配信を2004から行っている
  • フジテレビ１，２，Next、24x365でサイマルライブを実施
  • オンプレも併用した、ハイブリッドクラウドで運用している
• クラウドプレイアウトの開発背景
  • 新しい放送サービス
  • 24x365でリニア配信する
  • 放送品質、高品質な映像サービス
  • 持続性、安定性、止まってはダメ。有料サービス。
  • コスト、事業収益製が想像つかない。放送プレイアウトを流用するとコスト合わない
  • フレキシブルな対応ができるように
  • フルクラウド
    • 既存のクラウドともう一つ、マルチクラウド
  • EVC Bizlat、営業放送システムのコントロール、放送のをそのまま使うのはオーバスペック
• プレイアウトシステムの概要
  • Cloud
    • シンプル
  • Traditional
    • 複雑なシステム。営業放送（営放）システム、送出APC
    • テロなどの対応のため、オンプレミスである必要
  • System
    • クラウドプレイアウト開発
      • 冗長化
      • タイムコード重畳
      • 短尺コンテンツのサポート
    • 新規開発の構成ソフトウェア
      • 放送局のノウハウ
      • 配信に最適化
    • 既存コンテンツとの連携
    • ファイリング作業の軽減
    • 構成
      • オンプレからmp4でシステムをAWSへ、他、AWS上のMXFファイルを再利用（再放送用）
      • AWS上のプレイアウト1号機、2号機の冗長構成から、out
      • outはZixiでdecoder経由で、SDIでdTVなど送信先へ
      • VOS(配信専用のソフトウェア)
• デモ
  • 本番用のクラウドプレイアウトシステムに、AWS Summit会場からログイン
  • 編成を、この会場から設定可能
  • 新規の枠作って、この番組を入れましょう、など
  • 番組のメタ情報など編集可能
  • コマーシャルの登録も可能。（営放の中でやっていることが、すべてできる）
  • インターフェースはBizlat
  • プレイアウト側はVOSのインターフェース
  • プレイアウトに情報が行って、時間になったら放送（配信）が始まる、という具合
• Achievement
  • 安定した運用
  • 場所を限定しない監視体制
  • 運用にかかる人的リソースのミニマム化
  • ランニングコスト削減
  • 柔軟かつ迅速な事業展開
• 持ち運びができる放送局を目指している
• Channel in a bag

感想

全5社の事例紹介からなる、とても盛りだくさんのセッションでした！メディアアセットマネジメントやプレイアウトシステムなど、メディアワークフローにおける多様な箇所でAWSが利用されていることがわかりました。また昨年2017年11月にリリースされたAWS Media Servicesについて、海外のみならず日本国内においても、すでにいろいろな場所で導入されていることがわかり、充実したセッションでした。