Amazon Web Services ブログ

ハイブリッドの方法を使用して、Amazon DocumentDB へ移行する

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れた完全マネージドのドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在の MongoDB 3.6 用のプリケーションコード、ドライバー、ツールをそのまま使用して、Amazon DocumentDB 上でのワークロードの実行、管理、そしてスケーリングが行えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。

MongoDB から Amazon DocumentDB に移行するための主要なアプローチとしては、オフラインオンラインハイブリッドの 3 つがあります。詳細については「移行アプローチ」をご参照ください。

今回の記事では、ハイブリッドアプローチにより MongoDB のデータを Amazon DocumentDB に移行する方法についてご紹介していきます。ハイブリッドアプローチは、オフラインアプローチが持つ移行速度に、オンラインアプローチが提供するダウンタイムの最小化を組み合わせたものです。詳細については「Video: Live migration to Amazon DocumentDB」をご覧ください。

ソースデータセットが 1 TB を超える場合でダウンタイムを最小限に抑えるには、ハイブリッドメソッドが最良の選択肢となります。ハイブリッドの方法では、並列化を活用しながら、データの一括移行を行う mongorestore に対応した速度を実現します。さらに、ダウンタイム最小化のためには、AWS Database Migration Service (DMS) を利用しています。

データセットのサイズが 1 TB 未満の場合は、オンラインもしくはオフラインのアプローチが適しています。オフライおよびオンラインでの移行の詳細については、「オフラインの方法を使用して、MongoDB から Amazon DocumentDB に移行する」および「オンラインの方法を使用して、Amazon DocumentDB に移行する」をご参照ください。

この投稿では、ハイブリッドのアプローチを使用して、Amazon EC2 でホストされている MongoDB レプリカセットから Amazon DocumentDB クラスターにデータを移行する方法を紹介します。

前提条件

移行を開始する前に、次の前提条件を完了してください。

  1. ソースのバージョンと構成を確認する
  2. Amazon Document DB クラスターのサイズを選択してセットアップする
  3. EC2 インスタンスをセットアップする

ソースバージョンと構成の確認

移行元の MongoDB で使用しているバージョンが 3.6 より以前の場合は、ソースデプロイメントとアプリケーションドライバーをアップグレードする必要があります。この場合も、MongoDB 3.6 を Amazon DocumentDB に移行する際の互換性は確保されます。

mongo シェルに次のコードを入力することで、ソースデプロイメントのバージョンを確認できます。

mongoToDocumentDBOnlineSet1:PRIMARY> db.version()
3.4.4

加えて、移行元の MongoDB クラスター (またはインスタンス) がレプリカセットとして構成されていることも確認します。次のコードにより、MongoDB クラスターがレプリカセットとして構成されているかを確認できます。

db.adminCommand( { replSetGetStatus : 1 } )

"errmsg" : "not running with --replSet" のようなエラーメッセージが出力された場合は、そのクラスターはレプリカセットとして構成されていません。

移行元 Amazon DocumentDB クラスター のセットアップとサイズ設定

この投稿では、ターゲットの Amazon DocumentDB クラスターは、単一の db.r5.large インスタンスで作成したレプリカセットです。クラスターのサイズを決定するには、実稼働クラスタに適したインスタンスタイプを選択してください。Amazon DocumentDB インスタンスとコストの詳細については、「Amazon DocumentDB (MongoDB 互換) 料金」をご参照ください。

EC2 インスタンスのセットアップ

Amazon DocumentDB クラスターに接続して、インデックスや移行中の他のタスクを移行するには、クラスターと同じ VPC に EC2 インスタンスを作成し、mongo シェルをインストールします。この手順については「Amazon DocumentDB の開始方法」をご参照ください。お客様が AWS のリソースを作成する場合は、AWS IAM のベストプラクティスに従うことをお勧めしています。Amazon DocumentDB への接続を確認するには、CLI に次のコマンドを入力します。

Amazon Elastic Compute Cloud (EC2)$ mongo --ssl --host docdb-cluster-endpoint \
--sslCAFile rds-ca-2019-root.pem --username myuser \
--password mypassword
…
rs0:PRIMARY> db.runCommand('ping')
{ "ok" : 1 }

