翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Database Migration Service のベストプラクティス

AWS Database Migration Service (AWS DMS) を最も効果的に使用するためには、データ移行の最も効率的な方法に関するこのセクションの推奨事項をご参照ください。

AWS Database Migration Service での移行の計画

AWS Database Migration Service を使用してデータベース移行を計画するときは、以下の点を考慮してください。

スキーマの変換

AWS DMS は、スキーマまたはコード変換を実行しません。異なるデータベースエンジンに既存のスキーマを変換する場合、AWS SCT を使用します。AWS SCT は、ソースオブジェクト、テーブル、インデックス、ビュー、トリガー、およびその他のシステムオブジェクトをターゲットデータ定義言語 (DDL) 形式に変換します。AWS SCT を使用して、PL/SQL または TSQL などのほとんどのアプリケーションコードを同等のターゲット言語に変換することもできます。

AWS SCT は、AWS から無料でダウンロードできます。AWS SCT の詳細については、AWS SCT ユーザーガイドをご参照ください。

ソースエンドポイントとターゲットエンドポイントが同じデータベースエンジン上にある場合は、Oracle SQL Developer、MySQL Workbench、4 などのツールを使用してスキーマ PgAdminを移動できます。

AWS DMS 公開ドキュメントのレビュー

最初の移行前のソース エンドポイントとターゲット エンドポイントについて AWS DMS 公開ドキュメントページを確認することを強くお勧めします。このドキュメントは、移行の前提条件を特定し、開始する前に現在の制限事項を理解するのに役立ちます。詳細については、「AWS DMS エンドポイントの使用」を参照してください。

移行中、公開ドキュメントは、AWS DMS に関する問題のトラブルシューティングに役立ちます。これらのトピックは、AWS DMS と選択したエンドポイント データベースの両方を使用して一般的な問題を解決するのに役立ちます。詳細については、「での移行タスクのトラブルシューティング AWS Database Migration Service」を参照してください。

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

データベース移行の初期段階で環境に関する問題を発見するために、小規模なテスト移行を実行することをお勧めします。これにより、より現実的な移行の時間帯を設定するのにも役立ちます。さらに、フルスケールのテスト移行を実行して、AWS DMS が、ネットワーク上でデータベースのスループットを処理できるかどうかを測定する必要がある場合があります。この間、最初の全負荷と継続的なレプリケーションをベンチマークして最適化することをお勧めします。これにより、ネットワークのレイテンシーを把握し、全体的なパフォーマンスを測定するのに役立ちます。

この時点で、次のようなデータプロファイルとデータベースの大きさを理解する機会もあります。

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

いくつかの要因が AWS DMS 移行のパフォーマンスに影響を与えます。

パフォーマンスを向上させるには、次のベストプラクティスの一部またはすべてを使用します。これらのプラクティスを使用できるかどうかは、特定のユースケースに大きく左右されます。以下の制限があります。

独自のオンプレミスネームサーバーの使用

通常、AWS DMS レプリケーション インスタンスは、Amazon EC2 インスタンスでドメインネームシステム (DNS) リゾルバーを使用してドメイン エンドポイントを解決します。ただし、Amazon Route 53 Resolver を使用する場合は、独自のオンプレミス ネームサーバーを使用して特定のエンドポイントを解決できます。このツールを使用すると、オンプレミスととの間でクエリを実行できます。AWS インバウンドおよびアウトバウンド エンドポイント、転送ルール、プライベート接続を使用する。オンプレミスのネームサーバーを使用するメリットには、セキュリティの向上とファイアウォールの背後にある使いやすさが含まれます。

インバウンド エンドポイントがある場合、オンプレミスの DNS クエリを使用して AWS にホストされたドメインを解決できます。。エンドポイントは、リゾルバーを提供する各サブネットの IP アドレスを割り当てることによって設定されます。オンプレミスの DNS インフラストラクチャと AWS の間の接続を確立するには、AWS Direct Connectまたは、仮想プライベートネットワーク (VPN) を使用します。

