Amazon DocumentDB入門｜オンプレMongoDBをAWSに移行するマネージドドキュメントDBの設計と料金ガイド

オンプレで動いていたMongoDBサーバーが老朽化し、「そろそろクラウドに移したい」と考えているインフラエンジニアは多いはずです。MongoDBをそのままEC2に乗せ替えるのは手軽ですが、自前でレプリカセット管理・バックアップ・パッチ適用をしなければならず、マネージドに任せたい気持ちもある。そこで選択肢として挙がるのが Amazon DocumentDB です。

この記事では、Amazon DocumentDBのクラスター構成・MongoDB互換性の実態・料金体系・DynamoDBとの使い分け判断・移行手順・運用Tipsまでを、オンプレ経験者の視点でまとめます。

なぜDocumentDBなのか？オンプレMongoDBをクラウドに移す動機

オンプレのMongoDBで発生しやすい課題は、大きく3つです。

・ハードウェア老朽化: MongoDBはメモリを多用するため、数年経つとスペック不足でレイテンシが悪化します。一方でサーバー買い替えはキャパシティ予測が難しく、過剰投資になりやすいです。
・レプリカセット管理の手間: プライマリ昇格・セカンダリの追加・フェイルオーバー検証は手作業が多く、夜間障害の引き金になりがちです。
・バックアップの属人化: mongodumpのcronスクリプトが特定の担当者にしか把握されていない、という現場はまだ多いです。

Amazon DocumentDBはこれらをマネージドサービスとして解決します。ストレージ・バックアップ・パッチ適用はAWSが担い、エンジニアはアプリケーション層の改善に集中できます。

ただし「MongoDB互換」をそのまま信じて移行すると痛い目を見ます。互換性の範囲は後述しますが、完全な互換性ではない点を最初に頭に入れておいてください。

Amazon DocumentDBの基本構成

1. クラスター構成（プライマリ＋リードレプリカ）

DocumentDBのクラスターは1台のプライマリインスタンスと最大15台のリードレプリカで構成されます。プライマリが書き込みを受け付け、リードレプリカが読み込みを分散させます。

ストレージ層はAmazon Auroraと同じ設計で、3つのアベイラビリティゾーンにまたがる6コピーをバックグラウンドで維持します。インスタンス障害が発生してもストレージのデータは失われず、別のインスタンスが起動すればすぐに再アタッチできます。

オンプレのMongoDBレプリカセットとの大きな違いはここです。オンプレは「インスタンスもストレージも一体」ですが、DocumentDBは「コンピューティングとストレージが独立」しています。プライマリが落ちてもセカンダリ昇格を待つ必要がなく、新しいプライマリが素早くストレージを引き継ぎます。

ストレージは10GBから始まり、データ量に応じて自動で拡張されます。上限はクラスターバージョンによって異なりますが、一般的なワークロードでは64TB超まで対応できます。

2. ストレージ自動拡張の仕組み

DocumentDBのストレージは使った分だけ課金されます（後述の料金の節を参照）。「最初から大きなディスクを確保しなければならない」というオンプレ的な発想は不要です。データが増えればストレージが自動拡張し、データを削除すればその分だけ請求も減ります。

ただし注意点があります。一度拡張したストレージの容量は自動縮小しません。たとえばテスト用に大量データを投入して削除しても、確保されたストレージサイズは減りません。不要なコレクションをdropした後に請求が下がらない場合は、クラスターのスナップショットを取って新しいクラスターにリストアするのが一般的なサイズ縮小手順です。

3. MongoDB互換性の実態（どこまで互換か）

DocumentDBは「MongoDB 4.0、5.0 APIと互換性がある」と説明されていますが、すべてのMongoDBドライバーコマンドが動作するわけではありません。

使えない・挙動が異なる主な機能をあらかじめ把握しておきましょう。

移行前に必ず互換性チェックツール（AWSが提供するmigration assessment）を実行して、既存のMongoDBクエリが動作するかを確認することを強く推奨します。

料金の仕組み（コスト感覚）

DocumentDBの料金は「インスタンス料金 ＋ ストレージ料金 ＋ I/O料金 ＋ バックアップ料金」で構成されます。オンプレのように初期費用はかかりません。

1. インスタンス料金

インスタンスは起動している時間に応じてコンピューティング料金が発生します。執筆時点（2026年7月）の東京リージョン（ap-northeast-1）の参考価格は次の通りです（最新の正確な価格はAWS公式料金ページで必ず確認してください）。

MongoDBは「ワーキングセットがメモリに収まるか否か」でパフォーマンスが大きく変わります。ドキュメント数が多いコレクションを持つ場合はメモリを多く積んだ r6g 系を選ぶのが定石です。t3系は開発・検証環境向けと考えておきましょう。

2. ストレージ・I/O料金

・ストレージ: $0.11 / GB-month（東京リージョン、参考値）
・I/O: $0.20 / 100万リクエスト（読み書き合算）
・バックアップストレージ: 自動バックアップはクラスターのストレージ容量と同量まで無料。超過分は $0.023 / GB-month

