[レポート] CTD203: Amazon Prime Video – 驚異的な視聴体験の提供 #reinvent

先日開催されました AWS re:Invent 2018 より、11/28 (現地時間)に行われた下記セッションをレポートします。セッションの拝聴はできなかったのですが、公開された動画と資料をもとにお送りします。

なお同セッションは 11/27 に第1回が行われていますが、公開された動画はリピートセッションのものとのことです。

セッションタイトル

概要

セッション概要より抄訳:
Amazon Prime Video と Amazon (AWS) CloudFront のエンジニアが、どのようにして彼らが世界中の視聴者に映像を届けるために設計し最適化したか。ビデオパイプラインとアプリケーションの CDN への最適化、パフォーマンスや品質の測定、マルチ CDN の管理などについてのディスカッションをお届けします。

In this session, hear engineers from Amazon Prime Video and Amazon CloudFront discuss how they have architected and optimized their video delivery for scaled global audiences. Topics include optimizing the application and video pipeline for use with content delivery networks (CDN), optimizations in the CDN for efficient and performant video delivery, measuring quality, and effectively managing multi-CDN performance and policy. Learn how CloudFront delivers the performance that Prime Video demands, and hear best practices and lessons learned through scaling this fast-growing service.

Speaker

  • Nick Benson - Software Development Manager, Amazon Prime Video
  • Harrison Clement - Systems Development Engineer, Amazon Prime Video
  • Chaitanya Solapurkar - Software Development Engineer, Amazon CloudFront

資料

スライド

動画

内容

(※以下、掲載しているスクリーンショットはスライドから)

Amazon Prime Video

  • ミッション:裁量のビデオ視聴体験を、数百カ国・数百万のカスタマーへ届けること
    • 200ヶ国以上、22ヶ国語のオーディオトラック
    • 数千の異なるデバイス(スマフォ、ゲームコンソール etc.)
    • TBits/s のデータストリーム
    • Live配信とオンデマンドコンテンツ
    • とても柔軟なネットワークインフラ
  • トレードオフは重要
    • 信頼性(途中で止まったりしない)
    • 映像品質
    • 再生頭出し精度
    • ライブ配信のラグ
  • 継続的に改善を行う
    • 配布 -> 計測 -> 最適化 -> 配布 ...

スケールするトラフィック

  • 米国内において、全ダウンストリームの 7.74% が Prime Video
  • EU 件では 6.06%
  • イベントに対する予測・プランニング
    • 木曜夜のフットボールゲームなど
    • VODストリーム/日が 1.5 倍程に

  • AWSのリソースを保護(無駄に消費しない)
    • 素材のキャッシュ
    • ライブ配信トラフィックの中間層キャッシング
    • VODのロングテール視聴に対してオリジンを保護
    • サービス保護
    • キャッシュ可能なマニフェスト(プレイリスト)ファイル
    • Lambdaの利用
    • Lambda@Edgeによるサーバサイドの広告挿入
    • 動的なマニフェストファイルの統合・軽量化

CloudFront のトラフィック管理

  • トラフィックマネジメント
    • レイテンシベースのルーティング
    • 視聴者のレイテンシが一番小さくなるPOPへ誘導する
    • キャパシティマネジメント
    • 負荷予測(Prediction)
    • Flash crowd = 最初に現れるトラフィックの急増
    • アメフト中継やAmazon Primeオリジナルコンテンツなど
    • DDoSの検知と対処(緩和化)
  • POP内では
    • 負荷分散やスロットリング
    • HTTP/2

品揃えとスケール

  • 90%の視聴ストリームは、用意されたカタログの 12%のコンテンツ
  • 60%はわずか 2%のコンテンツに集中している
  • 所謂 long tail
  • Prime Video は非常に多くのコンテンツを持っている
    • 多言語
    • 地域別のエディション
    • パッケージフォーマット
    • デバイス互換性
    • ビットレート
    • さらに増え続けている
  • 課題: CDNは全てのコンテンツをキャッシュできない
  • スケールするためには: キャッシュの最適化
    • ポピュラーコンテンツに最適化したライブラリのシャーディング

CloudFrontのキャッシュ性能向上のために

  • TTL
    • 長寿命 vs 短寿命 vs 動的生成オブジェクト
    • ビデオコンテンツは年単位
    • マニフェストファイルは数秒
    • 動的生成オブジェクトはキャッシュしたくない(Zero TTL)
  • 変動するものは減らす
    • リクエストヘッダ
    • クッキー
    • クエリ文字列
  • キャッシュエラーでオリジンを保護
    • エラー時のTTLをカスタマイズ
    • オリジンにアクセスできない場合は配信を停止する
  • オリジンのタイムアウトを調整する
  • オリジンのFailover

機能とスケール

  • 複雑さの度合いが増加する
    • 手動〜プログラマブル〜自動化
  • ビジネスとテクノロジーのシーンは急速に変化する
    • サブスクリプション
    • グローバルな可用性
    • 木曜のアメフト中継
    • 広告機能
    • ライブ配信のスケール

  • Prime Video は様々なツールを使う
    • CloudFormation
    • CLI
    • Terraform
    • Amazon SNS
    • DynamoDB
    • Route 53
    • MediaTailor etc.

「視聴者のこだわり」とスケール

  • 主に顧客体験にフォーカス
  • インターネット上の障害の緩和
    • 手動で切り替えるのでは遅い
  • クライアントによるフェイルオーバの有効化
    • CDN切換
    • オリジンの切換
    • CDNのパフォーマンスを計測
  • 視聴環境を計測する
    • メトリクスは実際の視聴環境を反映するよう慎重に選ぶ
    • 再生・停止
    • ユーザの操作
    • ネットワーク転送量・ビットレート
    • ステータスコード
    • 配布時間
    • 再バッファレート
    • 最初のフレームが再生開始されるまでの時間
    • レイテンシ

  • CloudFront の裏側では
    • 負荷分散の向上
    • 良くアクセスされるオブジェクト
    • サーバ負荷
    • システムのチューニング
    • ディスクパフォーマンス
    • カーネルパラメータ
    • キャッシュポリシ

CloudFront メトリクスとレポート

  • CloudWatch メトリクス
    • Requests
    • Bytes Downloaded
    • Bytes Uploads
    • Total Error Rate
    • 4xx
    • 5xx
  • レポート
    • Usage
    • Requests
    • Byutes
    • Popular Objects
    • HTTP Status Codes
  • より深く把握するために、CloudFront ログをAthenaで解析する

まとめ

  • 予測と計画はトラフィックのスケーリングを助ける
  • コンテンツカタログの需要を把握する
  • 開発サイクルにAWSツールを合わせる
  • 視聴環境を向上させるために
    • CloudFrontのメトリクスとログを使用

所感

CDN というと「アクセスの多いコンテンツ」に対して強いという印象がありますが、Amazon Prime Videoの場合はロングテールコンテンツが多く、その状況にどう対処していくか、とても興味深いセッションでした。と同時に、「最終的にはログ調べて都度チューニングする」というところに落ち着いたことで、ここにも銀の弾丸がないことと、計測が大切と言うことを再認識されたと思います。