ビジネスを止めずにシステムリプレースを進める為のCDCという選択肢/osc24ng-2-b

Open Source Conference 2024 Nagaoka で発表した発表資料です。

https://ospn.connpass.com/event/325425/

私はキャリアの中で、多くのシステムリプレースに携わってきました。リソースが限られる中、開発を可能な限り止めずに並行稼働しながらリプレースを成功させるために、CDC（チェンジデータキャプチャ）を採用した手法をご紹介します。具体的には、Debeziumを使った実践例を通じて、Webアプリケーション開発者向けに効果的な方法をお伝えします。

対象者:
- Webアプリケーション開発者
- スタートアップなどにお勤めのシステムエンジニアの方

Transcript

1. ビジネスを止めずに システムリプレースを 進める為のCDCという 選択肢 2024-10-12 Open Source Conference 2024 Nagaoka
2. 自己紹介 01 システムリプレースの目的 02 CDCの紹介 03 最後に 04 目次 INDEX
3. ・ Webアプリケーションエンジニア(12年目) ・ バックエンドエンジニア | テックリード ・ 日本PostgreSQLユーザー会 中国地方支部長 ・ 妻と息子と娘と岡山在住 自己紹介 01 高橋 一騎 (@ikkitang) TakahashiIkki TakahashiIkki ikkitang ikkitang
4. 宣伝 (1) 01 2024年10月19日 (土) オープンセミナー岡山 https://okayama.open-seminar.org/ メインテーマは 「のびしろ」 『のびしろを広げる巻き込まれ力：　 偶然を活かすキャリアの作り方』 高橋が講演予定!!
5. 宣伝 (2) 01 2024年12月06日 (金) PostgreSQL Conference Japan 2024 https://www.postgresql.jp/jpug-pgcon2024 PostgreSQLをテーマにカンファレンス を開催します。 絶賛チケット販売中！！
6. 宣伝 (3) 01 (不定期) PostgreSQL アンカンファレンス https://pgunconf.connpass.com/ オフライン or オンラインで PostgreSQLをテーマに勉強会を開催 1セッションが10~20分と短くて 参加や聴講などが気軽にできます
7. システムリプレースの目的 02
8. システムリプレースとは 02 システムリプレース 既存のシステム（サービス）やソフトウェアを新しいシステムやソフトウェアに 置き換える事を指す システムリプレースの手法として、 徐々に新システムに移行するフェーズアプローチと 一度にすべてのシステムを新しいものに切り替えるビッグバンアプローチがある システムの規模感によって、手法を選択する。
9. システムリプレース 既存のシステム（サービス）やソフトウェアを新しいシステムやソフトウェアに 置き換える事を指す システムリプレースの手法として、 徐々に新システムに移行するフェーズアプローチと 一度にすべてのシステムを新しいものに切り替えるビッグバンアプローチがある システムの規模感によって、手法を選択する。 システムリプレースとは 02 今日はこっち
10. サービス開始から複数年が経過して、コードベースが大きい 作った人が退職してもう居なくて、何故この機能があるのかが分か らない 機能リリース優先で作られた為、どこかを修正すればどんな影響が 発生するか分からない 色んな要因によって事業成長のスピードが妨げられてしまう システム開発のジレンマ 02
11. 予約ID ... 性別 ゲスト会員 フラグ 1 ... “男性” 1 2 ... “女性” 0 ... ... ... ... 1000 ... “1” 0 システム開発のジレンマ 02 予約レコード ゲスト会員予約は 撤廃されてて カラムは使ってない 性別の書式が 定まってない
12. 今後の事業の成長の為にも日々機能開発は行いたい vs 機能開発を妨げる要因が沢山ある 開発の限られたリソースを 全てシステムリプレースに割り当てる事はできない。 ので、一部ずつ切り替えながらやる フェーズアプローチを選ぶ フェーズアプローチを選ぶ 02
13. 何のためにシステムリプレースをするのか 機能開発を阻害する要因を取り除く 技術部分の老朽化・パフォーマンス向上に対応する EoLを迎えたのでバージョンアップとか 運用コストを削減する 運用を再度見直す システムリプレースをやる 02
14. フレームワークのバージョンを上げる！ TypeScript ( or Go or Rust ) で書き直す！ SPA化して、Reactを採用する！ 開発のしやすさが上がって、価値提供までの速度は上がるが 一方で「キレイな旧システム」を作ってしまう可能性もある システムリプレースをやる 02
15. 例えばこういうパターン → クーポンには審査の概念があり、 　 承認されたクーポンのみを使う事が できる（というコード） 移植自体は簡単ではあるが、ヒアリング すると、現在はクーポンの承認フローは 無くて特に見ずに承認しているという　 背景があった システムリプレースをやる 02
16. システムリプレースとして クーポンの承認フローを消す方針を取る 運用フローの改善をする コードの認知不可を削減する といったメリットが生まれる システムリプレースをやる 02
17. システムの振る舞いを変えない システムリファクタリングではなくて システムの振る舞いを見直して置き換える システムリプレースをやる 要件定義・要求定義コストをかけても 中長期で運用コストを減らして皆が嬉しいシステムを作っていく システムリプレースをやる 02
18. CDCの紹介 03
19. フェーズアプローチは一部ずつ切り替えながら進めていく手法なので 旧システムとリプレースさせた新システムが平行稼働する データベースをリモデリングしたいけどその場合は？ 結局、旧システムからも書き込みをしないといけない？ ↑極力、旧システムには手をいれずに連携を取りたい ... !!! フェーズアプローチを進める 03
20. そこでCDCを採用してみる CDC 03
21. CDC : Change Data Capture データベースの変更（ Insert / Update / Delete ) を検知し　　 別のアプリケーションに伝達する為の技術や手法 採用事例 食べログさん： ElasticSearch Indexのリアルタイム更新 Chatworkさん： CQRSモデルの更新 オミカレさん： DBリファクタリングの実践 CDC 03
22. 伝搬 伝 搬 CDC 03 旧システム DB 新システム DB 新システム イベント / メッセージ 更新SQL
23. 伝搬 伝 搬 CDC 03 旧システム DB 新システム DB 新システム イベント / メッセージ 更新SQL ここが CDC
24. 名著 『データベース・リファクタリング』 でも紹介されている手法 新カラム（新テーブル）を追加 トリガーを用いて旧カラムの書き込みを検知して新カラムを更新 新カラムから読むようにコードを変更する 新カラムへ書き込むようにコードを変更する 旧カラムとトリガーを削除する トリガーベースのCDC 03
25. メリット SQL標準でも規定されており、ほとんどのDBMSで利用可能 各DBMS毎に方言・仕様がある デメリット データベースに追加の負荷が掛かる トランザクション処理にも影響がある ( ※ 後述 ) SQLで書く必要がある（好みによりそう） PostgreSQLなら 他言語で書ける （ざっと調べた感じ、テスト手法があんまり確立されてなさそう） トリガーベースのCDC 03
26. users before insert トリガー after insert トリガー Begin Commit トリガーベースのCDC 03 Insert SQL before トリガー after トリガー Insert SQL トランザクションの確定前に トリガーが順に実行される ↑ 設定のとき... app側で 右のような 処理をする
27. users before insert トリガー after insert トリガー Begin Commit after トリガー トリガーベースのCDC 03 Insert SQL before トリガー Insert SQL トランザクションの確定前に トリガーが順に実行される ↑ 設定のとき... app側で 右のような 処理をする beforeトリガー や after トリガー で 失敗すると Insert SQL 全体が ロールバックされてしまう
28. データベースのトランザクションログを直接読み取る手法 一般的にはサポートするツールを導入する手法が取られる Debezium / AWS DMS / Azure Data Factory / GoldenGate ... 各RDBMS固有のトランザクションログを出力する設定を有効化する 上記ツールのセットアップを行う ログベースのCDC 03
29. メリット 処理を別アプリケーションに切り出す事ができるので、 　　　　　 追加のオーバーヘッドが発生しない。 デメリット 各ツールの運用をキャッチアップする必要がある Debezium → AWSのマネージドサービスを使用するなら　　　　　　 　　　　　　　　　 一部制限がある AWS DMS → ローカルで開発環境を構成できない (僕調べ) ログベースのCDC 03
30. Begin Commit 監視 users debezium ログベースのCDC 03 Insert SQL トランザクションは Insert SQL が成功すれば コミットされる ↑ 設定のとき... app側で 右のような 処理をする 監視 users 監視 Consumer Insert SQL users 監視 Consumer Begin Commit リファクタリング users 監視 Consumer は 別ライフサイクルで トランザクションを実行する
31. Begin Commit 監視 users debezium ログベースのCDC 03 Insert SQL トランザクションは Insert SQL が成功すれば コミットされる ↑ 設定のとき... app側で 右のような 処理をする 監視 users 監視 Consumer Insert SQL users 監視 Consumer Begin Commit リファクタリング users 監視 Consumer は 別ライフサイクルで トランザクションを実行する ※ 詳しくは後ほど
32. CDC 手法まとめ 03 トリガーベース ログベース 手法 データベースのトリガーを 使用して変更を検出する手法 データベースのトランザクシ ョンログを直接監視する手法 メリット ほとんどのDBMSで利用可能 追加の負荷を最小限に 抑える事ができる デメリット データベースの動作に追加の オーバーヘッドが発生する セットアップの複雑性
33. ログベースのCDCを実践するソフトウェアとして 以下2種類の経験があります AWS DMS Debezium ログベースを支えるツール 03
34. AWS DMS 03 AWS DMS ( Database Migration Service ) データストアから別のデータストアへ移行できるようにするサービス 移行元をソース / 移行先をターゲットという ソースやターゲットとして主要なRDBMSをサポート（オンプレやS3とかも対象） 特徴 フルマネージドサービスなので管理が楽 ( Terraformなどでも管理できる） データ移行ツール なので アプリケーションを起動させるとかは一工夫必要
35. AWS DMSの実例 03 MySQL MySQL AWS DMS 別DB間のデータ移行 MySQL PostgreSQL AWS DMS 異種DB間のデータ移行 Kafkaに書いて Consumerを動かす Database AWS DMS Kafka ..... Consumer S3に書いてLambdaを動かす Database AWS DMS S3 Lambda
36. Debezium Kafka Connect を仕様してログベースのCDCを実装するためのツール ソースとして複数のRDBMSをサポート 特徴 AWSで使用する際、Kafka Connectの設定をいじるRESTエンドポイントが無いので　 細かい調整が難しい Kafkaの仕様に乗っかれるので自由度は高い Debezium 03
37. Apache Kafka オープンソースの分散型イベントストリーミングプラットフォーム 大量のメッセージを高速に処理する為に作られた分散メッセージシステム ※解説しだすとめっちゃ時間かかるのでほどほどに ... 特徴 メッセージに対してイベントを発生させる際に少なくとも一回、成功保証を持つ 非常に高速に動作する 高可用性を担保できる Apache Kafka 03
38. Debezium 03 Kafka ..... Consumer MySQL Debezium Consumer部分は 実質的には制限が無いので 自由度の高いアプリケーションが 実装できる データベースのリファクタリングしたり イベントを受け取ってメールしたり ... etc
39. Debeziumの使い方イメージ 03 以下のconfigを Debeziumに設定する アプリケーション側で以下のJSONが得られる
40. Debeziumの使い方 03 https://zenn.dev/stafes_blog/articles/ikkitang-691e9913644952 くわしくはこちら
41. 最後に 04
42. システムリプレースでは、ソフトウェアは捨てる事ができても データを捨て去る事は難しい CDCという手法が困難なシステムリプレースに 立ち向かう一助と慣れれば幸いです 一方でシステムリプレースは何のためを常に自問自答していきましょう 最後に 04
43. ご清聴ありがとうございました