Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ニアリアルタイム分析の実現に向けたChange Data Captureの導入 / Chang...
Search
Toshifumi Tsutsumi
April 11, 2023
Programming
3
2.1k
ニアリアルタイム分析の実現に向けたChange Data Captureの導入 / Change data capture for near realtime analytics
データ基盤アーキテクチャトレンド 2023 LT資料
https://findy.connpass.com/event/278140/
Toshifumi Tsutsumi
April 11, 2023
Tweet
Share
More Decks by Toshifumi Tsutsumi
See All by Toshifumi Tsutsumi
ModuleNotFoundErrorの傾向と対策:仕組みから学ぶImport / Unpacking ModuleNotFoundError
tosh2230
3
5.5k
CDCデータパイプラインを止めないために / One Stream of the CDC
tosh2230
0
1.5k
データリネージの組織導入事例と今後の戦略 / Introduction to an example of data lineage in GMO Pepabo
tosh2230
0
1k
SQLクエリ解析によるE2Eデータリネージの実現 / E2E-data-lineage
tosh2230
0
3.8k
データ抽出基盤 Yeti をつくっている話 / Yeti - Yet another Extract-Transfer Infrastructure
tosh2230
1
5.1k
Loggingモジュールではじめるログ出力入門 / Introduction to Python Logging
tosh2230
33
15k
データ基盤チームの設立と直近の取り組み / the-establishment-of-pepabo-data-platform-team
tosh2230
5
4.5k
Other Decks in Programming
See All in Programming
[Codecon - 2025] Como não odiar seus testes
camilacampos
0
100
大規模FlutterプロジェクトのCI実行時間を約8割削減した話
teamlab
PRO
0
450
「次に何を学べばいいか分からない」あなたへ──若手エンジニアのための学習地図
panda_program
3
710
0から始めるモジュラーモノリス-クリーンなモノリスを目指して
sushi0120
0
250
iOS開発スターターキットの作り方
akidon0000
0
230
Google I/O Extended Incheon 2025 ~ What's new in Android development tools
pluu
1
220
Reactの歴史を振り返る
tutinoko
1
170
JetBrainsのAI機能の紹介 #jjug
yusuke
0
180
NEWT Backend Evolution
xpromx
1
170
Strands Agents で実現する名刺解析アーキテクチャ
omiya0555
1
110
DataformでPythonする / dataform-de-python
snhryt
0
150
[DevinMeetupTokyo2025] コード書かせないDevinの使い方
takumiyoshikawa
2
250
Featured
See All Featured
Six Lessons from altMBA
skipperchong
28
3.9k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
182
54k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
Fireside Chat
paigeccino
38
3.6k
GitHub's CSS Performance
jonrohan
1031
460k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Transcript
堤 利史 / GMO PEPABO inc. 2023.04.11 データ基盤アーキテクチャトレンド 2023 1
ニアリアルタイム分析の 実現に向けた Change Data Captureの導入
2 自己紹介 GMOペパボ株式会社 技術部データ基盤チーム シニアエンジニア 2020年 中途入社 堤 利史 Tsutsumi
Toshifumi • データエンジニア • Twitter : @tosh2230 • エルデンリングはじめました
3 アジェンダ 1. ニアリアルタイム分析の目的 2. Change Data Capture(CDC) 3. CDCデータパイプラインの紹介
データ基盤 「Bigfoot」 マスコットキャラクター Bigfootくん キャラクターグッズあります https://suzuri.jp/zaimy/designs/13278107
1. ニアリアルタイム分析の目的 4
これまでのデータパイプライン 5 事業用 RDB のレコードは Google BigQuery へ日次で転送 転送手段と規模 -
Embulk によるバッチ転送 - テーブル数は数十〜数百 (事業によって異なる) - テーブルサイズは 100 GiB レベルなものも存在 https://speakerdeck.com/tosh2230/yeti-yet-another-extract-tra nsfer-infrastructure?slide=14
日次データ転送によって生じるタイムラグ 6 DWH で集計・分析が可能となるまでの時間 = 抽出時間 + 転送時間 + ロード時間
特定時点のスナップショットデータを順番に転送している 一部のデータがロードできたとしても必要なデータが揃わないと 集計・分析を開始できない ↓ サイズが大きいテーブルのデータが必要なら、その完了を待つ
2022年に生じた課題 7 BigQuery で集計・分析可能となるまでに要する時間が伸びて行く... 下記の対応をしたものの、抜本的な解決には至らず - 並列処理の調整 - RDB への負荷抑制のため、並列数に限度がある
- updated_at 列などによる更新差分レコード抽出 - アプリケーションの挙動次第で可否が決まるため、対象が限られる
ユーザー行動とストリーム処理 8 RDB に書き込まれる情報は、ユーザーの行動によって生じる それらが生成されるたびに転送すれば、タイムラグを最小限にできるのではないか? ユーザー行動をニアリアルタイムに捉えることで、よりよいサービス提供を目指す イベント駆動 データ転送 ストリーム 分析
機を逃さない フィードバック
2. Change Data Capture (CDC) 9
Change Data Capture(CDC) とは 10 データベースで生じたデータの変更を捕捉すること 広義には、その変更内容を他のシステムやデータストアへ転送して活用する部分も含む 活用例 - データレプリケーション
- キャッシュ更新 - 全文検索エンジンのインデックス更新
Debezium Server* を選択 Debezium が提供するアプリケーション - Debezium: Kafka Connect として動作
- Debezium Server: 変更イベントをメッセージングサービスへ送信(Kafkaless) 11 https://debezium.io/documentation/reference/2.1/architecture.html * 2023年4月時点で incubating state なので、将来的に仕様が変更となる可能性があります
検討候補と判断軸 12 候補は以下の3つとしていた - Debezium Server - Debezium - Airbyte
判断軸 - プライベートネットワーク内にある RDB にアクセスできるか - 1ヶ月で構築できるか - 運用の手間は少ないか - お財布にやさしいか
3. CDCデータパイプラインの紹介 13
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:
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: 今回構築した範囲
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
GCP 17 - Pub/Sub Subscription は BigQuery Subscriptions を指定して 専用テーブルに向けてストリーミングインサート
- CDC レコードと従来のスナップショットテーブルのレコードを マージしたビューを社内へ公開(詳細は次スライドで)
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
構築時に気をつけること 19 - MySQL は “binlog_format=ROW” が必須 - MIXED の場合は変更が必要
- レプリカ DB で binlog を出力すると安心 - デフォルト設定では、変更分を送信する前に既存のレコードをすべて転送する - Debezium のドキュメントにある “snapshot” はこれを指す - この間 lock がかかりっぱなしになる(レプリケーション遅延が起きます) - snapshot.mode の設定で制御可能
評価 20 - Debezium Server のリソース効率は今のところ良い - 変更レコードのみを転送するため、計画よりも小さいインスタンスタイプで稼働中 - テーブルを増やしていったときにどうなるか、経過観察
- マネージドサービスを活用したことで、開発工数と運用負荷を少なくできた - スナップショットテーブルの更新頻度を下げる余地が生まれた - ex. 日次から週次へ変更する - 転送コスト減 - RDS レプリカの負担減
今後の展望 21 Cloud Dataflow によるストリーム分析 - Pub/Sub 経由にしているねらいのひとつ - Subscription
を追加することで別のデータパイプラインを増やせる - 行動ログと掛け合わせて、アプリケーションへのリアルタイムフィードバックを実現 日次データ転送を前提としていた集計・分析業務の見直し - これまでは 「◦◦時になったらこの処理を動かす」をしていた - これからは (ほぼ)最新のデータでいつでも集計・分析できる - 機械学習モデルの学習頻度を増やすことも可能になる
22 Thank You! Thank You!