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
83
5分で分かった気になるDebezium
TokyuRuby会議15 発表資料
Tomohiro Hashidate
October 08, 2024
Tweet
Share
More Decks by Tomohiro Hashidate
See All by Tomohiro Hashidate
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
880
Rustで作るtree-sitterパーサーのRubyバインディング
joker1007
5
1.1k
tree-sitter-rbsで作って学ぶRBSとパーサージェネレーター
joker1007
3
260
Kafka Streamsで作る10万rpsを支えるイベント駆動マイクロサービス
joker1007
7
4.4k
neovimで作る最新Ruby開発環境2023
joker1007
2
4.3k
ReproのImport/Exportを支えるサーバーレスアーキテクチャ
joker1007
1
1.3k
Ruby on Rails on Lambda
joker1007
13
13k
Sidekiq to Kafka ストリームベースのmicro services
joker1007
4
8.9k
令和時代のRails運用
joker1007
35
15k
Other Decks in Programming
See All in Programming
SideKiqでジョブが二重起動した事象を深堀りしました
t_hatachi
0
230
読もう! Android build ドキュメント
andpad
1
240
安全に倒し切るリリースをするために:15年来レガシーシステムのフルリプレイス挑戦記
sakuraikotone
5
2.3k
令和トラベルにおけるコンテンツ生成AIアプリケーション開発の実践
ippo012
1
260
Develop Faster With FrankenPHP
dunglas
2
2.5k
WordPress Playground for Developers
iambherulal
0
120
リアクティブシステムの変遷から理解するalien-signals / Learning alien-signals from the evolution of reactive systems
yamanoku
2
1k
家族・子育て重視/沖縄在住を維持しながらエンジニアとしてのキャリアをどのように育てていくか?
ug
0
240
複数ドメインに散らばってしまった画像…! 運用中のPHPアプリに後からCDNを導入する…!
suguruooki
0
430
CTFのWebにおける⾼難易度問題について
hamayanhamayan
1
980
PHPのガベージコレクションを深掘りしよう
rinchoku
0
240
‘무차별 LGTM~👍’만 외치던 우리가 ‘고봉밥 코드 리뷰’를?
hannah0731
0
530
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
7
620
Docker and Python
trallard
44
3.3k
Agile that works and the tools we love
rasmusluckow
328
21k
Being A Developer After 40
akosma
90
590k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Optimising Largest Contentful Paint
csswizardry
35
3.2k
Adopting Sorbet at Scale
ufuk
75
9.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
The Cult of Friendly URLs
andyhume
78
6.3k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.1k
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という会社がエンジニアを募集しているらしい ですよ!