Slide 1

Slide 1 text

堤 利史 / GMO PEPABO inc. 2023.04.11 データ基盤アーキテクチャトレンド 2023 1 ニアリアルタイム分析の 実現に向けた Change Data Captureの導入

Slide 2

Slide 2 text

2 自己紹介 GMOペパボ株式会社 技術部データ基盤チーム シニアエンジニア 2020年 中途入社 堤 利史 Tsutsumi Toshifumi ● データエンジニア ● Twitter : @tosh2230 ● エルデンリングはじめました

Slide 3

Slide 3 text

3 アジェンダ 1. ニアリアルタイム分析の目的 2. Change Data Capture(CDC) 3. CDCデータパイプラインの紹介 データ基盤 「Bigfoot」 マスコットキャラクター Bigfootくん キャラクターグッズあります https://suzuri.jp/zaimy/designs/13278107

Slide 4

Slide 4 text

1. ニアリアルタイム分析の目的 4

Slide 5

Slide 5 text

これまでのデータパイプライン 5 事業用 RDB のレコードは Google BigQuery へ日次で転送 転送手段と規模 - Embulk によるバッチ転送 - テーブル数は数十〜数百 (事業によって異なる) - テーブルサイズは 100 GiB レベルなものも存在 https://speakerdeck.com/tosh2230/yeti-yet-another-extract-tra nsfer-infrastructure?slide=14

Slide 6

Slide 6 text

日次データ転送によって生じるタイムラグ 6 DWH で集計・分析が可能となるまでの時間 = 抽出時間 + 転送時間 + ロード時間 特定時点のスナップショットデータを順番に転送している 一部のデータがロードできたとしても必要なデータが揃わないと 集計・分析を開始できない ↓ サイズが大きいテーブルのデータが必要なら、その完了を待つ

Slide 7

Slide 7 text

2022年に生じた課題 7 BigQuery で集計・分析可能となるまでに要する時間が伸びて行く... 下記の対応をしたものの、抜本的な解決には至らず - 並列処理の調整 - RDB への負荷抑制のため、並列数に限度がある - updated_at 列などによる更新差分レコード抽出 - アプリケーションの挙動次第で可否が決まるため、対象が限られる

Slide 8

Slide 8 text

ユーザー行動とストリーム処理 8 RDB に書き込まれる情報は、ユーザーの行動によって生じる それらが生成されるたびに転送すれば、タイムラグを最小限にできるのではないか? ユーザー行動をニアリアルタイムに捉えることで、よりよいサービス提供を目指す イベント駆動 データ転送 ストリーム 分析 機を逃さない フィードバック

Slide 9

Slide 9 text

2. Change Data Capture (CDC) 9

Slide 10

Slide 10 text

Change Data Capture(CDC) とは 10 データベースで生じたデータの変更を捕捉すること 広義には、その変更内容を他のシステムやデータストアへ転送して活用する部分も含む 活用例 - データレプリケーション - キャッシュ更新 - 全文検索エンジンのインデックス更新

Slide 11

Slide 11 text

Debezium Server* を選択 Debezium が提供するアプリケーション - Debezium: Kafka Connect として動作 - Debezium Server: 変更イベントをメッセージングサービスへ送信(Kafkaless) 11 https://debezium.io/documentation/reference/2.1/architecture.html * 2023年4月時点で incubating state なので、将来的に仕様が変更となる可能性があります

Slide 12

Slide 12 text

検討候補と判断軸 12 候補は以下の3つとしていた - Debezium Server - Debezium - Airbyte 判断軸 - プライベートネットワーク内にある RDB にアクセスできるか - 1ヶ月で構築できるか - 運用の手間は少ないか - お財布にやさしいか

Slide 13

Slide 13 text

3. CDCデータパイプラインの紹介 13

Slide 14

Slide 14 text

VPC Private subnet 14 CDCデータパイプライン 構成図 VPC Private subnet RDS Replica RDS Primary S3 Fargate Batch ECS EC2 EFS Debezium Server Pub/Sub Merged view BigQuery Change events table BigQuery Snapshot table BigQuery Cloud Composer IN: OUT:

Slide 15

Slide 15 text

15 CDCデータパイプライン 構成図 VPC Private subnet VPC Private subnet RDS Replica RDS Primary S3 Fargate Batch ECS EC2 EFS Debezium Server Pub/Sub Merged view BigQuery Change events table BigQuery Snapshot table BigQuery Cloud Composer IN: OUT: 今回構築した範囲

Slide 16

Slide 16 text

AWS 16 - Debezium Server コンテナ*を ECS on EC2 で起動 - RDS for MySQL のレプリカが出力する binlog を読み込んで テーブル別につくった Cloud Pub/Sub Topic へ送信 - “変更をどこまで捕捉したか”を記録するファイルは EFS に保存 * https://github.com/debezium/container-images/tree/main/server

Slide 17

Slide 17 text

GCP 17 - Pub/Sub Subscription は BigQuery Subscriptions を指定して 専用テーブルに向けてストリーミングインサート - CDC レコードと従来のスナップショットテーブルのレコードを マージしたビューを社内へ公開(詳細は次スライドで)

Slide 18

Slide 18 text

2 Merged view 18 つくりかた 🍳 1. CDC レコード群から、Primary key ごとに最新のレコード状態を復元 2. 1 の Primary key を “含まない” レコードの集合をスナップショットテーブルから抽出 3. 1 と 2 を UNION ALL する Change events table BigQuery Snapshot table BigQuery Merged view BigQuery 1 PK別の最新状態 3

Slide 19

Slide 19 text

構築時に気をつけること 19 - MySQL は “binlog_format=ROW” が必須 - MIXED の場合は変更が必要 - レプリカ DB で binlog を出力すると安心 - デフォルト設定では、変更分を送信する前に既存のレコードをすべて転送する - Debezium のドキュメントにある “snapshot” はこれを指す - この間 lock がかかりっぱなしになる(レプリケーション遅延が起きます) - snapshot.mode の設定で制御可能

Slide 20

Slide 20 text

評価 20 - Debezium Server のリソース効率は今のところ良い - 変更レコードのみを転送するため、計画よりも小さいインスタンスタイプで稼働中 - テーブルを増やしていったときにどうなるか、経過観察 - マネージドサービスを活用したことで、開発工数と運用負荷を少なくできた - スナップショットテーブルの更新頻度を下げる余地が生まれた - ex. 日次から週次へ変更する - 転送コスト減 - RDS レプリカの負担減

Slide 21

Slide 21 text

今後の展望 21 Cloud Dataflow によるストリーム分析 - Pub/Sub 経由にしているねらいのひとつ - Subscription を追加することで別のデータパイプラインを増やせる - 行動ログと掛け合わせて、アプリケーションへのリアルタイムフィードバックを実現 日次データ転送を前提としていた集計・分析業務の見直し - これまでは 「○○時になったらこの処理を動かす」をしていた - これからは (ほぼ)最新のデータでいつでも集計・分析できる - 機械学習モデルの学習頻度を増やすことも可能になる

Slide 22

Slide 22 text

22 Thank You! Thank You!