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

ビジネスを止めずに システムリプレースを 進める為のCDCという 選択肢 2024-10-12 Open Source Conference 2024 Nagaoka

INDEX 目次 01 自己紹介 02 システムリプレースの目的 03 CDCの紹介 04 最後に

01 自己紹介 高橋 一騎 ( @ikkitang) ・ Webアプリケーションエンジニア(12年目) ・ バックエンドエンジニア | テックリード ・ 日本PostgreSQLユーザー会 中国地方支部長 ・ 妻と息子と娘と岡山在住 TakahashiIkki TakahashiIkki ikkitang ikkitang

01 宣伝 (1) 2024年10月19日 (土) オープンセミナー岡山 https://okayama.open-seminar.org/ メインテーマは 「のびしろ」 『のびしろを広げる巻き込まれ力： 偶然を活かすキャリアの作り方』 高橋が講演予定!!

• https://okayama.open-seminar.org/

01 宣伝 (2) 2024年12月06日 (金) PostgreSQL Conference Japan 2024 https://www.postgresql.jp/jpug-pgcon2024 PostgreSQLをテーマにカンファレンス を開催します。 絶賛チケット販売中！！

• https://www.postgresql.jp/jpug-pgcon2024

01 宣伝 (3) (不定期) PostgreSQL アンカンファレンス https://pgunconf.connpass.com/ オフライン or オンラインで PostgreSQLをテーマに勉強会を開催 1セッションが10~20分と短くて 参加や聴講などが気軽にできます

• https://pgunconf.connpass.com/

02 システムリプレースの目的

02 システムリプレースとは システムリプレース 既存のシステム（サービス）やソフトウェアを新しいシステムやソフトウェアに 置き換える事を指す システムリプレースの手法として、 徐々に新システムに移行するフェーズアプローチと 一度にすべてのシステムを新しいものに切り替えるビッグバンアプローチがある システムの規模感によって、手法を選択する。

02 システムリプレースとは システムリプレース 既存のシステム（サービス）やソフトウェアを新しいシステムやソフトウェアに 置き換える事を指す 今日はこっち システムリプレースの手法として、 徐々に新システムに移行するフェーズアプローチと 一度にすべてのシステムを新しいものに切り替えるビッグバンアプローチがある システムの規模感によって、手法を選択する。

02 システム開発のジレンマ サービス開始から複数年が経過して、コードベースが大きい 作った人が退職してもう居なくて、何故この機能があるのかが分か らない 機能リリース優先で作られた為、どこかを修正すればどんな影響が 発生するか分からない 色んな要因によって事業成長のスピードが妨げられてしまう

02 システム開発のジレンマ 予約レコード ゲスト会員予約は 撤廃されてて カラムは使ってない 予約ID ... 性別 ゲスト会員 フラグ 1 ... “男性” 1 2 ... “女性” 0 ... ... ... ... ... “1” 0 1000 性別の書式が 定まってない

02 フェーズアプローチを選ぶ 今後の事業の成長の為にも日々機能開発は行いたい vs 機能開発を妨げる要因が沢山ある 開発の限られたリソースを 全てシステムリプレースに割り当てる事はできない。 ので、一部ずつ切り替えながらやる フェーズアプローチを選ぶ

02 システムリプレースをやる 何のためにシステムリプレースをするのか 機能開発を阻害する要因を取り除く 技術部分の老朽化・パフォーマンス向上に対応する EoLを迎えたのでバージョンアップとか 運用コストを削減する 運用を再度見直す

02 システムリプレースをやる フレームワークのバージョンを上げる！ TypeScript ( or Go or Rust ) で書き直す！ SPA化して、Reactを採用する！ 開発のしやすさが上がって、価値提供までの速度は上がるが 一方で「キレイな旧システム」を作ってしまう可能性もある

02 システムリプレースをやる 例えばこういうパターン → クーポンには審査の概念があり、 承認されたクーポンのみを使う事が できる（というコード） 移植自体は簡単ではあるが、ヒアリング すると、現在はクーポンの承認フローは 無くて特に見ずに承認しているという 背景があった

02 システムリプレースをやる システムリプレースとして クーポンの承認フローを消す方針を取る 運用フローの改善をする コードの認知不可を削減する といったメリットが生まれる

02 システムリプレースをやる システムの振る舞いを変えない システムリファクタリングではなくて システムの振る舞いを見直して置き換える システムリプレースをやる 要件定義・要求定義コストをかけても 中長期で運用コストを減らして皆が嬉しいシステムを作っていく

03 CDCの紹介

03 フェーズアプローチを進める フェーズアプローチは一部ずつ切り替えながら進めていく手法なので 旧システムとリプレースさせた新システムが平行稼働する データベースをリモデリングしたいけどその場合は？ 結局、旧システムからも書き込みをしないといけない？ ↑極力、旧システムには手をいれずに連携を取りたい ... !!!

03 CDC そこでCDCを採用してみる

03 CDC CDC : Change Data Capture データベースの変更（ Insert / Update / Delete ) を検知し 別のアプリケーションに伝達する為の技術や手法 採用事例 食べログさん： ElasticSearch Indexのリアルタイム更新 Chatworkさん： CQRSモデルの更新 オミカレさん： DBリファクタリングの実践

03 CDC 伝搬 更新SQL 旧システム DB イベント / メッセージ 伝 搬 新システム DB 新システム

03 CDC 伝搬 更新SQL 旧システム DB イベント / メッセージ 伝 搬 新システム DB ここが CDC 新システム