アウトバウンド エンドポイントは、オンプレミスのネームサーバーに接続します。ネームサーバーは、許可リストに含まれ、アウトバウンド エンドポイントに設定された IP アドレスにのみアクセス権を付与します。ネームサーバーの IP アドレスがターゲットの IP アドレスです。アウトバウンド エンドポイントのセキュリティグループを選択するときは、レプリケーション インスタンスで使用されるものと同じセキュリティグループを選択します。

転送ルールは、ネームサーバーに転送するドメインを選択するために使用されます。1 つのアウトバウンド エンドポイントに複数の転送ルールが存在する可能性があります。転送ルールの範囲は、Virtual Private Cloud (VPC) です。VPC に関連付けられた転送ルールを使用すると、AWS クラウドの論理的に分離されたセクションをプロビジョニングできます。この論理的に隔離されたセクションから、AWS 仮想ネットワーク内のリソースを起動できます。

オンプレミスの DNS インフラストラクチャ内でホストされるドメインは、アウトバウンド DNS クエリを有効にする条件付き転送ルールとして構成できます。これらのドメインの 1 つに対してクエリが実行されると、ルールによって構成された DNS サーバーに DNS リクエストを転送する試みがトリガーされます。繰り返しますが、プライベート接続オーバー AWS Direct Connect または VPN が必要です。

Route 53 レゾルバーのアーキテクチャを次の図表に示します。

Route 53 DNS リゾルバーの詳細については、Amazon Route 53 デベロッパーガイドの「Route 53 レゾルバーの使用開始」をご参照ください。

Amazon Route 53 Resolver の AWS DMS での使用

Amazon Route 53 Resolver AWS DMS を使用してエンドポイントを解決するためのオンプレミス ネームサーバーを作成できます。

すべてが作成され、VPC はインバウンドおよびアウトバウンド ルールに関連付けられ、トラフィックのルーティングを開始できます。

Route 53 リゾルバーの詳細については、Amazon Route 53 デベロッパーガイドの「Route 53 Resolver の使用開始」をご参照ください。

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

一般に、AWS DMS は LOB データを 2 つのフェーズに移行します。

この LOB の移行プロセスでは、移行中はターゲットテーブルのすべての LOB 列で null が許容されるようにする必要があります。これは、ソーステーブルの LOB 列で null が許容されていない場合にも該当します。AWS DMS がターゲットテーブルを作成すると、LOB 列はデフォルトで NULL に設定されます。場合によっては、インポートやエクスポートなどの他のメカニズムを使用してターゲット テーブルを作成することがあります。このような場合、移行タスクを開始する前に LOB 列で NULL が許容されることを確認してください。

この要件には 1 つの例外があります。Oracle ソースから Oracle ターゲットへの同種移行を実行し、[制限付き LOB モード] を選択しているとします。この場合、すべての LOB 値を含めて、行全体が一度に入力されます。このような場合、AWS DMS では、必要に応じて、ターゲットテーブルの LOB 列を null 許容制約なしで作成できます。

制限付き LOB モードの使用

AWS DMS は、移行に LOB 値が含まれている場合に、パフォーマンスと利便性のバランスをとる 2 つのメソッドを使用します。

PostgreSQL など一部のデータベースエンジンに対して、AWS DMS は JSON データ型を LOB のように扱います。[Limited LOB mode] (制限付き LOB モード) を使用している場合、[Max LOB size] (最大 LOB サイズ) オプションが、JSON データが切り捨てられない値に設定されていることを確認します。

AWS DMS は、大きなオブジェクトのデータ型 (BLOB、CLOB、NCLOB) の使用を完全にサポートするようになりました。以下のソースエンドポイントは、完全に LOB サポートされています。

以下のターゲットエンドポイントは、完全に LOB サポートされています。

以下のターゲットエンドポイントには、制限付きの LOB サポートがあります。このターゲットエンドポイントに無制限の LOB サイズは使用できません。

