AWS Database Migration Service のターゲットとしての Amazon DocumentDB の使用 - AWS Database Migration Service

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

AWS Database Migration Service のターゲットとしての Amazon DocumentDB の使用

AWS DMS を使用して、AWS DMS がサポートするソースデータエンジンのいずれかから Amazon DocumentDB (MongoDB 互換) にデータを移行できます。ソースエンジンは、Amazon RDS、Aurora、Amazon S3 などの AWS マネージドサービス上にあります。または、エンジンは、MongoDB またはオンプレミスで実行されている Amazon EC2 などのセルフマネージド型データベース上に存在していてもかまいません。

AWS DMS を使用すると、ソースデータを Amazon DocumentDB のデータベース、コレクション、またはドキュメントにレプリケートできます。

注記

ソースエンドポイントが MongoDB または Amazon DocumentDB の場合、ドキュメントモードで移行を実行します。

MongoDB は、データをバイナリ JSON 形式 (BSON) で保存します。AWS DMS は、Amazon DocumentDB でサポートされているすべての BSON データ型をサポートしています。これらのデータ型のリストについては、 開発者ガイドMongoDBの「APIsサポートされる 、オペレーション、およびデータ型Amazon DocumentDB」を参照してください。

ソースエンドポイントがリレーショナルデータベースである場合は、AWS DMS はデータベースオブジェクトを次のように Amazon DocumentDB にマップします。

  • リレーショナルデータベース (データベーススキーマ) は、Amazon DocumentDB のデータベースにマップされます。

  • リレーショナルデータベース内のテーブルは、コレクションAmazon DocumentDBにマップされます。

  • リレーショナルテーブル内のレコードは、ドキュメントAmazon DocumentDBにマッピングされます。ソースレコードのデータから各ドキュメントが構築されます。

ソースエンドポイントが Amazon S3 である場合は、Amazon S3 の AWS DMS マッピングルールに対応する Amazon DocumentDB オブジェクトが作成されます。たとえば次のような URI があったとします。

s3://mybucket/hr/employee

この場合、AWS DMSは mybucket 内のオブジェクトを次のように Amazon DocumentDB にマップします。

  • URI の最上位の部分 (hr) は、Amazon DocumentDB のデータベースにマップされます。

  • URI の次の部分 (employee) は、Amazon DocumentDB のコレクションにマップされます。

  • employee 内の各オブジェクトは、Amazon DocumentDB のドキュメントにマップされます。

Amazon S3 のマッピングルールの詳細については、「AWS DMS のソースとしての Amazon S3 の使用」を参照してください。

AWS DMS のターゲットとしての Amazon DocumentDB の使用の詳細については、以下のセクションを参照してください。

注記

移行プロセスの段階的なチュートリアルについては、 ステップバイステップ移行ガイドの「MongoDB から Amazon DocumentDB への移行」を参照してください。AWS Database Migration Service

ソースから Amazon DocumentDB ターゲットへのデータのマッピング

AWS DMS は、ソースエンドポイントからレコードを読み取り、読み取ったデータに基づいて JSON ドキュメントを構築します。各 JSON ドキュメントでは、AWS DMS で _id フィールドを一意の識別子として機能するよう特定する必要があります。JSON ドキュメントは、その _id フィールドをプライマリキーとして使用して Amazon DocumentDB コレクションに書き込まれます。

単一列のソースデータ

ソースデータが 1 つの列で構成されている場合、そのデータは文字列型である必要があります。(実際のデータ型は、ソースエンジンの種類に応じて、VARCHAR、NVARCHAR、TEXT、LOB、CLOB などになります)。AWS DMS はこれらのデータを有効な JSON ドキュメントであると見なし、そのまま Amazon DocumentDB にレプリケートします。

結果の JSON ドキュメントに _id という名前のフィールドが含まれている場合は、そのフィールドが Amazon DocumentDB で一意の _id として使用されます。

JSON に _id フィールドが含まれていない場合は、Amazon DocumentDB によって自動的に _id 値が生成されます。

複数列のソースデータ

ソースデータが複数の列で構成されている場合、AWS DMS はそのすべての列から JSON ドキュメントを構築します。この場合、AWS DMS がドキュメントの _id フィールドを特定するプロセスは次のようになります。

  • _id という名前の列がある場合は、その列のデータがターゲット _id として使用されます。

  • _id 列はないがプライマリキーまたは一意のインデックスがある場合、AWS DMS はそのキーまたはインデックスの値を _id 値として使用します。プライマリキーや一意のインデックスのデータは、JSON ドキュメント内の明示的なフィールドとしても表示されます。

  • _id 列も、プライマリキーも、一意のインデックスもない場合は、Amazon DocumentDB によって自動的に _id 値が生成されます。

ターゲットエンドポイントのデータ型の強制変換

