AWS DMS のコンポーネント

このセクションでは、AWS DMS の内部コンポーネントと、データ移行におけるそのコンポーネントの動作について説明します。AWS DMS の基礎となるコンポーネントを理解することで、効率的にデータを移行し、問題のトラブルシューティング時および調査時に優れた洞察を得ることができます。

AWS DMS移行は、移行するデータベースの検出、自動スキーマ変換、レプリケーションインスタンス、ソースとターゲットのエンドポイント、レプリケーションタスクの 5 つのコンポーネントで構成されます。AWS DMS移行を作成するには、必要なレプリケーションインスタンス、エンドポイントのおよびタスクをAWS リージョンに作成します。

データベース検出

DMS Fleet Advisor は、複数のデータベース環境からデータを収集し、データインフラストラクチャに関するインサイトを提供します。DMS Fleet Advisor は、すべてのコンピューターにインストールする必要なく、1 つ以上の中央ロケーションからオンプレミスデータベースと分析サーバーからデータを収集します。現在、DMS Fleet Advisor は、Microsoft SQL、MySQL、Oracle、および PostgreSQL データベースサーバーをサポートしています。

ネットワークから検出されたデータに基づいて、DMS Fleet Advisor は、モニタリング対象のデータベースサーバーとオブジェクトを決定するために確認できるインベントリを構築します。これらのサーバー、データベース、およびスキーマの詳細が収集されるため、目的とするデータベース移行を実行可能かを分析できます。

スキーマおよびコード移行

DMS AWS DMS スキーマ変換により、異なるタイプのデータベース間のデータベース移行をより予測しやすくなります。DMS Schema Conversion を使用してソースデータプロバイダーの移行の複雑さを評価し、それを使用してデータベーススキーマとコードオブジェクトを変換できます。その後、変換されたコードをターゲットのデータベースに適用できます。

大まかに言うと、DMS Schema Conversion はインスタンスプロファイル、データプロバイダー、移行プロジェクトの 3 つのコンポーネントで動作します。インスタンスプロファイルは、ネットワークとセキュリティの設定を指定します。データプロバイダーは、データベース接続認証情報を保存します。移行プロジェクトには、データプロバイダー、インスタンスプロファイル、および移行ルールが含まれます。 AWS DMSデータプロバイダーとインスタンスプロファイルを使用して、データベーススキーマとコードオブジェクトを変換するプロセスを設計します。

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

大まかに説明すると、AWS DMS レプリケーション インスタンスとは、1 つ以上のレプリケーション タスクをホストするマネージド Amazon Elastic Compute Cloud (Amazon EC2)の インスタンスです。

関連付けられたいくつかのレプリケーションタスクを実行するレプリケーションインスタンスの例を以下の図に示します。

移行の特性とレプリケーションサーバーの容量に応じて、1 つのレプリケーションインスタンスを使用して、1 つ以上のレプリケーションタスクをホストできます。AWS DMS では、ユースケースに最適な設定を選択できるように、さまざまなレプリケーションインスタンスが用意されています。レプリケーションインスタンスのさまざまなクラスの詳細については、「移行に適した AWS DMS レプリケーション インスタンスを選択する」をご参照ください。

AWS DMS はレプリケーション インスタンスをAmazon EC2 インスタンスに作成します。サービスのテストや小規模な移行の場合、いくつかの小さいインスタンスクラスで十分です。移行に多数のテーブルが関与する場合や、複数の同時レプリケーションタスクを実行する予定の場合、大きいインスタンスを 1 つ使用することを検討してください。AWS DMS はかなりのメモリと CPU を消費する可能性があるため、このアプローチが推奨されます。

選択したAmazon EC2インスタンスクラスに応じて、レプリケーション インスタンスには 50 GB または 100 GB のデータストレージが付属しています。ほとんどのお客様にとって、通常このストレージ容量は十分な量です。ただし、移行で大規模なトランザクションや大量のデータ変更が発生する場合は、基本ストレージの割り当てを増やすことを検討します。変更データキャプチャ (CDC) によって、データがディスクに書き込まれる可能性があります。これは、ターゲットから変更が書き込まれる速度によって異なります。ログファイルもディスクに書き込まれるため、ロギングの重要度を上げると、ストレージの消費量も大きくなります。

AWS DMS は、マルチ AZ 配置を使用して高可用性およびフェイルオーバーサポートを提供します。AWS DMS のマルチ AZ 配置では、異なるアベイラビリティーゾーンにレプリケーションインスタンスのスタンバイレプリカが自動的にプロビジョニングされ、維持されます。プライマリレプリケーション インスタンスは、同期的にスタンバイレプリカにレプリケートされます。プライマリレプリケーション インスタンスに障害が発生するか、応答しない場合、スタンバイ状態で中断時間をできる限り抑えて、実行中のタスクを再開します。プライマリはその状態を常にスタンバイにレプリケーションしているため、マルチ AZ 配置ではパフォーマンス上のオーバーヘッドが発生します。

