DMSでDocumentDBからDynamoDBへ移行するときに見つけたバグ?や注意点をまとめます

DMSでDocumentDBからDynamoDBへ移行するときに見つけたバグ?や注意点について

タイトル通りなのですがDatabase Migration Service(DMS)でDocumentDBからDynamoDBへ移行する機会がありましたので、移行の際に注意してほしい点や移行で見つかったDMSの不具合らしき事象を紹介したいと思います。
今回はあくまで自分が遭遇した問題点などをまとめています。

環境

サービス名	バージョン
DocumentDB	3.6.0
DMS(インスタンス)	3.4.7

注意点(Tips)

移行できるデータサイズは400KBまで

DocumentDBではオブジェクトサイズは16MBまで保存できますが移行先であるDynamoDBのドキュメントサイズは400KBまでです。
そのため400KBを超えるデータの移行を行うとエラーになってしまいます。
400KBを超える大きいデータはS3に保存しS3へのリンクを格納するなど対応が必要になります。

ObjectIdと配列は値が変わる

例えばDocumentDBに以下のようなデータがあったとします。

{"_id": 123, numbers": [1, 2, 3]}

DMSでDynamoDBに移行すると以下のようになります。

oid__id - パーティションキー	array_numbers
123	{[1, 2, 3]}

項目名にはプレフィックスが付けられ、配列に関しては値が文字列になってしまうのDocumentDBを使っている感覚で参照すると痛い目にあうので要注意です。

スキーマレスなためDMSの設定によっては移行できない場合がある (テーブルモードのみ)

まずは前提の話ですがDocumentDBはスキーマレスなDBです。
そのため特定のデータにのみ新たな項目を増やしたりもできます。
DMSではこのような特殊なデータを見つけられない可能性があります。
DMSで全ての移行するデータを見つけるためにDocumentDBのソースエンドポイント作成時に"スキャンするドキュメントの数"をデータ数にする必要があります。(デフォルトは1000件)

他にも多く制限はあるので公式のドキュメントから確認してください。

移行するデータ量に応じたメモリが必要

こちらはどのDBのDMS移行でも起きる話だと思いますが体験したので紹介します。
今回移行したデータ量はかなり多かったためかメトリクスを確認するとメモリを使い切りるとディスク容量が消耗されました。おそらくSWAP領域の消費が始まったものだと考えられます。
AWSの問い合わせでも似たようなことが聞かれていました。
幸いディスク容量が尽きることはなかったですが大量のデータを移行する場合は、DMSインスタンス作成時にディスク容量を余裕を持って設定すると良いでしょう。

DMSのバグ？を見つけました

前程

前述した通りDocumentDBはスキーマレスなDBです。
そのため一つの項目でもデータによって別の型を保存することもできます。

起きた現象

一つの項目に複数の型のデータが保存されている場合、一つの型のデータしか移行されない
例) 以下のようなDocumentDBのデータを移行した場合

{"_id": 123, "number": 100, "_id": 456, "number": 1.23}

DMSでDynamoDBに移行すると以下のようになります。

oid__id - パーティションキー	array_numbers
123	100
456

移行前ではfloatのデータとint型のデータが混在してましたがDynamoDBに移行するとint型のデータのみ移行されておりfloat型のデータは空でした。
検証したところint型とstring型でも同様に片方の型のデータのみ移行されました。
ドキュメントを見ましたが該当しそうな箇所はありませんでした。
もし問題があるならエラーが出て欲しいところですが、検証した限りはエラーは出ず上記のようにデータ欠損のまま実行されるようでした。

後日談というか今回のオチ

AWSサポートへ問い合わせしましたが、
"原因を調査中です。2023年6月2日に調査結果を共有します。"と言う連絡があり現時点で原因はわかっていません。
自分の行った対策としては強引なやり方ですが型ごとにCollectionを分けて移行しました。これだと欠損することなく移行出来ました。

最後に

DocumentDBからDynamoDBへの移行はかなりレアケースだと思うので検討している方、実際に詰まっている方の助けになれたらと思います。