DocumentDB の特徴と使うための準備
Solution Architect の t_maru です。
業務で Amazon DocumentDB を使う機会がありましたので、必要な事前準備と実際に使ってみたメリット/デメリットについてお話します。
DocumentDB とは？
AWS には多数のデータベースサービスがあり、用途により色々と選択肢がありますが大別すると Relational Database サービスとそうでないサービス (NoSQL) に分けることができると思います。
そんな中で今回のテーマになっている DocumentDB は NoSQL サービスに該当します。
DocumentDB は MongoDB API との互換性のあるフルマネージドな JSON ドキュメントデータベースです。
下記の図はドキュメントデータベースのデータの持ち方を簡易的に表したものです。データは Document という単位で格納し、それを集めたものが Collection 呼ばれます。
SQL の用語の対比については、下記 AWS 公式ドキュメントに掲載されておりましたので SQL に馴染みのある方は下記のドキュメントを見ていただけるとイメージがつかみやすいと思います。
https://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/document-database-documents-understanding.html#document-database-sql-vs-nosql-terms
この Document にはスキーマはなく (Document を一意に識別するための ObjectID は必要です) 自由に Field を持つことが持つことができます。
具体的な例があったほうがわかりやすいので、以下に JSON 形式で表した Document の例を示します。
※ ObjectID にあたる `_id` は省略しています。
// Document 1
{
"FirstName": "一郎",
"LastName": "ビルド"
}
// Document 2
{
"FirstName": "二郎",
"LastName": "ビルド",
"Tel": "000-0000-0000"
}上記の例では FirstName, LastName, Tel が Field にあたるものです。また、先程 `自由に Field を持つことができる` と説明したように、Document 1, Document 2 のように持っている Field が異なっているものも保存できるのが特徴です。DynamoDB を扱ったことのある方は ObjectID を Primary Key に、Field を Attribute と読み替えていただければわかりやすいと思います。
また、MongoDB と API 互換のあるマネージドサービスですので、データを取得する際のクエリが柔軟にかけるという特徴もあります。用途が全く同一ではないため比較するのはあまり適切ではないのですが、DynamoDB のクエリと比べると使えるものがかなり増えるのでびっくりすると思います。
MongoDB のクエリに関する公式ドキュメントのリンクを参考として貼っておきます。
https://www.mongodb.com/docs/manual/tutorial/query-documents/
DocumentDB を使うために必要な準備
前項では DocumentDB の機能的な特徴についてお話ししましたが、ここからはリソースの側面から見てみようと思います。
文章だけで説明するよりは図を用いて説明したほうが早いと思いますので、簡単な構成図を掲載します。
上記からもわかるように DocumentDB は VPC サービスなので VPC, Subnet, SecurityGroup などのリソースが必要になってきます。また複数のインスタンスをまとめてクラスタというものを構成する必要がありますので、対障害性なども考慮して商用環境のリソースは複数の AZ に分散させるなどの考慮も必要になってきます。
上記の構成図では 3 つのインスタンスでクラスターを構成している図で記載しておりますが、検証等で High Availability 構成が不要の場合は Primary instance のみでクラスターとして構成することも可能です。
ここまで見ると RDS と似ているな、と思った方もいらっしゃるのではないかと思いますが概ねその理解で良いと思います。
少し脱線しますが、DocumentDB を作成後に Management Console で DocumentDB Cluster の ARN を見てみると下記のように `rds` という表記が使われていました。
どのような経緯でこのようになっているかわかりませんが、デプロイしたリソースを見ていて上記を見つけたときは、ああやっぱり近しいサービスなんだなと思った記憶があります。
(これは 2023/11 時点のものなので、今後整備されていき rds という表記はなくなっていくのかもしれません。)
次に紹介するものは GUI で DB を操作するツールです。これは DocumentDB を使うために必須ではないのですが、DocumentDB も RDS と同様に Management Console では DB の中身を見たり変更を加えたりすることができず開発中は少し不便なので GUI で DB を操作するためのツールも用意しておくと良いと思います。
ツールは AWS の公式ドキュメントでは以下の 2 つが紹介されています。
Studio 3T
DataGrip
私は Studio 3T を試してみましたが、30日の有償版の体験期間が切れて Free 版となったあともクエリやデータ変更等を行うには不足はありませんでしたので、DocumentDB を検証したりスモールスタートで初めて様子を見るような場合においては十分使えるツールだと思いました。
(有償版の機能の方が直感的に使える機能が豊富なので、有償版が使えるのであればそれに越したことは無いと思います。)
メリット/デメリット
DocumentDB のメリットとデメリットについて整理してみたいと思います。
まずはじめにメリットからまとめます。
JSON のままやり取りができるので Web アプリなど通信が伴うものとの相性が良い
複雑なスキーマ設計をしなくても利用できる
まず、1 点目として上げるならばやはり JSON でデータのやり取りができるという点だと思います。
Web アプリや Native アプリなどでバックエンド側と通信が必要になるようなケースでは JSON でデータをやりとりすることがかなり多いのではないかと思いますので、DB に対しても JSON をそのまま読み書きできるというのは余計なデータ変換処理を作る必要がなくなるため大きなメリットと言えます。
2 点目に挙げた点は、先程 DynamoDB のクエリと比較すると柔軟にデータ検索ができるという内容で話題に挙げたものです。パフォーマンスなどの観点からもしっかりとデータの検索パターンを洗い出して設計をすることが望ましいですが、とりあえず動かしてみようという場合に置いては事前に綿密な設計を必要とせずすぐに使い始められることもメリットになるのではないでしょうか。
次にデメリットになりそうな点を上げてみます。
VPC サービスなので API GW + Lambda などのよくある Serverless 構成とベストマッチとは言えない
Cluster 内のインスタンスが起動している時間に対して課金されるので費用がコンスタントにかかりやすい
1 点目に挙げた項目に関してですが、DocumentDB は VPC 内に配置する DB ですので、どうしても VPC 外部から接続する場合にはひと手間必要となり、AWS の VPC 外サービスのみで構成したような Serverless 構成の場合はベストマッチの組み合わせとは言えないと思います。またこれは 2 点目とも関連するのですが、アクセスがあったときだけ料金が発生するサービスと組み合わせても、DB は起動時間で課金されてしまいますのでできる限り費用を抑えて運用したい場合にも適さない可能性があります。
既に上記で説明してしまいましたが、DocumentDB は RDS と同様にインスタンスが起動している時間に対して料金が発生します。(ストレージの I/O に対しても料金が発生しますが相当量のトラフィックが無い限りはインスタンスの起動時間でかかる費用が大半を占めると思います。)
例えば夜間は使わないなどが予めわかっているようであればスケジュールで停止/起動すれば料金を節約することができますが、DB として機能させるには起動状態にしておく必要があるため用途によってはコストがネックになることもあると思いますので選定時から考慮しておく必要があると思います。
まとめ
今回は DocumentDB の特徴やメリット/デメリット、利用するために準備しておく必要があるものについてご紹介しました。
VPC を既に利用している場合や ECS でコンテナを立てて利用するなど予め VPC を使うことがわかっている場合、既に MongoDB を運用しておりフルマネージドの環境に移行したい場合などには DocumentDB も良い選択肢になると思いますので、用途や料金体系も踏まえた上で検討のテーブルに載せてみてはいかがでしょうか。