AWS DMS レプリケーションインスタンスの詳細については、「AWS DMS レプリケーション インスタンスを使用する」をご参照ください。

エンドポイント

AWS DMS は、エンドポイントを使用してソースまたはターゲットのデータストアにアクセスします。具体的な接続情報はデータストアによって異なりますが、一般的にエンドポイントを作成するときは次の情報を指定します。

• エンドポイントタイプ - ソースまたはターゲット。

• エンジンタイプ-データベースエンジンのタイプ（Oracle、および PostgreSQL など）。

• サーバー名 - AWS DMS が到達可能なサーバー名または IP アドレス。

• ポート - データベースサーバー接続に使用されるポート番号。

• 暗号化 - Secure Sockets Layer (SSL)モード（SSL を使用して接続を暗号化する場合）。

• 認証情報 - 必要なアクセス権限を持つアカウントのユーザー名とパスワード。

AWS DMS コンソールを使用してエンドポイントを作成する場合は、コンソールでエンドポイント接続をテストする必要があります。AWS DMSタスクでエンドポイントを使用する前に、テストが成功する必要があります。接続情報と同様に、特定のテスト基準はエンジンの種類によって異なります。一般的に、AWS DMS では、指定されたサーバー名とポートにデータベースが存在することと、提供された認証情報を使用して、移行を実行するために必要なアクセス許可を持つデータベースに接続できることを検証します。接続テストが成功すると、AWS DMS は、スキーマ情報をダウンロードして格納します。この情報は、後でタスク設定時に使用できます。スキーマ情報には、テーブル定義、プライマリキー定義、一意キー定義などがあります。

複数のレプリケーションタスクで 1 つのエンドポイントを使用することもできます。たとえば、2 つの論理的に異なるアプリケーションがあり、これらが同じソースデータベースにホストされていて、これらを別々に移行するとします。この場合は、アプリケーションテーブルのセットごとに 1 つずつ、2 つのレプリケーションタスクを作成します。両方のタスクで、同じ AWS DMS エンドポイントを使用できます。

エンドポイント設定を使用して、エンドポイントの動作をカスタマイズできます。エンドポイント設定では、ロギングの詳細、ファイルサイズ、その他のパラメータなど、さまざまな動作を制御できます。データストアエンジンの種類ごとに、利用できるエンドポイント設定が異なります。各データストアの特定のエンドポイント設定は、そのデータストアのソースセクションまたはターゲットセクションにあります。サポートされているソースとターゲットデータストアのリストについては、「AWS DMS のソース」と「AWS DMS のターゲット」をご参照ください。

AWS DMS エンドポイントの詳細な情報については、「AWS DMS エンドポイントの使用」をご参照ください。

レプリケーションタスク

一連のデータをソースエンドポイントからターゲットエンドポイントに移動するには、AWS DMS レプリケーションタスクを使用します。レプリケーションタスクの作成は、移行を開始する前に最後に実行する必要があります。

レプリケーションタスクの作成時に以下のタスク設定を指定します。

• レプリケーションインスタンス - タスクをホストして実行するインスタンス

• ソースエンドポイント

• ターゲットエンドポイント

• 移行タイプオプションは次にリストされるとおりです。移行タイプのオプションの詳細な説明については、「[Creating a task] (タスクの作成)」をご参照ください。

  • 全ロード (既存データの移行) - 既存のデータをコピーできる長さの停止が許容される場合は、このオプションが選択に適します。このオプションでは、ソースデータベースからターゲットデータベースにデータがそのまま移行され、必要に応じてテーブルが作成されます。

  • 全ロード + CDC (既存のデータを移行して、継続的な変更をレプリケート) - このオプションでは、ソースで変更をキャプチャしながら、全データロードが実行されます。フルロードが完了すると、キャプチャされた変更がターゲットに適用されます。最終的に、変更の適用は安定した状態に到達します。この時点で、アプリケーションをシャットダウンし、残りの変更がターゲットに移動するようにした後、ターゲットをポイントするアプリケーションを再起動できます。

  • CDC のみ（データ変更のみレプリケート） - 状況によっては、AWS DMS 以外の方法を使用して既存のデータをコピーした方が効率的である場合があります。たとえば、同機種間移行では、一括データのロードにネイティブのエクスポート/インポートツールを使用する方が効率的になる可能性があります。その場合は、AWS DMS を使用し、一括ロードを開始したときから変更をレプリケートして、ソースデータベースとターゲットデータベースの同期を保つことができます。

