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
1.6k
ニアリアルタイム分析の実現に向けた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
4.2k
CDCデータパイプラインを止めないために / One Stream of the CDC
tosh2230
0
1.2k
データリネージの組織導入事例と今後の戦略 / Introduction to an example of data lineage in GMO Pepabo
tosh2230
0
860
SQLクエリ解析によるE2Eデータリネージの実現 / E2E-data-lineage
tosh2230
0
3.3k
データ抽出基盤 Yeti をつくっている話 / Yeti - Yet another Extract-Transfer Infrastructure
tosh2230
1
4.4k
Loggingモジュールではじめるログ出力入門 / Introduction to Python Logging
tosh2230
32
13k
データ基盤チームの設立と直近の取り組み / the-establishment-of-pepabo-data-platform-team
tosh2230
5
4.2k
Other Decks in Programming
See All in Programming
WEBエンジニア向けAI活用入門
sutetotanuki
0
300
開発効率向上のためのリファクタリングの一歩目の選択肢 ~コード分割~ / JJUG CCC 2024 Fall
ryounasso
0
360
Kotlin2でdataクラスの copyメソッドを禁止する/Data class copy function to have the same visibility as constructor
eichisanden
1
130
RailsのPull requestsのレビューの時に私が考えていること
yahonda
5
1.7k
Vue.js学習の振り返り
hiro_xre
2
130
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
9
1k
詳細解説! ArrayListの仕組みと実装
yujisoftware
0
480
Realtime API 入門
riofujimon
0
110
Kubernetes for Data Engineers: Building Scalable, Reliable Data Pipelines
sucitw
1
200
現場で役立つモデリング 超入門
masuda220
PRO
13
2.9k
ECS Service Connectのこれまでのアップデートと今後のRoadmapを見てみる
tkikuc
2
210
とにかくAWS GameDay!AWSは世界の共通言語! / Anyway, AWS GameDay! AWS is the world's lingua franca!
seike460
PRO
1
550
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
680
Designing for humans not robots
tammielis
249
25k
A designer walks into a library…
pauljervisheath
202
24k
Building Your Own Lightsaber
phodgson
102
6k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Building an army of robots
kneath
302
42k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Done Done
chrislema
181
16k
Six Lessons from altMBA
skipperchong
26
3.5k
How to train your dragon (web standard)
notwaldorf
88
5.7k
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!