データベースマイグレーション

文書基準: 2026年8月

概要

オンプレミスDBをクラウドに移行したり、クラウド間でDBを移動したりする際にマイグレーションサービスを使用します。単純なバックアップ/リストアでも可能ですが、大規模DBではダウンタイムを最小化しながら継続的にデータを同期するオンラインマイグレーションが必要です。

マイグレーションの種類

種類	説明	ダウンタイム
同種マイグレーション	同じエンジン間の移動 (MySQL → MySQL)	最小 (CDCによるリアルタイム同期)
異種マイグレーション	異なるエンジンへの移行 (Oracle → PostgreSQL)	スキーマ変換 + データ移動が必要
継続的レプリケーション	オンプレミス ↔ クラウドのリアルタイム同期	なし (ハイブリッド運用)

製品比較

ベンダー	製品	備考
AWS	DMS (Database Migration Service)	同種/異種マイグレーション。CDC(Change Data Capture)による継続的レプリケーション
AWS	SCT (Schema Conversion Tool)	異種マイグレーション時のスキーマ自動変換
Azure	Azure Database Migration Service	オンライン/オフラインマイグレーション。Azure SQLへの移行に最適化
Azure	Azure Migrate	DBを含む全ワークロードのマイグレーション評価/実行
Google Cloud	Database Migration Service	MySQL, PostgreSQL, SQL Server → Cloud SQL/AlloyDB
Google Cloud	Datastream	CDCベースのリアルタイムレプリケーション。BigQueryへのストリーミングが可能
OCI	OCI Database Migration	Oracle/MySQL → OCI DB。オンラインマイグレーション(Zero Downtime)対応

主な違い

AWS DMS — 最も多くのソース/ターゲットエンジンの組み合わせをサポートします。Oracle、SQL Server、MongoDB、S3など多様なソースからAWS DBへ移行できます。SCTと併用すると、異種マイグレーションのスキーマ変換を自動化できます。

Azure — Azure SQLへのマイグレーションに特化しており、SQL Serverワークロードの移行が最もスムーズです。Azure Migrateでマイグレーション前の評価(互換性、コスト見積もり)を実施できます。

Google Cloud Datastream — CDCベースのリアルタイムレプリケーションを提供し、BigQueryへ直接ストリーミングして分析パイプラインを構築できます。

OCI Database Migration — Oracle/MySQL DBをOCIへオンラインマイグレーション(Zero Downtime)でき、GoldenGateベースのリアルタイムレプリケーションをサポートします。

マイグレーション戦略

データベースマイグレーションは大きく3つの戦略(6RのうちDB関連)に分かれます。複雑さとコストが異なるため、ワークロードの特性に合わせて選択します。

戦略	説明	適した場合	例
Rehost (リホスト)	同一エンジンをそのままクラウドへ移動。“Lift and Shift”	迅速な移行が目標、エンジン変更不要	MySQL → RDS MySQL, Oracle → OCI DB System
Replatform (リプラットフォーム)	エンジンは維持しつつ管理型サービスへ移行。一部最適化を適用	運用負担の軽減が目標、コード変更を最小化	MySQL → Aurora MySQL, PostgreSQL → AlloyDB
Refactor (リファクター)	エンジンを変更またはアーキテクチャを再設計	性能/コスト/拡張性の抜本的改善が目標	Oracle → PostgreSQL, モノリシックDB → DynamoDB + RDS分離

戦略選択の基準

時間的制約が大きい場合 → Rehost (最も速い)
運用コストを削減したい場合 → Replatform (管理型への移行)
ライセンスコスト削減または拡張性の限界を解決したい場合 → Refactor (最も高い効果、最も高いコスト/リスク)

DB内部ロジック(プロシージャ/トリガー)をそのまま移行する際のリスク

オンプレミスDBでは、ビジネスロジックの大部分をストアドプロシージャ(Stored Procedure)、トリガー(Trigger)、ユーザー定義関数(UDF) で実装しているケースが多くあります。マイグレーション時にこれらをそのまま移そうとする要求がよく発生しますが、クラウド環境では次のような問題が生じます。

拡張性の限界

DBインスタンスがボトルネックになる — プロシージャがDB内部で実行されるため、ビジネスロジックの負荷がDBのCPU/メモリを消費します。読み取り専用レプリカへ分散できず、DBインスタンスの垂直拡張でしか対応できません。
水平拡張が不可能 — アプリケーション層はオートスケーリングで無限に拡張できますが、DBはそうではありません。ロジックがDBにあると、システム全体の拡張性がDBの性能に縛られます。

