事業の成長にDBアーキテクチャをアラインするために AWS Database Migration Service (DMS) を活用した話

by taisa

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

すべてのユーザーがシステムを使いこなせる世界にシステム導入だけで終わらせない、利活用のためのDXプラットフォーム

Slide 4

Slide 4 text

すべてのユーザーがシステムを使いこなせる世界にシステム導入だけで終わらせない、利活用のためのDXプラットフォーム

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

11 © 2024 Techtouch. サービスA データベース A サービスB データベース B プレゼンテーションサービスC データベース C なぜマイクロサービスの切り直しをしたか ● 事業の成長とともに環境が変化し、ドメイン境界が初期の思想と変わってきた ○ サービスAとサービスBが疎結合ではなくなってきた（分散モノリス状態）デプロイの単位サービスA、B両方デプロイするケースが多い開発でサービス横断サービス間通信分散トランザクション

Slide 12

Slide 12 text

12 © 2024 Techtouch. サービスA データベース A サービスB データベース B プレゼンテーションなぜマイクロサービスの切り直しをしたか ● 分散モノリス状態とは ○ 複数のサービスで構成されているものの、何らかの理由でシステム全体が一緒にデプロイされなければならなくなっているシステムのことサービス横断した開発サービス間通信分散トランザクションサービスA、B両方デプロイするケースが多い

Slide 13

Slide 13 text

13 © 2024 Techtouch. サービスA データベース A サービスB データベース B プレゼンテーションなぜマイクロサービスの切り直しをしたか ● 分散モノリス状態とは ○ 複数のサービスで構成されているものの、何らかの理由でシステム全体が一緒にデプロイされなければならなくなっているシステムのことサービス横断した開発サービス間通信分散トランザクションサービスA、B両方デプロイするケースが多い分散システムの全ての欠点と単一プロセスモノリスの欠点を持ち、どちらの利点も十分には持たない。

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

19 © 2024 Techtouch. どうマイクロサービスの切り直しをしたか ● 別のドメイン境界でサービスを切り直し ○ サービスの特性上「サービスAB-main」「サービスAB-reader」（便宜上 main, reader とします）といった別ドメインでサービスを切った方がよいことが明らかになってきたモジュールA データベース B モジュールB APIゲートウェイデータベース A サービスAB 別ドメイン境界 main reader

Slide 20

Slide 20 text

Slide 21

Slide 21 text

21 © 2024 Techtouch. どうマイクロサービスの切り直しをしたか ● 切り直し後はサービスの独立性が高まり、マイクロサービスの利点の多くが享受できるように ○ サービスを横断した開発がなくなり独立デプロイ可能になったり、スケールアウトしやすくなったり、サービス間通信減らせたり main データベース A reader データベース B プレゼンテーション分散トランザクション ❌ サービス横断した開発サービス間通信分散トランザクション一見複雑になったようにも見えるが

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

27 © 2024 Techtouch. DB統合の前提 ● やりたいこと ○ 別々のスキーマから同一スキーマにDBを統合したい ● 制約 ○ それぞれのDBに同じ名前のテーブル名が存在するのでテーブル名をリネームする必要がある ● DBの特徴（Aurora MySQL 2.x）※1 ○ Auroraのレプリケーション機能を利用しようとしたが利用しているバージョンではテーブル単位のレプリケーションができなかったため断念（MySQLのユーザー情報等も同期されてしまう） ● サービスの特性 ○ サービスAB-main ■ 夜間メンテナンス可 ○ サービスAB-reader ■ 無停止でDB統合したい　上記の前提条件をクリアするために AWS DMSを利用してDB統合することにした！ ※1 参考: https://dev.mysql.com/doc/refman/5.7/en/binary-log-mysql-database.html

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

32 © 2024 Techtouch. main データベース A reader データベース B プレゼンテーションどうDB統合したか Read/Write Read Only binlog有効 1.コネクションをデータベースBに切り替える ❌ DMSでレプリケーション・スキーマ名リネーム・同一テーブル名リネーム ● Phase2 ○ readerのコネクションをデータベースBに切り替える（無停止）

Slide 33

Slide 33 text

33 © 2024 Techtouch. main データベース A reader データベース B プレゼンテーションどうDB統合したか Read/Write Read Only 2.DMSレプリケーション停止 1.メンテナンスで書き込みを止める ❌ ❌ 3.向き先をデータベースBに切り替える ● Phase3 ○ メンテナンスにより書き込みをとめ、mainのDBのむき先をデータベースBに切り替える

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

42 © 2024 Techtouch. データベース A データベース B DMS インスタンス気をつけるポイント① 外部キー制約やインデックスなどのメタデータは同期されない AWS DMS ● DMSはテーブル作成からレプリまでしてくれる設定がある ○ 外部キー制約やインデックスなどのメタデータは同期されないメタデータが必要な場合は事前にテーブルを作成しておきましょう！ create table if not exists drop table & create table truncate ・index ・外部キー・index ・外部キー →自動で作成されない Source Target

Slide 43

Slide 43 text

43 © 2024 Techtouch. データベース A データベース B DMS インスタンス気をつけるポイント② Max LOB サイズを適切に設定しないとデータが切り捨てられる AWS DMS ● LOB（Large Object）とは ○ データベースにおいて扱われる巨大なデータを表す用語（BLOB、CLOB、XLOB） ○ LOB列設定は制限付きLOBモードが推奨、最大LOBサイズを設定する・CLOB（json etc) ・BLOB（binary）・XLOB（xml）下記SQLでLOBカラムの最大値をチェックしましょう！・CLOB（json etc) ・BLOB（binary）・XLOB（xml） →切り捨て Source Target

Slide 44

Slide 44 text

44 © 2024 Techtouch. データベース A データベース B DMS インスタンス気をつけるポイント③ 同期先テーブルのLOBカラムはNOT NULL制約があると同期失敗する AWS DMS ● LOBカラムの同期は最初にNULLとなり、あとからデータが同期される動きとなる同期先テーブルのLOBカラムはNOT NULL制約をはずしましょう！参照：https://e-words.jp/w/LOB-1.html Source Target ・CLOB（json etc) ・BLOB（binary）・XLOB（xml） → NOT NULL（OK）・CLOB（json etc) ・BLOB（binary）・XLOB（xml） →NOT NULL（同期失敗）

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

47 © 2024 Techtouch. 気をつけるポイント⑥ フルロード時のtoo many connections発生に要注意 ● 並列にロードするテーブルの最大数のデフォルトは「8」 ● 開発環境は特にコネクション数が少ないので検証中は簡単にtoo many connectionsが発生します本番のDBコネクションを使い切るリスクがあるので事前にコネクション数チェックをしチューニングをしましょう！

Slide 48

Slide 48 text

48 © 2024 Techtouch. Appendix まとめ ● DMS は柔軟に設定ができて便利な一方躓きポイントが結構あるので要注意 ● 実際に利用する際は下記内容に注意してみてください 1. 外部キー制約やインデックスなどのメタデータは同期されない 2. Max LOB サイズを適切に設定しないと同期に失敗する 3. 同期先テーブルのLOBカラムはNOT NULL制約があると同期失敗する 4. インスタンスのメモリはなかなか解放されない 5. CASCADEで更新されたデータは同期されない 6. フルロード時のtoo many connections発生に要注意

Slide 49

Slide 49 text

すべてのユーザーがシステムを使いこなせる世界にシステム導入だけで終わらせない、利活用のためのDXプラットフォームご清聴ありがとうございました。