Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

CDCの紹介 03

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

最後に 04

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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