AWS ETL祭り - AWS Glue活用事例@primeNumber

データ基盤「systemN」の本番環境で100億レコード／月のETLをGlueで実装した話

Transcript

1. 2018年2月15日 AWS Glue活用事例 データ基盤「systemN」の本番環境で、 100億レコード/月のETLをGlueで実装した話
2. 自己紹介 1 CONFIDENTIAL • 小林寛和 ◦ @hiro-koba (Github) ◦ @hiro_koba_jp (Twitter / Qiita) • 株式会社primeNumber ◦ 執行役員 エンジニア • 好きなAWSサービス ◦ Elastic Beanstalk / AWS Lambda ◦ Redshift / AWS Glue © 2018 primeNumber Inc.
3. • primeNumber ◦ 中目黒のエンジニアリング・カンパニー • 事業内容 ◦ データエンジニアリングPaaS「systemN」 ◦ マーケティング・コンサルテーション 自社紹介 2 CONFIDENTIAL © 2018 primeNumber Inc.
4. データエンジニアリングPaaS「systemN」 3 CONFIDENTIAL © 2018 primeNumber Inc.
5. 導入事例: 総合マーケティング企業のDMP 4 © 2018 primeNumber Inc. CONFIDENTIAL • 用途 ◦ Webブラウザ・スマホアプリ上の行動ログ収集 ◦ 生ログを使用した分析 ◦ セグメンテーション・広告利用 • 規模感 ◦ 収集ログ量: 100億レコード／月超 ◦ ETLジョブ実行回数: 250回／日 ◦ Redshiftノード数: 20 nodes (dc2.large)
6. 5 CONFIDENTIAL AWS Glue導入事例 © 2018 primeNumber Inc.
7. 1. ログをKinesis Firehose経由でS3に蓄積 2. 1時間に1回バッチETL（クレンジング・変換） 3. prestoでETL後のログを可視化 Glue導入前のデータ基盤@2017年8月 6 CONFIDENTIAL © 2018 primeNumber Inc.
8. • 自前でEC2上にHadoop環境を構築 ◦ ETLサービス→Hive + Spark ◦ DWH→Presto • Hadoop専属エンジニア Glue導入前のETL基盤@2017年8月 7 CONFIDENTIAL © 2018 primeNumber Inc.
9. • ログ量の増加に伴い、様々な課題が ETL基盤@2017年8月 8 CONFIDENTIAL 応答速度求められると辛い スケールさせるのが手間 最小構成で結構高い インスタンス必要？ 再利用しにくい Hadoop専属エンジニア 以外触れない 重いクエリ走ると ETLに影響が・・・ © 2018 primeNumber Inc.
10. 課題1. コスト改善 9 • 人的コスト ◦ Hadoop専属エンジニアが必要 ◦ 運用上のボトルネック • 料金 ◦ 最小構成: 20万円／月 ◦ 仮に現在と同じレコード処理した場合 ▪ 100億レコード／月を処理するにはEC2 60台構成 ▪ 月間数百万円、全然ペイしない・・・ CONFIDENTIAL © 2018 primeNumber Inc.
11. • スケールアウトを容易に行えるように ◦ ノードの追加作業が複雑で、ダウンタイムも発生 ◦ 突発的なスパイク来たら死亡 • データ基盤としてのスケーラビリティ ◦ バッチだけでなくリアルタイム集計要件が出てきた ◦ Spark Streaming立てるとなると別クラスタ必要… 課題2. スケーラビリティを上げたい 10 CONFIDENTIAL © 2018 primeNumber Inc.
12. 課題3. ETL・DWHの可用性を上げたい 11 • DWH側が高負荷になるとETLが止まる ◦ prestoで重いクエリが実行されるとクラスタ毎落ちる ◦ 逆もまた然り • DWHがボトルネックに ◦ ETL後のログは別システムなどで利活用したい ◦ prestoを経由する必要があり、ボトルネック ◦ HDFSだと取り回しにくい CONFIDENTIAL © 2018 primeNumber Inc.
13. 12 CONFIDENTIAL 2017年9月1日、リプレイスPJT始動 0ベースで最適なアーキテクチャを模索 © 2018 primeNumber Inc.
14. Lambda Architecture 13 CONFIDENTIAL © 2018 primeNumber Inc. 引用: http://lambda-architecture.net/
15. Batch Layer & Serving Layer for systemN 1. 生ログを汎用的なバッチビューに変換 ◦ ダッシュボードからのクエリなど 2. ビジネス活用のためのバッチビュー構築 ◦ 1の汎用ログバッチビューから生成 ◦ 広告配信用のユーザー単位のサマリービューなど 14 CONFIDENTIAL © 2018 primeNumber Inc.
16. • リアルタイムなデータ集計に利用 ◦ Batch Layerで処理が間に合わない箇所で利用 ◦ 例: ドメインごとのPV/UU数を3秒以内に集計→可視化 サービスで表示 Speed Layer for systemN 15 CONFIDENTIAL © 2018 primeNumber Inc.
17. Lambda Architecture on AWS 16 CONFIDENTIAL © 2018 primeNumber Inc.
18. 17 CONFIDENTIAL 2017年9月中旬、実装開始 © 2018 primeNumber Inc.
19. • 解決したい課題 ◦ 料金・人的コスト最小化 ◦ スケーラビリティの確保 • 解決方法 ◦ マネージド・サービスAWS Glueの採用 ▪ インフラ面の運用コストほぼ0 ▪ 学習コストはコードを書くことのみ ▪ 料金は1/4以下に • 最小構成は月間20万円→5万円に ◦ スケーラビリティもLambdaとの統合で解決 Batch Layer実装 18 CONFIDENTIAL © 2018 primeNumber Inc.
20. Batch Layer - スケーラビリティを上げる工夫 19 CONFIDENTIAL © 2018 primeNumber Inc. • LambdaでGlueのDPUを自動設定 • 突発的なスパイクが来ても一定時間内に処理が終わるように ① 処理対象のログサイズ取得 ② 1時間以内に処理が終わる DPUの算出 ③ 算出したDPUを設定してJob Run
21. • 解決したい課題 ◦ DWH側の障害・メンテの影響がETLに波及しない ◦ DWHの処理性能がボトルネックにならない • 解決方法 ◦ ETLの出力先をS3に統一 ▪ DWH側の影響はETLに波及しない ◦ RedshiftとRedshift Spectrumの併用 ▪ 性能面のボトルネックは大きく改善 Serving Layer実装 20 CONFIDENTIAL © 2018 primeNumber Inc.
22. Serving Layer - ETLとDWHの分離 21 CONFIDENTIAL © 2018 primeNumber Inc. • ETLとDWHを分離するメリット ◦ 外的要因による障害が減る ▪ DWHの障害・メンテの度に止める必要なくなった ▪ 出力先をS3にしたことで、S3が落ちない限りETLは外的要 因で落ちない ◦ コストメリット ▪ 負荷が少ないロードのために、高価なDPUを使わない
23. Serving Layer - ETLとDWHの分離 22 CONFIDENTIAL © 2018 primeNumber Inc. • S3→RedshiftへのロードにはRinを採用 ◦ RinはS3→Redshiftのロードを行うためのOSS • ただしジョブ再実行時の冪等性に注意しないと重複発生 ◦ 現状手動でS3オブジェクト削除・DELETE文発行してる ① ETL後のログがS3に置かれたら SQSに通知 ② SQSをポーリングし、メッセージがあ ればRedshiftにCOPY ③ COPYが完了したらメッセージ削除
24. Serving Layer - 2つのクエリ実行方法 23 CONFIDENTIAL © 2018 primeNumber Inc. • 応答速度に応じてRedshift or Redshift Spectrumを選択 • どちらもRedshiftのI/Fでアクセスできる点がポイント ある程度時間がかかっても良いアクセス 応答速度が求められる場合は、 Redshiftにデータをロードしておく
25. Serving Layer - Glue Data Catalog 24 CONFIDENTIAL © 2018 primeNumber Inc. • ETL後のデータはGlueのData Catalogに登録して再利用性向上 ◦ Glue Data CatalogはCrawlerから作成できるメタデータ ◦ Redshift Spectrum、Athena、EMRからテーブルとして扱える ◦ AWS GlueのCrawlerを実行すればすぐ作れる • データのアーカイブ用途でも利用可能 ◦ 過去データ等、利用頻度は少ないが削除するかは悩ましい場合 ◦ S3に退避してData Catalog化しておけば解決 ① Glue CrawlerでS3上のログを クローリングし、Data Catalog作成 ② Redshift上でテーブルとして扱えるように
26. • ETL後のデータの内、一部のフィールドだけRedshiftに取り込 みたい • Redshift Spectrumからは全フィールドが見たい • AVRO＋COPYコマンドで解決 一部の列だけRedshiftにLoad 25 CONFIDENTIAL © 2018 primeNumber Inc. AVRO形式で出力 テーブル定義に存在するフィー ルドだけ取り込まれる Spectrumからは 全フィールドが見える Redshift上には 必要列だけロードし、 容量圧縮
27. 2017年9月末リリース 26 CONFIDENTIAL © 2018 primeNumber Inc. • 2017年9月1日、リプレイスPJT始動 • 2017年9月前半、アーキテクチャ設計 • 2017年9月後半、実装 • 2017年9月末日、本番リリース・完全切替
28. • ETL後のデータの再利用性もっと上げたい ◦ ETLのバージョン違いでデータ形式などもバラバラ ◦ 全期間のデータが同じスキーマで揃っていると再利用性が 更に高くなる • Spectrumのパフォーマンス上げたい ◦ Parquet形式にしたい（RedshiftのCOPY非対応） ◦ S3のパーティションも最適化したい ▪ Ex. s3://BUCKET/site_id=123/year=2018/… • ETL後のデータに対するETLを作成中 今後の課題1. データマート化 27 CONFIDENTIAL © 2018 primeNumber Inc.
29. • スモールスタートと実装スピードはGlueの得意とするところだ が、もう少しコスト抑えたい • コードで出来る最適化 ◦ RDDを極力使わないなどPySparkのチューニング ◦ Scala化の検証 • Glue以外の選択肢も ◦ ログ量が増えたらEMRの方が安かったりするかも？ ◦ 便利なDynamicFrameやEC2運用が発生するデメリットを 許容できるか、検証中 今後の課題2. Jobの高速化 28 CONFIDENTIAL © 2018 primeNumber Inc.
30. 29 CONFIDENTIAL AWS Glueの開発Tips © 2018 primeNumber Inc.
31. • データアクセス層とETL処理層に分けています プログラミングモデル 30 CONFIDENTIAL © 2018 primeNumber Inc. 入力はDynamicFrameで のロードが便利 ETL処理層のI/FはDataFrame 任意の列でディレクトリを切るなど は、DynamicFrame使えない
32. • ETL処理層はローカル開発 ◦ 少量データからDataFrameを作り、それをETLする ◦ Jupyter Notebookから実行 • データアクセス層の開発やE2Eで動かしたい時はDevEndpoint ◦ DynamicFrameでデータロードする箇所とか ◦ DevEndpointハマりどころ ▪ SparkContextを再生成しないとtoDF()が動かない ▪ spark.stop() glueContext = GlueContext(SparkContext.getOrCreate()) 開発環境 31 CONFIDENTIAL © 2018 primeNumber Inc.
33. • Glue Job Script ◦ データアクセス層の処理とロギングがメイン ◦ ETL処理はライブラリの呼び出す • Job Library ◦ Githubのprivateリポジトリからpip installし、Zipで固めて S3に配置 ◦ このバージョンが変わるとETLの出力も変わるため、バー ジョンごとにS3のディレクトリを変えている • External File ◦ 設定ファイルや変換に必要なインメモリDB等 • Glue Job ◦ 上記のScript、Lib、Fileの参照を持たせるだけ コンポーネントとリリース 32 CONFIDENTIAL © 2018 primeNumber Inc.
34. • Jobの実行結果 ◦ CloudWatch Eventを使用し、基本全てSNS通知 ◦ SNSはIFTTTに通知し、失敗時のみ通知するよう分岐 ◦ ただしJobのステータスがSUCCEEDEDなのにエラー終了 しているのを見たことがあるので、ちゃんとやるなら CloudWatch Logsのログでアラート設定すべきかも • Job実行時間 ◦ うまい方法見つけられてない ◦ 毎時GlueのAPI叩いてRunningのジョブの実行時間取る とか・・・？ ◦ 現状シビアに監視する必要が無いのでやってない 監視・障害検知 33 CONFIDENTIAL © 2018 primeNumber Inc.
35. • 念のためE2Eのカウントチェックやってる ◦ ETL前と後のログ数比較 ◦ 異常な乖離がないか、ルールを作ってチェック ◦ 今のところGlue起因のアラートは上がっていない 監視・障害検知 34 CONFIDENTIAL © 2018 primeNumber Inc.
36. • 改行コードを含むデータは正しく認識できない ◦ 複数行に分割されてテーブルが作られるので件数合わない ◦ Custom Classifierでも対応できないらしい ◦ 現状クロール対象のデータを修正するしか無い • 差分更新的めちゃ遅い ◦ 作成済みData Catalogの再クローリング遅い ◦ ファイル1つしか増えていなくても、全件クロールと同じくらい時間かかる ◦ パーティション追加は手動でやるしか・・・？ Glue Crawlerの注意点 35 CONFIDENTIAL © 2018 primeNumber Inc.
37. • コストが大幅に改善した ◦ Hadoopエンジニアに頼らない開発が出来るように ◦ 料金も約75%カット • スケーラビリティ向上 ◦ DPUを動的に算出すれば自動でスケール • S3を出力先にすることで可用性向上 ◦ ジョブがコケる外的要因を出来るだけ減らす ◦ Data Catalog + Redshift Spectrumで再利用性向上 まとめ 36 CONFIDENTIAL © 2018 primeNumber Inc.
38. We are hiring. primeNumberではデータエンジニアリング 基盤を一緒に育ててくれる仲間を募集中です
39. Any question? 38 © 2017 primeNumber Inc. CONFIDENTIAL ご清聴ありがとうございました