Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Hirokazu Kobayashi

February 15, 2018
Tweet

More Decks by Hirokazu Kobayashi

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  17. Lambda Architecture on AWS
    16
    CONFIDENTIAL © 2018 primeNumber Inc.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide