2020年に向けてスポーツイベントにおけるaws活用事例
Jsportsのプロ野球4球団春季キャンプクラウド収録環境実証実験について
動機
Sun製のSQServerという2000時間収録出来るサーバー（2011年に構築）があって、
収録&編集を行っていたが、日々フル状態でアーカイブ&削除していた。
まかないきれない状態の時、イレギュラーで平昌冬季の収録&編集をすることになり、
VTRをレンタルするなど、仮設の設備で逃がそうとしたが、
2016年のリオオリンピックの時、上記システムで収録&編集した実績から、
平昌冬季を安定した設備の既存の上記システムでやり、
春季キャンプの一部収録を仮設の設備でやることにした。
仮設の設備を構築するにも、VTRレンタルするのか、設置場所、空調、電源、運用誰がするのかの問題があった。
2011年に構築したシステムを刷新する予定もあり、
クラウドの勉強会で、たまたまそこに営業でいたAWSに依頼することにした。
AWSのサポートが入ることにより、協力会社3社の紹介&連携が素晴らしかった。
クラウド収録&編集環境について
映放連動を行わないマニュアル運用を行なった。
久米島、沖縄、宮崎からインターネット回線とNGN回線で、basebandに戻して、キャリアにお願いしてIP転送してもらった。
その後、Jsport内で、グラフィックとか制作処理よりをし、SDIでSoftBankのTMCに送った（この回線は臨時で工事してもらった）。
その後、AWSElementalCloudでLiveEncodeをし、S3にインジェストをした。
素材をS3にアップロードした事により、自由な場所でAmazonWorkspacesを使用して、編集する事が出来るようになった。
S3とAmazonWorkspacesはAmazonStｒageGatewayで同期が取られている。
（実際は、人手不足で現場がリモート地でAmazonWorkspacesで編集作業をすることはなかった）
よかった点
短期構築が出来た。
ストレスフリー（セキュリティ、設置場所、空調、電源、運用などの心配がない）になった事で、本来の番組制作に集中出来た。
ロケーションフリーになった(実際にAWSElementalCloudをiPhoneで操作していた)
編集が容易になった(２，３Mbpsでもカット・ハイライト編集可能)
課題点
S3とAmazonWorkspacesとの同期が長かった。(出力時、レンダリング時には、一旦AmazonWorkspacesのローカルに書き出して、処理をしてからS3にアップロードするべきだった)
ライブ放送時の追っかけ編集、ハイライト編集、エンディング作成で試したが、
収録中のクリップを編集することが不可能な為、1分毎のクリップを自動生成する仕組みを作ったが、クリップの数が膨大が出来てしまい、管理が煩雑になってしまったのと、クリップの前後の音声がかける現象が発生してしまった。(今後解決する予定)
今後
本社を経由せず中継現場から直接AWSに上げるようにして、
中継終了後、システムを使い捨てが出来る構成にする運用にする。
オンプレで運用しているAvidMediaComposerを、
AWS上でも同じ環境を構築出来るように出来ないか検討している。
AvidMediaComposerは利用時間課金なので、
月額課金ではどうなのかというコスト面も検証していく。
どこにいてもなんでも出来てしまうシステムが、
出来るより良い番組制作が本当に繋がるのか、
制作技術の人員配置やワークフロー、編成計画を含めて、検討していく。
JリーグとIMAGICAライブ
動機
Jリーグの改革(PDMCA:ミスがあってもチャレンジする)が発端。
1年間のJリーグ1043試合のH264フォーマットを、クリーン、ダーティ、スカウトィング(戦略で使用する広い映像)の3映像を集約してアーカイブ化している。
アーカイブした映像は、全国のキー局、データスタジアム、クラブハウス、JFA審判部などに送っている。
４K、ビデオアシスタントレフリーなど将来性を見据えて対応している。
国内だけでなく海外の要件を満たす為にIMAGICA社の協力を仰いだ。
IMAGICA社でこれらをオンプレで構築しようとしたが、費用対効果、Jリーグの試合が90日という期間内での運用なので、使用したい時に使用出来るクラウドの利点を利用出来るのと、パートナーを含めたサービス連携が容易だったのと、AWSのマネージドサービスサポートの親身な対応でAWSにする事にした。
システム環境について
クリーン(素の画像)、ダーティ(実況・CGが入った画像)、スカウトィング(フォーメーションとか戦略で使用する画像)、３つの映像を7つの映像に変換している。
クラブや審判部には、スカウトィングを送って、レフリングの振り返り、検証に使用する為。
データスタジアムにライブ中継を送って、CGを入れ、ダーティ画像を作成。
キー局に映像を送信している。
各クラブのHP、Jリーグのオウンドメディアに使用するクリップ編集もしている。
SNS(Youtube,FB)への配信映像も作成している。
IP信号だけでなく、SDI信号も対応。
よかった点
従来は三浦知良のゴールシーン映像のデリバリーは出来なかった。毎試合取材をすることは出来ないので。現在はそのような時、即座に映像を出力し、その日のニュースに出せることができ、Jリーグにとっても露出にも繋がり、ニュース各社にとっても良い映像が使えるようになった。
今後
一連の作業を自動化
* 試合映像のアーカイブ
* デジタル・アセットのデリバリー
画像、選手データを活用した新サービス
AWS Media Services とメディアワークフローの最新事例
クックパッドTV
クッキングライブアプリ、レシピ動画のライブ動画配信基盤事例
AWSElementalMediaLiveは配信を開始するのに時間がかかる
１分後に配信開始と出来ないので、番組配信日時が決まったタイミングで、
MediaLiveのリソースを作成するようにした。
だいたい１週間前に番組が決定され、同時に４つしか作成出来ないので、制限緩和予約して１週間分届けられるようにした。
セキュリティグループ
EC2と同じ感じだが、当初MediaLiveのセキュリティグループは変更が不可だった（現在は変更可能）。
MediaLiveのリソースは番組開始時１週間前に作成するので、その時にセキュリティグループを作成するが、その時に配信するスタジオが決定されていないので、配信するグローバルIPが確定されていなかったので、EIPを付けたEC2インスタンスにHAProxyを立て上げ、ReverceProxyして、そのEC2のセキュリティグループを動的に変更するようにしていた。
APIサーバーのオートスケーリング
ライブ配信は通常のwebサービスと違って、配信開始日時にアクセスが集中するので、通常の負荷ベースのオートスケーリングでは間に合わないので、専用にオートスケーリングさせる必要があった。
オートスケーリングの数値算出は、アクセスログをベースにデータ活用基盤というのがあって、それを利用して算出した。
APIサーバーのオートスケーリング詳細
ECSのdesired countを上げてタスク数を増やすのではなく、min capacityの方を上げるようにしている(放送開始前に負荷が来ていないので、タスクが減るのを防ぐ為)。
min capacityは放送開始時に元に戻して、あとは負荷ベースのスケールに任せるようにしている。
詳細はこちら: http://techlife.cookpad.com/?css=css&rev=1&page=1525245151
コメントとハートの配信周り
ライブの盛り上がり感を出す為に必要な要素。
APIとは別にRailsではなくGolangで実装した。
詳細はこちら: http://techlife.cookpad.com/entry/2018/04/12/180000
ライブ動画配信基盤について
主な責任
ライブ動画の配信
アーカイブ動画の保存
設計方針
スケールし運用が楽、動画配信する時に急にオリジンサーバーにアクセスが大量に来る。その時にオリジンサーバーは耐えないといけないが、その部分をS3やMediaStoreをmicroserviceに任せることによって、スケール可能にしている。
避けたかった事として、事前に人気番組前のサーバーを増強するとか予想外のアクセスとかで、サーバーダウンによる配信が停まるのを避けたかった。
AWSElementalMediaLiveの採用理由
他社のメディアサーバーと比べて、素直な設計で構築出来たから。
S3、MediaStoreをオリジンサーバーにして配信可能だったから。
AWSの他のサービスとの連携が可能だったから。
microserviceに全て運用を任せられるから。
アーキテクチャ
APIサーバーが番組情報を受信して、MediaLiveを開始してチャンネルとインプットを作成する。
ライブ開始の一定時間になったら、MediaLiveでチャンネルをidleからLiveに変更する。
配信されてきた動画をMediaStoreにアップロードして、ユーザーはCFを経由して見る。
アーカイブ動画は、MediaLiveのArchiveOutputGroupを使用して、S3に出力。
うまくいかなかった点
MediaLiveの状態遷移、StartingからなかなかRunningにならない。
この状態になると一生Runningにならないので、一旦チャンネルを壊して再生成する。
動画の配信検知は、配信を検知するデーモンを作成した。
MediaLiveの状態を取得することは可能だが、今配信されているかされていないかは取得出来なかった。
配信開始検知は、アーカイブのS3イベントを使用して、１つ目の動画(チャンク)が作成されたタイミングで、SQSにキューを入れるイベントを作成し、SQSをデーモン（ワーカー）が監視して、実際に配信されているか否か判断している。
配信終了検知は、MediaLiveのNetworkOutを使用して、Outputが一定より下回ったら、終了検知としている。
ArchiveOutputGroupは数秒毎の細かいtsファイルで作成される為、１つのファイルにしなければいけないので、S3のMultipart Uploadを使用して、細切れのtsファイルを１つのtsファイルにして、その後社内の動画変換サービスを使用してユーザーに提供している。
今後の開発
ユーザー同士の総合コミュニケーション(IAP)の実装。
レシピ事業の世界展開(現在トライアル)。
株式会社テレビ朝日
映像アーカイブと自動メタデータ付与について
背景
インターネットのライブ配信が非常に増加している。
ライブ配信が増加しているのは、スマフォの増加により、ライブ配信を視聴出来るデバイスが増えてきたから。TVの受信もスマートTVだったり、ゲーム機でもライブ配信視聴が可能が当たり前になっている。
日本では回線が安定しているのも起因している。
２０１０年以降ライブ配信事業が増えた。スポーツでいえばDAZN,TVerでもサッカーのワールドカップを配信する。
２０１３年にテレ朝動画、２０１５年には新日本プロレスと、２０１６年にはCAとAbemaTV。
課題
従来は放送素材のライブ配信が対象だったが、インターネットのオリジナル素材がメインになってきて、
放送素材であればメタ情報(出演者、要約)が付いていたが、インターネット素材にはないという点と、
インターネット素材の管理はどこですれば良いのかが課題になっていた。
それらの解決の為にAWSのMediaServiceを使用しようとした。
なぜAWSで構築しようと思ったのか
社内で複数のサービスがAWSで構築していたのと、導入が容易ですぐ検証が可能だから。
拡張も容易。
AWSMediaServiceが今回やりたかった事と非常に有効だと思ったから。
コンセプト
メタ情報付加に人を割けられないので、自動化する。
配信した映像を再確認したい。
映像を再利用したい。
フルマネージドで構築。インフラの管理を避ける。
AWSMediaServiceの利点
外部配信、トランスコードに有用。
機能毎に分かれているので単体で利用可能。
今回利用したのは、MediaLiveとMediaConvert。
それとは別にAWSRekognitionを使用して、画像分析と動画分析をし、メタ情報を自動生成した。
AWSRekognitionの中で有名人認識を利用した。
アーキテクチャ
社内のElementalLiveから、MediaLiveに送り、劣化させずにｔｓファイルとしてS3のバケットに保存。
その時、S3のPutEventで、Lambdaで高画質のtsファイルをプレビュー用の低画質のtsファイルと、Rekognitionで使用するメタ情報作成用の低画質mp４ファイルをそれぞれ変換して、それぞれのS3のバケットに保存する。
プレビュー用の動画は最終的にwebで見れるようにする＋タイムコードを付けて切り出しが出来るようにしておく。
生成した低画質mp4をRekognitionに学習させた。
認識した有名人情報はDynamoDBに保存した。
それらを最終的にwebから見れるように、APIGateway + Lambdaを作成した。
MediaConverterを利用して、高画質動画からタイムコードを指定して動画をダウンロードするようにした。
作成した動画、メタ情報はCFを経由してダウンロードするようなHTMLをS3に置いてwebでダウンロード出来るようにした。
内部ツールなので負荷対策はしていない。
結果
１.５ヶ月で構築完了。
Rekognitionは日本人認識可能（アルファベット表記)が可能(高いConfidence値が出た)
課題
Confidence値の信頼性がどの値までなのか不明。
認識出来なかったかどうかがわからないので、認識できないのは承知の上で使う。
MediaLiveはアイドル状態でも課金が発生するので、コストのコントロールをする必要がある。
今後
本運用に向けてのコスト計算。
メタ情報の収集と有効利用。音声情報、テロップ情報とか色んな情報を作成することによって、検索・分析に利用し高度な手法をしていきたい。
IMAGICA
トランスコード処理の効率化でAWSを利用事例
動機
様々なメザリンファイルからプレビューファイルを作りたかった。
MediaConvert
従来はElasticTranscoder・EC2のオンプレ。
オンプレのサーバー管理不要。
特別な実装なしにS3に。
柔軟なスケーリング(２０ファイルを同時にやりたい場合、２０ジョブ生成すれば良い）。
並列な処理が可能。キューがあって、パイプラインを使った割り込み処理が可能。
タイムコードベースでクリッピング可能。
タイムコードのBurn-inができる。
音声の入替えが可能。
プロフェショナルのコーデック対応。
一般人には使用しないトランスコードの設定が可能。
コツとポイント
映像、コーディングの知識がないと求めているものにはならない。
前後のワークフローの連携、自動化することで、効果を発揮する。
インターレース解除フィルタをテストしても解除出来なかったが、突然直ってることがあったので、
自分で検証して使用しないと駄目。
株式会社フォアキャストコミュニケーションズ
日本テレビの動画配信事例
従来
手動運用（バイク便、メール、人力）
現在
地デジ用マスター設備を刷新されたことにより、ファイルベースになった
HARBOR（イマジカの転送サービス）を利用して、ファイルを転送
そこからAWSに転送して、オンデマンドコンテンツ（AWS）へ
配信素材管理システム（Tradis）に情報を集約
HARBORは、５０Mbpsで１時間２３GBを転送可能
Tradisは、素材とメタデータを一元管理できるシステム
セキュリティ面でHARBORBOXとの接続にDirectConnectを使用
結果
移行が容易かつ、スピーディに構築することが可能になった
課題
全てが自動化されたわけではない。
外部ソリューションが使用してる為、プラッシュアップの余地あり。
株式会社フジテレビジョン
割愛
AWSによるセキュリティ・オートメーションの実践
自動化の最小パターン： 入力->評価->実行
例: システム障害 -> パラメータチェック(IP,port etc..) -> 管理者へ連絡etc...
入力
メトリクスベース(闘地、異常検知)
イベントベース(任意、定期)
ルールベース
評価
取得、解析、比較、演算
実行
通知（レポート）
確認（スキャン、棚卸し）
修正（パッチ適応）
対応（隔離、タグつけ）
分析（ログ解析）
評価を実行するのにLambdaを使用
ユースケース
リスクベースのアプローチで考える起点
脅威（DDoS攻撃）
脆弱性（セキュリティホール）
情報資産（情報漏えい）
脅威にまつわるセキュリティオートメーション
AWS WAF
AWS Firewall manager
ログ解析からAWSWAFルールを自動適用
ALB＆CF->S3にログファイル
S3のPutをトリガーでLambdaを実行し、閾値を超えたエラー数に基づくIPアドレスを特定
IPアドレスを元にブロックルール適用
IPブラックリストの自動更新とAWS WAFルールへの反映
Cloudwatchのeventを定期実行
ハニーポットへアクセスするBot対策、API-Gatewayで作成
アクセス解析、ソースIPを取得、解析
AmazonGuardDuty 脅威検知と継続的監視をするサービス
悪意のある不正なスキャンを検知したら重要度に基づき管理者に通知
AmazonCloudwatchEvents -> lambda -> AmazonChimeに通知
EC2インスタンスの端末感染検知
感染端末の初期対応と封じ込め
AmazonCloudwatchEvents -> AWSSystemManager Run Command
AWSSystemManager Run Command：リモートでコマンドを発行できるサービス
FirewallManagerで全ユーザーAWS WAFポリシー更新することもできる
不正ユーザーによるなりすまし
事後分析（レトロスペクティブ分析）の開始
AmazonCloudwatchEvents -> AWS Step function -> Lambda -> lambda -> ...っていうワークフローを定義できる
脆弱性
AWS Config
AWS Config Rules(企業ポリシ準拠の監視)
Amazon Inspecter（自動化されたセキュリティ評価）：脆弱性診断
AmazonMacie（気密データの保護、監視）
インシデントレスポンスが早くなる。