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