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

データ抽出基盤 Yeti をつくっている話 / Yeti - Yet another Extr...

データ抽出基盤 Yeti をつくっている話 / Yeti - Yet another Extract-Transfer Infrastructure

Data Engineering Meetup 【ZOZO × GMOペパボ】登壇資料
https://pepabo.connpass.com/event/242688/

GMOペパボのサービスと研究開発を支えるデータ基盤の裏側
https://speakerdeck.com/zaimy/inside-story-of-data-infrastructure-supporting-gmo-pepabos-services-and-r-and-d

Toshifumi Tsutsumi

April 20, 2022
Tweet

More Decks by Toshifumi Tsutsumi

Other Decks in Technology

Transcript

  1. データ”抽出”基盤 Yeti を つくっている話 堤 利史 / GMO PEPABO inc.

    2022.04.20 Data Engineering Meetup【ZOZO × GMOペパボ】 1
  2. 2 自己紹介 技術部 データ基盤チーム シニア 2020年 中途入社 堤 利史 Tsutsumi Toshifumi

    2020年12月にGMOペパボへ入社。 データエンジニアとしてデータ基盤の 開発・運用に従事。 Twitter: @tosh2230 好きなポケモン: グレッグル
  3. 6 1. GMOペパボにおけるELTの現状 Data source logs metrics GitHub issues databases

    Collect data tbls datasets BigQuery bigfoot/platform Cloud Storage - Permissions - Datasets - Buckets Data Studio bigfoot/cloud-composer Cloud Composer dags/ tbls-build base tbls.yml files patch files ( *.yml, *.json ) patched tbls.yml files tbls-meta tbls data catalog Apply metadata Generate & Commit Generate schema.json & commit bigfoot/data-catalog Update metadata & commit Spread sheet View Send analysis results
  4. 7 1. GMOペパボにおけるELTの現状 Data source logs metrics GitHub issues databases

    Collect data tbls datasets BigQuery bigfoot/platform Cloud Storage - Permissions - Datasets - Buckets Data Studio bigfoot/cloud-composer Cloud Composer dags/ tbls-build base tbls.yml files patch files ( *.yml, *.json ) patched tbls.yml files tbls-meta tbls data catalog Apply metadata Generate & Commit Generate schema.json & commit bigfoot/data-catalog Update metadata & commit Spread sheet View Send analysis results 本日はこの範囲のうち リレーショナルデータベース(RDB)の データ同期についてお話しします
  5. 1. GMOペパボにおけるELTの現状 8 - サービスが複数ある = データベースが複数ある - Amazon RDS

    に構築されているケースが多い - Bigfoot は GCP を中心に構成されている - AWS -> GCP のパブリッククラウド越境 - Bigfootへのデータ同期状況はサービスによって異なる - 同期していない場合 - リレーショナルデータベースやキーバリューストアは分析に不向き - 同期していても... - 同期方法がサービスごと異なり、ノウハウが分散している - サービスのデータを同期して分析したい! という点は同じ GMOペパボはインターネットサービスを多数運営しています
  6. 9 logs metrics GitHub issues databases Collect data tbls datasets

    BigQuery bigfoot/platform Cloud Storage - Permissions - Datasets - Buckets Apply metadata Generate schema.json & commit Send analysis results サービスのRDBとBigfootの間に”なにか”があればよいのでは? 1. GMOペパボにおけるELTの現状 なにか 2021年12月: 検討開始
  7. 10 logs metrics GitHub issues databases Collect data tbls datasets

    BigQuery bigfoot/platform Cloud Storage - Permissions - Datasets - Buckets Apply metadata Generate schema.json & commit Send analysis results サービスのRDBからBigfootへの”共通の入り口”をつくる 1. GMOペパボにおけるELTの現状 2021年12月: 検討開始 2022年01月: 実装開始 2022年03月: 本番稼働開始 2022年04月: いまここ
  8. AWS (各サービス) AWS (各サービス) 14 2. データ抽出基盤 Yeti Bigfoot ペパボの各サービス

    VPC Extract DAG Load DAG BigQuery Cloud Composer Private subnet RDS Replica RDS Primary VPC VPC VPC ECR Secret Manager S3 VPC Endpoints VPC Peering Queue Batch Job definition Private subnet Fargate (Batch Environment) Batch Jobs Cloud Formation
  9. 15 2. データ抽出基盤 Yeti データ抽出の流れ Step1: Extract DAG が AWS

    Batch Job の実行をリクエスト Step2: コンテナが RDB からテーブル定義とレコードを抽出 Step3: 抽出した結果を S3 バケットに保存 Step4: Load DAG がデータを Google BigQuery にロード
  10. AWS (各サービス) AWS (各サービス) 16 2. データ抽出基盤 Yeti Bigfoot ペパボの各サービス

    VPC Extract DAG Load DAG BigQuery Cloud Composer Private subnet RDS Replica RDS Primary VPC VPC VPC ECR Secret Manager S3 VPC Endpoints VPC Peering Queue Batch Job definition Private subnet Fargate (Batch Environment) Batch Jobs Cloud Formation Step1 Extract DAG が AWS Batch Job の 実行をリクエスト
  11. 17 2. データ抽出基盤 Yeti - オーケストレーターは Google Cloud Composer -

    フルマネージド Apache Airflow - Bigfoot 全体のデータ操作を担当 - DAG (Directed Acyclic Graph; 有向非巡回グラフ) - Airflow におけるワークフローの実行単位 - Extract DAG は Batch Job が完了するまで待機 - Extract DAG が正常終了したら Load DAG を開始 Step1: Extract DAG が AWS Batch Job の実行をリクエスト
  12. AWS (各サービス) AWS (各サービス) 18 2. データ抽出基盤 Yeti Bigfoot ペパボの各サービス

    VPC Extract DAG Load DAG BigQuery Cloud Composer Private subnet RDS Replica RDS Primary VPC VPC VPC ECR Secret Manager S3 VPC Endpoints VPC Peering Queue Batch Job definition Private subnet Fargate (Batch Environment) Batch Jobs Cloud Formation Step2 コンテナが RDB から テーブル定義とレコードを抽出
  13. 19 2. データ抽出基盤 Yeti - AWS Batch on AWS Fargate

    を利用 - ひとつのコンテナが1テーブルを担当 - 環境変数を経由して対象テーブル名や設定、抽出条件を指定 - DB 接続情報は AWS Secrets Manager から取得 - JobDefinition, Queue, Environment のパーツに分かれているため パフォーマンスチューニングをしやすい - Amazon RDS インスタンスとの接続はプライベートサブネットで実施 - RDS インスタンスと同じAZのサブネットを指定すると VPC 間のデータ転送量が無料になる Step2: コンテナが RDB からテーブル定義とレコードを抽出(1)
  14. - コンテナで実行しているアプリケーション k1LoW/tbls - テーブル定義, メタデータ, ポリシータグを出力 - 後続処理として、tbls 出力ファイルを

    BigQuery の データ型に変換するスクリプトを実行 Embulk - レコードの抽出 - RDBMS に合わせてプラグインを変更 - e.g. embulk-input-mysql Parquet 20 2. データ抽出基盤 Yeti Step2: コンテナが RDB からテーブル定義とレコードを抽出(2) AWS Batch Job RDS S3 JSON スキーマ レコード Parquet Parquet
  15. AWS (各サービス) AWS (各サービス) 21 2. データ抽出基盤 Yeti Bigfoot ペパボの各サービス

    VPC Extract DAG Load DAG BigQuery Cloud Composer Private subnet RDS Replica RDS Primary VPC VPC VPC ECR Secret Manager S3 VPC Endpoints VPC Peering Queue Batch Job definition Private subnet Fargate (Batch Environment) Batch Jobs Cloud Formation Step3 抽出した結果を S3 バケットに保存
  16. - レコード群を一定のサイズで区切って Apache Parquet 形式に変換 - Embulk での抽出結果は embulk-output-command で標準入力に流す

    - PyArrow で変換して S3 バケットに PUT - Fargate のメモリサイズに収めるための工夫 - Apache Parquet - 列指向ファイルフォーマット - ファイルサイズの圧縮を期待できる - 圧縮することによるメリット - データ転送費用の削減(S3 -> BigQuery) - データ出力・転送時間の削減 Parquet S3 JSON スキーマ レコード Parquet Parquet 22 2. データ抽出基盤 Yeti Step3: 抽出した結果を S3 バケットに保存 AWS Batch Job RDS
  17. AWS (各サービス) AWS (各サービス) 23 2. データ抽出基盤 Yeti Bigfoot ペパボの各サービス

    VPC Extract DAG Load DAG BigQuery Cloud Composer Private subnet RDS Replica RDS Primary VPC VPC VPC ECR Secret Manager S3 VPC Endpoints VPC Peering Queue Batch Job definition Private subnet Fargate (Batch Environment) Batch Jobs Cloud Formation Step4 Load DAG がデータを Google BigQuery にロード
  18. 24 2. データ抽出基盤 Yeti Step4: Load DAG がデータを Google BigQuery

    にロード - BigQuery Data Transfer Service(DTS) で一時テーブルとしてロード - 既存テーブルに対して一時テーブルのレコードを追加・更新 - Policy Tag を設定 - BigQuery 列レベルのセキュリティ - 列ごとにアクセス権限を設定できる - tbls で取得したメタデータの ColumnLabel 設定値で制御 - e.g. “Sensitive”ラベルがついている列は管理者のみアクセスできるようにする
  19. 26 2. データ抽出基盤 Yeti - 他のサービスに横展開しやすい - AWS CloudFormation でコード管理している

    - RDBMS の種類にあわせて、コンテナ内の Embulk Input プラグインを 変更すればだいたい動く - Extract DAG の設定ファイルにテーブル名を追記すれば同期対象を増やせる - サーバーレス基盤なので運用の負担が少ない - スケーリングを気にしなくてよい - コンテナ内のアプリケーションに集中できる - (コストは注視しています...) Yetiのよいところ
  20. 27 2. データ抽出基盤 Yeti - Extract DAG と Load DAG

    で、1タスク・1テーブルの構成になっている - Airflow にはサーバーのスペックに応じた Concurrency 推奨値がある - 同期テーブル数が増えると、いずれ Cloud Composer がボトルネックになる - 1タスク・nテーブル といったグルーピングが必要 - BigQuery DTS ではないロード方法の検討 - 新しいオブジェクトを認識するまで 10 min ほどの時間を要する - DTS のサービスステータスを確認する手段がなさそう... - “S3 -> GCS -> BigQuery” の経路に変更予定 Yetiで改善したいところ
  21. 3. 今後の展望 - Embulk を使っているサービスが多いので、まずはそこから始める - Yetiの目的のうち、下記の2点を社内に広めていく - データエンジニアリングに関するノウハウの蓄積と共有 -

    データマスキングやポリシータグによるデータ管理手法の共通化 - 全社統一 ELT 基盤へ💪 30 既存のRDB同期処理をYetiに移行する
  22. 3. 今後の展望 32 - ペパボでよく使われている BI ツールは Redash - Redash

    のメタデータは PostgreSQL に保存されている - Yeti で同期すれば、クエリの実行状況を把握できる - よりよい方法を提案することで、施策検討を効率化する BIツールに蓄積されたクエリ実行履歴の分析