(レポート)BDT322: RedfinとTwitterはいかにしてS3をつかってビッグデータプラットフォームを構築しているのか #reinvent

aws-reinvent2015

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

AWSのビッグデータ関連サービスと言えばAmazon Redshift、Amazon EMR、Amazon Kinesisなどが思い浮かびますが、ビッグデータのストア先として欠かせないのがAmazon S3です。

本セッションでは、RedfinTwitterの、ビッグデータ分析基盤でのS3活用事例が紹介されています。

イントロダクション

セッションは、AWSのPrincipal Solution ArchitectのIan Meyers氏による、S3についての紹介から始まります。

S3の紹介

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-1

  • オブジェクトサイズ : 最大5TBまで格納できる
  • 99.999999999%の耐久性、99.99%の可用性
  • SPOFが無い
  • サーバーサイドの暗号化をサポート
  • アクセス頻度に応じてcost-effectiveなオプションを選択できる : Standard/Infrequent Access/Glacier
  • イベント連携 : Lambda、SQS、SNS

S3のユースケース

ビッグデータプラットフォームでの、S3の典型的なユースケースについての紹介されていました。

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-2

  • プライマリのデータストア
    • DynamoDB、Redshift、Lambda、ERM、Datapipeline、Kinesis、Machine Learning等のサービスと連携
    • HDFSの代替(EMRFS) (S3でデータを永続化し、HDFSはジョブ実行時のテンポラリーストレージとして使う)
    • ERMのクラスターをシャットダウンできる
    • HDFSのスケーリングについて考慮が不要となる
    • データを複数のERMのクラスターでシェアできる
  • HadoopとHDFSのバックアップ
    • HBaseのIncremental Backup
  • データ中心のEvent Bus
    • EC2からS3をs3fs等を使ってマウントし、SFTPで受けたデータを直接S3へ保存
    • イベント連携でLambdaを起動し、データをRedshiftへ投入

RedfinでのS3の活用事例

Youg Huang氏による、RedfinでのS3活用事例の紹介です。

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-3

  • Redfinはエージェントがユーザーの不動産売買をサポート、エージェントにはユーザーの満足度に応じてボーナスを支払う
  • 毎月数百万のユーザーによる数十億のイベントが発生
  • 数千のエージェント、80のマーケット
  • エージェントが集めた不動産に関する情報、ユーザーの情報を分析

データ分析基盤の概要

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-4

  • バッチプロセス
    • 生データはS3に保存
    • データはERMで処理し(処理結果はS3に保存)、RedshiftやDynamoDBに格納
    • ERMのクラスターはEC2のスポットインスタンスを使用。データの処理が終わったらクラスターをシャットダウンしコストを削減
    • バッチ処理は複数の独立したタスクで構成。タスク単位で再実行が可能
    • 処理のチェックポイント毎にデータをS3に保存
  • リアルタイムプロセス
    • ストリームデータの処理にはSQS、Kinesisを使用

ストレージサービスの使い方

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-5

  • ERM : テンポラリーデータ
  • SQL/Kinesis : イベントバス、ストリーミングデータ
  • S3 : プライマリデータストア、データの永続化
  • DynamoDB : データキャッシュ
  • Redshift : DWH

  • すべてのデータはS3に保存

    • ROWデータ、ステージングデータ、プロダクションデータ
    • データはS3から再取得可能、再処理可能
  • S3を採用する理由
    • シンプルで使い易い
    • スケーラブル
    • 高い耐久性
    • AWSサービスとの親和性

Twitter

続いてTwitterのJoseph Unruh氏による、同社のTellApart部門でのS3の活用事例の紹介です。

TellApartは、ディスプレイ広告、パーソナライズした広告メッセージをリアルタイムで挿入するマーケティング技術を提供していた企業で、今年の4月にTwitterが買収しました。

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-6

  • 秒間20万リクエスト/秒、毎日15〜20TBのデータをS3に保存
  • ユーザーに有意義な広告を届けるためには?
  • 100ms以内にユーザーを特定、購買履歴、プロファイルの情報、広告への入札額を確認

ラムダアーキテクチャ

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-7

  • バッチレイヤ
    • バックエンドでユーザーグラフ等を作成し、Read-OnlyのDBへデータを投入
  • スピードレイヤー
    • KafkaとSpark
    • 最新の履歴データなどをSpeedDB(Redisベース)に格納
  • これらをFrontendでマージ
  • Redfinのようにバッチ処理はスポットインスタンスを利用。(Spot Fleetに移行中)

S3のユースケース

Hadoop、Sparkのデータストアの他、Apache Aurora用のDockerコンテナストレージとしてもS3を活用しているとのこと。

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-9

キャッシュレイヤー

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-10

  • S3では速度的に要件を満たさない場合があるため、キャッシュレイヤーを用意
  • 2週間前までのデータはHDFSに、直近のデータはTACHYONに保存

S3のパフォーマンス関連のTIPS

BDT322__How_Redfin__amp__Twitter_Leverage_Amazon_S3_For_Big_Data-11

  • ロード分散
    • EC2の帯域幅の制限を考慮する
    • r3.8xlarge × 1台より、r3.2xlarge × 4台の方がS3からのデータ転送が早い
    • ただし、台数が増えるとEC2間のデータ転送がボトルネックとなるため、限界はある
  • Reading/Writing
    • マルチパートアップロード/ダウンロードを使う
    • SPARKを使うときは、JetS3tではなく新しいs3aライブラリを使う(後者の方がより高パフォーマンスでエラーリカバリに優れている)
    • list処理を避ける
  • Map/Reduce
    • 投機的実行を無効化する
    • ファイルサイズをHDFSのブロックサイズと同じまたは若干小さめ(SparkとHadoopはブロックサイズに基づきデータを分散するため)
    • カラムベースのファイルフォーマットを使用する(Parquetなど)

まとめ

バッチ処理を「S3 + スポットインスタンス」の組み合わせで実行することでコストを削減している点がRedfin、Twitter共通のプラクティスでした。S3でビッグデータを扱う上でのTIPSもとても参考になりました。

極めて高い耐久性に加え、データのImport/Export、イベント連携など、他AWSサービスとの連携機能がサービスレベルで備わっているのがS3の特徴です。この特徴を活かし、ビッグデータの文脈に限らず、S3を中心にデータフローを設計するのがAWSでのベストプラクティスと言えるかと思います。