この記事は公開されてから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ネイティブな構成としておくことが大事。
などといったありがちなコメントで締めたいと思います。
それではまた。