完全な LOB サポートがあるエンドポイントについては、LOB データ型にサイズ制限を設定できます。

LOB パフォーマンスが向上しました。

LOB データの移行時に、次の異なる LOB 最適化設定を指定できます。

テーブルごとの LOB 設定

テーブルごとの LOB 設定を使用すると、一部またはすべてのテーブルのタスクレベルの LOB 設定を上書きできます。これを行うには、table-settings ルール内の lob-settings を定義します。次に、大きな LOB 値を含むテーブルの例を示します。

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

次に、移行タスクを作成し、新しい lob-settings ルールを使用してテーブルの LOB 処理を変更します。bulk-max-siz 値は、最大 LOB サイズ (KB) を決定します。指定されたサイズより大きい場合は切り捨てられます。

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

たとえ AWS DMS タスクが FullLobMode : true で作成されても、テーブルごとの LOB 設定で AWS DMS はこの特定テーブルの LOB データを 16,000 に切り捨てるようになります。タスクログを確認して、これを確認できます。

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

インライン LOB 設定

AWS DMS タスクを作成するときは、LOB モードにより、LOB の処理方法が決まります。

フル LOB モードと限定 LOB モードでは、それぞれ独自の利点とデメリットがあります。インライン LOB モードは、フル LOB モードと制限付き LOB モードの両方の利点を組み合わせたものです。

小さい LOB と大きい LOB を両方ともレプリケーションの必要があり、ほとんどの LOB が小さい場合は、インライン LOB モードを使用できます。このオプションを選択すると、フルロード中に AWS DMS タスクは小さな LOB をインラインで転送するため、効率が向上します。AWS DMS タスクは、ソース テーブルからルックアップを実行して、大きな LOB を転送します。

変更処理中に、ソーステーブルからルックアップを実行して、小規模と大規模 LOB ともレプリケーションされます。

インライン LOB モードを使用する場合、AWS DMS タスクは、すべての LOB サイズをチェックして、インラインで転送するサイズを決定します。指定されたサイズよりも大きい LOB は、フル LOB モードを使用してレプリケーションされます。従って、ほとんどの LOB が指定された設定よりも大きいことがわかっている場合は、このオプションを使用しない方がよいでしょう。代わりに、無制限の LOB サイズを許可します。

このオプションは、FullLobMode が true に設定されているときのみ利用可能なタスク設定の属性 InlineLobMaxSize を使用して構成します。InlineLobMaxSize のデフォルト値は 0 で、範囲は 1～102,400 キロバイト (100 MB) です。

たとえば、次の AWS DMS タスク設定を使用できます。ここで InlineLobMaxSize 値を 5 に設定すると、5 KiB (5,120 バイト) 以下のすべての LOB がインラインで転送されます。

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

大規模なテーブルを移行する場合のパフォーマンスの向上

大規模なテーブルを移行する際のパフォーマンスを向上するには、移行を複数のタスクに分割します。行フィルタリングを使用して複数のタスクへの移行を分割するには、キーまたはパーティションキーを使用します。たとえば、1〜8,000,000 の整数プライマリキー ID がある場合、行フィルタリングを使用して 8 つのタスクを作成し、それぞれ 100 万レコードを移行できます。

日付でパーティション化された大規模なパーティションテーブルがある場合は、日付に基づいてデータを移行できます。たとえば、月別にパーティション化されたテーブルがあり、現在の月のデータのみが更新されたとします。この場合、静的な毎月のパーティションごとに全ロードタスクを作成し、現在更新されているパーティションに対して全ロード + CDC タスクを作成することができます。

テーブルに単一列のプライマリキーまたは固有インデックスがある場合は、AWS DMS タスクで範囲タイプの並列ロードを使用してテーブルをセグメント化し、データを並列にロードすることができます。詳細については、「テーブルとコレクション設定のルールとオペレーション」を参照してください。

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

