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
5分で分かった気になるDebezium
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Tomohiro Hashidate
October 08, 2024
Programming
1
200
5分で分かった気になるDebezium
TokyuRuby会議15 発表資料
Tomohiro Hashidate
October 08, 2024
Tweet
Share
More Decks by Tomohiro Hashidate
See All by Tomohiro Hashidate
ReproでのicebergのStreaming Writeの検証と実運用にむけた取り組み
joker1007
0
560
マイクロサービスへの5年間 ぶっちゃけ何をしてどうなったか
joker1007
23
9.1k
Quarkusで作るInteractive Stream Application
joker1007
0
220
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
joker1007
25
19k
rubygem開発で鍛える設計力
joker1007
4
1.2k
実践Kafka Streams 〜イベント駆動型アーキテクチャを添えて〜
joker1007
3
1.3k
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
1.2k
Rustで作るtree-sitterパーサーのRubyバインディング
joker1007
5
1.6k
tree-sitter-rbsで作って学ぶRBSとパーサージェネレーター
joker1007
3
360
Other Decks in Programming
See All in Programming
CSC307 Lecture 07
javiergs
PRO
1
560
Lambda のコードストレージ容量に気をつけましょう
tattwan718
0
140
疑似コードによるプロンプト記述、どのくらい正確に実行される?
kokuyouwind
0
390
16年目のピクシブ百科事典を支える最新の技術基盤 / The Modern Tech Stack Powering Pixiv Encyclopedia in its 16th Year
ahuglajbclajep
5
1k
AIフル活用時代だからこそ学んでおきたい働き方の心得
shinoyu
0
140
humanlayerのブログから学ぶ、良いCLAUDE.mdの書き方
tsukamoto1783
0
200
360° Signals in Angular: Signal Forms with SignalStore & Resources @ngLondon 01/2026
manfredsteyer
PRO
0
130
CSC307 Lecture 05
javiergs
PRO
0
500
LLM Observabilityによる 対話型音声AIアプリケーションの安定運用
gekko0114
2
440
今こそ知るべき耐量子計算機暗号(PQC)入門 / PQC: What You Need to Know Now
mackey0225
3
380
コマンドとリード間の連携に対する脅威分析フレームワーク
pandayumi
1
460
15年続くIoTサービスのSREエンジニアが挑む分散トレーシング導入
melonps
2
230
Featured
See All Featured
Building an army of robots
kneath
306
46k
Claude Code のすすめ
schroneko
67
210k
Fireside Chat
paigeccino
41
3.8k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
240
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
950
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
HDC tutorial
michielstock
1
390
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
55k
A designer walks into a library…
pauljervisheath
210
24k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.2k
Faster Mobile Websites
deanohume
310
31k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Transcript
5分で分かった気になるDebezium joker1007
自己紹介 joker1007 Repro inc. チーフアーキテクト 日本酒とクラフトビールが好き Asakusa.rb メンバー
今、CDCが熱い!
CDCって何? Change Data Captureの略称。 データの変更という事象を記録し、それを別の場所に転送する機能を指す。 CDCはRDBをデータソースとすると決まっている訳ではないが、今回はRDBへの変更 におけるCDCを中心に話をする。
Debeziumとは CDCを実現するためのミドルウェア。 メインターゲットはRDBだが、Cassandra, MongoDB, Spannerにも対応している。 CDCの実現方法はデータベースごとに異なる。 MySQLはレプリケーションと同様の仕組みでbinlogを読むことで行う。 PostgreSQLはlogical decodingという機能に基いている。 単体でも動作できるが、Kafka
Connectプラグインとして動作させるのが一般的。
DebeziumのCDCイベント例 ペイロードサンプルが大きいのでスライドからは割愛。 https://debezium.io/documentation/reference/2.1/connectors/mysql.html#mysql- create-events
何故CDCが必要なのか
ユースケース1 複数のデータストアでデータを同期する
複数のデータストアにデータを書くケースは良くある。 RDBとKafkaとCassandraとElasticSearchに一緒に書きたいとか、Redisの各ノードに 伝播させたいとか。 複雑なアプリケーションには必須と言っていい。
つまりこういう状態
何が問題か アプリケーション側で複数のデータストアを扱うとエラーハンドリングが非常に 複雑になる。 RDBに書いた後に通信エラーでCassandraへの書き込みが失敗したら、どこ からリトライするか。 RDBのコミットをどのタイミングで確定させるか。 順序性の問題の考慮もかなり難しい。 複数のノードに渡ってRDBに書いたのと同じ順序でCassandraに書いたと保 証できるか
Debeziumでこうなる
嬉しい点 CDCを介することで、アプリケーション処理と各種データストアへの書き込み処 理を分離できる。アプリケーションはRDBに書くだけ。 パーティショニングキーの選択が正しければ順序もRDBのトランザクションの通 りに確実に処理できる。 Kafkaのレコードを受け取って書き込む簡単なアプリを書くだけ。エラーが起きた ら1プロセス内の単純なリトライで済む。Kafka Connectで完結できるなら自分で 何かを書く必要すら無い場合もある。 複雑な制御をアプリケーションで頑張るのではなく構造とミドルウェアでカバーす
る。
その他の応用 BigQueryなどのDWHの場合はRDBと同時に即時書き込みをするのが合わないケース もある。 そういった場合に書き込みペースを容易にコントロールすることもできる。 Kafkaに貯めておいて、必要な時にまとめてloadすれば良い。
ユースケース2 マイクロサービスのトリガイベント
CDCのイベントでサービスを起動する CDCのイベントはイベント駆動マイクロサービスのトリガとして利用できる。 例えば受注ステータスの変更をRDBで更新するだけで、そのイベントを発送サービス が受け取るといったことができる。 DebeziumならKafkaに入るので、そのイベントは保存期間中は複数サービスで何度も 再取得できる。
何が嬉しいのか イベント駆動のマイクロサービスの利点は、疎結合に作り易いこと、そして複数の サービスをトリガしやすいこと。 Debeziumを介することで、アプリケーション側はRDBに書くという普通のWebアプリ ケーションと同じことをやるだけで、複数のサービスを協調して動かす基盤が出来 る。
設計上の注意 こういうアーキテクチャを採用する際は、Fire and Forgetの原則とCQRSを意識できる 様になると良い。 データの流れを大きなサイクルとして捉え、一方向にデータが流れる様に工夫するこ と。 書き込みの責任を負うのは原則一箇所のみ。 私見だが、読み書きの責任範囲が明確に分かっていれば、データストアを共有しても それなりにマイクロサービスの制御は効くと思っている。
CDCとイベントベースアーキテクチャの利点 データの変更履歴を維持しやすいため、監査性が高いシステムが構築できる (保持 し続けるのには一定のコストがかかるものの) RDBのトランザクションログがイベントソースになるため、Kafkaと組み合わせる ことでパフォーマンスと順序の整合性を両立できる。 分散トランザクションの問題を回避しつつ、スケーラブルな分散システムを構築 する基盤になる ストリーム処理へのデータ投入を意識しなくて良くなり、リードタイムの短い集 計基盤を作るための導入として最適
Railsとの相性の良さ RailsはRDBの扱いに非常に優れている。 RDBを触るだけなら正しく作れば非常にシンプルなコードになる。 アプリケーションが複雑化する要因として、ロジックとは直接関係がないデータ同期 や非同期処理のトリガ・エラーハンドリングなどの要素が少なくない。 Debeziumと組み合わせることでRailsは得意なRDBの処理に集中でき、コードがシンプ ルになる。 アプリケーションエンジニアはActiveRecordを触っているだけで、分散ストリーム基 盤へのデータ投入が可能になる。
CDCとそれを実現するDebeziumの良さを 完全に理解しましたね
CDCやKafkaを使ったデータ指向なアプリケーション を開発したくなりましたが? Reproという会社がエンジニアを募集しているらしい ですよ!