AWS DMSのベストプラクティスを整理してみた

背景・目的

DMSのベストプラクティスを理解するため、整理してみます。

概要

下記を基に整理します。

AWS Database Migration Serviceでの移行の計画

ネットワーク設定

• レプリケーションインスタンスとソース/ターゲットデータベース間の接続を設定
• VPC内の接続からVPN経由のオンプレミス接続まで対応

ソースエンドポイントとターゲットエンドポイント

• 移行するテーブルとデータを特定
• DMSは基本的なスキーマ移行（テーブル、プライマリキー）のみサポート
• セカンダリインデックス、外部キー、ユーザーアカウントは自動作成されない
• サプリメンタルロギングなどの追加設定が必要な場合がある

スキーマとコードの移行

• DMSはスキーマやコードの変換を行わない
• 手動ツール（SQL Developer、MySQL Workbench等）またはAWS Schema Conversion Tool (SCT) を使用
• SCTでスキーマ全体の変換とPL/SQL/TSQLの変換が可能

データ型の互換性

• ソースとターゲット間でデータ型の変換が必要な場合がある
• 各データストアのドキュメントで対応状況を確認

事前チェック

• 診断サポートスクリプト
  • 移行失敗の可能性を事前に検出
• 移行前評価
  • タスク実行前に潜在的な問題を特定

スキーマの変換

AWS DMSはスキーマ・コード変換を行わないため、別途ツールが必要。

異なるエンジン間の変換

• AWS SCT (Schema Conversion Tool) を使用
• 変換内容: テーブル、インデックス、ビュー、トリガー、システムオブジェクト
• アプリケーションコード (PL/SQL、TSQL) も変換可能
• 無料ダウンロード可能

同一エンジン間の移行

• データベース専用ツールでスキーマを起動:
  • Oracle
    • SQL Developer
  • MySQL
    • MySQL Workbench
  • PostgreSQL
    • PgAdmin4

PoC (概念実証) を実行する

環境検証

• 初期段階での問題発見
• 現実的な移行時間の見積もり

パフォーマンス測定

• フルスケールテストでネットワーク経由のスループット確認
• 初期全負荷と継続的レプリケーションのベンチマーク・最適化
• ネットワークレイテンシーの把握

データプロファイル把握

• テーブルサイズの分布（大・中・小）
• データ型と文字セット変換の動作確認
• LOB列を持つテーブルの数
• 実際の移行所要時間の測定

AWS DMS 移行のパフォーマンスの向上

AWS DMS 移行のパフォーマンスには、いくつかの要因が影響する。

• ソースのリソース可用性
• 利用可能なネットワークスループット
• レプリケーション サーバーのリソース容量
• ターゲットの変更取り込み機能
• ソースデータのタイプとディストリビューション
• 移行するオブジェクトの数

適切なレプリケーション サーバーのプロビジョニング

AWS DMS は、Amazon EC2 インスタンスで実行されるマネージドサービス。下記の流れで処理される

1. ソース データベースに接続するレプリケーション インスタンスを使用
2. ソースデータを読み取り
3. ターゲットデータベースが使用できるようにデータをフォーマット
4. ターゲットデータベースにデータをロードする

これらの処理の殆どはメモリ内で行われる。
大きいトランザクションではディスクでのバッファリングが必要になる。

AWS DMS R5 および C5 インスタンスクラスのサポート

R5インスタンス

• メモリ集約型
• 用途は、大規模データセット、高スループットトランザクションの継続的移行/レプリケーション
• スペックは、最大768 GiBメモリ
• R4と比較し、vCPUあたり5%追加メモリ、CPU性能20%向上、GiB単価10%改善

C5インスタンス

• CPU集約型
• 用途は、異種移行（例: Oracle→PostgreSQL）
• ネットワークは、最大25 Gbps、EBS専用帯域14 Gbps（ENA使用）
• 特徴は、コンピューティング比あたり低価格、高コスト効率

選択基準

• 高スループット・大量メモリ必要は、R5を選択する
• 異種移行・高CPU負荷はC5を選択する

ストレージ

デフォルト容量

• インスタンスクラスに応じて50 GBまたは100 GBが付属している
• 用途は、ログファイル、キャッシュされた変更に使用される