AWS DMS では、Amazon DocumentDB ターゲットエンドポイントへの書き込み時にデータ構造を変更できます。これらの変更をリクエストするには、ソースエンドポイントでテーブルや列の名前を変更するか、タスクの実行時に適用される変換ルールを指定します。

ネストされた JSON ドキュメント (json_ プレフィックス) の使用

ソース列の名前に json_ というプレフィックスを付けることによってデータ型を強制変換することができます (json_columnName)。手動で行うことも、変換を使用して行うこともできます。この場合、その列は、文字列フィールドとしてではなく、ターゲットドキュメント内のネストされた JSON ドキュメントとして作成されます。

たとえば、MongoDB ソースエンドポイントから次のドキュメントを移行するとします。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}" }

これらのソースデータ型を強制変換しない場合、埋め込まれている ContactDetails ドキュメントは文字列として移行されます。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}" }

しかし、変換ルールを追加して、ContactDetails を JSON オブジェクトに強制変換することができます。たとえば、ソース列の元の名前が ContactDetails であるとします。 また、名前を変更したソース列が json_ContactDetails であるとします。AWS DMS は、次のように ContactDetails フィールドをネストされた JSON としてレプリケートします。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactDetails": { "Home": { "Address": "Boston", "Phone": "1111111111" }, "Work": { "Address": "Boston", "Phone": "2222222222" } } }

JSON 配列 (array_ プレフィックス) の使用

列の名前に array_ というプレフィックスを付けることによってデータ型を強制変換することができます (array_columnName)。手動で行うことも、変換を使用して行うこともできます。この場合、AWS DMS はその列を JSON 配列と見なし、ターゲットドキュメントに JSON 配列を作成します。

ソースエンドポイントから次のドキュメントを移行するとします。MongoDB

{ "_id" : "1", "FirstName": "John", "LastName": "Doe",
 "ContactAddresses": ["Boston", "New York"],
 "ContactPhoneNumbers": ["1111111111", "2222222222"] }

これらのソースデータ型を強制変換しない場合、埋め込まれている ContactDetails ドキュメントは文字列として移行されます。

{ "_id": "1", "FirstName": "John", "LastName": "Doe",
 "ContactAddresses": "[\"Boston\", \"New York\"]",
 "ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
 }

しかし、変換ルールを追加して、ContactAddressContactPhoneNumbers を JSON 配列に強制変換することができます。その例を次の表に示します。

ソース列の元の名前 ソース列の変更後の名前
ContactAddress array_ContactAddress
ContactPhoneNumbers array_ContactPhoneNumbers

これにより、AWS DMS で ContactAddressContactPhoneNumbers が次のようにレプリケートされます。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactAddresses": [ "Boston", "New York" ], "ContactPhoneNumbers": [ "1111111111", "2222222222" ] }

TLS を使用した Amazon DocumentDB への接続

デフォルトでは、新しく作成された Amazon DocumentDB クラスターは、Transport Layer Security (TLS) を使用したセキュアな接続のみを受け入れます。TLS が有効になっている場合、Amazon DocumentDB へのすべての接続でパブリックキーが必要になります。

Amazon DocumentDB のパブリックキーを取得するには、AWS がホストする Amazon S3 バケットから rds-combined-ca-bundle.pem ファイルをダウンロードします。このファイルのダウンロードの詳細については、https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html の「TLS を使用した接続の暗号化Amazon DocumentDB 開発者ガイド」を参照してください

この.pem ファイルをダウンロードしたら、以下で説明するように、そのファイルに含まれるパブリックキーを AWS DMS にインポートできます。

AWS マネジメントコンソール

