この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
DA事業本部の春田です。
本記事は、AWS re:Invent2019の ANT333: How Woot.com built a serverless data lake with AWS analytics のセッションレポートです。
The English version is here.
概要
Woot.com designed and developed a data lake as a replacement for their legacy data warehouse to deliver powerful analytics capabilities across multiple business areas. In this session, learn how it used Amazon EMR, Amazon Athena, AWS Glue, and Amazon QuickSight to build an automated process to ingest and centralize data from external and internal sources for immediate analysis.
Woot.comはレガシーなデータウェアハウスの代替としてデータレイクをデザイン・開発し、複数のビジネス領域にまたがって強力な分析基盤の構築に成功しました。このセッションでは、彼らがどうAmazon EMRやAmazon Athena、AWS Glue、Amazon QuickSightを使って、外部と内部のデータソースから即時分析ができるよう、データを抽出・集約するための自動化処理を構築したか解説します。
スピーカー
- Karthik Kumar Odapally
- Sr Solutions Architect, Amazon Web Services
- Zhaolu (Yolanda) Meng
- Woot.com
- Theo Carpenter
- Sr. Systems Manager, Woot.com
ECサイトのWoot.comはモダンなデータレイクの構築を非常に綺麗に成功させ、様々なベネフィットを獲得しました。本セッションでは、様々なタイプのデータストアをAWS上のデータレイクへ移行するポイントについて紹介します。
内容
Wootとは？
- Amazonの子会社であるが、Amazonのエコシステムからは独立
- 小さなエンジニアチームで、組織全てのサービスを管轄
- "One day, one deal"
課題点
- 自動化
- 数分でデータを投入し、標準化
- スケール
- 指数関数的な成長速度に合わせてスケーリングできるプラットフォーム
- レポーティング
- ユーザーが設定可能
- 実際のデータをどうレポーティングするか？
- 誤検知がないことをどう確保するか？
- BIツールがニア・リアルタイムでデータを簡単に操作できるよう、どう確保するか？
- パフォーマンス
- 現在のデータ
- ブラック・フライデーなどのピークイベントの期間では、その時点のデータにアクセスできる必要がある
- アクセシビリティ
- ツールとログオン
- 顧客の期待に応える性能
レガシーなソリューション
- 単一のDBインスタンス
- リソースを共有
- 複雑なカスタム・インジェスチョン
- ブラックフライデーの期間、レポートが生成できなかった
- バグ修正を難しくしていた3万行のコード
- 使いづらい
- 分割されたDBユーザー
- 学習曲線
- エクセル形式のデータを修正するのに3日かかる
要件
- プラットフォームに依存しない
- どんなデータ、どんなソースでもクラウド上で互換
- 回復性
- 役割で分離
- 単一のクエリで何時間もかけないプラットフォーム
- セルフサービス
- データの民主化
- アクセス管理やデータベースチューニングよりも、ビジネスの課題にエンジニアを注力させる
全体像
- レゴブロックのようなアーキテクチャ
- データセンター
- レガシーのSQL Server
- Microsoft Dynamics NAV services
- Wootの本番環境VPC
- AWSマネージド・サービスの活用
- データレイク
- ランディングゾーンとしてのS3
- 生データと加工データ
- ETL処理
- GlueでS3からデータをロード
- ビジネスロジックや"秘伝のタレ"を追加
- データウェアハウス
- レポーティング
- Amazon Redshiftへロード
- サードパーティからアクセス
- エンジニア用にAthena
- 即時接続するQuickSite
既存データの移行
- データレイクとしてS3を選択
- AWS Data Migration Serviceで既存データをS3へセットアップ&ストリーミング
- 異なるアカウントのバケット間でデータの移動
- コスト削減のためにファイルを圧縮して移動
- Glue用に列名は含めている
データ・パイプラインの構築
- 特定の技術に依存させない
- スケーラビリティの確保
- .NETのAWS SDKとKinesis Firehoseを活用
- ダイレクト・プット・インジェスチョン
- S3へ直接ポインティング
- S3は可用性、スケーラビリティ、耐久性要件を満たしていた
- アカウントは分離
- ETLを実行するために、DynamoDB StreamでLambdaを発火
統合
- S3内のデータを操作
- AWS GlueがETLスケジュールを管理
- Glueのクローラーでメタデータを収集
- クローラーが新しいカラムやスキーマを検知
- FirehoseからくるJSONデータをParquetに変換
Wootのデータレイク・ソリューション
- データ・インジェスチョン → Amazon Kinesis Data Firehose
- データストレージ → Amazon S3
- データ処理 → AWS Lambda, AWS Glue
- データ移行 → AWS Database Migration Service (AWS DMS), AWS Glue
- オーケストラレーション・メタデータ管理 → AWS Glue
- クエリ・データ可視化 → Amazon Athena, Amazon QuickSight
- ユーザー認証管理 → AWS Directory Service
GODSアーキテクチャ
- GODS (Google's of Data Services; Good Old Data Services)
- どんなソースからでもデータをクエリできる
- 将来の予測・評価
- 売上はどのくらいの見込みか？
- オブジェクトはどのくらい新しいのか？
- 主力ベンダーか？小規模なベンダーか？
ジョブ・オーケストラレーション
- 多種のデータソース、データ処理、ETL
- 依存関係のタグ付きで、全てのジョブステータスをDynamoDBに保存
- テーブルが更新されるたびに、ジョブステータスも追って更新するようLambdaを発火
次のステップ
- AWS Lake Formationを採用
- 複数の環境で一貫性を保持
- 設定をシンプルに
- トランザクションデータ
- 少しずつデータをロード
- ETLとビューをシンプルに
- 購買の評価
- モデル化
- 購入履歴をトラッキングするシステム
学んだこと
- 集計
- クリックストリームデータなど、生データを前もって集計しておく
- 生データを保管しておく
- バージョニング
- 問題が発生したときに再集計
- 古いデータはGlacierに移してコスト削減
- サービス制限
- ファイルの数やサイズと、クエリのスピード間のバランス
- データの質
アーキテクチャの欠点
- 可視性が乏しい、Athenaのクエリが失敗した時、即座に知らせてくれない
- QuickSiteにデフォルトのAdminロールがない
- オートセーブがデフォルトになっている
- リソース制限のせいで、Glueが同じワーカープロセスでリトライするので、再び失敗する
- Glueが誤ったフォーマットの日付型を読み込まない
良かった点
- 魔法のような機能
- パフォーマンス
- AWS統合
- 使いやすさ
- フレキシブル
数値で見るポイント
- データ量が12TBから60TBに増加
- 80%が新しいデータ
- 週あたり40時間の削減
- ビジネスレポートの自動化
- 90%の運用コストを削減
- ライセンスコストやクラスターコストを削減
- 1アカウントから8アカウントへ増加し、データを共有
- 週あたり6億行のデータを集計
- Wootのサービス自体に影響はなし（0 screaming Woot monkeys harmed）
18