I/O料金は見落としがちです。書き込みが多いワークロード（例: センサーデータのリアルタイム記録）では、I/O料金がインスタンス料金を上回ることもあります。移行前にオンプレのIOPS実績をもとに試算しておくことを強く推奨します。

3. 月額コスト試算例

中規模のMongoDBワークロードを想定した試算例です。

シナリオ: db.r6g.large（プライマリ1台）＋ リードレプリカ1台、ストレージ200GB、月間I/O 5億リクエスト

I/O量が多いシナリオでは、DocumentDB Elastic Clusters（I/O最適化モード）の利用も検討に値します。Elastic ClustersはvCPU時間課金＋GB課金のシンプルな構成で、I/O課金がない代わりにGB課金単価がやや高めです。読み書きが均等なワークロードではElastic Clustersの方がトータルコストが低くなる場合があります。

DynamoDBとの使い分け判断

「DocumentDBとDynamoDB、どちらを選べばいいか？」という質問は頻出です。両者はどちらも「AWSのドキュメントDB」と紹介されることがありますが、特性は大きく異なります。

判断の分岐点は「既存のMongoDB資産を活かすか、設計を一から見直せるか」です。

既存のMongoDBアプリケーションをなるべく短期間で移行したいなら DocumentDB が適切です。アプリのコードをほとんど変えずに接続文字列の変更だけで移行できるケースもあります。

一方、新規開発でアクセスパターンがシンプルな場合（例: ユーザーIDで1件取得するだけ）や、無限スケールと運用の手間ゼロを優先するなら DynamoDB の方が長期的に低コストです。

Amazon DynamoDBの詳細な設計とユースケースについてはこちらの記事で解説しています。

オンプレMongoDBからの移行手順

DocumentDBへの移行は大きく「事前確認 → クラスター作成 → データ移行 → 接続切り替え」の4ステップです。

1. 移行前の互換性確認と事前準備

まず使用中のMongoDB操作が DocumentDB と互換性があるかを確認します。AWSは Schema Conversion Tool（SCT）の MongoDBスキャン機能や、公式の互換性チェックリストを提供しています。代表的なチェックポイントは次の通りです。

・MongoDBのバージョンが3.6以上であること（それ以下は先にアップグレードが必要）
・$text 全文検索を使っていないこと（使っている場合はOpenSearch連携への設計変更を先に行う）
・MapReduceを使っていないこと（Aggregation Pipelineへの書き換えが必要）
・ドライバーがTLS必須接続に対応していること（DocumentDBはTLS必須）

2. DocumentDBクラスターの作成

AWSコンソールからクラスターを作成します。VPCの選定が重要で、必ずプライベートサブネットに配置してください。インターネットからの直接アクセスは想定されていません。

# AWS CLIでDocumentDBクラスターを作成する例
aws docdb create-db-cluster \
  --db-cluster-identifier my-docdb-cluster \
  --engine docdb \
  --engine-version 5.0.0 \
  --master-username dbadmin \
  --master-user-password "YourSecurePassword" \
  --vpc-security-group-ids sg-xxxxxxxx \
  --db-subnet-group-name my-docdb-subnet-group

# プライマリインスタンスを追加
aws docdb create-db-instance \
  --db-instance-identifier my-docdb-instance \
  --db-instance-class db.r6g.large \
  --engine docdb \
  --db-cluster-identifier my-docdb-cluster

VPCの設計については Amazon VPC入門の記事 も参考にしてください。オンプレからのアクセスには AWS Site-to-Site VPN または AWS Direct Connect が必要です。

3. TLS証明書の取得

DocumentDBはTLS接続が必須です。オンプレMongoDBでTLSを使っていなかった場合、接続文字列の修正に加えてCA証明書バンドルの設置が必要です。

# AWS提供のCA証明書バンドルをダウンロード
wget https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem

# 証明書の配置（アプリサーバー上）
sudo mv ap-northeast-1-bundle.pem /etc/ssl/certs/docdb-ca-bundle.pem

4. データ移行（mongodump / mongorestore）

既存のMongoDBから mongodump でデータをエクスポートし、DocumentDB に mongorestore でインポートします。

# オンプレMongoDBからエクスポート
mongodump \
  --host 192.168.1.100 \
  --port 27017 \
  --db myapp \
  --out /tmp/mongodump-backup

# DocumentDBへインポート（TLS使用）
mongorestore \
  --host my-docdb-cluster.cluster-xxxxxxxx.ap-northeast-1.docdb.amazonaws.com \
  --port 27017 \
  --username dbadmin \
  --password "YourSecurePassword" \
  --tls \
  --tlsCAFile /etc/ssl/certs/docdb-ca-bundle.pem \
  --db myapp \
  /tmp/mongodump-backup/myapp

大規模なデータ移行（数十GB以上）の場合は、AWS Database Migration Service（DMS）を使うと差分レプリケーション（CDC: Change Data Capture）も活用でき、ダウンタイムを最小化できます。

5. アプリケーションの接続文字列変更

データ移行が完了したら、アプリケーションの接続文字列を切り替えます。

