AWS Database Migration Service（DMS）は、ダウンタイムなしでAWS上のデータベースを確実に移行するように設計されています。当初、DMSはAWSRedshiftを含むリレーショナルデータベースのみをサポートしていました。 2017年4月、DMSは2つのNoSQLデータベースを追加しました。ソースデータベースとしてMongoDBを追加し、ターゲットデータベースとしてAWSDynamoDBを追加しました。この2つの記事のチュートリアルでは、MongoDBデータベースをDMS上のDynamoDBに移行する方法について説明します。 MongoDBをDMSソースとして使用するための要件の1つは、MongoDBがレプリカセットとして実行されている必要があることです。レプリカセットは、これら2つの記事の最初の記事でDockerイメージを使用して作成します。
この記事には次のセクションがあります：
- 環境の設定
- データベース移行サービス用のIAMユーザーの作成
- 暗号化キーの作成
- MongoDBデータベースの作成
- DynamoDBテーブルの作成
- 結論
環境の設定
唯一の前提条件はAWSアカウントであり、https：//aws.amazon.com/resources/create-account/で作成できます。 AWSでソースデータベースとターゲットデータベースの両方を実行します。 MongoDBソースには、Dockerを使用します。図1に示すように、AWSMarketplaceから選択したCoreOS（Stable）によるAMI Container LinuxでEC2インスタンスを起動します。CoreOSはDockerを備えているため、Linuxプラットフォームとして選択されます。プレインストールされています。
図1： CoreOSAMIを選択してEC2インスタンスを起動する
CoreOS EC2インスタンスで使用されるセキュリティグループには、すべてのトラフィックを受け入れるようにインバウンド/アウトバウンドルールが設定されている必要があります。これは、すべての送信元と宛先の間のすべてのポートでのすべてのプロトコルのトラフィックを意味します（ 0.0.0.0/0、::/0 。
データベース移行サービス用のIAMユーザーの作成
このセクションでは、移行の作成に使用されるさまざまなAWSサービス（DMS、EC2、DynamoDB、KMS、IAM、CloudWatchなど）にアクセスするためのIAMユーザーを作成します。まず、必要な権限を持つポリシーを作成する必要があります。続いて、ユーザーを作成し、そのユーザーにポリシーを割り当てます。 IAMポリシーを作成するには、[ポリシー]を選択します IAMコンソールで、[ポリシーの作成]をクリックします 。 [ポリシーの作成]で、[独自のポリシーの作成]を選択します 。 [ポリシーの確認]で、ポリシー名（ DMS ）を指定します 例として）、次のポリシードキュメントをコピーして[ポリシードキュメント]フィールドに貼り付けます。
{"Version"： "2012-10-17"、 "Statement"：[{"Effect"： "Allow"、 "Action"： "dms：*"、 "Resource"： "*"}、{ "Effect"： "Allow"、 "Action"： "dynamodb：*"、 "Resource"： "*"}、{"Effect"： "Allow"、 "Action"： "kms：*"、 "Resource"： "*"}、{"Effect"： "Allow"、 "Action"： "iam：*"、 "Resource"： "*"}、{"Effect"： "Allow"、 "Action"： "ec2：* "、" Resource "：" * "}、{" Effect "：" Allow "、" Action "：" cloudwatch：* "、" Resource "：" * "}、{" Effect "：" Allow "、" Action "：" aws-marketplace：* "、" Resource "：" * "}、{" Effect "：" Allow "、" Action "：" logs：* "、" Resource "：" * "}、{" Effect "：" Allow "、" Action "：[" redshift：Describe * "、" redshift：ModifyClusterIamRoles "]、" Resource "：" * "}]}
ポリシーの検証をクリックします 。出力が「このポリシーは有効です」の場合は、ポリシーの作成をクリックします 、図2に示すように。
図2： IAMポリシーの作成
図3に示すように、新しいIAMポリシーが作成されます。
図3： IAMポリシー「DMS」
次に、IAMユーザーを作成します。 ユーザーを選択します ユーザーの追加をクリックします 、図4に示すように。
図4： ユーザーを追加
ユーザーの追加 、ユーザー名を指定します 、図5に示すように、アクセスタイプの場合 、プログラムによるアクセスを選択します およびAWSマネジメントコンソールへのアクセス 。
図5： ユーザーの追加
コンソールパスワードの場合 、カスタムパスワードを選択します パスワードを指定します（図6を参照）。 [次へ]をクリックします。
図6： AWS Access Type> Next
を選択します
[権限の設定]で、[既存のポリシーを直接添付する]をクリックします 、図7に示すように。
図7： 権限の設定
図8に示すように、前に作成したDMSポリシーを選択し、[次へ]をクリックします。
図8： DMSポリシーの選択
[レビュー]で、[ユーザーの作成]をクリックします 、図9に示すように。
図9： レビュー>ユーザーの作成
IAMユーザーが作成されます。図10に示すURLをコピーして、ユーザーが作成したとおりにAWSマネジメントコンソールにログインします。
図10： IAMユーザーURL
新しいユーザーはユーザーにリストされます （図11を参照）。
図11： IAMユーザーURL
暗号化キーの作成
次に、DMSの移行に使用する暗号化キーを作成します。作成したIAMユーザーとしてログインし、図10にコピーしたURLを使用します。 IAMを選択します AWS管理コンソールでサービスを実行し、暗号化キーを選択します 。 キーの作成をクリックします ウィザードを開始して暗号化キーを作成します。ウィザードを使用して暗号化キー（ dms ）を作成します ）、図12に示すように。
図12： 新しい暗号化キー
MongoDBデータベースの作成
このセクションでは、MongoDBデータベースを作成し、その後DynamoDBに移行します。 Dockerを使用して、CoreOSインスタンスが起動されたMongoDBインスタンスを実行します。 CoreOSインスタンスにログインするには、図13に示すように、CoreOSインスタンスのパブリックIPアドレスを取得します。
図13： CoreOSインスタンスのパブリックIPアドレス
SSHは、キーペアとパブリックIPを使用してCoreOSインスタンスにログインします。
ssh -i "docker.pem" [email protected]
図14に示すように、CoreOSインスタンスのコマンドラインプロンプトが表示されます。
図14： CoreOSインスタンス
次に、次のコマンドを実行して、MongoDBイメージ「mongo」を使用してMongoDBのDockerコンテナーを起動します。 Dockerコンテナポート27017は、 -pを使用して27017としてホスト上に公開されます。 docker runのオプション 。コンテナ名は「mongo1」に設定され、コマンド mongod --replSet repl0 「repl0」と呼ばれるMongoDBレプリカセットを開始するために作成されたコンテナで実行されます。前述のように、MongoDBをDMSソースとして使用するには、MongoDBレプリカセットが必要であり、スタンドアロンのMongoDBをソースとして使用することはできません。
docker run -p 27017：27017 mongo mongod --replSet repl0
Dockerイメージmongo プルされ、図15の「MongoDBstarting」というメッセージで示されているように、MongoDBが開始されます。
図15： DockerImagedockerのダウンロード
MongoDBインスタンスはポート27017で開始されます（図16を参照）。レプリカセットはまだ作成されていないため、次にレプリカセットを初期化します。
図16： Mongoインスタンスが開始されました
Dockerコンテナはdockerpsで一覧表示されます 図17に示すように、コマンド。
図17： Mongo用のDockerコンテナの一覧表示
次のコマンドを使用して、Mongoコマンドラインインターフェイス（CLI）のコマンドシェルを開始します。
docker exec -it mongo1 mongo
MongoDBシェルバージョン3.4.4は、URL mongodb：//127.0.0.1：27017で接続されます。 、図18に示すように。
図18： MongoDBシェルの接続
図19に示すように、MongoCLIコマンドプロンプトが表示されます。
図19： MongoShellコマンドプロンプト
テストとして使用するようにMongoDBデータベースを設定します use test 図20に示すように、コマンド。
図20： データベースをテストとして設定する
次に、レプリカセットのメンバーまたはインスタンスを定義する必要があるレプリカセットを初期化します。 MongoDBのDockerコンテナが実行されているCoreOSEC2インスタンスのプライベートIPを取得します（図21を参照）。
図21： CoreOSインスタンスのプライベートIP
Mongo CLIで、レプリカセット構成に次の構成を指定します。
config ={"_id"： "repl0"、 "members"：[{"_id"：0、 "host"： "172.30.2.20:27017"}]}
図22に示すように、レプリカセットの構成が設定されます。
図22： レプリカセット構成の設定
構成を使用してレプリカセットの構成を開始します。
rs.initiate（config）
図23に示すように、レプリカセットが初期化されます。
図23： レプリカセットが初期化されました
レプリカセットの構成を出力します。
rs.conf（）
repl0：PRIMARY コマンドプロンプトは、レプリカセットが初期化され、レプリカセットのプライマリメンバーがMongoCLIコマンドを実行するように設定されていることを示します。プライマリは、書き込み操作用のレプリカセット内の唯一のメンバーです。 wlslogというMongoDBコレクションを作成します db.createCollection（<コレクション名>）を使用 コマンド。
db.createCollection（ "wlslog"）
図24に示すように、MongoDBコレクションが作成されます。MongoDBコレクションはドキュメントのコレクションです。ドキュメントはBSON（バイナリJSON）形式です。
図24： コレクションの作成
MongoCLIでJSONドキュメントを定義する次のステートメントを実行します。
doc1 ={"timestamp"： "Apr 8、2014 7:06:16 PM PDT"、 "category"： "Notice"、 "type"： "WebLogicServer"、 "servername"： "AdminServer"、 "code "：" BEA-000365 "、" msg "："サーバーの状態がSTANDBYに変更されました "} doc2 ={"timestamp "："2014年4月8日19:06:17PDT "、" category "：" Notice "、" type "：" WebLogicServer "、" servername "：" AdminServer "、" code "：" BEA-000365 "、" msg "："サーバーの状態がSTARTINGに変更されました "} doc3 ={"timestamp "："2014年4月8日7 ：06：18 PM PDT "、" category "：" Notice "、" type "：" WebLogicServer "、" servername "：" AdminServer "、" code "：" BEA-000365 "、" msg "："サーバーの状態が変更されましたto ADMIN "} doc4 ={" timestamp "："2014年4月8日19:06:19PDT "、" category "：" Notice "、" type "：" WebLogicServer "、" servername "：" AdminServer "、" code "：" BEA-000365 "、" msg "："サーバーの状態がRESUMINGに変更されました "} doc5 ={"timestamp "："2014年4月8日19:06:20PDT "、" category "：" Notice "、 "type"： "WebLogicServer"、 "servername"： "AdminServer"、 "code"： "BEA-000331"、 "msg"："開始されたWebLogicAdmin Server"} doc6 ={"timestamp"："2014年4月8日7 ：06：21 PM PDT "、 "category"： "Notice"、 "type"： "WebLogicServer"、 "servername"： "AdminServer"、 "code"： "BEA-000365"、 "msg"："サーバーの状態がRUNNINGに変更されました"}doc7 ={"タイムスタンプ"："2014年4月8日19:06:22PDT "、"カテゴリ "："通知 "、"タイプ "：" WebLogicServer "、"サーバー名 "：" AdminServer "、"コード "：" BEA-000360 " 、"msg"："サーバーは実行モードで起動しました"}
図25に示すように、JSONドキュメントの変数が定義されます。
図25： JSONドキュメントの変数の定義
JSONドキュメントをwlslogに追加します コレクション。
db.wlslog.insert（[doc1、doc2、doc3、doc4、doc5、doc6、doc7]）
図26の出力に示されているように、7つのドキュメントが wlslogに追加されます。 コレクション。
図26： コレクションに追加されたJSONドキュメント
wlslogに追加されたドキュメントを一覧表示します コレクション。
db.wlslog.find（）
図27に示すように、追加された7つのドキュメントが一覧表示されます。
図27： Mongoコレクションからのドキュメントの検索または取得
DynamoDBテーブルの作成
DMSソース用のMongoDBレプリカセットを作成したら、次にDMSターゲット用のDynamoDBテーブルを作成します。以前に作成してポリシーを割り当てたIAMユーザー（dvohra）としてログインします。 AW管理コンソールでDynamoDBサービスを選択し、テーブルの作成を選択します 、図28に示すように。
図28： DynamoDB>テーブルの作成
Create DynamoDBテーブルで、テーブル名を指定します 主キーを指定します 、これは _idのようにパーティションキーでもあります 、図29に示すように。テーブル名は任意であり、 wlslogに設定されていますが 、MongoDBレプリカセットで作成されたMongoDBコレクションと同じであるため、主キーを _idに設定する必要があります 各MongoDBドキュメントには主キーフィールド_idが割り当てられるためです 。
図29： DynamoDBテーブルの作成
DynamoDBテーブルwlslog 図30に示すように、作成されます。
図30： DynamoDBテーブルwlslogが作成されました
DynamoDBテーブルwlslogをクリックします ダッシュボードとテーブルの詳細（主キー _id を含む） 、が表示されます（図31を参照）。
図31： DynamoDBテーブルのwlslogの詳細
DMS移行が作成されると、IAMロール dms-vpc-role 管理ポリシーAmazonDMSVPCManagementRole 自動的に作成されます。 DMSサービスがDynamoDBサービスにアクセスするには、サービスアクセスロール dms-vpc-roleを変更する必要があります DMSからDynamoDBへのアクセスを提供する次のポリシードキュメントを追加します。
{"Version"： "2012-10-17"、 "Statement"：[{"Effect"： "Allow"、 "Action"：["dynamodb：*"]、 "Resource"：["*" ]}]}
図32に示すように、DMSポリシーの作成に使用したのと同じ手順を使用して、ポリシーDynamoDBを作成し、[ポリシードキュメント]フィールドボックスで前のポリシードキュメントを指定します。[ポリシーの作成] 。
図32： ポリシーの確認>ポリシーの作成
図33に示すように、DynamoDBポリシーが作成されます。
図33： IAMポリシーDynamoDBが作成されました
dms-vpc-role DynamoDBポリシーが追加される対象を図34に示します。
図34： DMSVPCの役割
dms-vpc-roleをクリックします アタッチポリシーを使用してDynamoDBポリシーを追加します。図35に示すように、AmazonDMSVPCManagementRoleおよびDynamoDBポリシーはマネージドポリシーとしてリストされている必要があります。
図35： DMSVPCロールの権限ポリシー
結論
この記事では、MongoDBをAmazon DynamoDBに移行するためのAWSデータベース移行サービス（DMS）の使用について紹介しました。移行するデータソースとしてMongoDBレプリカセットを作成することから始め、宛先テーブルとしてDynamoDBテーブルも作成しました。後続の記事では、データを移行するためのDMS移行の作成と実行について説明します。