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
Tomohiro Hashidate
October 08, 2024
Programming
1
130
5分で分かった気になるDebezium
TokyuRuby会議15 発表資料
Tomohiro Hashidate
October 08, 2024
Tweet
Share
More Decks by Tomohiro Hashidate
See All by Tomohiro Hashidate
rubygem開発で鍛える設計力
joker1007
3
980
実践Kafka Streams 〜イベント駆動型アーキテクチャを添えて〜
joker1007
3
1.1k
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
1.1k
Rustで作るtree-sitterパーサーのRubyバインディング
joker1007
5
1.4k
tree-sitter-rbsで作って学ぶRBSとパーサージェネレーター
joker1007
3
300
Kafka Streamsで作る10万rpsを支えるイベント駆動マイクロサービス
joker1007
7
4.8k
neovimで作る最新Ruby開発環境2023
joker1007
3
4.5k
ReproのImport/Exportを支えるサーバーレスアーキテクチャ
joker1007
1
1.3k
Ruby on Rails on Lambda
joker1007
13
13k
Other Decks in Programming
See All in Programming
チームのテスト力を鍛える
goyoki
3
830
Cache Me If You Can
ryunen344
2
3k
Putting The Genie in the Bottle - A Crash Course on running LLMs on Android
iurysza
0
140
個人開発で徳島大学生60%以上の心を掴んだアプリ、そして手放した話
akidon0000
1
130
Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ
inetand
0
2.4k
Laravel Boost 超入門
fire_arlo
3
220
Android 16 × Jetpack Composeで縦書きテキストエディタを作ろう / Vertical Text Editor with Compose on Android 16
cc4966
2
260
AIを活用し、今後に備えるための技術知識 / Basic Knowledge to Utilize AI
kishida
22
5.9k
Azure SRE Agentで運用は楽になるのか?
kkamegawa
0
2.5k
今だからこそ入門する Server-Sent Events (SSE)
nearme_tech
PRO
3
250
Reading Rails 1.0 Source Code
okuramasafumi
0
250
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
azukiazusa1
24
12k
Featured
See All Featured
Navigating Team Friction
lara
189
15k
Designing for Performance
lara
610
69k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Docker and Python
trallard
46
3.6k
It's Worth the Effort
3n
187
28k
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という会社がエンジニアを募集しているらしい ですよ!