Disney+のリアルタイム顧客体験を支える統合ストリーミングプラットフォーム #ANT309 #reinvent

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

あけましておめでとうございます!DA部の春田です。

本記事は、AWS re:Invent 2020のセッション動画、「ANT309: How Disney+ uses fast data ubiquity to improve the customer experience」のレポート記事です。

English version is here.

Disney+のデータ分析基盤の一部、Unified Streaming Platformのテーマや活用方法を紹介しているセッションです。

概要

Disney+は、タイトルレコメンデーションのリアルタイム表示や、マイクロサービス間でイベントの送信、運用分析のためのログの伝達など、Amazon Kinesisを使用してリアルタイムアクションを実現し、顧客体験の向上に努めています。このセッションではDisney+が、統合ストリーミング・プラットフォーム上にリアルタイム・データドリブン機能をどのように構築したかについて紹介します。このプラットフォームではサーバレス・コードレスで、Amazon Kinesis Data Streamsで毎時10億ものイベントを取り込み、Amazon Kinesis Data Analytics for Apache Flinkで変換処理と分析、Amazon Kinesis Data Firehoseで他のシステムへデータ配信を行っています。これらのサービスによって、どのように高品質で信頼性の高いDisney+の視聴体験が数千万のユーザーに届けられているのかを覗いてみてください。

スピーカー

  • Martin Zapletal
    • Director, Software Engineering - Disney+

How Disney+ uses fast data ubiquity to improve the customer experience - AWS re:Invent 2020

内容

  • ストリーミング・データとDisney+
  • 過去 - サイロ化
  • 進化 – サイロ化されたデータのストリーミング
  • 現在 – データ・ドリブン
  • ストリーミング・データ・プラットフォーム
  • 3つのゴール: Ubiquity、Platform、Culture
  • 結論

ストリーミング・データとDisney+

  • Disney+がストリーミングデータを使用する目的
    • リアルタイムで自動更新されるパーソナライズ・レコメンデーション
    • APIの監視
    • 機外学習モデルを適用し、潜在的な不正や悪用を検知する
    • 動画の進捗をトラッキング
  • ストリーミングデータのユースケース
    • 数千万のユーザー
    • 数百のAmazon Kinesis Data Streams
    • 数千のシャード
    • 複数リージョン
    • 数十億のイベント
    • 数テラのデータ

過去 - サイロ化

  • Disney+は常に最先端の技術を導入し、ソリューションのイノベート、改善を行っている
  • サイロ化していた時期
    • 複数のデータベース、データウェアハウスを伴うマイクロサービス
    • バッチ処理は可能だが、インサイトを得るのに時間がかかる&限界がある
    • サイロ化によって、データから得られる最大限のパワーにアクセスできない

進化 – サイロ化されたデータのストリーミング

  • ストリーミング、イベントドリブン、非同期
  • カスタム可能で、独立したインテグレーションとデータウェアハウス
  • イベントドリブン → ドメインの分離、デプロイのスケーラビリティ、再現性、バックプレッシャー
  • データベースとデータソリューション間でデータの受け渡し

  • どのチームも、それぞれ独自のデータフォーマットやスキーマ管理、データの質が求められる
    • → サイロ化は維持した
  • まだできていないこと
    • 組織全体へスケーリング
    • データの最大活用
  • → 組織全体へスケールさせる方法を模索する必要が生じる

現在 – データ・ドリブン

  • 高速なデータの民主化
    • データやチーム間の境界やサイロをどう破るか?
    • 誰もが意思決定、アクション、実験ができるようにする
  • リアルタイムデータ、インサイト、機械学習
  • 実験
  • 洞察
  • 文化

誰もが必要な時にいつでも利用感応な、データとインサイト

ストリーミング・データ・プラットフォーム

  • 技術とユースケースのギャップを埋める
  • データドリブンの恩恵を得られる簡単でアクセスしやすいプラットフォーム
  • ストリーミング機能はデータドリブンエコシステム全体の一部にすぎない

  • サービス、デバイス、プロデューサーの役割
    • 標準化されたこのプラットフォームでそれぞれのデータセットを公開する
    • 他のチームのデータセットを参照するコンシューマーになる
    • 既存データから新しいデータを生成したり、よくあるソリューションに利用する
  • 真ん中の三角形
    • ストリーミング・プラットフォームや分析、機械学習、実験検証において橋渡しとなるインテグレーション

  • ストリーミングデータプラットフォーム
    • バックボーン: Amazon Kinesis Data Streams
    • AWSサービスやサードパーティソフト上で稼働する抽象化層
    • 技術とユースケースのギャップを埋める
  • Kinesis
    • 信頼性が高く、高機能で、コスト効率の良いイベントログが必須
    • 他の選択肢: Kafka、Pulsarなど
    • Amazon Kinesis Data Streams
      • 複製、パーティション、順序、分散ログ
      • マネージド、3AZにレプリケーション
      • 他のAWSサービスとのインテグレーション
      • ニアリアルタイム
      • スケーラビリティ、柔軟性

3つのゴール: Ubiquity、Platform、Culture

