Help us understand the problem. What is going on with this article?

AWS DocumentDB vs AWS DynamoDB vs MongoDB on EC2 技術選定

MongoDBからの移行での技術選定を書いていきます。
NoSQLのブームが再来していると感じている今日この頃。

今回技術選定をすることになった経緯としては、
既存のwebサイトがlocalhostのMongoDBで動いていたため、冗長化ができずに単一障害点となっており、
webAPおよびDBを冗長化して耐障害性/可用性を高める必要がありました。
※web/APとDBが同一インスタンス上で動いている

既存の環境

Ubuntu 16.04.4 LTS
nginx 1.10.3
node.js 8.9.4
MongoDB 3.4.10

現状では監査ログの出力やフェールオーバーの仕組みは取り入れておりません。
またかなり古いバージョンとなっていますが、今回の記事にはほぼ関係ないので、ご了承ください

Local mongoからの移行技術選定

選定の候補に上がったのは以下でした。
AWSを使用しているので、選択肢はAWSの中で使用できるNoSQLサーバとなります。

  • MongoDB on EC2
  • DocumentDB
  • DynamoDB

アプリケーションの用途として、データ収集用のサーバです。
技術選定の際は以下で考え、総合的判断で算出していきます。
※ ()の中は優先度を示しています

  1. アプリケーションへの影響が小さい (中)
  2. 現状の性能が担保できる (高)
  3. 保守運用コストが低い (中)
  4. サーバ固定費が低い (中)
  5. 耐障害性/可用性が担保できる (高)
  6. DB側の開発コストが低い (高)
  7. データ移行コストが低い (低)

それぞれメリットやデメリットなどを以下で挙げていきます。

MongoDB on EC2

既存のWeb/APとDB一体型からDBを外出しした形となります。
既存と性能や呼び出し方が変わらないため影響は小さいですが、追加開発が多くなります。

メリット

  • アプリケーションへの影響が最小
  • 現状の性能を担保しやすい
  • データ移行コストが最も低い

デメリット

  • バックアップなどの管理をしなければならない
  • フェールオーバーの仕組みをカスタマイズしなければならない
  • ログの送付や監査ログの仕組みをカスタマイズしなければならない

DocumentDB

AWSフルマネージドサービスとなります。
MongoDBとの互換性も高いことが特徴となります。

メリット

  • MongoDBとの互換性が高いため、アプリケーション影響が小さい
  • mongo shellをサポートしているためデータ移行コストも低い
  • AWSフルマネージドのためバックアップや監査ログの運用が楽
  • 可用性や耐障害性もAWSが担保してくれる (はず)
  • 開発コストが低い

デメリット

  • 性能によって費用が高くなる可能性がある

DynamoDB

AWSのマネージドサービスとなります。
MongoDBとの互換性はありませんが、DMS (Database Migration Service)を使用することで移行が楽になります。

メリット

  • サーバの管理が不要
  • AWSマネージドのためバックアップや監査ログの運用が楽
  • 可用性や耐障害性もAWSが担保してくれる

デメリット

  • アプリケーションへの影響が大きい (DB設計からの見直しが必要なため修正が多い)
  • DBの開発コストが高い (設計から見直しが必要)
  • データ移行のコストが他よりも高い (DMSの構築もしなければならない)
  • 性能によって費用が高くなる可能性がある

技術選定結果と考察

以下主観ですが、表にまとめてみました。
性能や費用面は検証が必要なものの、結論から言えばDocumentDBが総評として良さそうと判断しました。

比較項目 MongoDB on EC2 DocumentDB DynamoDB
アプリケーション影響
性能担保 ? ?
保守運用コスト ×
費用 2~3倍 ? ?
耐障害性/可用性
DB側開発コスト ×
データ移行 ×
  1. アプリケーションへの影響が小さい (中)
  2. 現状の性能が担保できる (高)
  3. 保守運用コストが低い (中)
  4. サーバ固定費が低い (中)
  5. 耐障害性/可用性が担保できる (高)
  6. DB側の開発コストが低い (高)
  7. データ移行コストが低い (低)

別途検証の記事は上げていきますので、お楽しみに。

やはり、開発までのハードルの低さ、管理の簡単さ (コスト減)を合理的に判断するとマネージドサービスの使用が良さそうですね。

ただ、ベンダーロックインになってしまうのでコンバージドなアーキテクチャも状況によって検討の余地がありそうです。
Local MongoDB (EC2) vs DocumentDBの記事も記載していきます。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away