ソースインスタンスまたは Amazon DocumentDB クラスターへの接続に問題がある場合は、その両方でセキュリティグループの設定をチェックし、適切なポート (デフォルトでは27017) でのアクセス許可をEC2 インスタンスに対し付与しているかを確認してください。トラブルシューティングの詳細情報については、「 Amazon DocumentDB のトラブルシューティング」をご参照ください。

Amazon DocumentDB はデフォルトでTransport Layer Security (TLS) 暗号化を使用します。TLS 暗号化コレクションを介して接続するには、認証機関 (CA) ファイルをダウンロードして、mongo シェルを使用して接続します。次のコードをご覧ください。

Amazon Elastic Compute Cloud (EC2)$ curl -O https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem

TLS を無効にすることもできます。詳細については「転送中のデータの暗号化」をご参照ください。

インデックス作成および移行のためには、EC2 インスタンスの Amazon EBS ボリュームに、エクスポートされたデータを保持するのに十分な容量を確保することが重要です。データベースのサイズの概算バイト数は、mongo シェルで db.stats() コマンドを実行し storageSize の値を調べることで取得できます。次のコードをご覧ください。

mongoToDocumentDBHybridSet1:PRIMARY> db.stats()
{
"db" : "zips-db",
"collections" : 1,
"views" : 0,
"objects" : 193579,
"avgObjSize" : 65.97073815367189,
"dataSize" : 9843917,
"storageSize" : 8125248,
"numExtents" : 0,
"indexes" : 1,
"indexSize" : 610304,
"scaleFactor" : 1,
"fsUsedSize" : 2396921856,
"fsTotalSize" : 8577331200,
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1582412608, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1582412608, 1)
}

ハイブリッドでの移行手順

次の図は、ハイブリッドでの移行プロセスにおける 6 つのステップを示しています。各ステップは次のとおりです。

  1. アプリケーションが引き続きソースに書き込む
  2. Amazon DocumentDB インデックスツールを使用してインデックスをダンプする
  3. mongodump を使用してデータをダンプする
  4. Amazon DocumentDB インデックスツールを使用してインデックスを復元する
  5. mongorestore を使用してデータを復元する
  6. AWS DMS の変更データキャプチャ (CDC) によりデータをレプリケートする
  7. アプリケーションのエンドポイントを Amazon DocumentDB クラスターに変更する

ステップ 1: アプリケーションによるソースへの継続的な書き込み

ハイブリッドの方式を使って Amazon DocumentDB に移行している間、アプリケーションは移行元の MongoDB データベースへの書き込みを継続するようにます。ソースデータベースへの書き込みを停止した上で、アプリケーションのターゲットを Amazon DocumentDB クラスターに変更する方法については、ステップ 7 で説明します。

ステップ 2: Amazon DocumentDB インデックスツールを使用したインデックスのダンプ

移行を開始する前に、移行元の MongoDB クラスターと同じインデックスを、ターゲットの Amazon DocumentDB クラスターにも作成します。AWS DMS はデータの移行を処理しますが、インデックスは移行しません。インデックスを移行するには、Amazon DocumentDB インデックスツールを使用して、前提条件として準備した EC2 インスタンス上に対し、MongoDB クラスターからインデックスをエクスポートします。このツールの入手には、Amazon DocumentDB ツールの GitHub リポジトリのクローンを作成した上で、README.md の指示に従います。

次のコードでは、移行元の MongoDB クラスターにあるインデックスを、EC2 インスタンスに直接ダンプします。

python migrationtools/documentdb_index_tool.py --dump-indexes 
--dir ~/index.js/ 
--host ec2-user.us-west-2.compute.amazonaws.com 
--auth-db admin 
{"USERNAME", user},
{"PASSWORD", password}

2020-02-11 21:46:50,432: Successfully authenticated to database: admin
2020-02-11 21:46:50,432: Successfully connected to instance ec2-user.us-west-2.compute.amazonaws.com:27017
2020-02-11 21:46:50,432: Retrieving indexes from server...
2020-02-11 21:46:50,440: Completed writing index metadata to local folder: /home/ec2-user/index.js/

インデックスのエクスポートが正常に完了した後、Amazon DocumentDB クラスターでそれらのインデックスを復元します。

ステップ 3: mongodump を使用したデータのダンプ

