クックパッドTV
クッキングライブアプリ、レシピ動画のライブ動画配信基盤事例
AWSElementalMediaLiveは配信を開始するのに時間がかかる
1分後に配信開始と出来ないので、番組配信日時が決まったタイミングで、
MediaLiveのリソースを作成するようにした。
だいたい1週間前に番組が決定され、同時に4つしか作成出来ないので、制限緩和予約して1週間分届けられるようにした。
セキュリティグループ
EC2と同じ感じだが、当初MediaLiveのセキュリティグループは変更が不可だった(現在は変更可能)。
MediaLiveのリソースは番組開始時1週間前に作成するので、その時にセキュリティグループを作成するが、その時に配信するスタジオが決定されていないので、配信するグローバル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イベントを使用して、1つ目の動画(チャンク)が作成されたタイミングで、SQSにキューを入れるイベントを作成し、SQSをデーモン(ワーカー)が監視して、実際に配信されているか否か判断している。
配信終了検知は、MediaLiveのNetworkOutを使用して、Outputが一定より下回ったら、終了検知としている。
ArchiveOutputGroupは数秒毎の細かいtsファイルで作成される為、1つのファイルにしなければいけないので、S3のMultipart Uploadを使用して、細切れのtsファイルを1つのtsファイルにして、その後社内の動画変換サービスを使用してユーザーに提供している。
今後の開発
ユーザー同士の総合コミュニケーション(IAP)の実装。
レシピ事業の世界展開(現在トライアル)。
株式会社テレビ朝日
映像アーカイブと自動メタデータ付与について
背景
インターネットのライブ配信が非常に増加している。
ライブ配信が増加しているのは、スマフォの増加により、ライブ配信を視聴出来るデバイスが増えてきたから。TVの受信もスマートTVだったり、ゲーム機でもライブ配信視聴が可能が当たり前になっている。
日本では回線が安定しているのも起因している。
2010年以降ライブ配信事業が増えた。スポーツでいえばDAZN,TVerでもサッカーのワールドカップを配信する。
2013年にテレ朝動画、2015年には新日本プロレスと、2016年にはCAとAbemaTV。
## 課題
従来は放送素材のライブ配信が対象だったが、インターネットのオリジナル素材がメインになってきて、
放送素材であればメタ情報(出演者、要約)が付いていたが、インターネット素材にはないという点と、
インターネット素材の管理はどこですれば良いのかが課題になっていた。
それらの解決の為にAWSのMediaServiceを使用しようとした。
なぜAWSで構築しようと思ったのか
社内で複数のサービスがAWSで構築していたのと、導入が容易ですぐ検証が可能だから。
拡張も容易。
AWSMediaServiceが今回やりたかった事と非常に有効だと思ったから。
コンセプト
メタ情報付加に人を割けられないので、自動化する。
配信した映像を再確認したい。
映像を再利用したい。
フルマネージドで構築。インフラの管理を避ける。
AWSMediaServiceの利点
外部配信、トランスコードに有用。
機能毎に分かれているので単体で利用可能。
今回利用したのは、MediaLiveとMediaConvert。
それとは別にAWSRekognitionを使用して、画像分析と動画分析をし、メタ情報を自動生成した。
AWSRekognitionの中で有名人認識を利用した。
アーキテクチャ
社内のElementalLiveから、MediaLiveに送り、劣化させずにtsファイルとしてS3のバケットに保存。
その時、S3のPutEventで、Lambdaで高画質のtsファイルをプレビュー用の低画質のtsファイルと、Rekognitionで使用するメタ情報作成用の低画質mp4ファイルをそれぞれ変換して、それぞれのS3のバケットに保存する。
プレビュー用の動画は最終的にwebで見れるようにする+タイムコードを付けて切り出しが出来るようにしておく。
生成した低画質mp4をRekognitionに学習させた。
認識した有名人情報はDynamoDBに保存した。
それらを最終的にwebから見れるように、APIGateway + Lambdaを作成した。
MediaConverterを利用して、高画質動画からタイムコードを指定して動画をダウンロードするようにした。
作成した動画、メタ情報はCFを経由してダウンロードするようなHTMLをS3に置いてwebでダウンロード出来るようにした。
内部ツールなので負荷対策はしていない。
結果
1.5ヶ月で構築完了。
Rekognitionは日本人認識可能(アルファベット表記)が可能(高いConfidence値が出た)
課題
Confidence値の信頼性がどの値までなのか不明。
認識出来なかったかどうかがわからないので、認識できないのは承知の上で使う。
MediaLiveはアイドル状態でも課金が発生するので、コストのコントロールをする必要がある。
今後
本運用に向けてのコスト計算。
メタ情報の収集と有効利用。音声情報、テロップ情報とか色んな情報を作成することによって、検索・分析に利用し高度な手法をしていきたい。
IMAGICA
トランスコード処理の効率化でAWSを利用事例
動機
様々なメザリンファイルからプレビューファイルを作りたかった。
MediaConvert
従来はElasticTranscoder・EC2のオンプレ。
オンプレのサーバー管理不要。
特別な実装なしにS3に。
柔軟なスケーリング(20ファイルを同時にやりたい場合、20ジョブ生成すれば良い)。
並列な処理が可能。キューがあって、パイプラインを使った割り込み処理が可能。
タイムコードベースでクリッピング可能。
タイムコードのBurn-inができる。
音声の入替えが可能。
プロフェショナルのコーデック対応。
一般人には使用しないトランスコードの設定が可能。
コツとポイント
映像、コーディングの知識がないと求めているものにはならない。
前後のワークフローの連携、自動化することで、効果を発揮する。
インターレース解除フィルタをテストしても解除出来なかったが、突然直ってることがあったので、
自分で検証して使用しないと駄目。
株式会社フォアキャストコミュニケーションズ
日本テレビの動画配信事例
従来
手動運用(バイク便、メール、人力)
現在
地デジ用マスター設備を刷新されたことにより、ファイルベースになった
HARBOR(イマジカの転送サービス)を利用して、ファイルを転送
そこからAWSに転送して、オンデマンドコンテンツ(AWS)へ
配信素材管理システム(Tradis)に情報を集約
HARBORは、50Mbpsで1時間23GBを転送可能
Tradisは、素材とメタデータを一元管理できるシステム
セキュリティ面でHARBORBOXとの接続にDirectConnectを使用
結果
移行が容易かつ、スピーディに構築することが可能になった
課題
全てが自動化されたわけではない。
外部ソリューションが使用してる為、プラッシュアップの余地あり。
株式会社フジテレビジョン
割愛