AWS Database Migration Service のベストプラクティス - AWS データベース移行サービス

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

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

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

AWS Database Migration Service での移行の計画

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

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

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

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

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

  • [Diagnostic support script results] (診断サポートスクリプトの結果) — 移行を計画する場合は、診断サポートスクリプトを実行することをお勧めします。これらのスクリプトの結果から、移行の失敗の可能性に関する詳細情報を確認できます。

    サポートスクリプトがデータベースで使用できる場合は、次のセクションにある対応するスクリプトトピックのリンクを使用して、サポートスクリプトをダウンロードします。スクリプトを検証して確認したら、ローカル環境のスクリプトトピックで説明されている手順に従ってスクリプトを実行できます。スクリプトの実行が完了すると、結果を確認できます。トラブルシューティング作業の最初のステップとして、これらのスクリプトを実行することをお勧めします。この結果は、AWS Support チームと協力しているとき有用です。詳細については、「での診断サポートスクリプトの使用 AWS DMS」を参照してください。

  • [Premigration assessments] (移行前評価) — 移行前評価は、データベース移行タスクの指定されたコンポーネントを評価して、移行タスクが期待どおりに実行されない可能性のある問題を特定するのに役立ちます。この評価を使用すると、新規または変更されたタスクを実行する前に、潜在的な問題を特定できます。移行前の評価での作業の詳細については、「タスクの移行前評価の有効化と操作」をご参照ください。

スキーマの変換

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 がデータ型と文字セットの変換を処理する方法。

  • ラージオブジェクト (LOB) 列を持つテーブルの数。

  • テスト移行の実行所要時間。

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

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

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

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

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

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

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

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

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

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

AWS DMS は Amazon EC2 インスタンス上で実行されるマネージドサービスです。このサービスはソース データベースに接続するレプリケーション インスタンスを使用し、ソースデータを読み取り、ターゲットデータベースが使用できるようにデータをフォーマットし、ターゲットデータベースにデータをロードします。

この処理のほとんどはメモリ内で行われます。ただし、大きいトランザクションではディスクでのバッファリングが必要になることがあります。キャッシュされたトランザクションとログファイルもディスクに書き込まれます。以下のセクションでは、レプリケーション サーバーの選択時に考慮すべき点について説明します。

CPU

AWS DMS は異機種間移行用に設計されていますが、同種の移行もサポートしています。同種移行を実行するには、まず各ソースデータ型を同等の AWS DMS データ型に変換します。次に、それぞれのデータ型をAWS DMS ターゲット データ型に変換します。データベースエンジンごとにこれらの変換の参照は、AWS DMSユーザーガイドをご参照ください。

AWS DMS がこれらの変換を最適に実行するには、変換が発生したときに CPU が使用可能であることが前提です。CPU をオーバーロードし、十分な CPU リソースがないと、移行が遅くなり、他の副作用も引き起こす可能性があります。

レプリケーション インスタンスクラス

サービスのテストや小規模な移行の場合、いくつかの小さいインスタンスクラスで十分です。移行に多数のテーブルが関与する場合や、複数の同時レプリケーション タスクを実行する予定の場合、大きいインスタンスを 1 つ使用することを検討してください。サービスがかなりの量のメモリと CPU を消費するため、より大きなインスタンスを使用することをお勧めします。

T2 タイプのインスタンスは、適度なベースラインパフォーマンスを実現したり、ワークロードの必要に応じて非常に高いパフォーマンスまでバーストする機能を実現できるように設計されています。常時または一貫して CPU をフルに使用するわけではないが、バーストが必要なことがあるワークロード向けに用意されています。T2 インスタンスは、ウェブサーバー、デベロッパー環境、小規模データベースなどの汎用ワークロードに適しています。低速移行のトラブルシューティングで T2 インスタンスタイプを使用する場合は、CPU 使用率ホストメトリックスを確認します。これは、そのインスタンスタイプのベースラインを超えてバーストしているかどうかを確認できます。

この C4 インスタンスクラスは、大量の演算を行うワークロードで最高レベルのプロセッサパフォーマンスを実現するように設計されています。毎秒パケット (PPS) パフォーマンスが非常に高く、ネットワークジッターが低く、ネットワーク レイテンシーが低くなります。また、AWS DMS は特に Oracle から PostgreSQL への移行など、異機種間の移行やレプリケーションを実行する場合に、CPU を大量に消費することもあります。C4 インスタンスは、このような状況に適しています。