mongodump ツールを使用して、MongoDB レプリカセットから移行先の EC2 インスタンスに対し、データをエクスポートします。–-readPreference オプションではセカンダリを設定して、ダンプを強制的にセカンダリレプリカセットメンバーに接続させます。この手順により、ソースデプロイメントに対する mongodump からの影響度合が軽減されます。--readPreference オプションを使用するには、replicaSetName/replicasetMember の形式により、レプリカセットメンバーに接続します。次のコードをご覧ください。

Amazon Elastic Compute Cloud (EC2)$ mongodump \
--host mongoToDocumentDBHybridSet1/ec2-x-x-x-x.us-west-2.compute.amazonaws.com 
--username user \
--password password --db zips-db -o .\
--authenticationDatabase admin \
--readPreference secondary
2020-02-03T20:39:05.649+0000 writing zips-db.zips to
2020-02-03T20:39:05.683+0000 done dumping zips-db.zips (29353 documents)

データがエクスポートされるのに必要な時間は、移行元データセットのサイズ、移行先と移行元インスタンスの間のネットワーク速度、および移行先インスタンスにあるリソースの状況によって異なります。mongodump が処理を開始した時刻を記録しておきます。この情報は、後に DMS とCDC での処理を開始する際に必要となります。

インデックスとデータのエクスポートが正常に完了した後、Amazon DocumentDB クラスターで、そのデータとインデックスを復元します。

ステップ 4: Amazon DocumentDB インデックスツールを使用したインデックスの復元

前のステップでターゲットクラスターにエクスポートしたインデックスを復元するには、Amazon DocumentDB インデックスツールを使用します。

次のコードは、EC2 インスタンスから Amazon DocumentDB クラスターのインデックスを復元します。

python migrationtools/documentdb_index_tool.py --restore-indexes
--dir ~/index.js/ 
--host docdb-2x2x-02-02-19-07-xx.cluster-xxxxxxxx.us-west-2.docdb.amazonaws.com:27017
--tls --tls-ca-file ~/rds-ca-2019-root.pem 
{"USERNAME", user}, 
{"PASSWORD", password}

2020-02-11 21:51:23,245: Successfully authenticated to database: admin
2020-02-11 21:51:23,245: Successfully connected to instance docdb-2x2x-02-02-19-07-xx.cluster-xxxxxxxx.us-west-2.docdb.amazonaws.com:27017
2020-02-11 21:51:23,264: zips-db.zips: added index: _id

インデックスが正しく復元されたことを確認するには、mongo シェルを使用して Amazon DocumentDB クラスターに接続し、特定のコレクションのインデックスをリスト化します。次のコードをご覧ください。

mongo --ssl 
--host docdb-2020.cluster-xxxxxxxx.us-west-2.docdb.amazonaws.com:27017
--sslCAFile rds-ca-2019-root.pem --username documentdb --password documentdb
db.zips.getIndexes()

ステップ 5: mongodump を使用したデータの復元

mongodump ユーティリティを使い、ステップ 3 でターゲットクラスターにダンプしたデータを復元します。

次のコードは、EC2 インスタンスから Amazon DocumentDB クラスターにデータを復元します。並列化により復元を高速化するには、--numInsertionWorkersPerCollectionオプションを使います。実用的な方法としては、クラスターの主要インスタンスでの vCPU 数を、numInsertionWorkersPerCollection 値に設定します。インデックスの復元はステップ 4 で完了しているので、ここでは --noIndexRestore オプションを使用し、インデックスの作成が重複することを防ぎます。次のコードをご覧ください。

Amazon Elastic Compute Cloud (EC2)$ mongorestore --host docdb-cluster-endpoint –-ssl –-sslCAFile rds-combined-ca-bundle.pem --username myuser --password mypassword – numInsertionWorkersPerCollection 64 --noIndexRestore <dump_dir>

mongodump の処理が、移行元 MongoDB クラスターでのすべてのデータベースを対象としている (たとえば、ダンプするデータベースを --db オプションにより個別に指定していない) 場合、ダンプ先のディレクトリから管理者ディレクトリを削除します。削除をしない場合、Amazon DocumentDB に対する復元を試みるとエラーが派生します。

