Homogeneous / Heterogeneous Database Migration

データベース移行では、データをどう移すかだけではなく、移行元と移行先でデータベースエンジンが変わるかを確認する必要があります。

同じ種類のデータベースエンジン
→ Homogeneous Migration

異なるデータベースエンジン
→ Heterogeneous Migration

Heterogeneous Migrationでは、データ型、SQL構文、関数、ストアドプロシージャ、その他のデータベース機能が異なる可能性があるため、データを移すだけではなくSchema ConversionとDatabase Compatibilityの確認が重要になります。

1. 最初にEngine Changeの有無を見る

データベース移行を分類するときは、オンプレミスからAWSへ移行するかどうかだけでは判断しません。中心となるのは、移行元と移行先のデータベースエンジンです。

PostgreSQL
↓
Amazon RDS for PostgreSQL

PostgreSQL
↓
Aurora PostgreSQL

これらは同じ種類のデータベースエンジンを利用する移行としてHomogeneous Migrationに分類できます。

Oracle Database
↓
Aurora PostgreSQL

このようにデータベースエンジンそのものが変わる場合はHeterogeneous Migrationです。クラウドへ移行すること自体ではなく、Engine Changeの有無で分類します。

2. Homogeneous Migrationは同じ種類のエンジン間の移行

Homogeneous Migrationでは、移行元と移行先で同じ種類のデータベースエンジンを使用します。

PostgreSQL → Amazon RDS for PostgreSQL
PostgreSQL → Aurora PostgreSQL
MySQL → Amazon RDS for MySQL

同じエンジンを使用するため、Oracle固有のSQLをPostgreSQL用SQLへ変換するようなエンジン間の大規模なSchema Conversionは中心課題になりにくくなります。

ただし、Homogeneous Migrationだから互換性確認が不要になるわけではありません。

3. Homogeneous MigrationでもDatabase Compatibilityは確認する

同じ種類のデータベースエンジンでも、バージョン、拡張機能、設定、利用しているデータベース機能などが異なる場合があります。

同じエンジン
↓
Homogeneous Migration
↓
バージョン / 拡張機能 / 利用機能の互換性を確認

エンジン名が同じという理由だけで移行可能とは判断せず、Homogeneous Migrationという分類と実際のDatabase Compatibilityを分けて考えます。

4. Heterogeneous MigrationはEngine Changeを伴う

Heterogeneous Migrationでは、移行元と移行先で異なるデータベースエンジンを使用します。

Oracle Database → Aurora PostgreSQL
Microsoft SQL Server → Amazon RDS for PostgreSQL

この場合、テーブル、列、データ型、インデックス、ビュー、関数、ストアドプロシージャ、トリガーなどが移行先でそのまま利用できるとは限りません。

Engine Change
↓
Database Compatibilityを評価
↓
必要なSchema Conversionを行う

エンジンが変わる場合は、データ移行そのものとは別に互換性と変換の必要性を確認します。

5. Schema Conversionはデータベース構造やコードを変換する

Schema Conversionでは、移行元データベースの構造やコードを、移行先データベースと互換性のある形式へ変換します。

Oracle用のデータ型
↓
PostgreSQLで利用できるデータ型

移行元エンジン固有のストアドプロシージャ
↓
移行先で利用できるコード

Schema Conversionと業務データそのものの移行は同じ処理ではありません。

スキーマ / コード
→ 互換形式へ変換

データ
→ 別途移行

スキーマやコードの変換が完了しても、既存の業務データが自動的にすべて移行済みになるわけではありません。

6. Database Compatibilityはテーブル名だけでは判断できない

異なるデータベースエンジン間では、テーブルを作成できることだけでDatabase Compatibilityが成立したとは判断できません。

データ型
SQL構文
関数
ストアドプロシージャ
ビュー
トリガー
エンジン固有機能

移行元で使用していた関数が移行先に存在しない場合は、別の実装へ変更する必要が生じる可能性があります。

