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.4k
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
SODA - FACT BOOK
sodainc
1
1.1k
エンジニア向け採用ピッチ資料
inusan
0
130
Go Modules: From Basics to Beyond / Go Modulesの基本とその先へ
kuro_kurorrr
0
120
Perplexity Slack Botを作ってAI活用を進めた話 / AI Engineering Summit プレイベント
n3xem
0
660
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
240
プロダクト開発でも使おう 関数のオーバーロード
yoiwamoto
0
160
カクヨムAndroidアプリのリブート
numeroanddev
0
430
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
880
事業戦略を理解してソフトウェアを設計する
masuda220
PRO
22
6.2k
コード書くの好きな人向けAIコーディング活用tips #orestudy
77web
3
320
GoのGenericsによるslice操作との付き合い方
syumai
2
660
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
11
1.9k
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
How to train your dragon (web standard)
notwaldorf
92
6.1k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
940
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Code Review Best Practice
trishagee
68
18k
Making the Leap to Tech Lead
cromwellryan
134
9.3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.8k
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!