AWS DMS は、ソースとターゲットのデータベースを同期させたまま、データの継続的なレプリケーションを行います。これは、限られた量のデータ定義言語 (DDL) のみレプリケーションします。AWS DMS​ は、インデックス、ユーザー、権限、ストアドプロシージャ、およびテーブルデータに直接関係しない他のデータベースの変更などの項目を反映しません。

継続的レプリケーションの予定があれば、レプリケーション インスタンスで [Multi-AZ] (マルチ AZ) オプションを有効にする必要があります。[Multi-AZ] (マルチ AZ) オプションは、レプリケーション インスタンスに対して高可用性とフェイルオーバーに対応しています。ただし、このオプションによって、パフォーマンスに影響を及ぼす可能性があり、ターゲット システムに変更を適用するときにレプリケーションの速度が低下する可能性があります。

ソース データベースまたはターゲット データベースをアップグレードする前に、これらのデータベースで実行されている AWS DMS のタスクを停止することをお勧めします。アップグレードが完了したら、タスクを再開します。

継続的レプリケーションでは、ソース データベース システムとAWS DMS レプリケーション インスタンス間のネットワーク帯域幅を特定することが重要です。継続的レプリケーション中にネットワークがボトルネックを引き起こさないようにしてください。

また、ソース データベース システムの 1 時間あたりの変更率とアーカイブログ生成率を特定することも重要です。これにより、継続的レプリケーション中に発生する可能性のあるスループットを理解するのに役立ちます。

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

AWS DMS は、ソースデータベースでいくつかのリソースを使用します。全ロードタスク中、AWS DMS では、並行処理される各テーブルに対してソーステーブルのテーブル全体のスキャンが実行されます。さらに、移行の一環として作成する各タスクは、CDC プロセスの一部としてソースに変更を問い合わせます。AWS DMS で、Oracle などの一部のソースの CDC を実行する場合は、データベースの変更ログに書き込むデータ量を増やす必要がある場合があります。

ソースデータベースに過度に負荷が掛かっている場合は、移行のタスクの数または、タスクごとのテーブルの数を減らすことができます。各タスクは独立してソースの変更を取得するため、タスクを統合することで変更キャプチャの作業負荷を減らすことができます。

ターゲットデータベースのボトルネックを減らす

移行中に、ターゲットデータベース上の書き込みリソースと競合するプロセスをすべて削除してください。

移行中にデータ検証を使用する

データがソースからターゲットに正確に移行されたことを確認するため、データ検証が推奨されます。タスクの検証を有効にすると、AWS DMS は、テーブルに対して全ロードが実行された後で、ソースデータとターゲットデータの比較をすぐに開始します。

データ検証は、AWS DMS がソースとターゲットのエンドポイントでサポートしている次のデータベースで動作します。

詳細については、「AWS DMS データ検証」を参照してください。

メトリクスを使用する AWS DMS タスクのモニタリング

AWS DMS コンソールを使用して、タスクのメトリクス モニタリング用にいくつかのオプションがあります:

モニタリング メトリクスの詳細については、「タスクのモニタリング AWS DMS 」をご参照ください。

イベントと通知

AWS DMS は Amazon SNS を使用して、レプリケーション インスタンスが作成されたときや削除されたときなど AWS DMS イベントが発生したとき通知を送信します。これらの通知は、AWS リージョンについて Amazon SNS でサポートされている任意の形式で操作できます。これには、電子メールメッセージ、テキストメッセージ、または HTTP エンドポイントへの呼び出しが含まれます。

詳細については、「AWS Database Migration Service での Amazon SNS イベントと通知の使用」を参照してください。

タスクログを使用して、移行の問題のトラブルシューティングをする

場合によっては、AWS DMS で、タスクログでのみ表示可能な問題が発生することがあります。特に、データ切り捨て問題または外部キー違反による行の拒否は、タスクログに書き込まれます。そのため、データベースを移行するときは、タスクログを確認することが重要です。タスクログを表示するには、タスク作成 CloudWatch の一部として Amazon を設定します。

詳細については、「Amazon を使用したレプリケーションタスクのモニタリング CloudWatch」を参照してください。