Ubiquity

  • ニアリアルタイムデータをユニバーサルに利用可能
  • データの管理とアクセスのための最適なフレームワーク

  • デバイス
    • ECS: デバイスから来るデータを処理
    • データをKinesis Data Streamsへ公開
  • サービス
    • リクエストを受けとり、ビジネスロジックを適応する
    • ダウンストリームでログを生成
  • 2つのストリームをマージ・結合
    • バリデーションやフィルタリングでデータに付加価値をつける
    • 加工データをコンシューマーに流す
  • 2つのダウンストリーム
    • 過去データのバリデーション
    • 失敗時データのバリデーション
    • 両方ともS3へ出力される
  • 2つのリアルタイムユースケース
    • ニアリアルタイムの運用分析とユースケース
      • Sparkを用いた集計
      • 集計データをKinesis Data FirehoseでAmazon Elasticsearchへ保存する
    • 不正検知
      • Kinesis Data Analytics for Apache Flink
      • 基本的な集計や機械学習モデルの適用
      • Kinesis Data Streamのコンシューマーがデータを活用
  • データ管理の自動化
    • 組織横断でデータを利用可能に
    • どこから来たデータでも、スキーマ・質・ガバナンスを管理する
    • APIドリブンのサービスとは異なり、プロデューサーはコンシューマーが誰で、どうデータを利用しているか知らない
    • 宣言的な方法で
      • スキーマやプロパティを定義
      • エコシステム全体で強制
  • → Schema registoryの誕生

  • Schema Registry
    • スキーマやプロパティを中央集権的なViewを提供
    • エコシステム全体で監視を強制
    • できるだけアップストリームでバリデーションを適用
    • できるだけ開発ライフサイクルを高速化

Platform

  • ツールやベストプラクティス
    • ストリーミングソリューションや宣言的なパイプライン・デプロイを構築
    • 共通の課題にフォーカスしたコントロールプレーン
  • チームは常にそれぞれがソリューションをカスタママイズできる能力を持っておきたい
  • → パターン化し、大きなパイプラインとして構成

  • 高信頼性のドメイン・イベント
    • Viewが常にSource of Truthとなるように、データの信頼性を確保
    • 問題点 → トランザクションの担保や不可分性、独立性を失う
      • ダウンストリームのコンシューマーが受け取ったデータが不順だったり、イベントを受け取りそびれたりする
    • DynamoDB Stream: データベースや変換処理のログをコミットしておく

  • バリデーション、ルーティング、フィルタリング
    • ストリームは抽象化されている
    • コンシューマーはストリームをサブスクライブし、データを取得するだけ

  • 結合と加工
    • 2つのKinesis Data StreamsをECSで結合する

  • 抽出
    • KinesisからS3へデータを同期
    • Schema Registoryの情報を使用

  • データプラットフォームではDelta形式を採用
  • ストリーミングアプリの成熟さは、全てがAPIアプリと同じレベルに到達しているわけではない
  • ストリーミングアプリの要件
    • アーキテクチャパターン
    • テスト自動化
    • パフォーマンステストと管理
    • 柔軟性とオートスケーリング
    • デプロイ
    • 可観測性、アラート
    • 信頼性、回復性
    • 運用のシンプルさ
    • マルチリージョンのレプリケーション、フェイルオーバー
    • データの繋がり、関係性
    • 自己修復
    • 分散型の追跡
    • コスト効率性
    • 情報の見つけやすさ
    • トラフィックのルーティング
    • 担保
    • サービスプラットフォームとしてのストリーミング
    • → 本番環境への準備ができているか確証を得ておく

  • 設定可能なトレードオフ
    • グラフ: デプロイ中のKinesis Data Analytics for Apache FlinkアプリのCPUまたはメモリの使用量
    • 途中でわずかにギャップが発生 → その期間はメトリクスを出力できていない
    • このギャップを許容できるユースケースもあれば、ニアリアルタイム処理が要求される許容できないユースケースもある
  • レイテンシの管理
    • 処理が少し長くなると、他の処理に影響を及ぼす可能性
  • デプロイ・パターン
    • Blue-greenのようなデプロイ方式を採用

  • ストリームの柔軟性
    • Kinesis Data Streamsがトラフィックに合わせてスケールアップ・ダウンできるように
  • アプリケーションの柔軟性
    • 特性を最大限に活用できるように、シャードの数を変更
  • 柔軟性のトレードオフ
    • スケーリングによってシャードと割り当ての再バランシングが発生する

  • グラフ: 2つのリージョンのストリームのスループット
    • 一点において、片方のトラフィックがゼロに落ち、もう片方がその分だけ拾ってしまっている
    • 徐々に安定し、通常に戻る
    • 原因は、予定されていたカオステスト
  • 障害のシナリオ
    • 信頼性かDelivery Semanticsの担保
    • ユースケースに合わせて適切に選択し、端から端まで持続させる

Culture

  • 会社のカルチャーとして、データ中心の考察
  • 焦点
    • ドキュメント化・ベストプラクティス
    • トレーニングやチーム内でのコラボレーション
    • ツール化や使いやすさの追求
    • データ統合

結論

  • データドリブンの組織とデータの民主化
  • Ubiquitous data
  • ストリーミング・データ・プラットフォーム
  • 文化とツール
  • Amazon Kinesis上に構築

AWS re:Invent 2020絶賛開催中!

ぜひ本編のセッション動画もご覧ください!サインアップがまだの方は以下のリンクからどうぞ。

AWS re:Invent | Amazon Web Services