03 トリガーベースのCDC 名著 『データベース・リファクタリング』 でも紹介されている手法 新カラム（新テーブル）を追加 トリガーを用いて旧カラムの書き込みを検知して新カラムを更新 新カラムから読むようにコードを変更する 新カラムへ書き込むようにコードを変更する 旧カラムとトリガーを削除する

03 トリガーベースのCDC メリット SQL標準でも規定されており、ほとんどのDBMSで利用可能 各DBMS毎に方言・仕様がある デメリット データベースに追加の負荷が掛かる トランザクション処理にも影響がある ( ※ 後述 ) SQLで書く必要がある（好みによりそう） PostgreSQLなら 他言語で書ける （ざっと調べた感じ、テスト手法があんまり確立されてなさそう）

03 トリガーベースのCDC トランザクションの確定前に トリガーが順に実行される before insert トリガー users ↑ 設定のとき... after insert トリガー before トリガー Begin app側で 右のような 処理をする Insert SQL Insert SQL Commit after トリガー

03 トリガーベースのCDC トランザクションの確定前に トリガーが順に実行される before insert トリガー users ↑ 設定のとき... after insert トリガー before トリガー Begin app側で 右のような 処理をする Insert SQL Insert SQL Commit after トリガー beforeトリガー や after トリガー で 失敗すると Insert SQL 全体が ロールバックされてしまう

03 ログベースのCDC データベースのトランザクションログを直接読み取る手法 一般的にはサポートするツールを導入する手法が取られる Debezium / AWS DMS / Azure Data Factory / GoldenGate ... 各RDBMS固有のトランザクションログを出力する設定を有効化する 上記ツールのセットアップを行う

03 ログベースのCDC メリット 処理を別アプリケーションに切り出す事ができるので、 追加のオーバーヘッドが発生しない。 デメリット 各ツールの運用をキャッチアップする必要がある Debezium → AWSのマネージドサービスを使用するなら 一部制限がある AWS DMS → ローカルで開発環境を構成できない (僕調べ)

03 ログベースのCDC 監視 監視 debezium users ↑ 設定のとき... users 監視 Consumer トランザクションは Insert SQL が成功すれば コミットされる Begin users 監視 Consumer Begin app側で 右のような 処理をする Insert SQL リファクタリング Insert SQL Commit Commit users 監視 Consumer は 別ライフサイクルで トランザクションを実行する

03 ログベースのCDC 監視 監視 debezium users ↑ 設定のとき... users 監視 Consumer トランザクションは Insert SQL が成功すれば コミットされる Begin users 監視 Consumer Begin app側で 右のような 処理をする Insert SQL リファクタリング Insert SQL Commit users 監視 Consumer は 別ライフサイクルで トランザクションを実行する Commit ※ 詳しくは後ほど

03 CDC 手法まとめ トリガーベース ログベース データベースのトリガーを 使用して変更を検出する手法 データベースのトランザクシ ョンログを直接監視する手法 メリット ほとんどのDBMSで利用可能 追加の負荷を最小限に 抑える事ができる デメリット データベースの動作に追加の オーバーヘッドが発生する セットアップの複雑性 手法

03 ログベースを支えるツール ログベースのCDCを実践するソフトウェアとして 以下2種類の経験があります AWS DMS Debezium

03 AWS DMS AWS DMS ( Database Migration Service ) データストアから別のデータストアへ移行できるようにするサービス 移行元をソース / 移行先をターゲットという ソースやターゲットとして主要なRDBMSをサポート（オンプレやS3とかも対象） 特徴 フルマネージドサービスなので管理が楽 ( Terraformなどでも管理できる） データ移行ツール なので アプリケーションを起動させるとかは一工夫必要

03 AWS DMSの実例 別DB間のデータ移行 Kafkaに書いて Consumerを動かす ..... MySQL AWS DMS MySQL Database AWS DMS Kafka Consumer S3に書いてLambdaを動かす 異種DB間のデータ移行 MySQL AWS DMS PostgreSQL Database AWS DMS S3 Lambda

03 Debezium Debezium Kafka Connect を仕様してログベースのCDCを実装するためのツール ソースとして複数のRDBMSをサポート 特徴 AWSで使用する際、Kafka Connectの設定をいじるRESTエンドポイントが無いので 細かい調整が難しい Kafkaの仕様に乗っかれるので自由度は高い

03 Apache Kafka Apache Kafka オープンソースの分散型イベントストリーミングプラットフォーム 大量のメッセージを高速に処理する為に作られた分散メッセージシステム ※解説しだすとめっちゃ時間かかるのでほどほどに ... 特徴 メッセージに対してイベントを発生させる際に少なくとも一回、成功保証を持つ 非常に高速に動作する 高可用性を担保できる

03 MySQL Debezium Debezium ..... Consumer部分は 実質的には制限が無いので 自由度の高いアプリケーションが 実装できる Consumer データベースのリファクタリングしたり イベントを受け取ってメールしたり ... etc Kafka

03 Debeziumの使い方イメージ 以下のconfigを Debeziumに設定する アプリケーション側で以下のJSONが得られる

03 Debeziumの使い方 くわしくはこちら https://zenn.dev/stafes_blog/articles/ikkitang-691e9913644952

• https://zenn.dev/stafes_blog/articles/ikkitang-691e9913644952

04 最後に

04 最後に システムリプレースでは、ソフトウェアは捨てる事ができても データを捨て去る事は難しい CDCという手法が困難なシステムリプレースに 立ち向かう一助と慣れれば幸いです 一方でシステムリプレースは何のためを常に自問自答していきましょう

ご清聴ありがとうございました