AWS Database Migration Serviceを使って無停止でDB統合※読み込み側だけだよー📢

Transcript

1. © 2024 Techtouch. AWS Database Migration Service を使って
 無停止でDB統合 ※読み込み側だけだよー📢

2. すべてのユーザーが システムを使いこなせる世界に システム導入だけで終わらせない、利活用のためのDXプラットフォーム
3. すべてのユーザーが システムを使いこなせる世界に システム導入だけで終わらせない、利活用のためのDXプラットフォーム
4. 4 © 2024 Techtouch. Database Migration Service とは 参考：https://aws.amazon.com/jp/blogs/news/webinar-bb-awsdatabasemigrationservice-2021
5. © 2024 Techtouch. なぜDBを統合するにいたったか

6. 6 © 2024 Techtouch. なぜDBを統合するにいたったか - マイクロサービスでサービスを運用している - 一部のサービスが分散モノリス状態であった - モジュラーモノリスへ変更 - 別ドメインでサービス切り直し - 変更した結果 - DBが分かれたままなので開発効率はそこまであがらない - DB※RDSを統合することとした 👈 ココ
7. 7 © 2024 Techtouch. 変更後の構成 なぜDBを統合するにいたったか
8. 8 © 2024 Techtouch. なぜDBを統合するにいたったか - 変更後の構成 - main - Read/Write - viewer - Read Only - 課題 - DBが分かれたままなので開発効率はそこまであがらない - 分散トランザクション問題は残ったまま → DB統合しよう！！
9. © 2024 Techtouch. 前提

10. 10 © 2024 Techtouch. 前提 - やりたいこと - 同一スキーマにDBを統合したい - 制約 - それぞれのDBに同じ名前のテーブル名が存在する - テーブル名をリネームする必要がある
11. 11 © 2024 Techtouch. 前提 - DBの特徴 - 最初Aurora MySQL 2.xのレプリケーション機能を利用しようとした が利用しているバージョンではテーブル単位のレプリケーションがで きなかったため断念 — Aurora MySQL 2.x のバイナリログレプリケーションでは information_schema, performance_schema, mysql データベース上の Aurora の管理テーブルを除く、すべ てのデータベースの変更がレプリケーションされる (ソースのバイナリログに書き込まれ る) 動作となる 参照：https://dev.mysql.com/doc/refman/5.7/en/binary-log-mysql-database.html
12. 12 © 2024 Techtouch. 前提 - サービスの特性 - main - 夜間メンテナンス可 - viewer - メンテナンス入れたくない！
13. © 2024 Techtouch. 統合プロセス

14. 14 © 2024 Techtouch. 統合プロセス
15. 15 © 2024 Techtouch. 統合プロセス
16. 16 © 2024 Techtouch. 統合プロセス
17. © 2024 Techtouch. DMS設定

18. 18 © 2024 Techtouch. DMS設定
19. 19 © 2024 Techtouch. DMS設定
20. © 2024 Techtouch. DMSで気をつけるポイント

21. 21 © 2024 Techtouch. 気をつけるポイント① 外部キー制約やインデックスなどのメタデータは同期されない - DMSはテーブル作成からレプリまでしてくれる設定がある - 外部キー制約やインデックスなどのメタデータは同期されない メタデータが必要な場合は事前にテーブルを作成しておきましょう！ create table if not exists drop & create truncate
22. 22 © 2024 Techtouch. 気をつけるポイント② Max LOB サイズを適切に設定しないとデータが切り捨てられる - LOB（Large Object）とは - データベースにおいて扱われる巨大なデータを表す用語 - BLOB（バイナリデータ） - CLOB（テキストデータ）→ JSON型 etc - XLOB（XMLデータ） - 完全LOBモード - データを切り捨てないが速度が低下するリスク - 制限付きLOBモード（推奨） - リソースを事前に割り当てる - サイズを超過するとデータを切り捨てる 　下記SQLでLOBカラムの最大値をチェックしましょう！
23. 23 © 2024 Techtouch. 気をつけるポイント③ 同期先テーブルのLOBカラムはNot Null制約があると同期失敗する - 同期先テーブルのLOBカラムはNot Null制約をはずしましょう！ - LOBカラムは最初にNULLとなりあとからデータが同期される動きとなる（は ず）ため 参照：https://e-words.jp/w/LOB-1.html
24. 24 © 2024 Techtouch. 気をつけるポイント④ インスタンスのメモリはなかなか開放されない - フルロード時にメモリを結構使う - その後のレプリケーション中も徐々にメモリが食われ続ける 初回フルロード時のメモリ使用量とレプリケーション期間に使われるメモリ量を事前に確認してメ モリ枯渇しないように注意しましょう！
25. 25 © 2024 Techtouch. 気をつけるポイント⑤ CASCADEで更新されたデータは同期されない - レプリケーション中は「テーブル統計で」状況が確認できる - 「検証に失敗しました」にカウントされターゲット側のデータは更新されない CASCADE利用しているか事前にチェックしましょう！
26. 26 © 2024 Techtouch. 気をつけるポイント⑥ too many connections発生しがち - 並列にロードするテーブルの最大数のデフォルトは8 - 開発環境では簡単にtoo many connectionsが発生した 本番のDBコネクションを食いつぶすリスクがあるのでコネクション数チェックしましょう！
27. 27 © 2024 Techtouch. まとめ - サービスのアーキテクチャに合わせた手法を使う - 難しければ手前でアーキテクチャを変更するのも一手 - DMS - 柔軟に設定ができて便利 - 必要に応じて細かいチューニングを - 気をつけないと躓きポイントが割とあるので要注意 1. 外部キー制約やインデックスなどのメタデータは同期されない 2. Max LOB サイズを適切に設定しないと同期に失敗する 3. 同期先テーブルのLOBカラムはNot Null制約があると同期失敗する 4. インスタンスのメモリはなかなか解放されない 5. CASCADE で更新されたデータは同期されない 6. too many connections 発生しがち
28. © 2024 Techtouch. - https://x.com/taisa831 - https://taisa.super.site - 著書（共著） ご清聴ありがとうございました。