メニュー
AWS Database Migration Service
ユーザーガイド (Version API バージョン: 2016-01-01)

ベストプラクティス

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

AWS Database Migration Service 移行のパフォーマンスの向上

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

  • ソースのリソース可用性

  • 利用可能なネットワークスループット

  • レプリケーションサーバーのリソース容量

  • ターゲットの変更取り込み機能

  • ソースデータのタイプとディストリビューション

  • 移行するオブジェクトの数

テストでは、最適な条件のもとで約 12〜13 時間で、1 テラバイトのデータを移行しました。 これらの最適な条件には、Amazon Elastic Compute Cloud (Amazon EC2) で実行される Amazon Relational Database Service (Amazon RDS) のソースデータベース、および Amazon RDS のターゲットデータベースの使用が含まれます。 ソースデータベースには、最大 250 GB のデータを含むいくつかの大きなテーブルに比較的均等に分散されたデータの典型的な量が含まれます。

移行のパフォーマンスは、その途中で、1 つ以上のボトルネックによって制限される場合があります。 次のリストは、パフォーマンスを高めるためにできることをいくつか示しています。

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

デフォルトでは AWS DMS は、一度に 8 つのテーブルをロードします。 dms.c4.xlarge またはより大きなインスタンスなどの大量レプリケーションサーバーを使用する際、これを少し増やすことによりパフォーマンスがある程度向上する場合があります。 ただし、ある時点で並列処理を増やすことによりパフォーマンスが低下します。 レプリケーションサーバーが、dms.t2.medium など、比較的小さい場合は、この数を減らします。

ターゲットのボトルネックを削除する

移行中に、ターゲットデータベースの書き込みリソースに対して相互に競合する可能性があるプロセスの削除を試行します。 このプロセスの一環として、不要なトリガーと認証、セカンダリインデックスを無効にします。 Amazon RDS データベースに移行する場合、カットオーバーの準備ができるまでは、ターゲットのバックアップとマルチ AZ を無効にすることをお勧めします。 同様に、Amazon 以外の RDS システムに移行する場合、カットオーバーまではターゲットのロギングを無効にすることをお勧めします。

複数のタスクを使用する

時には、単一の移行のために複数のタスクを使用することでパフォーマンスが向上します。 共通のトランザクションに関与しないテーブルのセットがある場合、複数のタスクに移行を分割できる場合があります。 トランザクションの整合性はタスク内に維持されます。したがって、個別のタスクのテーブルが、共通のトランザクションに関与しないことが重要です。 また、各タスクはそれぞれ独立してトランザクションのストリームを読み込みため、ソースシステムに過度のストレスをかけないよう注意が必要です。

LOB パフォーマンスの向上

LOB の移行の改善については、「ラージバイナリオブジェクト (LOB) の移行」を参照してください。

変更処理の最適化

デフォルトでは、AWS DMS は、トランザクションの完全性を維持する [トランザクションモード] で、変更を処理します。 トランザクションの完全性を一時的に失効できる場合は、代わりに [最適化バッチ] オプションを使用できます。 このオプションでは、効率的にトランザクションがグループ化され、効率化のためにバッチに適用します。 [最適化バッチ] オプションを使用することは、ほぼ確実に参照整合性制約に違反するため、移行プロセス中はこれらを無効にし、カットオーバープロセスの一環として、再度有効にする必要があることに注意してください。

レプリケーションインスタンス用に最適なサイズを決定する

レプリケーションインスタンスの正しいサイズの決定はいくつかの要因によって変わります。 以下の情報は、移行プロセスおよびメモリやストレージがどのように使用されるかを理解するのに役立ちます。

テーブルは、個別にロードされます。デフォルトでは、一度に 8 つのテーブルがロードされます。 各テーブルのロード中、そのテーブルのトランザクションはメモリにキャッシュされます。 使用可能なメモリを使用すると、トランザクションはディスクにキャッシュされます。 そのようなトランザクションのテーブルをロードすると、そのテーブルのトランザクションとそれ以降のトランザクションはテーブルにすぐに適用されます。

すべてのテーブルがロードされ、個々のテーブルの未処理のキャッシュされたトランザクションすべてが AWS DMS によって適用される場合、ソーステーブルとターゲットテーブルが同期されます。 この時点では、AWS DMS は、トランザクションの整合性を維持する方法でトランザクションが適用されます。 (ご覧のとおり、テーブルフルロード時、および個々のテーブルのキャッシュしたトランザクションが適用されている間は同期されていません。)

前の説明から、キャッシュされたトランザクションを保持するのに必要なのは、比較的小さいディスク領域であることが分かります。 特定の移行に使用するディスク領域の量は以下の要因によって決まります。

  • テーブルサイズ - 大きいテーブルでは、ロードに時間がかかり、そのため、テーブルがロードされるまでこれらのテーブルのトランザクションはキャッシュされる必要があります。 テーブルにロードされたら、これらのキャッシュされたトランザクションが適用されて、ディスクでは保持されなくなります。

  • データ操作言語 (DML) のアクティビティ - 使用中のデータベースはさらにトランザクションを生成します。 これらのトランザクションはテーブルがロードされるまでキャッシュされる必要があります。 すべてのテーブルがロードされるまで、テーブルがロードされると直ちに個々のテーブルにトランザクションが適用されることに注意してください。 この時点で AWS DMS は、すべてのトランザクションを適用します。

  • トランザクションのサイズ - 大規模なトランザクションによって生成された–データはキャッシュされる必要があります。 テーブルがフルロードプロセス中に 10 GB のトランザクションを蓄積する場合、それらのトランザクションはフルロードが完了するまでキャッシュされる必要があります。

  • 移行の合計サイズ - –大きな移行には時間がかかり、生成されたログファイルは大きくなります。

  • タスクの数 - さらに多くのタスクとキャッシュが必要となり、さらに多くのログファイルが生成されます。

