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

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

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

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

AWS Database Migration Service での移行の計画

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

  • ソースとターゲットのデータベースを AWS DMS レプリケーションインスタンスに接続するネットワークを設定する必要があります。これは、同じ VPC 内にある 2 つの AWS リソースをより複雑な設定にレプリケーションインスタンスとして接続する (オンプレミスデータベースを VPN 経由で Amazon RDS DB インスタンスに接続するなど) のと同じくらい簡単です。詳細については、「データベース移行のネットワーク設定」を参照してください

  • ソースとターゲットのエンドポイント – ソースデータベース内のどの情報とテーブルをターゲットデータベースに移行する必要があるかを知っている必要があります。AWS DMS では、テーブルとプライマリキーの作成を含む、基本的なスキーマの移行がサポートされています。ただし、AWS DMS では、ターゲットデータベースのセカンダリインデックス、外部キー、ユーザーアカウントなどは自動的に作成されません。ソースおよびターゲットデータベースエンジンによっては、サプリメンタルロギングをセットアップしたり、ソースまたはターゲットデータベースの他の設定を変更したり必要がある点に注意してください。詳細については、「データ移行のソース」および「データ移行のターゲット」を参照してください。

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

  • サポートされていないデータ型 – ソースの一部のデータ型は、ターゲットデータベースのデータ型と同等のデータ型に変換する必要があります。サポートされているデータ型の詳細については、データストアのソースまたはターゲットセクションを参照してください。

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

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

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

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

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

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

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

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

テストでは、最適な条件のもとで単一の–タスクを使用して、約 12AWS DMS13 時間で 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 は、トランザクションの完全性を維持するトランザクションモードで変更を処理します。トランザクションの完全性を一時的に失効できる場合は、代わりに [最適化バッチ] オプションを使用できます。このオプションでは、効率的にトランザクションがグループ化され、効率化のためにバッチに適用します。[最適化バッチ] オプションを使用することは、ほぼ常に参照整合性制約に違反します。移行プロセス中はこれらを無効化し、カットオーバープロセスの一環として再度有効にすることをお勧めします。

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

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、MySQLWorkbench などのツールを使用するか、スキーマを移動することができます。PgAdmin4

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

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

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

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

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

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

制限付き LOB モードの使用

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

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

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

PostgreSQLなど、一部のデータベースエンジンに対して、 AWS DMSは のように JSON データ型を処理しますLOBs。 Limited LOB mode を選択した場合、最大 LOB サイズオプションが、JSON データが切り捨てられない値に設定されていることを確認します。

AWS DMSCLOBsでは、大きなオブジェクトのデータ型 (BLOB、 、および ) の使用が完全にサポートされますNCLOBs。以下のソースエンドポイントは、完全に LOB サポートされています。

  • Oracle

  • Microsoft SQL Server

  • ODBC

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

  • Oracle

  • Microsoft SQL Server

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

  • Amazon Redshift

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の図は、Route 53リゾルバーのアーキテクチャを示しています。


                Route 53 リゾルバーのアーキテクチャ

AWS Route-53 DNS リゾルバーの詳細については、「Route 53 リゾルバーの開始方法」を参照してくださいAmazon Route 53 開発者ガイド

でのAmazon Route 53リゾルバーの使用AWS DMS

を使用してエンドポイントを解決するAWS DMSには、 のオンプレミスネームサーバーを作成しますAmazon Route 53 Resolver。プロセスの説明は次のとおりです。

に基づいて DMS 用のオンプレミスネームサーバーを作成するにはRoute 53

  1. AWS マネジメントコンソールにサインインし、https://console.aws.amazon.com/route53/ にある Route 53 コンソールを開きます。

  2. Route 53コンソールで、Route 53リゾルバーを設定する AWS リージョンを選択します。Route 53リゾルバーはリージョンに固有です。

  3. クエリの方向 (インバウンド、アウトバウンド、またはその両方) を選択します。—

  4. インバウンドクエリ設定を指定します。

    1. エンドポイント名を入力し、VPC を選択します。

    2. VPC 内からサブネットを 1 つ以上割り当てます (たとえば、可用性のため 2 つを選択します)。

    3. エンドポイントとして使用する特定の IP アドレスを割り当てるか、Route 53リゾルバーによって自動的に割り当てられます。

  5. VPC 内のワークロードが DNS クエリを DNS インフラストラクチャにルーティングできるように、オンプレミスドメインのルールを作成します。

  6. オンプレミス DNS サーバーの 1 つ以上の IP アドレスを入力します。

  7. ルールを送信します。

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

Route 53リゾルバーの詳細については、の「Route 53 リゾルバーの開始方法」を参照してくださいAmazon Route 53 開発者ガイド。

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。 詳細については、「」を参照してください。AWS DMS のソースとして Oracle を使用する場合の追加の接続属性