Tweet
Tweet

Slide 1

Slide 1 text

2018年2月15日 AWS Glue活用事例 データ基盤「systemN」の本番環境で、 100億レコード/月のETLをGlueで実装した話

Slide 2

Slide 2 text

自己紹介 1 CONFIDENTIAL ● 小林寛和 ○ @hiro-koba (Github) ○ @hiro_koba_jp (Twitter / Qiita) ● 株式会社primeNumber ○ 執行役員 エンジニア ● 好きなAWSサービス ○ Elastic Beanstalk / AWS Lambda ○ Redshift / AWS Glue © 2018 primeNumber Inc.

Slide 3

Slide 3 text

● primeNumber ○ 中目黒のエンジニアリング・カンパニー ● 事業内容 ○ データエンジニアリングPaaS「systemN」 ○ マーケティング・コンサルテーション 自社紹介 2 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 4

Slide 4 text

データエンジニアリングPaaS「systemN」 3 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 5

Slide 5 text

導入事例: 総合マーケティング企業のDMP 4 © 2018 primeNumber Inc. CONFIDENTIAL ● 用途 ○ Webブラウザ・スマホアプリ上の行動ログ収集 ○ 生ログを使用した分析 ○ セグメンテーション・広告利用 ● 規模感 ○ 収集ログ量: 100億レコード／月超 ○ ETLジョブ実行回数: 250回／日 ○ Redshiftノード数: 20 nodes (dc2.large)

Slide 6

Slide 6 text

5 CONFIDENTIAL AWS Glue導入事例 © 2018 primeNumber Inc.

Slide 7

Slide 7 text

1. ログをKinesis Firehose経由でS3に蓄積 2. 1時間に1回バッチETL（クレンジング・変換） 3. prestoでETL後のログを可視化 Glue導入前のデータ基盤@2017年8月 6 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 8

Slide 8 text

● 自前でEC2上にHadoop環境を構築 ○ ETLサービス→Hive + Spark ○ DWH→Presto ● Hadoop専属エンジニア Glue導入前のETL基盤@2017年8月 7 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 9

Slide 9 text

● ログ量の増加に伴い、様々な課題が ETL基盤@2017年8月 8 CONFIDENTIAL 応答速度求められると辛い スケールさせるのが手間 最小構成で結構高い インスタンス必要？ 再利用しにくい Hadoop専属エンジニア 以外触れない 重いクエリ走ると ETLに影響が・・・ © 2018 primeNumber Inc.

Slide 10

Slide 10 text

課題1. コスト改善 9 ● 人的コスト ○ Hadoop専属エンジニアが必要 ○ 運用上のボトルネック ● 料金 ○ 最小構成: 20万円／月 ○ 仮に現在と同じレコード処理した場合 ■ 100億レコード／月を処理するにはEC2 60台構成 ■ 月間数百万円、全然ペイしない・・・ CONFIDENTIAL © 2018 primeNumber Inc.

Slide 11

Slide 11 text

● スケールアウトを容易に行えるように ○ ノードの追加作業が複雑で、ダウンタイムも発生 ○ 突発的なスパイク来たら死亡 ● データ基盤としてのスケーラビリティ ○ バッチだけでなくリアルタイム集計要件が出てきた ○ Spark Streaming立てるとなると別クラスタ必要… 課題2. スケーラビリティを上げたい 10 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 12

Slide 12 text

課題3. ETL・DWHの可用性を上げたい 11 ● DWH側が高負荷になるとETLが止まる ○ prestoで重いクエリが実行されるとクラスタ毎落ちる ○ 逆もまた然り ● DWHがボトルネックに ○ ETL後のログは別システムなどで利活用したい ○ prestoを経由する必要があり、ボトルネック ○ HDFSだと取り回しにくい CONFIDENTIAL © 2018 primeNumber Inc.

Slide 13

Slide 13 text

12 CONFIDENTIAL 2017年9月1日、リプレイスPJT始動 0ベースで最適なアーキテクチャを模索 © 2018 primeNumber Inc.

Slide 14

Slide 14 text