R4 インスタンスクラスは、メモリ負荷の大きいワークロード用に最適化されたメモリです。AWS DMS を使用する高スループット トランザクション システムの継続的移行やレプリケーションが原因で、大量の CPU やメモリを消費することがあります。R4 インスタンスは、vCPU 別のメモリが含まれます。

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

R5 インスタンスは、メモリ内の大きいデータ セットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されています。AWS DMS を使用する高スループット トランザクション システムの継続的移行やレプリケーションが原因で、大量の CPU やメモリを消費することがあります。R5 インスタンスは、R4 より vCPU あたり 5% の追加メモリを提供し、最大サイズは 768 GiB のメモリを提供します。さらに、R5 インスタンスは GiB あたりの価格を 10% 向上させ、R4 に比べて CPU パフォーマンスを約 20% 向上させます。

C5 インスタンスクラスは、計算負荷の高いワークロードに最適化されており、コンピューティング比あたりの低価格で費用対効果の高いパフォーマンスを提供します。これにより、ネットワークパフォーマンスが大幅に向上します。Elastic Network Adapter (ENA) は、Amazon EBS に最大 25 Gbps のネットワーク帯域幅と最大 14 Gbps の専用帯域幅を C5 インスタンスで提供します。AWS DMS は特に、異機種間 (例:Oracle から PostgreSQL) の移行やレプリケーションを実行する場合に、CPU を大量に消費する可能性があります。C5 インスタンスは、このような状況に適しています。

[Storage (ストレージ)]

選択した インスタンスクラスに応じて、レプリケーション インスタンスには 50 GB または 100 GB のデータストレージが付属しています。このストレージは、ロード中に収集されるログファイルおよびキャッシュされた変更に使用されます。ソースシステムがビジー状態であるか、大量のトランザクションを実行する場合は、ストレージを増やす必要がある場合があります。レプリケーション サーバーで複数のタスクを実行している場合は、ストレージを増やすことも必要になる場合があります。ただし、通常はデフォルトの量で十分です。

AWS DMS 内のすべてのストレージボリュームは GP2 または汎用ソリッド ステート ドライブ (SSD) です。GP2 ボリュームには、1 秒あたり 3 つの I/O オペレーション (IOPS) のベースパフォーマンスがあり、クレジットベースで最大 3,000 IOPS をバーストできます。経験則として、ReadIOPSWriteIOPSのレプリケーション インスタンスのメトリクスを確認します。これらの値の合計が、そのボリュームのベースパフォーマンスを超えないようにしてください。

マルチ AZ

マルチ AZ インスタンスを選択すると、ストレージ障害から移行を保護できます。ほとんどの移行は一時的なものであり、長期間実行することを意図していません。継続的レプリケーションで AWS DMS を使用する場合、マルチ AZ インスタンスを選択すると、ストレージの問題が発生した場合に可用性が向上します。

フルロード中に単一の AZ またはマルチ AZ レプリケーションインスタンスを使用して、フェイルオーバーまたはホストの交換が発生すると、フルロードのタスクが失敗することが予想されます。移行が完了しなかったテーブル、またはエラー状態にある残りのテーブルについては、障害が発生した時点からタスクを再開できます。

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

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

AWS Management Console でこの数を変更するには、コンソールを開き、[Tasks] (タスク) を選択後、タスクの作成または変更を選択してから、[Advanced Settings] (詳細設定) を選択します。[Tuning Settings] (チューニング設定) で、[Maximum number of tables to load in parallel] (並列にロードするテーブルの最大数) オプションを変更します。

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

並列全ロードの使用

パーティションとサブパーティションに基づいて、Oracle、Microsoft SQL Server、MySQL、Sybase、および IBM Db2 LUW ソースからの並列ロードを使用できます。これにより、全体の全負荷時間が短縮されます。さらに、AWS DMS 移行タスクの実行中に、大きなテーブルまたはパーティションテーブルの移行を高速化できます。これを行うには、テーブルをセグメントに分割し、同じ移行タスクでセグメントを並行してロードします。

並列ロードを使用するには、parallel-load オプションを指定した table-settings タイプのテーブルマッピングルールを作成します。table-settings ルール内では、並列でロードする 1 つ以上のテーブルに選択条件を指定します。選択条件を指定するには、parallel-loadtype 要素を次のいずれかに設定します。

  • partitions-auto

  • subpartitions-auto

  • partitions-list

  • ranges

  • none

これらの設定の詳細については、「テーブルとコレクション設定のルールとオペレーション」をご参照ください。

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

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

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

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

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

カットオーバーの直前にトリガーを有効にする必要があります。

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

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

