この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWSのビッグデータ関連サービスと言えばAmazon Redshift、Amazon EMR、Amazon Kinesisなどが思い浮かびますが、ビッグデータのストア先として欠かせないのがAmazon S3です。
本セッションでは、RedfinとTwitterの、ビッグデータ分析基盤でのS3活用事例が紹介されています。
イントロダクション
セッションは、AWSのPrincipal Solution ArchitectのIan Meyers氏による、S3についての紹介から始まります。
S3の紹介
- オブジェクトサイズ : 最大5TBまで格納できる
- 99.999999999%の耐久性、99.99%の可用性
- SPOFが無い
- サーバーサイドの暗号化をサポート
- アクセス頻度に応じてcost-effectiveなオプションを選択できる : Standard/Infrequent Access/Glacier
- イベント連携 : Lambda、SQS、SNS
S3のユースケース
ビッグデータプラットフォームでの、S3の典型的なユースケースについての紹介されていました。
- プライマリのデータストア
- 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活用事例の紹介です。
- Redfinはエージェントがユーザーの不動産売買をサポート、エージェントにはユーザーの満足度に応じてボーナスを支払う
- 毎月数百万のユーザーによる数十億のイベントが発生
- 数千のエージェント、80のマーケット
- エージェントが集めた不動産に関する情報、ユーザーの情報を分析
データ分析基盤の概要
- バッチプロセス
- 生データはS3に保存
- データはERMで処理し(処理結果はS3に保存)、RedshiftやDynamoDBに格納
- ERMのクラスターはEC2のスポットインスタンスを使用。データの処理が終わったらクラスターをシャットダウンしコストを削減
- バッチ処理は複数の独立したタスクで構成。タスク単位で再実行が可能
- 処理のチェックポイント毎にデータをS3に保存
-
リアルタイムプロセス
- ストリームデータの処理にはSQS、Kinesisを使用
ストレージサービスの使い方
- ERM : テンポラリーデータ
- SQL/Kinesis : イベントバス、ストリーミングデータ
- S3 : プライマリデータストア、データの永続化
- DynamoDB : データキャッシュ
- Redshift : DWH
-
すべてのデータはS3に保存
- ROWデータ、ステージングデータ、プロダクションデータ
-
データはS3から再取得可能、再処理可能
-
S3を採用する理由
- シンプルで使い易い
- スケーラブル
- 高い耐久性
- AWSサービスとの親和性
続いてTwitterのJoseph Unruh氏による、同社のTellApart部門でのS3の活用事例の紹介です。
TellApartは、ディスプレイ広告、パーソナライズした広告メッセージをリアルタイムで挿入するマーケティング技術を提供していた企業で、今年の4月にTwitterが買収しました。
- 秒間20万リクエスト/秒、毎日15〜20TBのデータをS3に保存
- ユーザーに有意義な広告を届けるためには？
- 100ms以内にユーザーを特定、購買履歴、プロファイルの情報、広告への入札額を確認
ラムダアーキテクチャ
- バッチレイヤ
- バックエンドでユーザーグラフ等を作成し、Read-OnlyのDBへデータを投入
- スピードレイヤー
- KafkaとSpark
- 最新の履歴データなどをSpeedDB(Redisベース)に格納
- これらをFrontendでマージ
- Redfinのようにバッチ処理はスポットインスタンスを利用。(Spot Fleetに移行中)
S3のユースケース
Hadoop、Sparkのデータストアの他、Apache Aurora用のDockerコンテナストレージとしてもS3を活用しているとのこと。
キャッシュレイヤー
- S3では速度的に要件を満たさない場合があるため、キャッシュレイヤーを用意
- ２週間前までのデータはHDFSに、直近のデータはTACHYONに保存
S3のパフォーマンス関連のTIPS
- ロード分散
- 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でのベストプラクティスと言えるかと思います。
14
