AWS Database Migration Service
ユーザーガイド (Version API Version 2016-01-01)

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

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

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

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

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

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

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

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

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

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

テストでは、最適な条件のもとで単一の AWS DMS タスクを使用して、約 12 ~ 13 時間で 1 テラバイトのデータを移行しました。これらの最適な条件には、Amazon EC2 で実行される Amazon RDS のソースデータベース、および Amazon RDS のターゲットデータベースの使用が含まれます。それらはすべて同じアベイラビリティーゾーンにあります。ソースデータベースには、最大 250 GB のデータを含むいくつかの大きなテーブルに比較的均等に分散されたデータの典型的な量が含まれます。ソースデータには、BLOB などの複雑なデータ型は含まれていませんでした。

パフォーマンスを向上させるには、次のベストプラクティスの一部またはすべてを使用します。これらのプラクティスを使用できるかどうかは、特定のユースケースに大きく左右されます。必要に応じて制限事項について言及します。

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

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

AWS マネジメントコンソールでこの数を変更するには、コンソールを開き、[タスク] を選択後、タスクの作成または変更を選択してから、[Advanced Settings (詳細設定)] を選択します。[Tuning Settings (チューニング設定)] で、[並列にロードするテーブルの最大数] オプションを変更します。

AWS CLI を使用してこの数を変更するには、TaskSettingsMaxFullLoadSubTasks パラメータを変更します。

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

インデックス、トリガーおよび参照整合性制約は、移行パフォーマンスに影響を及ぼすことがあるため、移行が失敗する原因になります。これらが移行に及ぼす影響は、レプリケーションタスクが全ロードタスクであるか、継続的なレプリケーション (CDC) タスクであるかによって異なります。

全ロードタスクの場合は、プライマリキーインデックス、参照整合性制約、データ操作言語 (DML) トリガーを削除することをお勧めします。または、全ロードタスクが完了するまで、その作成を遅延させることができます。全ロードタスク中、インデックスは不要であり、存在する場合、インデックスはメンテナンスのオーバーヘッドが発生します。全ロードタスクは一度にテーブルのグループをロードするため、参照整合性の制約に違反します。同様に、挿入、更新、および削除トリガーは、たとえば、以前に一括ロードされたテーブルに対して行の挿入がトリガーされた場合にエラーを引き起こす可能性があります。他のタイプのトリガーも、追加された処理のためにパフォーマンスに影響を及ぼします。

データボリュームが比較的少なく、追加の移行時間が重要でない場合は、全ロードタスクの前にプライマリキーとセカンダリインデックスを作成できます。参照整合性制約とトリガは常に無効にする必要があります。

全ロード + CDC タスクの場合は、CDC フェーズの前にセカンダリインデックスを追加することをお勧めします。AWS DMS は論理的なレプリケーションを使用するため、DML オペレーションをサポートするセカンダリインデックスをインプレースして、完全なテーブルスキャンを防止する必要があります。CDC フェーズの前にレプリケーションタスクを一時停止して、そのタスクを再開する前にインデックスを作成後、トリガーを作成し、参照整合性制約を作成することができます。

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

Amazon RDS データベースに移行する場合、カットオーバーの準備ができるまでは、ターゲットのバックアップとマルチ AZ を無効にすることをお勧めします。同様に、Amazon 以外の RDS システムに移行する場合、カットオーバーまではターゲットのロギングを無効にすることをお勧めします。

複数のタスクを使用する

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

複数のタスクを使用して、個別のレプリケーションストリームを作成して、ソース上の読み取り、レプリケーションインスタンス上のプロセス、およびターゲットデータベースへの書き込みを並列化することができます。

変更処理の最適化

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

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

適切なレプリケーションインスタンスの選択は、ユースケースのいくつかの要因によって異なります。レプリケーションインスタンスリソースの使用方法を理解しやすいように、次の説明を参照してください。全ロードと CDC タスクの一般的なシナリオを説明します。

全ロードタスク中、AWS DMS はテーブルを個別にロードします。デフォルトでは、一度に 8 つのテーブルがロードされます。AWS DMS では完全ロードタスク中に継続的な変更がキャプチャされるため、この変更を後でターゲットエンドポイントに適用することができます。変更はメモリにキャッシュされます。使用可能なメモリがなくなると、変更はディスクにキャッシュされます。テーブルの全ロードタスクが完了すると、AWS DMS はキャッシュされた変更をただちにターゲットテーブルに適用します。

テーブルのキャッシュされた変更がすべて適用されると、ターゲットエンドポイントはトランザクション上一貫性のある状態になります。この時点で、ターゲットは、最後にキャッシュされた変更に関して、ソースエンドポイントと同期しています。次に AWS DMS はソースとターゲット間の継続的なレプリケーションを開始します。そのために、AWS DMS ではソーストランザクションログからの変更オペレーションを行い、トランザクションに一貫性のある方法でターゲットに適用します (バッチ最適化適用が選択されていないと仮定)。可能な場合、AWS DMS は、レプリケーションインスタンスのメモリを介して、継続的な変更をストリーミングします。それ以外の場合、AWS DMS は、ターゲットに適用できるようになるまで変更をレプリケーションインスタンスのディスクに書き込みます。