• ターゲットテーブル準備モードオプションは以下にリストされるとおりです。ターゲットテーブルモードの詳細な説明については、「[Creating a task] (タスクの作成)」をご参照ください。

  • 何もしない – AWS DMS ではターゲットテーブルがターゲットで事前に作成されていることを前提とします。

  • ターゲット上のテーブルを削除 – AWS DMS はターゲットテーブルを削除して再作成します。

  • 切り捨て – ターゲットでテーブルを作成済みである場合、AWS DMS は移行のスタート前にそれらを切り捨てます。テーブルが存在しない場合、このオプションを選択すると、AWS DMS は不足しているテーブルを作成します。

• LOB モードオプションは以下にリストされるとおりです。LOB モードの詳細な説明については、「AWS DMS タスクのソースデータベースの LOB サポートの設定」をご参照ください。

  • LOB 列を含めない – LOB 列は移行対象から除外されます。

  • 完全 LOB モード – サイズに関係なく LOB 全体を移行します。AWS DMS は [Max LOB Size] (最大 LOB サイズ) パラメータで制御されるチャンクの単位で LOB を移行します。このモードは制限付き LOB モードを使用するよりも低速です。

  • 制限付き LOB モード – LOB を[Max LOB Size] (最大 LOB サイズ) で指定された値まで切り詰めます。このモードは完全 LOB モードを使用するよりも高速です。

• テーブルマッピング – 移行するテーブルと移行方法を示します。詳細については、「テーブルマッピングを使用して、タスクの設定を指定する」を参照してください。

• データ変換は以下にリストされるとおりです。データ変換の詳細については、「 JSON を使用するテーブル選択および変換を指定する」をご参照ください。

  • スキーマ、テーブル、および列の名前を変更します。

  • テーブルスペース名の変更 (Oracle ターゲットエンドポイント用)。

  • ターゲットのプライマリキーと一意のインデックスを定義します。

• [Data validation] (データ検証)

• CloudWatchアマゾンロギング

タスクを使用してソースエンドポイントからターゲットエンドポイントにデータを移行します。タスク処理はレプリケーションインスタンスで実行されます。ログ記録要件、制御テーブルデータ、エラー処理など、移行するテーブルとスキーマ、および特別な処理を指定します。

概念的には、AWS DMSレプリケーションタスクは、次の図に示すように 2 つの異なる機能を実行します。

全ロードプロセスは、簡単に理解できます。データは、ソースから一括抽出で抽出され、ターゲットに直接ロードされます。AWS DMS コンソールの [詳細設定] で、抽出して並列にロードするテーブルの数を指定できます。

AWS DMS タスクの詳細については、「AWS DMS タスクの使用」をご参照ください。

継続的なレプリケーションまたは変更データキャプチャ (CDC)

AWS DMS タスクを使用して、ターゲットへのデータの移行中にソースデータストアへの継続的な変更をキャプチャすることもできます。ソースエンドポイントから継続的な変更をレプリケートするときに AWS DMS が使用する変更キャプチャプロセスは、データベースエンジンのネイティブ API を使用することでデータベースログへの変更を収集します。

CDC プロセスで、レプリケーションタスクは、メモリ内のバッファを使用して転送中のデータを保持することによって、ソースからターゲットへの変更をストリーミングするように設計されています。何らかの理由でメモリ内バッファが枯渇すると、レプリケーションタスクによって、ディスク上のキャッシュの変更は保留中に変更されます。この状況は、たとえば、AWS DMS がソースからの変更をターゲットに適用できるよりも速く取得している場合に発生します。この場合、タスクのターゲットレイテンシーが、タスクのソースレイテンシーを超えていることがわかります。

これを確認するには、AWS DMS コンソールでタスクに移動し、[タスクのモニタリング] タブを開きます。CDC LatencyTarget と CDC LatencySource のグラフはページの下部に表示されます。ターゲットのレイテンシーを示すタスクがある場合は、アプリケーションの速度を上げるために必要なターゲットエンドポイントのチューニングがある可能性があります。

上記で説明したように、レプリケーションタスクではタスクログ用のストレージも使用されます。通常、レプリケーションインスタンスで事前設定されているディスク容量では、十分に変更をログ記録および反映することができます。追加のディスク容量が必要な場合 (例: 詳細なデバッグを使用して移行の問題を調査する場合)、レプリケーションインスタンスを変更してより多くの容量を割り当てることができます。