データベース移行プロジェクトにおけるDMS活用 — 移行波との統合
大規模移行プロジェクトにおけるDMSの位置づけと、MGNによるサーバー移行との統合的なカットオーバー計画を解説します。
DMSとSchema Conversion Toolの技術的な仕組み(スキーマ変換、CDCの原理)は 2-3の記事で解説済みです。本記事では、移行プロジェクト全体の中でDMSが どう位置づけられ、サーバー移行(MGN)と統合的に計画されるかを解説します。
SAA レベル:基礎概念
移行プロジェクトにおけるDMSの役割(おさらい)
- アプリケーションサーバーの移行(MGN)とは独立して、データベース層の移行を担当する
- 同種移行(MySQL→Aurora MySQL等)と異種移行(Oracle→Aurora PostgreSQL等)で、必要な準備(SCTの要否)が異なる
SAA 試験のポイント
アプリケーションサーバーとデータベースサーバーは、それぞれ異なる移行ツール(MGNとDMS)で移行されることが多く、プロジェクト計画上はこの2つの移行トラックを同期させる必要があるという基本認識がSAAで問われます。
SAP レベル:高度な設計シナリオ
アプリケーション移行とデータベース移行の同期
SAP 試験のポイント
MGNでアプリケーションサーバーをレプリケーションしつつ、並行してDMSでデータベースをCDCで同期させ、両方の準備が整った同じタイミングで、アプリケーションのカットオーバーとデータベースのカットオーバーを一体的に実施する、という統合的な移行計画がSAPレベルで問われます。片方だけを先行して切り替えると、新環境のアプリケーションが旧環境のデータベースに接続する、といった不整合な中間状態が生まれるリスクがあります。
移行順序の戦略的判断
SAP 試験のポイント
「データベースを先に移行するか、アプリケーションを先に移行するか」はプロジェクトごとに戦略が異なります。SAPでは、**データベースを先にAWSへ移行し、しばらくはオンプレミスのアプリケーションからAWS上のデータベースへ接続させる(ハイブリッド期間を設ける)**ことで、リスクを分散する設計パターンが問われることがあります。この場合、オンプレミス〜AWS間の低レイテンシな接続(Direct Connect)が前提条件になります。
| 移行順序 | メリット | 考慮事項 |
|---|---|---|
| DB先行移行 | DB移行のリスクを先に検証できる | オンプレミスアプリ→AWS DBの接続にDirect Connectが必要 |
| アプリ先行移行 | アプリの動作検証を先に完了できる | AWSアプリ→オンプレミスDBの接続にDirect Connectが必要 |
| 同時カットオーバー | 中間状態を作らない | 調整の複雑さとリスクが増す |
設計上の落とし穴
「移行の複雑さを避けるため、必ずアプリとDBを同時に切り替えるべき」という判断は、大規模で複雑なシステムではかえってリスクを高めることがあります。SAPレベルでは、ハイブリッド期間を意図的に設けて段階的に移行する方が、各ステップのリスクを分離・検証できるという判断が問われる場合もあり、画一的な正解がない点への理解が求められます。
移行リハーサルとロールバック計画
- MGNのテスト起動と同様、DMSのCDCも本番影響なくターゲット環境でのデータ検証を繰り返し実施できる
- 統合カットオーバーの前に、アプリ・DB双方を含めた総合リハーサルを実施し、問題があれば両方を旧環境に切り戻すロールバック手順を明文化しておくことが、大規模移行プロジェクトの成功率を左右する
まとめ
- SAA: アプリケーション移行(MGN)とデータベース移行(DMS)が異なるトラックで進行することを理解する。
- SAP: 両トラックを統合したカットオーバー計画、ハイブリッド期間を設けた段階的移行のトレードオフを踏まえた設計ができる。
次は DataSync/Transfer Familyを見ていきましょう。