Heterogeneous Migrationでは、データを保存できるかだけでなく、既存のデータベースロジックを移行先で正しく実現できるかまで確認します。

7. AWS Schema Conversion ToolはSchema Conversionを支援する

AWS Schema Conversion Tool（AWS SCT）は、データベーススキーマを別のデータベースエンジン向けに変換するためのツールです。

移行元スキーマ
↓
解析
↓
移行先向けへ変換

対象にはテーブル、ビュー、ストアドプロシージャ、関数などのデータベースオブジェクトやコードが含まれます。

AWS SCTを使っても、すべてのデータベースコードが必ず完全自動変換されるわけではなく、変換できない項目や手動対応が必要な項目が残る可能性があります。

8. 変換前にDatabase Compatibilityを評価する

大規模なHeterogeneous Migrationでは、まず全部変換してみるのではなく、事前に変換の難易度を把握することが重要です。

AWS SCTや現在のDMS Schema Conversionでは、変換評価によって自動変換可能なオブジェクトと手動対応が必要なオブジェクトを確認できます。

自動変換可能
↓
変換

自動変換困難
↓
アクション項目を確認
↓
手動対応

評価結果から、自動変換できる範囲、手動対応が必要な場所、想定される変換作業量を把握します。

9. 自動変換できないことは移行失敗を意味しない

変換評価で手動対応が必要な項目が見つかった場合でも、Heterogeneous Migration全体が不可能だと即断するわけではありません。

移行元固有の関数
↓
自動変換不可
↓
移行先で同等処理を手動変換 / 再実装できるか評価

評価結果は移行可否だけを見るものではなく、どこまで自動変換でき、どこに手動対応が必要かを判断するために利用します。

10. AWS SCTの現在の位置付け

AWS Schema Conversion Toolは現在もSAP-C02の対象サービスに含まれ、引き続き利用できます。

一方、現在のAWS DMSドキュメントでは、新しいスキーマ変換についてはDMS Schema Conversionの利用が推奨されています。AWS SCTは従来のAWS Schema Conversion Toolとして案内されています。

AWS SCT
→ 引き続き利用可能
→ SAP-C02対象

DMS Schema Conversion
→ 現在AWSが推奨するSchema Conversion機能

AWS SCTが試験範囲から削除済みという理解でも、AWS SCTが現在唯一の推奨方式という理解でもありません。

11. DMS Schema Conversionは現在のAWS DMSの機能

現在のAWSでは、DMS Schema ConversionがAWS DMSの機能として提供されています。

移行元のメタデータを読み取る
↓
変換評価
↓
Schema Conversion
↓
変換結果を確認
↓
移行先へ適用

DMS Schema Conversionはスキーマやデータベースコードを移行先互換形式へ変換し、自動変換できない項目をアクション項目として確認できます。

DMS Schema Conversion
→ スキーマ / コードを変換

AWS DMSのデータ移行機能
→ データを移行

Schema Conversionを実行しただけで業務データの移行まで完了したとは考えません。

12. HomogeneousとHeterogeneousを比較する

Homogeneous Migrationだから何も確認しなくてよいわけでも、Heterogeneous Migrationだから必ずすべて手動変換になるわけでもありません。

13. 判断の流れ

移行元エンジンを確認
↓
移行先エンジンを確認
↓

同じ種類
↓
Homogeneous Migration
↓
バージョン / 機能などのDatabase Compatibilityを確認

異なる種類
↓
Heterogeneous Migration
↓
Database Compatibilityを評価
↓
Schema Conversionが必要
↓
自動変換可能範囲と手動対応項目を確認

この段階では、どのデータ移行ツールを使うか、Full Load / CDCをどう組み合わせるか、許容業務停止時間からどの方式を最終選択するかまでは決めません。

ここで完成させるのは、Engine Changeの有無から移行を分類し、Database CompatibilityとSchema Conversionの必要性を判断できることです。