AWSにおけるムービーレイクの運用

BigData-JAWS 勉強会#16 登壇用資料として利用
オンデマンド 動画群の運用を考える上で、大まかな観点について説明

Transcript

1. 株式会社サーバーワークス AWSにおけるムービーレイクの運⽤ BigData-JAWS 勉強会#16 登壇⽤資料 2021年3⽉1⽇ アプリケーションサービス部 ⽥⻫ 省吾
2. 1.はじめに 2. 「受け取る」フェーズ 3. 「加⼯する」フェーズ 4. 「保存する」フェーズ 5. 「提供する」フェーズ 6. おわりに 今⽇の内容
3. ⾃⼰紹介 名 前 ⽥⻫ 省吾（たさい しょうご） 所 属 株式会社 サーバーワークス アプリケーションサービス部 得意なサービス ・Amazon Connect ・Amazon WorkSpaces ・AWS Client VPN ・Ops系AWSサービス全般 最近Client VPNのホワイトペーパーを執筆しました︕ https://www.serverworks.co.jp/resources/form/8564/ 仲良くなりたい サービス ・AWS Glue(というよりPySpark) 今年やりたいこと ・地⽅でテレワーク・⼆地域居住 3
4. 今回のプレゼンの主な題材となる案件について ▸⾃社製品を販売する加盟店のTVごし にPR動画を配信・再⽣する ▸ライセンスサーバー 、クライアント アプリはお客様開発 ▸オーダーはランニングコスト重視 4
5. オンデマンド動画基盤の運営上の観点 ▸配信したい動画の保存受け⼝を⽤意する ▸画質やファイルフォーマット等の品質を揃える ▸DRMによる暗号化を実施する ▸ 各⼯程の動画を適切に保存・アーカイブ・削除する ▸加⼯済み動画を配信する ▸配信結果を把握できるようにする 5 受けとる 1 加⼯する 2 溜める 3 配信する 4
6. オンデマンド動画基盤の運営上の観点 6 受け取る 加⼯する 溜める 配信する
7. 1. はじめに 2.「受け取る」フェーズ 3. 「加⼯する」フェーズ 4. 「保存する」フェーズ 5. 「提供する」フェーズ 6. おわりに 今⽇の内容
8. 通常ビックデータの受け⼝としてよく出てくるサービス 8
9. 通常ビックデータの受け⼝としてよく出てくるサービス 9
10. 動画管理の受け⼝となりうるサービス ▸通常のデータ受け⼝⽤サービスは ペイロード制限でだいたいアウト ▸エンコード⽤EC2に直接アップロード するような⽅法もなしではないが・・ ▸S3に直接アップロードが無難︖ ▸Kinesis Video Streamで収集した動 画もオンデマンド配信に利⽤可 10
11. S3を受け⼝とする際の留意点 ▸単にPutObjectするだけではパラメー タを付与できない ▸変換処理⽤のパラメータも連携する 上では以下のような⼯夫が必要 ▸プログラム処理の場合︓タギング ▸⼈⼒の場合︓with 指⽰ファイル 11 動画処理⽤パラメータの連携
12. 1. はじめに 2. 「受け取る」フェーズ 3.「加⼯する」フェーズ 4. 「保存する」フェーズ 5. 「提供する」フェーズ 6. おわりに 今⽇の内容
13. 動画の加⼯はMediaConvertにおまかせ ▸マネージドの動画変換サービス 1. 出⼒動画の分数に対する従量課⾦ 2. ごりごり使うワークロードではリザー ブド料⾦も提供 3. 多機能・多オプション 13 やはりマネージドサービスが⼀番
14. 動画の加⼯はMediaConvertにおまかせ ▸プログラムにシンプルに組み込める 1. 所定のconfigをもとに変換処理を指⽰ (CreateJob） 2. 変換処理の確認コマンド（GetJob）も しくはEventBridgeで終了を補⾜ 14 コーディングもお⼿軽（コーディングは）
16. 定義が⻑い! 200⾏~くらい
17. 【閑話休題】⼀般的なETL処理と動画処理の違い ▸動画はさまざまなデータフォーマッ トへの変換要望がある ▸同じくさまざまな品質要求がある ▸仮に変更処理に成功しても、品質が 万全とは限らない ▸ex.ノイズが気になる、セグメント調整 ▸いきなり公開せずに⼀度内部確認するよ うなフローがあるとベター 17
18. 多様な設定パターンに対応する⼯夫 ▸よくある定型パターンについては呼 び出し元でconfigを同梱しておく ▸こまかなパラメータ調整についても 対応できるようなつくりにしておく ▸どの動画に関してどの設定値で変換 したか記録を残しておくとよい 18
19. 条件に応じた動画の配信はMediaPackageにおまかせ 19 やはりマネージドサービスが⼀番（⼆度⽬） ▸マネージドの動画配信サービス 1. 処理対象の動画容量に対する従量課⾦ 2. 個々の動画再⽣環境に即した配信プロ トコル・DRM処理を実施するエンドポ イントを提供 3. CloudFront等CDN経由での配信の強 制・オリジンの保護が可能
20. ただし︕︕︕
21. マネージドサービスを使えない・使わないケースもある ▸料⾦最重要視の場合 ▸使いたい・使い慣れたミドルウェア がある ▸再⽣環境のパターンが少なく定まっ ている 21
22. どのコンピューティングサービスを使うか 22
23. どのコンピューティングサービスを使うか 23
24. どのコンピューティングサービスを使うか 24 AWS Batchがおすすめ Fargateも少なからぬ場合で可
25. 動画処理に⼤活躍のAWS Batch 25 ⼤容量ファイルを効率よくこなすならコレ︕ ▸⾼負荷処理をこなすジョブ・インス タンス群をコントロールできる 1. ⼤容量のストレージをもつECSタスク を必要なときに必要なだけ呼び出せる 2. 実⾏環境には⾃作Dockerイメージを利 ⽤可能 3. 万が⼀スポットインスタンスが途中終 了した場合のリトライ規定が可能
26. 次点以降のサービスの理由 ▸EC2︓起動の⼿間がネック。AMI代 もったいない ▸Lambda︓動画のエンコード・DRM 処理にはvCPUもストレージも貧弱 ▸Fargate︓昨春パワーアップして⼤抵 の動画はこなせるようになった ▸+ もうBatchからも呼べるように 26
27. 全体の動画処理フローはStep Functionsで管理 27 個々の動画の変換ワークフローの管理に適する ▸動画処理にかかわる各サービス・処 理のオーケストレーションが可能 1. EventBridgeを介して特定APIの実⾏を トリガーに⼀連のジョブフローを実⾏ 2. 各動画の処理履歴の可視化が可能 3. Lambdaをはじめ、複数のAWSサービ スとスムーズに連携が可能
28. 1. はじめに 2. 「受け取る」フェーズ 3. 「加⼯する」フェーズ 4.「保存する」フェーズ 5. 「提供する」フェーズ 6. おわりに 今⽇の内容
29. 動画ファイルの保存場所はS3以外考えられない ▸他動画サービスとのインテグレー ションの相性からも、料⾦⾯からも S3で保管するのが⾃然 ▸EBSやEFS、FSxで敢えて保存するメ リットはあまり思いつかない ▸なにか⾯⽩いユースケースがあれば教えてく ださい︕ 29 みなさんご存知、超安価なストレージサービス
30. 【閑話休題】ビックデータのアーカイブ上の留意点 ▸S3（標準）が0.025USD/GB、標準 Glacier ・Deep Archiveが 0.005USD/GB・ 0.002USD/GB(⽉) ▸⼀⽅ 標準Glacier ・Deep Archive に 移す上ではそれぞれ0.0571USD・ 0.065USD per 1000reqかかる ▸零細な容量のファイルが多数あるよ うな場合に適⽤すると⾼くつく 30 Glacier実は⾼くつく（場合がある）問題
31. 動画を⻑期アーカイブする場合 ▸ある程度具体的な試算を考えてみる ▸仮定 ▸総容量︓10TB（10GB動画1000本） ▸保存期間︓10年 31 動画の場合Gracierを使わない⼿はない
32. 動画を⻑期アーカイブする場合 ▸S3の標準ストレージ => 累計約300,000円(⼗分安いが） ▸Deep Archive => 保存料は累計約24,000円、スト レージタイプ移⾏代⾦ 約7円 ▸ただし、そもそも⻑期保存する動画 ファイルは限定すべき 32 動画の場合Gracierを使わない⼿はない
33. ライフサイクルポリシー管理になじまないファイルもある 33
34. ライフサイクルポリシー管理になじまないファイルもある 34 配信期間を 管理して削除 処理完了後 削除
35. 1. はじめに 2. 「受け取る」フェーズ 3. 「加⼯する」フェーズ 4. 「保存する」フェーズ 5.「提供する」フェーズ 6. おわりに 今⽇の内容
36. 配信についてはCloudFrontにお任せ 36 昔から動画配信で⼤活躍の鉄板サービス ▸おなじみのCDNサービス 1. Cacheでストレスフリーな動画配信 2. OAIやMediaPackage連携を利⽤したオ リジン保護の実施 3. 別途AWS WAFやLambda Edgeを利⽤ することで柔軟なアクセス制御も可能
37. CloudFrontのアクセスログ 分析 ▸Athena上テーブルの主要カラム ▸date︓リクエスト発⽣⽇（UTC） ▸time︓リクエスト終了時刻（UTC） ▸bytes︓送出容量 ▸request_ip︓クライアントIP ▸uri︓FQDNおよびクエリ⽂字列を含まな いパス部分 ▸その他トラシュ⽤カラム ▸ result_type ▸ x_edge_detailed_result_type ▸ response_result_type ▸ fle_status 37
38. ⽉次のアクセス数集計の例
40. dateとtimeを結合してJST化
41. サブクエリ結果をさらに 任意の集計単位でしぼり込み
42. あるuriに関するレコード数 = 特定⽉のある動画の再⽣数
43. あるuriに関するレコード数 = 特定⽉のある動画の再⽣数 動画ファイル名にID値等を 採⽤しておくとのちの整形で楽
44. 1. はじめに 2. 「受け取る」フェーズ 3. 「加⼯する」フェーズ 4. 「保存する」フェーズ 5. 「提供する」フェーズ 6.おわりに 今⽇の内容
45. 今回の発表のまとめ ▸S3にただ置くだけではなく、後続の処理⽤のパラメータ連携⽅法に留意 ▸Media Convert利⽤時に⼤切になるのはconfigの⽤意・カスタマイズ ▸Media XXXを使えない場合はAWS Batchを活⽤すべし ▸各処理はStep Functionsを使って連携・統合・可視化を図る ▸ ⻑期保存⽤動画については積極的にGlacierを活⽤する ▸ 消すべきタイミングにすぐ消せるように⼯夫する ▸CloudFrontを有効活⽤する ▸再⽣数レベルの情報ならCloudFrontのログからAthenaで集計可 45 受けとる 1 加⼯する 2 溜める 3 配信する 4