容量増加が必要なケース

• ソースシステムが高負荷/大量トランザクション
• 複数タスクの同時実行する場合
• 通常はデフォルトで十分

ストレージタイプ: GP2 (汎用SSD)

• ベースパフォーマンス: 3 IOPS/GB
• バースト: 最大3,000 IOPS（クレジットベース）

監視ポイント

• ReadIOPS + WriteIOPS の合計がボリュームのベースパフォーマンスを超えないこと

マルチ AZ

メリット

• ストレージ障害から保護できる
• 継続的レプリケーション使用時の可用性向上

使用推奨ケース

• 継続的レプリケーション（長期運用）
• 一時的な移行では通常不要

フェイルオーバー時の動作

• フルロード中のフェイルオーバー/ホスト交換の場合、タスクが失敗する（単一AZ/マルチAZ共通）
• 未完了テーブル/エラー状態テーブルについては、障害発生時点から再開可能

複数のテーブルを並列的にロードする

デフォルトでは、同時に8テーブルをロードする

チューニング指針

• 大型インスタンス（dms.c4.xlarge以上）を使用した場合、増やすことでパフォーマンスが向上する可能性あり
• 小型インスタンス（dms.t2.medium等）は、減らすことを推奨

インデックス、トリガーおよび参照整合性制約の使用

インデックス、トリガーおよび参照整合性制約は、移行パフォーマンスに影響を及ぼすことがあるため、移行が失敗する原因になる

レプリケーション タスクが全ロードタスクであるか、継続的なレプリケーション (CDC) タスクであるかによって移行に及ぼす影響が異なる。

• 全ロードタスクの場合は、プライマリキーインデックス、参照整合性制約、データ操作言語 (DML) トリガーを削除することを推奨

• ロード + CDC タスクの場合は、CDC フェーズの前にセカンダリ インデックスを追加することを推奨

バックアップとトランザクションログを無効にする

• Amazon RDS データベースに移行する場合、カットオーバーの準備ができるまでは、ターゲットのバックアップとマルチ AZ を無効にすることを推奨
• Amazon RDS以外 に移行する場合、カットオーバーまではターゲットのロギングを無効にすることを推奨

複数のタスクを使用する

単一の移行のために複数のタスクを使用することでパフォーマンスが向上する場合がある。

変更処理の最適化

デフォルトではトランザクションモードで整合性を維持する

最適化バッチオプション

• トランザクション完全性を一時的に失効可能な場合に使用
• トランザクションをグループ化してバッチ適用
• これにより、効率化・高速化につながる
• 参照整合性制約に違反する可能性が高い。そのため移行中は、参照整合性制約をオフにし、カットオーバー時に参照整合性制約をオンにする

ラージバイナリオブジェクト (LOB) の移行

移行プロセスは2フェーズ。

1. AWS DMS はターゲットテーブルに新しい行を作成し、関連付けられた LOB 値を除くすべてのデータを行に入力
2. AWS DMS は、ターゲットテーブルの行を LOB データで更新

• 移行中はターゲットテーブルのすべての LOB 列で null が許容されるようにする必要がある

継続的なレプリケーション

• ソースとターゲットの同期を維持
• レプリケーション対象は、テーブルデータ、限定的なDDL
• レプリケーション対象外は、インデックス、ユーザー、権限、ストアドプロシージャ等

推奨設定

• マルチAZオプション有効化
• ただし、パフォーマンス影響とレプリケーション速度低下の可能性がある

運用上の注意点

• DBのアップグレード時にタスク停止し、アップグレード、タスクを再開する

パフォーマンス考慮事項

• ソースDB - レプリケーションインスタンス間のネットワーク帯域幅
• ソースDBの1時間あたりの変更率
• アーカイブログ生成率

ソースデータベースのロードを縮小する

AWS DMS はソースデータベースの一部のリソースを使用する。

• 全ロードタスク中、 AWS DMS では、並行処理される各テーブルに対してソーステーブルのテーブル全体のスキャンが実行される
• 各タスクが独立してソースの変更を問い合わせる

考察

今回、ベストプラクティスの一部をドキュメントから読み解きました。
次回以降、実際に試してみます。

参考