複数のタスクを使用する

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

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

変更処理の最適化

デフォルトでは、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 リゾルバーのアーキテクチャー

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

Amazon Route 53 Resolver の AWS DMS での使用

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

Route 53 に基づく AWS DMS のオンプレミスネームサーバーを作成するには
  1. AWS Management Console にサインインし、Route 53 コンソール (https://console.aws.amazon.com/route53/) を開きます。

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

ラージバイナリオブジェクト (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 つのメソッドを使用します。

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

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

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

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

  • Oracle

  • Microsoft SQL Server

  • ODBC

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

  • Oracle

  • Microsoft SQL Server

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

  • Amazon Redshift

  • Amazon S3

完全な 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 サイズを許可します。

このオプションは、FullLobModetrue に設定されているときのみ利用可能なタスク設定の属性 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 万レコードを移行できます。

コンソールで行フィルタリングを適用するには、次を実行します。
  1. AWS Management Consoleを開きます。

  2. [タスク] を選択して、新しいタスクを作成します。

  3. [Table mappings] (テープル マッピング) を選択し、[Selection rules] (選択ルール) を展開します。

  4. [Add new selection rule] (新規選択ルールの追加) を選択します。これで、次以下:、次以上:、次と等しい:、または 2 つの値の範囲の条件の列フィルターを追加できます。列フィルターの詳細については、「 コンソールからテーブル選択および変換を指定する」を参照してください。

日付でパーティション化された大規模なパーティションテーブルがある場合は、日付に基づいてデータを移行できます。たとえば、月別にパーティション化されたテーブルがあり、現在の月のデータのみが更新されたとします。この場合、静的な毎月のパーティションごとに全ロードタスクを作成し、現在更新されているパーティションに対して全ロード + 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 を実行する場合は、データベースの変更ログに書き込むデータ量を増やす必要がある場合があります。

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

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

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

  • 不要なトリガーをオフにします。

  • 初期ロード時にセカンダリ インデックスをオフにし、継続的レプリケーション中に後でオンに戻します。

  • Amazon RDS データベースでは、カットオーバーまでバックアップとマルチ AZ をオフにすることをお勧めします。

  • 非 RDS システムに移行する場合、カットオーバーまでターゲット上のロギングをオフにすることをお勧めします。

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

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

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

  • Oracle

  • PostgreSQL

  • MySQL

  • MariaDB

  • Microsoft SQL Server

  • Amazon Aurora MySQL 互換エディション

  • Amazon Aurora PostgreSQL 互換エディション

  • IBM Db2 LUW

  • Amazon Redshift

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

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

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

ホスト メトリクス

ホストメトリクスは、特定のレプリケーション インスタンスのCloudWatch メトリクス タブにあります。ここでは、レプリケーション インスタンスのサイズが適切かどうかを監視できます。

レプリケーションタスクのメトリクス

受信およびコミットされた変更、レプリケーションホストとソース/ターゲットデータベース間のレイテンシーなどのレプリケーションタスクのメトリクスは、特定のタスクのCloudWatch メトリクスタブにあります。

テーブル メトリクス

個々のテーブル メトリクスは、[Table statistics] (テーブルの統計) タブで個々のタスクごとに表示されます。これらのメトリクスには、次の数値が含まれます。

  • 全ロード中にロードされた行。

  • タスクの開始後に挿入、更新、削除を行います。

  • タスク開始後の DDL オペレーション。

モニタリング メトリクスの詳細については、「タスクのモニタリング 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 の使用を開始するには、次の考慮事項に注意します。

  • DMS レプリケーションインスタンスのオーバーヘッドを避けるため、デバッグが必要なタスクに対してのみ Time Travel をオンにします。

  • Time Travel を使用して数日間実行される可能性があるレプリケーションタスクのトラブルシューティングを行う場合は、リソースのオーバーヘッドがないかレプリケーションインスタンスのメトリクスをモニタリングします。ソースデータベースで長時間にわたり、高いトランザクション負荷がかかる場合には特にこのアプローチをとることが適切となります。詳細については、「タスクのモニタリング AWS DMS 」を参照してください。

  • Time Travel タスクの設定でEnableRawDatatrue と設定されている場合、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 にデータベースを簡単かつ安全にローコストで移行できます。レプリケーション インスタンスと追加のログストレージに対してのみ料金が発生します。各データベース移行インスタンスには、ほとんどのレプリケーションでスワップ領域、レプリケーション ログ、およびデータキャッシュに十分なストレージが含まれており、インバウンドデータ転送は無料です。

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

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