Lambda Architecture 13 CONFIDENTIAL © 2018 primeNumber Inc. 引用: http://lambda-architecture.net/

Slide 15

Slide 15 text

Batch Layer & Serving Layer for systemN 1. 生ログを汎用的なバッチビューに変換 ○ ダッシュボードからのクエリなど 2. ビジネス活用のためのバッチビュー構築 ○ 1の汎用ログバッチビューから生成 ○ 広告配信用のユーザー単位のサマリービューなど 14 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 16

Slide 16 text

● リアルタイムなデータ集計に利用 ○ Batch Layerで処理が間に合わない箇所で利用 ○ 例: ドメインごとのPV/UU数を3秒以内に集計→可視化 サービスで表示 Speed Layer for systemN 15 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 17

Slide 17 text

Lambda Architecture on AWS 16 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 18

Slide 18 text

17 CONFIDENTIAL 2017年9月中旬、実装開始 © 2018 primeNumber Inc.

Slide 19

Slide 19 text

● 解決したい課題 ○ 料金・人的コスト最小化 ○ スケーラビリティの確保 ● 解決方法 ○ マネージド・サービスAWS Glueの採用 ■ インフラ面の運用コストほぼ0 ■ 学習コストはコードを書くことのみ ■ 料金は1/4以下に ● 最小構成は月間20万円→5万円に ○ スケーラビリティもLambdaとの統合で解決 Batch Layer実装 18 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 20

Slide 20 text

Batch Layer - スケーラビリティを上げる工夫 19 CONFIDENTIAL © 2018 primeNumber Inc. ● LambdaでGlueのDPUを自動設定 ● 突発的なスパイクが来ても一定時間内に処理が終わるように ① 処理対象のログサイズ取得 ② 1時間以内に処理が終わる DPUの算出 ③ 算出したDPUを設定してJob Run

Slide 21

Slide 21 text

● 解決したい課題 ○ DWH側の障害・メンテの影響がETLに波及しない ○ DWHの処理性能がボトルネックにならない ● 解決方法 ○ ETLの出力先をS3に統一 ■ DWH側の影響はETLに波及しない ○ RedshiftとRedshift Spectrumの併用 ■ 性能面のボトルネックは大きく改善 Serving Layer実装 20 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 22

Slide 22 text

Serving Layer - ETLとDWHの分離 21 CONFIDENTIAL © 2018 primeNumber Inc. ● ETLとDWHを分離するメリット ○ 外的要因による障害が減る ■ DWHの障害・メンテの度に止める必要なくなった ■ 出力先をS3にしたことで、S3が落ちない限りETLは外的要 因で落ちない ○ コストメリット ■ 負荷が少ないロードのために、高価なDPUを使わない

Slide 23

Slide 23 text

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が完了したらメッセージ削除

Slide 24

Slide 24 text

Serving Layer - 2つのクエリ実行方法 23 CONFIDENTIAL © 2018 primeNumber Inc. ● 応答速度に応じてRedshift or Redshift Spectrumを選択 ● どちらもRedshiftのI/Fでアクセスできる点がポイント ある程度時間がかかっても良いアクセス 応答速度が求められる場合は、 Redshiftにデータをロードしておく

Slide 25

Slide 25 text

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上でテーブルとして扱えるように

Slide 26

Slide 26 text

● ETL後のデータの内、一部のフィールドだけRedshiftに取り込 みたい ● Redshift Spectrumからは全フィールドが見たい ● AVRO＋COPYコマンドで解決 一部の列だけRedshiftにLoad 25 CONFIDENTIAL © 2018 primeNumber Inc. AVRO形式で出力 テーブル定義に存在するフィー ルドだけ取り込まれる Spectrumからは 全フィールドが見える Redshift上には 必要列だけロードし、 容量圧縮

Slide 27

Slide 27 text

2017年9月末リリース 26 CONFIDENTIAL © 2018 primeNumber Inc. ● 2017年9月1日、リプレイスPJT始動 ● 2017年9月前半、アーキテクチャ設計 ● 2017年9月後半、実装 ● 2017年9月末日、本番リリース・完全切替

Slide 28

Slide 28 text

