Database Migration Service の Source に MongoDB が選択可能になりました!

eyecatch_dms

菊池です。

Database Migration Service(DMS)の移行元データベース(Source)としてMongoDBが設定可能になりました。

試してみた

早速試してみます。

SourceとしてEC2で動作するMongoDBのレプリカセット、TargetとしてS3を利用します。

dms-mongo-006

 

前提条件

移行元のMongoDBの前提条件です。

  • Version 2.6.x または 3.x
  • レプリカセット構成でOplogにアクセス可能なユーザが必要

マイグレーションモード

公式ドキュメントによると、MongoDBからのマイグレーションには2つのモードがあります。MongoDBはJSON形式のドキュメント(RDBのレコードに相当)でデータを扱いますので、それをどのような形式で出力するかが異なります。

  • ドキュメントモード:JSONドキュメントを1つのカラムとしてそのまま出力
  • テーブルモード:JSONドキュメントのキー毎にカラムを設定して出力

今回は上記の2つのパターンで、それぞれどのように出力されるか見てみたいと思います。

エンドポイントの作成

Source/Targetのエンドポイントを作成します。

TargetとなるS3は、バケット/フォルダと権限のあるIAMロールを設定します。

dms-mongo-001

次に、SourceとなるMongoDBです。サーバ名にはマイグレーションインスタンスから解決可能な名前を、ポートはMongoDBデフォルトの27017を設定しました。SSLは今回はVPC内のため設定しません。

dms-mongo-002

ユーザ名、パスワードはあらかじめMongoDBに作成したものを設定します。ユーザにはバックアップに必要な権限を付与しておきます。今回はrootのロールを設定しました。Authentication sourceは認証するユーザが登録されたデータベースを設定します。通常はadminです。

Metadata modeには、前述のtabledocumentがあります。今回は両方のパターンを試しました。

dms-mongo-005

タスクの実行

準備ができたらタスクを実行します。

dms-mongo-003

dms-mongo-004

出力データの確認

DMSで出力したデータを確認してみます。

移行元のMongoDBのデータベース、mainには、以下のようなuserコレクションとデータがあります。

s0-rs0:PRIMARY> db.users.find()
{ "_id" : ObjectId("58dddfc7e87a9d84c86068ed"), "userid" : 10000, "name" : "hoge1", "age" : 19 }
{ "_id" : ObjectId("58dddfc7e87a9d84c86068ee"), "userid" : 20000, "name" : "hoge2", "age" : 33 }
{ "_id" : ObjectId("58dddfc7e87a9d84c86068ef"), "userid" : 30000, "name" : "hoge3", "age" : 41 }
{ "_id" : ObjectId("58dddfc7e87a9d84c86068f0"), "userid" : 40000, "name" : "hoge4", "age" : 24 }
{ "_id" : ObjectId("58dddfc7e87a9d84c86068f1"), "userid" : 50000, "name" : "hoge5", "age" : 50 }
{ "_id" : ObjectId("58dddfc8e87a9d84c86068f2"), "userid" : 60000, "name" : "hoge6", "age" : 16 }
{ "_id" : ObjectId("58dde7c9c1a34a4d588ce97d"), "userid" : 70000, "name" : "hoge7", "age" : 55 }

DMSでS3に出力されたデータを確認します。データベース、コレクションのフォルダが作成され、csv形式で保存されています。

dms-mongo-007

ドキュメントモードの出力

$ cat LOAD00000001.csv
"{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068ed" }, "userid" : 10000, "name" : "hoge1", "age" : 19 }"
"{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068ee" }, "userid" : 20000, "name" : "hoge2", "age" : 33 }"
"{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068ef" }, "userid" : 30000, "name" : "hoge3", "age" : 41 }"
"{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068f0" }, "userid" : 40000, "name" : "hoge4", "age" : 24 }"
"{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068f1" }, "userid" : 50000, "name" : "hoge5", "age" : 50 }"
"{ "_id" : { "$oid" : "58dddfc8e87a9d84c86068f2" }, "userid" : 60000, "name" : "hoge6", "age" : 16 }"
"{ "_id" : { "$oid" : "58dde7c9c1a34a4d588ce97d" }, "userid" : 70000, "name" : "hoge7", "age" : 55 }"

JSONドキュメント毎に単一のレコードが作成されています。

テーブルモードの出力

$ cat LOAD00000001.csv
"58dddfc7e87a9d84c86068ed",+1.0000000000000000e+04,"hoge1",+1.9000000000000000e+01
"58dddfc7e87a9d84c86068ee",+2.0000000000000000e+04,"hoge2",+3.3000000000000000e+01
"58dddfc7e87a9d84c86068ef",+3.0000000000000000e+04,"hoge3",+4.1000000000000000e+01
"58dddfc7e87a9d84c86068f0",+4.0000000000000000e+04,"hoge4",+2.4000000000000000e+01
"58dddfc7e87a9d84c86068f1",+5.0000000000000000e+04,"hoge5",+5.0000000000000000e+01
"58dddfc8e87a9d84c86068f2",+6.0000000000000000e+04,"hoge6",+1.6000000000000000e+01
"58dde7c9c1a34a4d588ce97d",+7.0000000000000000e+04,"hoge7",+5.5000000000000000e+01

元のJSONドキュメントのキー:$oiduseridnameageの単位で、csv形式でデータが入っていることが確認できました。

さいごに

いかがでしょうか。

まさか、DMSでMongoDBがサポートされるとは思っていませんでした。今回は基本的なデータのエクスポートのみでしたが、ネストしたJSONデータの移行やchange data capture (CDC)なども試してレポートしていきたいと思います。

また、先に対応したS3へのマイグレーションと合わせることで、データのバックアップやEMR/Athenaを使った分析といった応用もできそうなので、現在運用しているMongoDBの活用の幅が広がりそうです!

 

AWS Cloud Roadshow 2017 福岡