パブリックキー (.pem) ファイルをインポートするには

  1. AWS DMS コンソール (https://console.aws.amazon.com/dms) を開きます。

  2. ナビゲーションペインで [Certificates] を選択します。

  3. [Import certificate (証明書のインポート)] を選択し、次の操作を行います。

    • [Certificate identifier (証明書の識別子)] に、証明書の一意の名前を入力します (例: docdb-cert)。

    • [Import file (ファイルのインポート)] で、.pem ファイルを保存した場所を参照します。

    すべての設定が正しいことを確認したら、[Add new CA certificate (新しい CA 証明書の追加)] を選択します。

AWS CLI

次の例に示すように aws dms import-certificate コマンドを使用します。

aws dms import-certificate \ --certificate-identifier docdb-cert \ --certificate-pem file://./rds-combined-ca-bundle.pem

AWS DMS のターゲットエンドポイントを作成するときに、証明書の識別子 (docdb-cert など) を指定します。また、[SSL mode (SSL モード)] パラメータを [verify-full] に設定します。

Amazon DocumentDB をターゲットとする継続的なレプリケーション

AWS DMS で継続的なレプリケーションが有効になっている場合、Amazon DocumentDB 内のドキュメントでソースとの同期が維持されます。ソースレコードが作成または更新されると、AWS DMS はまず、影響を受ける Amazon DocumentDB レコードを次のように特定します。

  • ソースレコードに _id という名前の列がある場合は、その列の値を使用して Amazon DocumentDB コレクションの対応する _id が特定されます。

  • _id 列はないがプライマリキーまたは一意のインデックスがある場合、AWS DMS はそのキーまたはインデックスの値を Amazon DocumentDB コレクションの _id として使用します。

  • ソースレコードに _id 列も、プライマリキーも、一意のインデックスもない場合、AWS DMS はすべてのソース列を Amazon DocumentDB コレクションに対応するフィールドとして照合します。

新しいソースレコードが作成されると、AWS DMS は対応するドキュメントを Amazon DocumentDB に書き込みます。既存のソースレコードが更新された場合、AWS DMS は Amazon DocumentDB のターゲットドキュメントに対応するフィールドを更新します。ターゲットドキュメントには存在するがソースレコードには存在しないフィールドは、一切変更されません。

ソースレコードが削除されると、AWS DMS は対応するドキュメントを Amazon DocumentDB から削除します。

ソースの構造の変更 (DDL)

継続的なレプリケーションでは、ソースのデータ構造 (テーブル、列など) の変更が Amazon DocumentDB の対応する要素に反映されます。リレーショナルデータベースでは、これらの変更はデータ定義言語 (DDL) ステートメントを使用して開始されます。次の表に、AWS DMS でこれらの変更がどのように Amazon DocumentDB に反映されるかを示します。

ソースの DDL Amazon DocumentDB ターゲットへの影響
CREATE TABLE 空のコレクションが作成されます。
テーブル名を変更するステートメント (RENAME TABLEALTER TABLE...RENAME など) コレクションの名前が変更されます。
TRUNCATE TABLE コレクションからすべてのドキュメントを削除しますが、HandleSourceTableTruncatedtrue の場合のみ除きます。 詳細については、「変更処理の DDL 処理のタスク設定」を参照してください。
DROP TABLE コレクションを削除します (HandleSourceTableDroppedtrue の場合のみ)。 詳細については、「変更処理の DDL 処理のタスク設定」を参照してください。
テーブルに列を追加するステートメント (ALTER TABLE...ADD など) この DDL ステートメントは無視され、警告が表示されます。ソースで最初の INSERT が実行されたときに、ターゲットドキュメントに新しいフィールドが追加されます。
ALTER TABLE...RENAME COLUMN この DDL ステートメントは無視され、警告が表示されます。ソースで最初の INSERT が実行されたときに、ターゲットドキュメントに新しい名前のフィールドが追加されます。
ALTER TABLE...DROP COLUMN この DDL ステートメントは無視され、警告が表示されます。
列のデータ型を変更するステートメント (ALTER COLUMN...MODIFY など) この DDL ステートメントは無視され、警告が表示されます。ソースでその新しいデータ型を使用した最初の INSERT が実行されたときに、その新しいデータ型のフィールドを使用してターゲットドキュメントが作成されます。

ターゲットとしての Amazon DocumentDB の使用における制限

AWS DMS のターゲットとして Amazon DocumentDB を使用する場合、以下の制限が適用されます。

  • Amazon DocumentDB では、コレクション名にドル記号 ($) を含めることはできません。また、データベース名に Unicode 文字を含めることもできません。

  • AWS DMS で複数のソーステーブルを 1 つの Amazon DocumentDB コレクションにマージすることはできません。

  • AWS DMS は、プライマリキーがないソーステーブルの変更を処理する際に、そのテーブルの LOB 列を無視します。

  • [Change table (変更テーブル)] オプションが有効になっている場合に AWS DMS で "_id" という名前のソース列が検出されると、その列が変更テーブルに "__id" (2 つのアンダースコア) として表示されます。

  • ソースエンドポイントとして Oracle を選択する場合は、Oracle ソースで完全なサプリメンタルロギングが有効になっている必要があります。有効になっていないと、ソースに変更されていない列がある場合にデータが null 値として Amazon DocumentDB にロードされます。

Amazon DocumentDB のターゲットデータ型

次の表に、AWS DMS を使用する場合にサポートされる Amazon DocumentDB ターゲットのデータ型と、AWS DMS のデータ型からのデフォルトマッピングを示します。AWS DMS のデータ型の詳細については、「AWS Database Migration Service のデータ型」を参照してください。

AWS DMS データ型

Amazon DocumentDB データ型

BOOLEAN

ブール値

BYTES

バイナリデータ

DATE

日付

TIME

文字列 (UTF8)

DATETIME

日付

INT1

32 ビット整数

INT2

32 ビット整数

INT4

32 ビット整数

INT8

64 ビット整数

NUMERIC

文字列 (UTF8)

REAL4

Double

REAL8

Double

STRING

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。

UINT1

32 ビット整数

UINT2

32 ビット整数

UINT4

64 ビット整数

UINT8

文字列 (UTF8)

WSTRING

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。

BLOB

バイナリ

CLOB

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。

NCLOB

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。