大規模データベースを、移行して終わりではなく運用まで担当します

オンプレミスからAWS・Azureへの移行

オンプレミスからクラウドへの移行では、同じ製品名であっても運用の前提が変わります。マネージドサービスではOSレイヤーに触れられないため、常駐エージェント、ローカルファイル連携、OSのスケジューラに依存した処理は、そのまま持ち込めるかを最初に切り分ける必要があります。

GIIPはオンプレミスSQL ServerのAWS RDSへの移行、オンプレミスOracleのAWSへの移行を実際に経験しています。またAWSとAzureの両方でデータベースを運用しているため、片方のクラウドの前提を他方に持ち込まない形で設計できます。

スキーマ・互換性・クエリの検証

「動くかどうか」ではなく「同じ結果になるか」を確認する工程です。

• スキーマ定義（主キー、インデックス、制約、パーティション）の差異を洗い出します。
• データ型・文字コード・照合順序の差異が、値そのものに影響しないかを確認します。
• 既存のSQLが移行先で同じ実行計画になるとは限りません。重くなるクエリを事前に特定します。
• ストアドプロシージャ、トリガー、ジョブ、バッチ処理の依存関係を列挙し、移行対象から漏れないようにします。
• 移行前後の件数・定義の突合を、目視ではなく機械的に回せる形にします。

切り替え計画とロールバック計画

移行の可否を分けるのは、多くの場合「うまくいったとき」ではなく「うまくいかなかったとき」の設計です。切り戻せない切り替えは、業務上の判断としてリスクが高すぎます。

• 切り替え時にどのノード・どの時点を基準とするかを事前に確定します。
• 許容できる停止時間を業務側と合意し、それに収まる方式を選びます。
• 切り戻しの判断基準（何が起きたら戻すか）と、その所要手順を書き出します。
• 切り替え後に確認する項目と、その確認を誰が行うかを決めます。

停止時間の目安は環境ごとに異なります。実測に基づかない一般値をお伝えすることはしていません。

移行後の性能監視

移行直後は、これまで問題にならなかったクエリが表面化しやすい時期です。実行計画の変化、接続数の変化、バッチ処理の負荷特性の変化が同時に起きるためです。

GIIPは移行して終わりにせず、移行後の監視・性能分析・運用まで同じチームで継続します。現在もAWSとAzure上のクラウドデータベースを継続的に監視しています。

AWS DMS などのツールの使用について

GIIPは特定の移行ツールの採用を前提にしていません。AWS Database Migration Service（DMS）のようなマネージドツールが適する場面もあれば、論理ダンプやレプリケーションを使う方が確実な場面もあります。

ツールは移行元・移行先の組み合わせ、データ量、許容できる停止時間、検証にかけられる期間から選びます。本ページでは、実際の案件でどのツールを使用したかは公開していません。

1. 1

   現行構成の確認

   データベースの種類、バージョン、オンプレミスかクラウドか、インスタンス構成を確認します。

2. 2

   規模の把握

   データ容量とおおよそのテーブル数を確認します。どちらが主要な難所になるかがここで決まります。

3. 3

   依存関係の棚卸し

   ジョブ、バッチ、外部インターフェース、他システムとの連携を列挙します。

4. 4

   停止許容範囲の確認

   無停止が必要か、何時間まで停止できるかを業務側の条件として確認します。

5. 5

   移行方式と検証計画の提示

   前提を明示したうえで、方式の選択肢・検証項目・切り戻し方針を整理してご提示します。

6. 6

   移行後の運用範囲の決定

   監視・運用をGIIPが担当するか、引き継ぐかを決めます。