基幹システムAWS移行でDMSに泣いた話

Transcript

1. 基幹システムAWS移行で DMSに泣いた話 基幹システムAWS移行で DMSに泣いた話 ユニフォームネクスト株式会社 大道　真弘 ユニフォームネクスト株式会社 大道　真弘 2026. 1. 17 2026. 1. 17
2. 1 . 自 己 紹 介 2 . D M S と は ？ 3 . D M S に 泣 い た 話 4 . ま と め アジェンダ
3. ユニフォームネクストにて情シスエンジニアとして10年勤務 主に基幹システムの運用・保守と 社内インフラを担当。 2年前に基幹システムのクラウド基盤をAWSへ移管することになり、 データベースの移行時にでDMSを利用した経験が共有できれば！ 大 道 　 真 弘 自己紹介
4. DMS = Database Migration Service　の略 オンプレミスや他のクラウドからAWSへ データベースを移行するためのマネージドサービス 【DMSの特徴】 ・同種移行/異種移行が可能 　 （例：Oracle → Oracle、PostgreSQL → MySQL） ・リアルタイムのデータ複製や継続的なレプリケーションが可能 ・データをフィルタリングして選択的に移行可能 DMS とは？
5. DMS とは？ DMSのレプリケーションインスタンス役割
6. DMS に泣いた話
7. フルロード24 時 DMS に泣いた話
8. DMS に泣いた話 DMSに3つタスクタイプがある ・フルロード（移行のみ） ・フルロード＋レプリケーション（移行＋複製） 　※このタイプを利用 ・レプリケーション（複製のみ） DMSのタスク作成画面（抜粋）
9. DMS に泣いた話 レプリケーションインスタンスのメトリクス（抜粋）
10. DMS に泣いた話 フルロードが進まなかった原因 レプリケーションインスタンスで T3系インスタンス（バーストありのモデル）を 利用していた
11. DMS に泣いた話 フルロードが進まなかった原因の対応 レプリケーションインスタンスで T3系インスタンス（バーストありのモデル）を 利用していた →　T3系以外のインスタンスに変更
12. DMS に泣いた話 レプリケーションインスタンスで見ておくとよいメトリクス ・BurstBalance ・CPUUtilization ・FreeableMemory
13. DMS に泣いた話 フルロードが進まない原因は解決した
14. DMS に泣いた話
15. DMS に泣いた話 9時間で7%・・・
16. DMS に泣いた話 フルロードが遅い原因 ・移行対象のテーブルに大量のレコードがある ・カラムが多いテーブルが複数ある ・スペック不足
17. DMS に泣いた話 フルロードが遅い原因の対応方法 ・移行対象に大量のレコードがある 　→　タスク分割で対応 ・カラムが多いテーブルが複数ある 　→　タスク分割で対応 ・スペック不足 　→　レプリケーションインスタンスのスペック調整
18. DMS に泣いた話
19. DMS に泣いた話 1時間で44%に改善！
20. レプリケーション 遅延 DMS に泣いた話
21. DMS に泣いた話 本番環境と同様のスペックでDMSのテストしたところ 業務終了時点でのレプリケーション遅延が4.5時間ほど発生
22. DMS に泣いた話 データ移行の構成
23. DMS に泣いた話 赤枠あたりが問題ありそう
24. DMS に泣いた話 調査したが原因わからず
25. DMS に泣いた話 AWS移管のタイムスケジュール ▪切替前日の夜 0:00　DMSの実行開始。 ▪切替当日 18:00　社内業務終了。 00:00　AWS切替作業開始。
26. DMS に泣いた話 AWS切り替えまで6時間
27. DMS に泣いた話 いける
28. DMS に泣いた話 原因は不明だったが、移行スケジュールの再現性を重視 ・本番環境での移行テストを4回実施 ・レプリケーション遅延が22時～23時で解消
29. まとめ DMS移行で得た教訓 ・フルロードはインスタンスタイプとタスク設計 　 （バースト回避／重いテーブルは分割） ・レプリケーション遅延は運用の再現性を優先