● ETL後のデータの再利用性もっと上げたい ○ ETLのバージョン違いでデータ形式などもバラバラ ○ 全期間のデータが同じスキーマで揃っていると再利用性が 更に高くなる ● Spectrumのパフォーマンス上げたい ○ Parquet形式にしたい（RedshiftのCOPY非対応） ○ S3のパーティションも最適化したい ■ Ex. s3://BUCKET/site_id=123/year=2018/… ● ETL後のデータに対するETLを作成中 今後の課題1. データマート化 27 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 29

Slide 29 text

● スモールスタートと実装スピードはGlueの得意とするところだ が、もう少しコスト抑えたい ● コードで出来る最適化 ○ RDDを極力使わないなどPySparkのチューニング ○ Scala化の検証 ● Glue以外の選択肢も ○ ログ量が増えたらEMRの方が安かったりするかも？ ○ 便利なDynamicFrameやEC2運用が発生するデメリットを 許容できるか、検証中 今後の課題2. Jobの高速化 28 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 30

Slide 30 text

29 CONFIDENTIAL AWS Glueの開発Tips © 2018 primeNumber Inc.

Slide 31

Slide 31 text

● データアクセス層とETL処理層に分けています プログラミングモデル 30 CONFIDENTIAL © 2018 primeNumber Inc. 入力はDynamicFrameで のロードが便利 ETL処理層のI/FはDataFrame 任意の列でディレクトリを切るなど は、DynamicFrame使えない

Slide 32

Slide 32 text

● ETL処理層はローカル開発 ○ 少量データからDataFrameを作り、それをETLする ○ Jupyter Notebookから実行 ● データアクセス層の開発やE2Eで動かしたい時はDevEndpoint ○ DynamicFrameでデータロードする箇所とか ○ DevEndpointハマりどころ ■ SparkContextを再生成しないとtoDF()が動かない ■ spark.stop() glueContext = GlueContext(SparkContext.getOrCreate()) 開発環境 31 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 33

Slide 33 text

● 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.

Slide 34

Slide 34 text

● Jobの実行結果 ○ CloudWatch Eventを使用し、基本全てSNS通知 ○ SNSはIFTTTに通知し、失敗時のみ通知するよう分岐 ○ ただしJobのステータスがSUCCEEDEDなのにエラー終了 しているのを見たことがあるので、ちゃんとやるなら CloudWatch Logsのログでアラート設定すべきかも ● Job実行時間 ○ うまい方法見つけられてない ○ 毎時GlueのAPI叩いてRunningのジョブの実行時間取る とか・・・？ ○ 現状シビアに監視する必要が無いのでやってない 監視・障害検知 33 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 35

Slide 35 text

● 念のためE2Eのカウントチェックやってる ○ ETL前と後のログ数比較 ○ 異常な乖離がないか、ルールを作ってチェック ○ 今のところGlue起因のアラートは上がっていない 監視・障害検知 34 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 36

Slide 36 text

● 改行コードを含むデータは正しく認識できない ○ 複数行に分割されてテーブルが作られるので件数合わない ○ Custom Classifierでも対応できないらしい ○ 現状クロール対象のデータを修正するしか無い ● 差分更新的めちゃ遅い ○ 作成済みData Catalogの再クローリング遅い ○ ファイル1つしか増えていなくても、全件クロールと同じくらい時間かかる ○ パーティション追加は手動でやるしか・・・？ Glue Crawlerの注意点 35 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 37

Slide 37 text

● コストが大幅に改善した ○ Hadoopエンジニアに頼らない開発が出来るように ○ 料金も約75%カット ● スケーラビリティ向上 ○ DPUを動的に算出すれば自動でスケール ● S3を出力先にすることで可用性向上 ○ ジョブがコケる外的要因を出来るだけ減らす ○ Data Catalog + Redshift Spectrumで再利用性向上 まとめ 36 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 38

Slide 38 text

We are hiring. primeNumberではデータエンジニアリング 基盤を一緒に育ててくれる仲間を募集中です

Slide 39

Slide 39 text

Any question? 38 © 2017 primeNumber Inc. CONFIDENTIAL ご清聴ありがとうございました