ベンダー依存の増加

特定のDBエンジンに固定される — Oracle PL/SQL、SQL Server T-SQL、PostgreSQL PL/pgSQLは互いに互換性がありません。管理型サービスへ移行したり、別のクラウドへ移動したりする際に、全ロジックを再作成する必要があります。
異種マイグレーションが困難になる — Oracle → PostgreSQLへ移行する際、データはDMSで移動できますが、プロシージャは手動変換が必要で、変換ツール(SCTなど)がすべての構文をサポートしているわけではありません。

運用・可観測性の問題

バージョン管理が困難 — アプリケーションコードはGitで管理されますが、プロシージャはDB内にあるためバージョン管理が脆弱です。
テスト自動化が困難 — 単体テスト、CI/CDパイプラインへプロシージャを組み込むのが難しくなります。
障害原因の特定が遅れる — APM、分散トレーシングツールはアプリケーションコードを追跡しますが、プロシージャ内部はブラックボックスです。
デバッグツールの制限 — IDEサポートがアプリケーション言語(Java、Pythonなど)と比べて貧弱です。

セキュリティ・コンプライアンスリスク

アクセス権限管理が複雑 — プロシージャが内部で複数のテーブルを操作すると、最小権限の原則の適用が難しくなります。
監査ログの解像度が低い — プロシージャ1つの実行のみが記録され、内部動作はログに残らないケースが多くあります。

推奨アプローチ

状況	推奨方向
とにかく迅速にクラウドへ移行する必要がある場合	Rehostでプロシージャを維持 → その後段階的にアプリケーション層へ移行
管理型DBへ移行する場合	管理型DBがサポートするプロシージャ機能の範囲を確認 (例: 一部のSystem Procedureは管理型で制限される)
新規設計の場合	ビジネスロジックをアプリケーション層に置き、DBはデータの保存/照会に専念
分散トランザクションが必要な場合	プロシージャの代わりにSagaパターン、イベント駆動アーキテクチャを検討

マイグレーションプロセス

DBマイグレーションは一回限りのデータ移動ではなく、複数の段階を経るプロジェクトです。

段階	主な活動
1. Discovery	現在のDBインベントリの把握 (エンジン、バージョン、サイズ、性能、依存関係)
2. Assessment	互換性評価、スキーマ変換の必要性、コスト見積もり、リスク要因の識別
3. Planning	マイグレーション戦略(Rehost/Replatform/Refactor)の選択、ダウンタイム予算の確定、ロールバック計画の策定
4. Migration	スキーマ移行 → 初期データロード → CDCベースの継続的レプリケーション → 検証
5. Validation	データ整合性検証、アプリケーションテスト、性能比較
6. Cutover	アプリケーションを新DBへ切り替え。読み取り専用モード → レプリケーション完了待ち → 切り替え

ダウンタイム最小化戦略

大規模DBマイグレーションでダウンタイムを削減する主要な手法です。

手法	説明	使用タイミング
CDC (Change Data Capture)	ソースDBのトランザクションログを読み取りターゲットへ継続的にレプリケーション	オンラインマイグレーションの基本。初期ロード後にリアルタイム同期
Blue/Greenデプロイ	既存DB(Blue)と新規DB(Green)を同時に運用しトラフィックを切り替え	切り替え時にロールバックを容易にしたい場合
読み取り専用ロック	Cutover直前にソースDBを読み取り専用へ切り替え、レプリケーション完了後に切り替え	数分〜数十分のダウンタイムが許容できる場合
デュアルライト	アプリケーションが両方のDBへ同時に書き込む	ゼロダウンタイムに近い可用性が必要だが複雑さが高い

よくある間違い

異種マイグレーションの難易度を過小評価 — Oracle → PostgreSQL移行はデータ移動だけでなく、プロシージャ、トリガー、クエリ全体を再作成する必要があります。Assessmentなしで開始するとスケジュールが何倍にも延びます。
CDCレプリケーション遅延を監視しない — Cutover時点でレプリケーション遅延が大きいとデータ損失が発生します。レプリケーション遅延メトリクスを常時監視してください。
Cutover後にソースDBを即座に廃棄 — 切り替え後に予期しない問題が発見される可能性があります。ソースDBを一定期間維持し、ロールバックの可能性を確保してください。

チェックリスト

マイグレーション前に互換性評価(Assessment)を実施し、変換が必要な項目を識別したか
CDCレプリケーション遅延の監視とCutover判断基準(遅延 < N秒)を定義したか
Cutover後にデータ整合性検証(レコード数、チェックサム、サンプル比較)を実施したか