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
21
5分で分かった気になるDebezium
TokyuRuby会議15 発表資料
Tomohiro Hashidate
October 08, 2024
Tweet
Share
More Decks by Tomohiro Hashidate
See All by Tomohiro Hashidate
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
240
Rustで作るtree-sitterパーサーのRubyバインディング
joker1007
5
750
tree-sitter-rbsで作って学ぶRBSとパーサージェネレーター
joker1007
3
180
Kafka Streamsで作る10万rpsを支えるイベント駆動マイクロサービス
joker1007
7
3.1k
neovimで作る最新Ruby開発環境2023
joker1007
2
3.7k
ReproのImport/Exportを支えるサーバーレスアーキテクチャ
joker1007
1
1.2k
Ruby on Rails on Lambda
joker1007
13
12k
Sidekiq to Kafka ストリームベースのmicro services
joker1007
4
8.7k
令和時代のRails運用
joker1007
35
15k
Other Decks in Programming
See All in Programming
メルカリ ハロ アプリの技術スタック
atsumo
2
880
フロントエンドの現在地とこれから
koba04
10
4.6k
Kotlin Multiplatform at Stable and Beyond (Kotlin Vienna, October 2024)
zsmb
2
410
実践サーバーレスパフォーマンスチューニング ~その実力に迫る~ / Practical Serverless Performance Tuning ~A Close Look at its Power~
seike460
PRO
2
230
DevFest Android in Korea 2024 - 안드로이드의 문단속 : 앱을 지키는 암호화 이야기
mdb1217
1
170
Memory API: Patterns, Use Cases, and Performance
josepaumard
2
200
/←このスケジュール表に立ち向かう フロントエンド開発戦略 / A front-end development strategy to tackle a single-slash schedule.
nrslib
1
390
Subclassing, Composition, Python, and You
hynek
3
190
2024-10-01 dev2next - Observability for Modern JVM Applications
jonatan_ivanov
1
140
4年間変わらなかった YOUTRUSTのアーキテクチャ
daiki1003
2
670
ACES Meet におけるリリース作業改善の取り組み
fukucheee
0
150
Google Play Consoleデベロッパー アカウントの確認 / Verifying your Play Console developer account
kubode
0
290
Featured
See All Featured
Faster Mobile Websites
deanohume
304
30k
RailsConf 2023
tenderlove
28
860
The Straight Up "How To Draw Better" Workshop
denniskardys
232
130k
Being A Developer After 40
akosma
85
590k
YesSQL, Process and Tooling at Scale
rocio
167
14k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
5
130
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
A Philosophy of Restraint
colly
203
16k
How to train your dragon (web standard)
notwaldorf
87
5.6k
Building Your Own Lightsaber
phodgson
102
6k
A designer walks into a library…
pauljervisheath
202
24k
Pencils Down: Stop Designing & Start Developing
hursman
119
11k
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という会社がエンジニアを募集しているらしい ですよ!