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
950
実践Kafka Streams 〜イベント駆動型アーキテクチャを添えて〜
joker1007
3
1.1k
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
1k
Rustで作るtree-sitterパーサーのRubyバインディング
joker1007
5
1.3k
tree-sitter-rbsで作って学ぶRBSとパーサージェネレーター
joker1007
3
290
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
学習を成果に繋げるための個人開発の考え方 〜 「学習のための個人開発」のすすめ / personal project for leaning
panda_program
1
110
Vibe coding コードレビュー
kinopeee
0
460
Understanding Ruby Grammar Through Conflicts
yui_knk
1
120
STUNMESH-go: Wireguard NAT穿隧工具的源起與介紹
tjjh89017
0
380
大規模FlutterプロジェクトのCI実行時間を約8割削減した話
teamlab
PRO
0
490
フロントエンドのmonorepo化と責務分離のリアーキテクト
kajitack
2
130
Laravel Boost 超入門
fire_arlo
1
110
【第4回】関東Kaggler会「Kaggleは執筆に役立つ」
mipypf
0
710
コーディングは技術者(エンジニア)の嗜みでして / Learning the System Development Mindset from Rock Lady
mackey0225
2
560
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
160
サーバーサイドのビルド時間87倍高速化
plaidtech
PRO
0
440
GUI操作LLMの最新動向: UI-TARSと関連論文紹介
kfujikawa
0
1k
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.7k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
20k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
820
Designing for humans not robots
tammielis
253
25k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Site-Speed That Sticks
csswizardry
10
780
Measuring & Analyzing Core Web Vitals
bluesmoon
9
560
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という会社がエンジニアを募集しているらしい ですよ!