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
2k
ニアリアルタイム分析の実現に向けた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.3k
CDCデータパイプラインを止めないために / One Stream of the CDC
tosh2230
0
1.4k
データリネージの組織導入事例と今後の戦略 / Introduction to an example of data lineage in GMO Pepabo
tosh2230
0
1k
SQLクエリ解析によるE2Eデータリネージの実現 / E2E-data-lineage
tosh2230
0
3.7k
データ抽出基盤 Yeti をつくっている話 / Yeti - Yet another Extract-Transfer Infrastructure
tosh2230
1
5k
Loggingモジュールではじめるログ出力入門 / Introduction to Python Logging
tosh2230
32
14k
データ基盤チームの設立と直近の取り組み / the-establishment-of-pepabo-data-platform-team
tosh2230
5
4.4k
Other Decks in Programming
See All in Programming
try-catchを使わないエラーハンドリング!? PHPでResult型の考え方を取り入れてみよう
kajitack
3
290
RubyKaigi Hack Space in Tokyo & 函館最速 "予習" 会 / RubyKaigi Hack Space in Tokyo & The Fastest Briefing of RubyKaigi 2026 in Hakodate
moznion
1
120
TSConfigからTypeScriptの世界を覗く
planck16
2
1.3k
💎 My RubyKaigi Effect in 2025: Top Ruby Companies 🌐
yasulab
PRO
1
130
『Python → TypeScript』オンボーディング奮闘記
takumi_tatsuno
1
140
推論された型の移植性エラーTS2742に挑む
teamlab
PRO
0
150
JVM の仕組みを理解して PHP で実装してみよう
m3m0r7
PRO
1
250
Reactive Thinking with Signals, Resource API, and httpResource @Devm.io Angular 20 Launch Party
manfredsteyer
PRO
0
130
ワイがおすすめする新潟の食 / 20250530phpconf-niigata-eve
kasacchiful
0
180
TypeScriptのmoduleオプションを改めて整理する
bicstone
4
420
技術懸念に立ち向かい 法改正を穏便に乗り切った話
pop_cashew
0
760
事業KPIを基に価値の解像度を上げる
nealle
0
200
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
The Power of CSS Pseudo Elements
geoffreycrofte
76
5.8k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.2k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
GraphQLとの向き合い方2022年版
quramy
46
14k
Site-Speed That Sticks
csswizardry
7
590
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.3k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.8k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
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!