[レポート] Amazon Prime Videoはどのように大量トラフィック(全USの8%!)を処理しているのか #reinvent #ANT348

re:Invent 2019で行われたセッション「How Prime Video processes 8 percent of all US internet traffic on AWS」のレポートです。
2019.12.03

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

AWSを愛する皆さま、こんにちは。
コンサルティング部の西野(@xiye_gen)です。

目次

セッション概要

タイトル

How Prime Video processes 8 percent of all US internet traffic on AWS

概要

Amazon Prime Video is one of the largest streaming services in the world, serving over 8 percent of all internet traffic in the US on any day. With millions of devices in over 200 countries around the world, collecting and analyzing telemetry data in real time is a major scaling challenge. In this session, learn how the team used AWS technologies such as Amazon Kinesis, AWS Lambda, and Amazon Simple Storage Service (Amazon S3) to build a next-generation telemetry platform that handles millions of transactions per second (TPS) and hundreds of petabytes of data.

動画

※公開後に本ブログに追記します。

レポート

今日では200を超える国々で提供されるようになったAmazon Prime Videoのトラフィック量は、なんとアメリカにおける一日の総トラフィック量の8%をしめているそうです。Amazon Prime Videoはビジネスモデルの変革にあわせて視聴データ収集プラットフォームのアーキテクチャを変更することに成功しました。

本セッションではKinesis/Lambda/S3などを用いて大量トランザクションおよび数百ペタバイト級のデータを処理できるようになったAmazon Prime Videoの変革の道のりについて説明されています。

ビデオ・オン・デマンドが直面する問題

  • 大量のトラフィック
  • たくさんの種類の大量のデバイス
  • 端末に応じたカスタムエンコーディング
  • 数多くのタイトル

ライブストリーミングが直面する問題

  • Dependency on providers
  • Scaling limitations
  • 予測できないトラフィックの増加
  • リアルタイムの分析

Stage1: Platform overview

  • オリジナルの構成
    • Customer devices -> APIGW -> Kinesis Data Streams -> Lambda -> Kinesis Data Firehose -> S3 -> Glue -> Athena <- BI Users
  • 修正後の構成
    • Customer devices -> Route53 -> ELB -> EC2 -> Kinesis Data Streams -> Amazon EC2 -> Amazon Kinesis Data Streams -> Amazon EC2 -> S3 -> EMR -> Athena <- BI Users
  • 達成できたこと
    • 10億イベントの処理
    • リアルタイムな可視性
    • 2分以内にデータの処理とS3への保存を完了
    • ピーク時100万TPSの処理
  • 残った課題
    • ライブイベントのトラフィックにスコープが限定されていること
    • 2つのプラットフォームの維持
    • 非常に遅いクエリ

Stage2: Evolution

  • Stage2のArchitecture

  • 達成できたこと

    • リアルタイム分析ツールで2秒以内にデータへアクセス
    • 大量(hundreds of billions)のイベントを一日で処理
    • ペタバイト級のデータを週ごとに手に入れる
  • 残った課題
    • データソースの遅延
    • Frugality vs. availability
    • データレイクの構築

Stage3: Sharing is caring

  • Stage3のアーキテクチャ

Next steps

  • コンテナの戦略
  • データレイクの統合化戦略
  • 機械学習
  • 自動化されたダッシュボード
  • 時系列データ

重要なこと(Key takeaways)

  • ベアメタル vs. マネージドサービスの比較を徹底することでプラットフォームの再評価にも役立つ。
  • 全てをモニターしテストせよ!それこそが実際のワークロードを最適化する唯一の方法である。
  • サービスの同期的な呼び出しではなくKinesis Data StreamsやSQS等のキューイングメカニズムを利用することで、システムの耐久性を高めデータロストの可能性を低減できる。
  • 解決できない問題はない。アーキテクチャの変更を恐れなければ、きっと進化は訪れる。

終わりに

このブログがほんの少しでも世界を良くできれば嬉しいです。
コンサルティング部の西野(@xiye_gen)がお送りしました。