【レポート】AWS Transformation Day 2017 : Scaling Hollywood-compliant Premium Video Streaming in the Cloud #AWSTransformationDay

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ベルリンの半瀬です。 10/25(水)、26(木)にドイツのケルンで開催されたAWS Transformation Day 2017に参加してきました。かなり遅くなってしまいましたが、セッションのレポートをお届けしたいと思います。

はじめに

Bernhard Widmann氏による「Scaling Hollywood-compliant Premium Video Streaming in the Cloud」を拝聴しました

動画

  • 日時: 2017年10月26日(木) Day2
  • タイトル: Scaling Hollywood-compliant Premium Video Streaming in the Cloud
  • 登壇者: Bernhard Widmann - Media Architect, maxdome

スライド

http://aws-de-media.s3.amazonaws.com/images/TransformationDay/TDay_Slides/Maxdome_TDay.pdf

内容

本セッションは、100万ものユーザー(ドイツ及びオーストリア)に対して、1ペタバイト以上の動画を提供する https://www.maxdome.de/ maxdomeが、どのようにして巨大なトラフィック(ピーク時 150Gbps、50,000request/sec)をコントロールをして>いるかについての事例紹介です。

maxdomeについて

maxdomeは、ProSiebenSat.1 Media(プロジーベンザット1メディア、P7S1とも)のグループ企業です。サービスmaxdomeは50,000本以上の映画、TVプログ>ラムなど様々な動画を提供しており、ドイツのオンラインビデオ配信事業では最大手です。

Media Storageとしての達成指標

提供するメディアストレージとしてのKPIは以下のようなものです。

  • 10万もの時間あたり視聴
  • 20億のチャンク
  • 200万ものファイル
  • 12万ものムービーシリーズ
  • 総計1ペタバイトのvideo/audio

Peak Trafficの達成指標

クリアすべきピーク帯のtrafficについて。

  • オリジンに対する最大15Gbps, 5000の秒間リクエスト
  • エッジでは150Gbpsが要求される
  • 3時間の日次ピーク帯
  • 年間 200ペタバイトのvideo/audioファイルの提供  

チャレンジ

  • 200msec以内のレイテンシ(エンドユーザー)
  • 100種類のデバイスに対応
  • Cloud上でのMPAA保護規定の準拠
  • オンプレミスよりOPEX(Operating Expenditure)
  • ダウンタイムなしでの移行

構成

Financial Aspect

AWS に移行することで、従来のおよそ半分までコスト抑えることができた。 その中でも特に削減ができたのが、

  • DTO(Data Traffic Out)のコスト
  • コンピューティングコスト(AutoScalingの導入により、ピーク帯に合わせて実際に必要な分のみかかる)

Tecnical Challenge

  • S3のソフトリミット 800Requests/secをどうハンドリングするか
  • ピーク帯ではその何倍ものアクセスが来るため
  • Load test tool Locustを使用し、900ユーザーの同時アクセスパフォーマンスを計測した
  • 既存の構成では650RPS程度のスループットに対して25%程度のエラーが発生していたが、システム改修によりほぼ900RPSまで改善した
    • キースペースデザインの変更
    • AWSエンタプライズサポート(S3チーム)に以下の最適化を依頼
    • Manual Partitioning
    • Cache Tierの有効化

Content Delivery network - Cloudfront

CDNは当然ながら動画配信においてキーコンポーネントとなる

  • レイテンシをより低減する
  • オリジンの保護
  • DDoS対策
  • 最も大きなコスト要因となる
  • リージョナルエッジキャッシュがよりキャッシュ効率を向上させた
  • リージョナルキャッシュ開始後の改善結果(前年度比較

Media Analytics - Mastering Big Data

分析要件としては主に2つある 1. 配信業者として、メディアの使用状況をコンテンツオーナーに届ける義務がある 2. コンテンツ配信に適切な、ストレージクラスを調整する必要がある

分析のために、CDNログを主に利用する。技術的な要件は以下である

  • 500Milion(5億)行のログが日次でCDNで発生
  • パフォーマンスとコストに最適化されたサーバレスアーキテクチャであること
  • カスタム開発が不要であり、スタンダードなAWSコンポーネントのみを使用すること

初めはCFログをLambdaで直接バケットインポートしていたが、1日分のAthenaクエリ実行に数分かかり20%のデータロスが発生し ているようだった。現在のアプローチではインポート用のLambdaからKinnesisFirehorseを経由してバケットに格納し、さらに>そこからLambdaでAthenaテーブルをパーティショニングすること(時間単位で?)で実行クエリを数秒にまで短縮することがで>きた。またデータロスも解消できた。

Lessons Learned

  • ロードテストをあらかじめかつ継続的に実行すること
  • 職務分掌されたアカウントを用意すること
  • 可能な限り頻繁にクラウドフロントを使用するようにすること
  • ハイブリッドな構成は避け、なるべくAWSネイティブな構成とすること
  • 全てはCloudWatchで追うことができる(モニタリング)

さいごに

AWS Transformation Day Germanyのセッション紹介でした。 想定されるトラフィックの見積もりとシミュレーションを重ねておくことが大事。テストを繰り返すことが大事。テストをすぐ に行えるような準備が大事。そのためにもAWSネイティブな構成としておくことが大事。

などといったありがちなコメントで締めたいと思います。

それではまた。