# 変更前（オンプレMongoDB）
mongodb://dbuser:password@192.168.1.100:27017/myapp

# 変更後（DocumentDB）
mongodb://dbadmin:password@my-docdb-cluster.cluster-xxxxxxxx.ap-northeast-1.docdb.amazonaws.com:27017/myapp?tls=true&tlsCAFile=/etc/ssl/certs/docdb-ca-bundle.pem&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false

retryWrites=false は DocumentDB での必須設定です。MongoDBドライバーのデフォルトである retryWrites=true を有効にしたままにすると接続エラーが発生します（DocumentDBは retryableWrites を別の方式で処理するため）。

応用・実務Tips

【重要】コネクションプールの調整

DocumentDBへの接続数はインスタンスサイズによって上限があります。db.r6g.large は最大接続数が約15,000ですが、アプリケーションサーバーが複数台ある場合は合計接続数に注意が必要です。コネクションプールのサイズを`maxPoolSize`パラメータで明示的に設定しましょう。

# Node.js/Mongoose でコネクションプールサイズを指定する例
mongoose.connect(DOCDB_URI, {
  tls: true,
  tlsCAFile: '/etc/ssl/certs/docdb-ca-bundle.pem',
  maxPoolSize: 10,    // アプリサーバー1台あたりの最大接続数
  serverSelectionTimeoutMS: 5000,
});

リードレプリカへの読み込み分散

接続文字列に `readPreference=secondaryPreferred` を設定すると、SELECTに相当する読み込みリクエストをリードレプリカに自動的に振り分けます。プライマリへの負荷を下げ、コストパフォーマンスを改善できます。ただし、書き込み直後の読み込みでリードレプリカのデータがわずかに遅延することがあります（レプリケーションラグ）。強い整合性が求められる場合は `readPreference=primary` を使いましょう。

CloudWatchでのパフォーマンス監視

DocumentDBは Amazon CloudWatch と統合されており、CPUUtilization・FreeableMemory・ReadLatency・WriteLatency・VolumeReadIOPs・VolumeWriteIOPs などのメトリクスを標準で確認できます。

Amazon CloudWatchの設定と活用方法はこちらの記事で詳しく解説しています。MemoryクラウドDBではFreeableMemoryが閾値（例: インスタンスメモリの30%）を下回った場合のアラートを設定しておくのが定石です。

自動バックアップ保持期間の設定

DocumentDBはデフォルトで1日の自動バックアップが有効になっています。本番環境では保持期間を7日以上に設定することを推奨します。コンソールまたはCLIで変更できます。

# バックアップ保持期間を7日に設定
aws docdb modify-db-cluster \
  --db-cluster-identifier my-docdb-cluster \
  --backup-retention-period 7 \
  --apply-immediately

よくあるトラブルと対処法

トラブル1: 接続タイムアウトが頻発する

DocumentDBへのネットワーク経路（VPCセキュリティグループやNACL）でポート27017のインバウンドが許可されているか確認してください。また、アプリサーバーとDocumentDBが同じVPC内またはVPCピアリングで繋がっているかを確認します。インターネット経由でのアクセスはDocumentDBでは直接できません。

トラブル2: retryWrites エラーが出る

前述の通り、MongoDBドライバーのデフォルト設定 `retryWrites=true` がDocumentDBと互換性がありません。接続文字列に `retryWrites=false` を追加してください。

トラブル3: $text演算子でエラーになる

$text は DocumentDB で非対応です。全文検索が必要な場合は Amazon OpenSearch Service と組み合わせて使うアーキテクチャを検討してください。DocumentDB の Change Stream を使って OpenSearch にリアルタイム同期する構成がよく使われます。

トラブル4: mongodump/mongorestoreが途中で止まる

大量データのインポート中にネットワークが途切れると途中でエラーになることがあります。EC2インスタンスをDocumentDBと同じVPC内に立ち上げ、そのインスタンス上でmongodump/mongorestoreを実行することでデータ経路を短くして安定させる手法が有効です。大規模移行ではAWS DMSの利用も検討してください。

トラブル5: コスト試算より実際の請求が高い

I/O料金の見積もりが甘い場合に起こります。DocumentDBはページキャッシュに乗っていないデータを読み出す際のI/Oだけでなく、書き込み時のWAL（Write-Ahead Logging）のI/Oも課金対象です。書き込みが多いワークロードでは予想以上のI/O料金が発生することがあります。AWS Cost Explorerで「DocumentDB」サービスのI/O行を定期的にチェックしましょう。

本記事のまとめ

Amazon DocumentDBは、オンプレのMongoDBをAWSにリフト&シフトする際の有力な選択肢です。ただし「MongoDB互換」は完全互換ではなく、$text全文検索・MapReduce・一部のAggregation Pipelineステージは非対応です。移行前に互換性チェックを必ず行ってください。

料金は「インスタンス＋ストレージ＋I/O」の3構造で、特にI/O料金が想定外に膨らむことがある点を注意してください。

DynamoDBとの選択は「既存MongoDB資産の活用優先か、スケーラビリティと運用負荷ゼロを優先するか」で判断しましょう。

移行手順の要点を整理します。