レプリケーションインスタンスが変更処理をどのように処理するか、およびそのプロセスでメモリがどのように使用されるかについて、何らかの制御があります。変更処理のチューニング方法の詳細については、「変更処理のチューニング設定」を参照してください。

上記の説明から、使用可能なメモリの合計が重要な考慮事項であることがわかります。レプリケーションインスタンスに十分なメモリがあるため、AWS DMS でキャッシュされた継続的な変更をディスクに書き込まずにストリーミングできる場合は、移行のパフォーマンスが大幅に向上します。同様に、変更キャッシングとログストレージに対応するのに十分なディスク容量を持つレプリケーションインスタンスを設定すると、パフォーマンスも向上します。有効な最大 IOPS は選択したディスクサイズによって異なります。

レプリケーションインスタンスクラスと使用可能なディスクストレージを選択する際、次の要素を考慮してください。

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

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

  • トランザクションサイズ – 長時間実行されるトランザクションでは、多くの変更が生成される可能性があります。最適なパフォーマンスを得るために、AWS DMS がトランザクションモードで変更を適用する場合は、トランザクションのすべての変更をストリーミングするのに十分なメモリが利用できる状態である必要があります。

  • 移行の合計サイズ - 大規模な移行には時間がかかり、それ比例して多数のログファイルが生成されます。

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

  • ラージオブジェクト -LOB でテーブルをロードするには時間がかかります。

事例証拠は、ログファイルが AWS DMS に必要な領域の大半を使用することを示しています。デフォルトのストレージ設定は、通常は十分です。

ただし、複数のタスクを実行するレプリケーションインスタンスには、さらに多くのディスク容量が必要な場合があります。さらに、データベースに大きいアクティブなテーブルが含まれる場合は、全ロードタスク中にディスクにキャッシュされるトランザクションのためのディスクスペースを増やさなければならない場合があります。たとえば、ロードに 24 時間かかり、1 時間あたり 2 GB のトランザクションが発生する場合は、キャッシュされるトランザクションに対応するために 48 GB の空き領域があることを確認します。また、レプリケーションインスタンスに割り当てるストレージ領域が増えるほど、取得する IOPS も高くなります。

上記のガイドラインは考えられるすべてのシナリオをカバーしていません。レプリケーションインスタンスのサイズを決定する際に、特定のユースケースの詳細を検討することが重要です。移行が実行されたら、レプリケーションインスタンスの CPU、空きメモリ、空き領域、および IOPS を監視します。収集したデータに基づいて、必要に応じてレプリケーションインスタンスのサイズを増減することができます。

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

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

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

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

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

スキーマの変換

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

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

ソースおよびターゲットエンドポイントが同じデータベースエンジンの場合は、Oracle SQL Developer、MySQL Workbench、または PgAdmin4 などのツールを使用して、スキーマを起動できます。

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

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

  1. AWS DMS は、ターゲットテーブルに新しい行を作成し、その行に関連する LOB 値を除くすべてのデータを入力します。

  2. AWS DMS は、ターゲットテーブルの行を LOB データで更新します。

この 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 つのメソッドを使用します。

  • [制限付き LOB モード] は、すべての LOB 値をユーザー指定のサイズ制限 (デフォルトは 32 KB) に移行します。サイズ制限を超える LOB 値は、手動で移行する必要があります。[制限付き LOB モード]、すべての移行タスクのデフォルトで、通常最高のパフォーマンスが得られます。ただし、[最大 LOB サイズ] パラメータの設定が正しいことを確認する必要があります。このパラメータは、すべてテーブルに対して最大の LOB サイズに設定する必要があります。

  • [完全 LOB モード] は、サイズに関係なくテーブル内のすべての LOB データを移行します。[完全 LOB モード] は、テーブル内のすべての LOB データを移動する際の利便性を提供しますが、そのプロセスがパフォーマンスに重大な影響を与える可能性があります。

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

AWS DMS は、大きなオブジェクトのデータ型 (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​ は、インデックス、ユーザー、権限、ストアドプロシージャ、およびテーブルデータに直接関係しない他のデータベースの変更などの項目を反映しません。

継続的なレプリケーションを使用する予定がある場合は、レプリケーションインスタンスで [マルチ AZ] オプションを有効にする必要があります。[マルチ AZ] オプションは、レプリケーションインスタンスに対して高可用性とフフェイルオーバーサポートを提供します。ただし、このオプションによって、パフォーマンスに影響を及ぼす可能性があります。

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 をターゲットとして使用するときにソースも Oracle の場合には、AWS DMS はテーブルスペースをソースで定義されているように移行します。ただし、ソースが 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 を使用するテーブルマッピングによりテーブル選択および変換を指定する」を参照してください。

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

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

AWS マネジメントコンソールで行フィルタリングを適用するには、コンソールを開き、[タスク] を選択してから、新しいタスクを作成します。[テーブルマッピング] セクションで、[Selection Rule (選択ルール)] の値を追加します。次に、(2 つの値の間で) より小さいか等しい、より大きいか等しい、等しいまたは範囲条件の列フィルタを追加できます。列フィルタについての詳細は、「 コンソールからのテーブルマッピングによりテーブル選択および変換を指定する」を参照してください。

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