全体の復元に要した時間に注意してください。MongoDB の oplog のサイズは、この期間のデータや、次のステップ 6 で行うオンライン移行の完了までに必要な時間を保持するのに足りる大きである必要があります。AWS DMS の CDC タスクでは、oplog を頼りに Amazon DocumentDB にデータをレプリケートします。

ステップ 6: 全データロードと AWS DMS によるレプリケート

AWS DMS は、データベースを AWS のサービスに効率的かつ安全に移行するのに役立つマネージド型サービスです。AWS DMS では、全データロードと CDC、2 つの方法でデータベース移行が可能です。ハイブリッド移行のアプローチでは、CDC を使い Amazon DocumentDB に変更か所をレプリケートします。AWS DMS の使用法の詳細については、「AWS Database Migration Service のステップバイステップチュートリアル」をご参照ください。

ハイブリッド移行を実行するには、次の手順を完了します。

  1. AWS DMS レプリケーションインスタンスを作成します。この手順については「AWS DMS レプリケーションインスタンスを使用する」をご参照ください。
    データ移行の場合、この投稿では dms.t2.medium インスタンスタイプを使用しています。AWS DMS はレプリケーションインスタンスを使用して、ソースの MongoDB からターゲットである Amazon DocumentDB クラスターにデータを移行するタスクを実行します。
    さらに、AWS DMS では、特定のインスタンスタイプと移行ターゲットに対して、最大 6 か月間無料のレプリケーションインスタンスが利用可能です。詳細については「無料のDMS – AWS Database Migration Service」をご参照ください。
  1. MongoDB ソースと Amazon DocumentDB ターゲットエンドポイントを作成します。詳細については「AWS DMS エンドポイントの使用」をご参照ください。
    次のスクリーンショットは、MongoDB クラスターとターゲットの Amazon DocumentDB クラスターに対するこの投稿のエンドポイントを示しています。
  1. ソースとターゲットのエンドポイント間でデータを移行するためのレプリケーションタスクを作成します。
    a.タスクタイプで [データ変更のみをレプリケートする] を選択します。
    b.[作成時にタスクを起動] を有効にする。
    タスクの作成直後にレプリケーションが開始されます。次のスクリーンショットは、全ロード完了後にレプリケーションを実行中のデータベース移行タスクのステータスを示しています。
    タスクに mongodbtodocumentbd-online-fullandongoing を選択すると、より具体的な詳細を確認できます。Table statistics セクションでは、タスクが全データロードの統計結果とソースデータベースとターゲットデータベース間のレプリケーションの実行が表示されます。そのスクリーンショットを次に示します。
    各ドキュメントの数が一致することを確認するには、ソースデータベースとターゲットデータベースで db.collection.count() コマンド を実行します。
    Amazon CloudWatch メトリクスにより移行ステータスを監視したり、進行状況を示すダッシュボードを作成することもできます。次の画面は、ソースデータベースからの着信 CDC の変更の割合を示しています。

ステップ 7: アプリケーションのエンドポイントの Amazon DocumentDB クラスターへの変更

全ロードが完了し、CDC プロセスが継続的なレプリケートを実施し始めたら、アプリケーションのデータベース接続文字列を変更して、Amazon DocumentDB クラスターを使用できるようにします。詳細については、「Amazon DocumentDB エンドポイントについて」および「Amazon DocumentDB のベストプラクティス」をご参照ください。

まとめ

この投稿では、ハイブリッドの方法を使用した、MongoDB から Amazon DocumentDB へのデータ移行方法を説明しました。他の移行方法の詳細については、「オフラインの方法を使用して、MongoDB から Amazon DocumentDB に移行する」、「オンラインの方法を使用して、Amazon DocumentDB に移行する」、および、「Amazon DocumentDB (MongoDB 互換) でのランプアップ」をご参照ください。

ご質問やご意見はコメント欄にお寄せください。

 


著者について

 

Vijay Injamは、アマゾン ウェブ サービスの NoSQL データアーキテクトです。

 

 

 

 

Jeff Duffy は、アマゾン ウェブ サービスのシニア NoSQL スペシャリストソリューションアーキテクトです。

 

 

 

 

Joseph Idziorek は、アマゾン ウェブ サービスのプリンシパルプロダクトマネージャーです。