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

>100 Views

October 20, 24

スライド概要

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

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

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

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

ikkitang

@ikkitang938

スライド一覧

岡山でWebサービスを作っています

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

ダウンロード(pdf - 5.54MB)

各ページのテキスト

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

03 CDCの紹介

19.

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

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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

30.

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

31.

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

32.

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

33.

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

34.

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

35.

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

36.

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

37.

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

38.

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

39.

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

40.

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