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

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

データ抽出基盤 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  12. 12
    2. データ抽出基盤 Yeti

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. 33
    Thank You!
    Thank You!

    View Slide