Time Travel を使用したレプリケーションタスクのトラブルシューティング

AWS DMS の移行に関する問題のトラブルシューティングには、Time Travel を利用できます。Time Travel の詳細については、「Time Travel タスクの設定」を参照してください。

Time Travel の使用を開始するには、次の考慮事項に注意します。

Oracle ターゲットのユーザーおよびスキーマの変更

Oracle をターゲットとして使用するとき、AWS DMS はターゲット　エンドポイントのユーザーが所有するスキーマにデータを移行します。

たとえば、PERFDATA という名前のスキーマを Oracle のターゲット　エンドポイントに移行するとして、ターゲット　エンドポイントのユーザー名が MASTER だとします。AWS DMS は Oracle ターゲットを MASTER として接続し、MASTER スキーマに PERFDATA からのデータベースオブジェクトを代入します。

この動作をオーバーライドするには、スキーマ変換を指定する必要があります。たとえば、PERFDATA スキーマ オブジェクトをターゲット エンドポイントの PERFDATA スキーマに移行する場合、次の変換を使用できます。

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

変換の詳細については、「 JSON を使用するテーブル選択および変換を指定する」をご参照ください。

Oracle ターゲットでテーブルとインデックスのテーブル スペースを変更する

Oracle をターゲットとして使用する場合、AWS DMS はすべてのテーブルとインデックスを、ターゲットのデフォルトのテーブルとインデックステーブルスペースに移行します。たとえば、ソースが Oracle ではないデータベースエンジンだとします。すべてのターゲットテーブルとインデックスは、同じデフォルトのテーブルスペースに移行されます。

この動作をオーバーライドするには、該当するテーブルスペース変換を指定する必要があります。たとえば、テーブルとインデックスをソースのスキーマから名付けられた Oracle ターゲットのテーブルとインデックスのテーブルスペースに移行するとします。この場合、次のような変換を使用できます。ここでは、ソース スキーマは INVENTORY と名付けられ、ターゲットの該当するテーブルとインデックスのテーブル スペースはそれぞれ INVENTORYTBL および INVENTORYIDX と名付けられます。

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

変換の詳細については、「 JSON を使用するテーブル選択および変換を指定する」をご参照ください。

Oracle がソースとターゲットの両方である場合、Oracle ソースの追加の接続属性 enableHomogenousTablespace=true を設定することで、既存のテーブルまたはインデックステーブルスペースの割り当てを保持できます。詳細については、「のソースとして Oracle を使用する場合のエンドポイント設定 AWS DMS」を参照してください。

レプリケーション インスタンスバージョンのアップグレード

AWS では、新機能とパフォーマンスの強化を含め、定期的に新しいバージョンの AWS DMS レプリケーション エンジン ソフトウェアをリリースしています。レプリケーション エンジン ソフトウェアの各バージョンには、他のバージョンと区別するための独自のバージョン番号があります。レプリケーション インスタンスを新しいバージョンにアップグレードする前に、AWS DMS の本番作業ロードを実行しているレプリケーションインスタンスの既存バージョンを必ずテストします。利用可能なバージョン アップグレードの詳細は、「AWS DMS リリースノート」をご参照ください。

移行コストについて

AWS Database Migration Service で、AWS にデータベースを簡単かつ安全にローコストで移行できます。レプリケーション インスタンスと追加のログストレージに対してのみ料金が発生します。各データベース移行インスタンスには、ほとんどのレプリケーションでスワップ領域、レプリケーション ログ、およびデータキャッシュに十分なストレージが含まれており、インバウンドデータ転送は無料です。

初期ロード時またはピークロード時にさらに多くのリソースが必要になる場合があります。クラウド ウォッチ メトリクスを使用して、レプリケーション インスタンスのリソース使用率を綿密に監視できます。その後、使用状況に基づいてレプリケーション インスタンスのサイズをスケールアップおよびスケールダウンできます。

移行コストの見積りの詳細については、以下をご参照ください。