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

© 2024 Techtouch. • 名前 ◦ taisa831 / 佐藤昌基 •
所属 ◦ Techtouch株式会社 • ブログ ◦ https://taisa.super.site • 出版 ◦ Python FlaskによるWebアプリ開発入門 ◦ はじめてのフロントエンド開発自己紹介

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

5 © 2024 Techtouch. アジェンダ • マイクロサービスの切り直しをした話 ◦ なぜマイクロサービスの切り直しをしたか ◦
どうマイクロサービスの切り直しをしたか • AWS DMSを活用してDB統合した話 ◦ なぜDB統合したか ◦ どうDB統合したか • 今後の課題 • まとめ • Appendix ◦ AWS DMSで気を付けるポイント ◦ Appendixまとめ

8 © 2024 Techtouch. マイクロサービスとは引用元: マイクロサービスの概要 | AWS (amazon.com)
ビジネスドメインを中心にモデル化された、独立してリリース可能なサービス

10 © 2024 Techtouch. サービスA データベース A サービスB データベース B
プレゼンテーションサービスC データベース C なぜマイクロサービスの切り直しをしたか • テックタッチは初期の頃からマイクロサービスアーキテクチャを採用しているデプロイの単位

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

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

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

14 © 2024 Techtouch. なぜマイクロサービスの切り直しをしたか課題まとめ ◦ サービスを横断した開発が頻発するため一緒にデプロイする必要がある ◦ サービス間通信が頻発するため開発効率が悪い
◦ 分散トランザクションに対応するために難易度の高い仕組みを利用する必要がある ◦ 片方のサービスが停止した場合サービス全体に影響がでる

プレゼンテーションどうマイクロサービスの切り直しをしたか • サービスA、Bと分かれていたマイクロサービス

17 © 2024 Techtouch. モジュールA データベース B モジュールB APIゲートウェイどうマイクロサービスの切り直しをしたか
• モジュラーモノリス化 ◦ 新しくモジュールA、Bに変更したコンテナを作成したデータベース A サービスAB

18 © 2024 Techtouch. モジュールA データベース B モジュールB APIゲートウェイどうマイクロサービスの切り直しをしたか
• モジュラーモノリス化への移行 ◦ 旧サービスA、Bを残しながら加重ルーティングにてリクエストを振り分け移行した旧サービスA 旧サービスB データベース A 90% 10% 加重ルーティングサービスAB

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

20 © 2024 Techtouch. どうマイクロサービスの切り直しをしたか • 別のドメイン境界でサービスを切り直し ◦ イベントストーミングを実施し裏付け ▪
ビジネスプロセスやドメインの知識を共有、可視化、理解するプロセス

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

24 © 2024 Techtouch. なぜDB統合したか • DBがサービスA、B時代のまま分かれているのでDB周りの開発効率がよくない • RDSのコストが無駄にかかるサービスAB-main
データベース A サービスAB-reader データベース B プレゼンテーション分散トランザクション

25 © 2024 Techtouch. なぜDB統合したか • こうしたい！！！サービスAB-main データベース AB
サービスAB-reader プレゼンテーション

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

28 © 2024 Techtouch. DB統合の前提参考：https://aws.amazon.com/jp/blogs/news/webinar-bb-awsdatabasemigrationservice-2021 • Database Migration Service
（DMS）とは

31 © 2024 Techtouch. main データベース A reader データベース B
プレゼンテーションどうDB統合したか Read/Write Read Only 1. binlog有効 2. DMSでレプリケーション・スキーマ名リネーム・同一テーブル名リネーム • Phase1 ◦ DMSでレプリケーションをはる

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

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

34 © 2024 Techtouch. どうDB統合したか • こうなった！！！ main データベース AB
reader プレゼンテーションデータベース A ❌

36 © 2024 Techtouch. 今後の課題 • サービスの進化によってデータ構造が広くというより深くなってきた ◦ リレーショナルで表現するのが難しいjsonのネストが深くなってきたイメージ •
適切なデータアーキテクチャ選定で適切に事業要求とDB制約を捌いていきたい main データベース AB reader プレゼンテーション最適化最適化

38 © 2024 Techtouch. まとめ • 事業の成長に合わせてサービスのアーキテクチャをアラインしていこう！ ◦ サービスのアーキテクチャに合わせた手法を使う ◦
難しければアーキテクチャを変更するのも手 ◦ DBも含めてアーキテクチャにアラインするのは比較的困難だけど、AWS DMSを使えばやりたいことができるかも！

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

気をつけるポイント② 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

気をつけるポイント③ 同期先テーブルの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（同期失敗）

45 © 2024 Techtouch. 気をつけるポイント④ インスタンスのメモリはなかなか開放されない • フルロード時にメモリを結構使う • その後のレプリケーション中も徐々にメモリが減り続ける
• メモリ解放はDMSに依存初回フルロード時のメモリ使用量と、レプリケーション期間に使われるメモリ量を事前に確認しメモリ枯渇しないように注意しましょう！

46 © 2024 Techtouch. 気をつけるポイント⑤ CASCADEで更新されたデータは同期されない • レプリケーション中は「テーブル統計で」状況が確認できる • CASCADEで更新されたデータは「検証に失敗しました」にカウントされ、レプリケーションは止まらないが、
ターゲット側のデータが更新されない CASCADEを利用しているか事前にチェックし対策しましょう！

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

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

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

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

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

More Decks by taisa

Featured

Transcript