データ”抽出”基盤 Yeti を つくっている話 堤 利史 / GMO PEPABO inc. 2022.04.20 Data Engineering Meetup【ZOZO × GMOペパボ】 1

2 自己紹介 技術部 データ基盤チーム シニア 2020年 中途入社 堤　利史 Tsutsumi Toshifumi 2020年12月にGMOペパボへ入社。 データエンジニアとしてデータ基盤の 開発・運用に従事。 Twitter: @tosh2230 好きなポケモン: グレッグル

3 アジェンダ 1. GMOペパボにおけるELT*の現状 2. データ抽出基盤 Yeti 3. 今後の展望 * ELT: Extract, Load, Transform

1. GMOペパボにおける ELTの現状 4

- データ駆動のためのエコシステムの提供 - サービスの動的な改善と意思決定の自動化をサポート 詳細はこちらの資料を ご参照ください 👉 1. GMOペパボにおけるELTの現状 5 データ基盤 Bigfoot https://speakerdeck.com/zaimy/inside-story-of-data-infrastructure-sup porting-gmo-pepabos-services-and-r-and-d

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

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)の データ同期についてお話しします

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

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月: 検討開始

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月: いまここ

1. GMOペパボにおけるELTの現状 11 下記の三点を目的としています💪 - データエンジニアリングに関するノウハウの蓄積と共有 - データマスキングやポリシータグによるデータ管理手法の共通化 - サービスを横断したデータ活用の推進 サービスのRDBからBigfootへの”共通の入り口”をつくる

12 2. データ抽出基盤 Yeti

13 Yet another Extract-Transfer Infrastructure 2. データ抽出基盤 Yeti

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

15 2. データ抽出基盤 Yeti データ抽出の流れ Step1: Extract DAG が AWS Batch Job の実行をリクエスト Step2: コンテナが RDB からテーブル定義とレコードを抽出 Step3: 抽出した結果を S3 バケットに保存 Step4: Load DAG がデータを Google BigQuery にロード

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 の 実行をリクエスト

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 の実行をリクエスト

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 から テーブル定義とレコードを抽出

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

- コンテナで実行しているアプリケーション 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

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 バケットに保存

- レコード群を一定のサイズで区切って 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

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 にロード

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

25 Yetiを 構築・運用してみて どうですか？

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

27 2. データ抽出基盤 Yeti - Extract DAG と Load DAG で、1タスク・1テーブルの構成になっている - Airflow にはサーバーのスペックに応じた Concurrency 推奨値がある - 同期テーブル数が増えると、いずれ Cloud Composer がボトルネックになる - 1タスク・nテーブル といったグルーピングが必要 - BigQuery DTS ではないロード方法の検討 - 新しいオブジェクトを認識するまで 10 min ほどの時間を要する - DTS のサービスステータスを確認する手段がなさそう... - “S3 -> GCS -> BigQuery” の経路に変更予定 Yetiで改善したいところ

28 1. セクションタイトル 3. 今後の展望

3. 今後の展望 29 - 既存のRDB同期処理をYetiに移行する - バッチレイヤー以外の選択肢を設ける - BIツールに蓄積されたクエリ実行履歴の分析 話題に挙がっているトピックをご紹介します

3. 今後の展望 - Embulk を使っているサービスが多いので、まずはそこから始める - Yetiの目的のうち、下記の2点を社内に広めていく - データエンジニアリングに関するノウハウの蓄積と共有 - データマスキングやポリシータグによるデータ管理手法の共通化 - 全社統一 ELT 基盤へ💪 30 既存のRDB同期処理をYetiに移行する

3. 今後の展望 31 - RDBとの同期は日次で行っている - スピードレイヤーにあたる何かを提供していきたい - Change Data Capture (CDC) が有力な選択肢 バッチレイヤー以外の選択肢を設ける

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

33 Thank You! Thank You!