事例証拠は、ログファイルが AWS DMS に必要な領域の大半を使用することを示しています。 デフォルトのストレージ設定は、通常は十分です。 複数のタスクを実行するレプリケーションインスタンスには、さらに多くのディスク容量が必要な場合があります。さらに、データベースに大きいアクティブなテーブルが含まれる場合は、フルロード中にディスクにキャッシュされるトランザクションを考慮する必要があります。たとえば、ロードに 24 時間かかり、1 時間あたり 2 GB のトランザクションが発生する場合は、キャッシュされるトランザクションに対応するために 48 GB の空き領域があることを確認します。

ソースデータベースのロードを削減する

移行中、AWS DMS では、並行処理される各テーブルに対してソーステーブルのテーブル全体のスキャンが実行されます。 また、各タスクは変更情報のためソースの定期的なクエリを実行します。 変更処理を実行するにはデータベース変更ログに書き込まれたデータの量を増やすことが必要な場合もあります。 ソースデータベースに過度に負荷を負わせている場合は、移行のタスクの数または、タスクごとのテーブルの数 (またはその両方) を減らすことができます。 ソースに負荷を追加しない場合は、ソースシステムの読み込みコピーから移行を実行することをご検討ください。 ただし、読み込みコピーを使用するとレプリケーションの遅延が増加します。

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

DMS で、現在タスクログでのみ表示可能な問題 (警告またはエラー) が発生する場合があります。 特に、データ切り捨て問題または外部キー違反による行の拒否は、現在はタスクログを介してのみ表示されます。 そのため、データベースを移行するときは、タスクログを確認することが重要です。

スキーマ変換

AWS DMS は、スキーマまたはコード変換を実行しません。ソースとターゲットが同じデータベースエンジンの場合、Oracle SQL Developer、MySQL Workbench、または pgAdmin III などのツールを使用して、スキーマを起動できます。異なるデータベースエンジンに既存のスキーマを変換する場合、AWS スキーマ変換ツールを使用できます。このツールは、ターゲットスキーマを作成でき、スキーマ全体 (テーブル、インデックス、ビューなど) を生成および作成することもできます。このツールを使用して PL/SQL または TSQL を PgSQL や他の形式に変換することもできます。AWS スキーマ変換ツールの詳細については、「AWS スキーマ変換ツール」を参照してください。

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

LOB データを移行することは、2 段階で行われます。 まず、LOB 列の行が LOB データなしでターゲットテーブルに作成されます。 次に、ターゲットテーブルの行は LOB データで更新されます。 つまり、移行中、テーブルの LOB 列はターゲットデータベースで NULLABLE になっている必要があることを意味します。 AWS DMS がターゲットテーブルを作成する場合は、ソーステーブルで NULLABLE でなくても、LOB 列は NULLABLE に設定されます。 Import/Export などの他のメカニズムを使用してターゲットテーブルを作成した場合、LOB 列が NULLABLE である必要があります。

デフォルトで、レプリケーションタスクは [Full LOB] サポートモードで実行するように設定されます。 この設定がテーブルのすべての LOB を移動する場合、プロセスも遅くなります。 移行タスクの実行速度を向上するには、新しいタスクを作成し、「制限付きサイズ LOB」 モードを使用するためにタスクを設定する必要があります。 このモードを選択した場合、MAX LOB パラメータの設定が正しいことを確認する必要があります。 このパラメータは、すべてテーブルに対して最大の LOB サイズに設定する必要があります。

可能な限り、最適なパフォーマンスのために [limited LOB mode] パラメータを使用します。いくつかの大きな LOB と主に小さな LOB を含むテーブルがある場合は、移行する前にテーブルを分割し、移行の一環としてテーブルのフラグメントを統合することを検討してください。

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

  • Oracle

  • Microsoft SQL Server

  • ODBC

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

  • Oracle

  • Microsoft SQL Server

以下のターゲットエンドポイントは、制限付きの LOB サポートをされています。 これらのターゲットエンドポイントに無制限の LOB サイズは使用できません。

  • Amazon Redshift

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

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

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

継続的なレプリケーションを使用する場合は、レプリケーションインスタンスで [Multi-AZ] オプションを有効にする必要があります。[Multi-AZ] オプションでは、レプリケーションインスタンスの高可用性とフェイルオーバーサポートが提供されます。

Oracle ターゲットのユーザー/スキーマの変更

Oracle をターゲットとして使用するときは、ターゲット接続に使用されるスキーマ/ユーザーにデータを移行することを前提とします。別のスキーマにデータを移行する場合は、スキーマ変換を使用する必要があります。たとえば、ターゲットエンドポイントがユーザー RDSMASTER に接続し、ユーザー PERFDATA から PERFDATA に移行する場合は、以下のように変換を作成する必要があります。

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

変換の詳細については、「 JSON を使用した選択および変換テーブルマッピング」を参照してください。