互換性ワークロードの検出インデックスの移行ユーザー移行データ移行モニタリング検証

Amazon DocumentDB 移行ランブック

このランブックは、 AWS Database Migration Service (DMS) を使用して MongoDB データベースを Amazon DocumentDB に移行するための包括的なガイドを提供します。これは、最初の検出から移行後の検証まで、end-to-endの移行ジャーニーを通じてデータベース管理者、クラウドエンジニア、開発者をサポートするように設計されています。

MongoDB と Amazon DocumentDB の実装とサポートされている機能の違いを考慮すると、このランブックは構造化された体系的なアプローチを強調しています。重要な移行前評価の概要、互換性に関する考慮事項、および最小限の中断で移行を成功させるために必要な主要なタスクについて詳しく説明します。

ランブックは、以下のトピックで構成されています。

互換性 — Amazon DocumentDB でサポートされている MongoDB 機能とデータ型を理解し、潜在的な非互換性を特定します。
ワークロードの検出 — 読み取り/書き込みパターン、データボリューム、パフォーマンスベースラインなど、既存の MongoDB ワークロードを分析します。
インデックスの移行 — Amazon DocumentDB MongoDB インデックスを抽出および変換するための戦略を分析します。
ユーザー移行 — データベースユーザー、ロール、アクセスコントロールを Amazon DocumentDB に移行するためのアプローチについて詳しく説明します。
データ移行 — 全ロードおよび変更データキャプチャ (CDC) など AWS DMS、を使用したデータ移行のさまざまな方法について説明します。
モニタリング — DMS またはネイティブツールを使用して移行する際のさまざまなモニタリングアプローチについて詳しく説明します。
検証 — 移行後のデータ整合性チェック、機能検証、パフォーマンス比較の手順を提供します。

このランブックのガイダンスに従うことで、チームはアプリケーションの機能を維持し、リスクを最小限に抑えながら、Amazon DocumentDB へのスムーズで安全で効率的な移行を確保できます。

互換性

MongoDB から Amazon DocumentDB に移行する場合、移行を成功させるには、徹底的な初期評価と機能の互換性チェックが不可欠です。このプロセスは、集約パイプライン演算子、クエリパターン、インデックス、データモデルなど、MongoDB 機能の包括的なインベントリから始まります。

Amazon DocumentDB は MongoDB 3.6、4.0、5.0 API と互換性があるため、新しい MongoDB 固有の機能を使用するアプリケーションではリファクタリングが必要になる場合があります。評価する重要な領域には、シャーディングメカニズム (Amazon DocumentDB は異なるアプローチを使用）、トランザクション実装、変更ストリーム機能、インデックスタイプ (特にスパースインデックスと部分インデックス) などがあります。

パフォーマンス特性も異なり、Amazon DocumentDB は予測可能なパフォーマンスを持つエンタープライズワークロード向けに最適化されています。テストでは、両方のシステムに対して代表的なワークロードを実行して、最適化が必要なクエリパターンを特定する必要があります。

評価フェーズでは、潜在的なパフォーマンスギャップを検出するために実行計画をモニタリングすることが重要です。これにより、明確な移行ロードマップを作成し、必要なアプリケーションの変更を特定し、スムーズな移行のための現実的なタイムラインを確立できます。

コア機能の互換性

包括的な機能サポート

CRUD オペレーション — 一括演算子やクエリ演算子など、すべての基本的な作成、読み取り、更新、削除オペレーションを完全にサポートし、シームレスなアプリケーションの互換性を実現します。
豊富なインデックス作成機能 — 単一フィールド、複合、TTL、部分インデックス、スパースインデックス、2dsphere インデックスの包括的なサポートを活用して、テキストベースのルックアップのクエリパフォーマンスとテキストインデックス (バージョン 5) を最適化します。
エンタープライズグレードのレプリケーション — リードレプリカを備えた堅牢な自動フェイルオーバーメカニズムにより、運用上のオーバーヘッドなしで優れた高可用性を実現できます。
高度なバックアップソリューション — データ保護のためのPoint-in-Timeリカバリ (PITR) とオンデマンドの手動スナップショットを備えた自動バックアップシステムにより、簡単にバックアップできます。

拡張 AWS統合機能

効率的な集約 — エンタープライズワークロード向けに最適化されたパフォーマンスで、最も一般的に使用される集約ステージ ($match、$group$sort、、 $projectなど) を活用します。
トランザクションのサポート — マルチドキュメントトランザクションとマルチコレクショントランザクションを実装し、ほとんどのビジネスアプリケーションのニーズに最適です。
リアルタイムデータ追跡 — シンプルなコマンドで変更ストリームを有効にし、リアルタイムのデータ変更モニタリング用のシンプルなパラメータグループ設定で変更ストリームの保持期間を延長します。
位置情報ベースのサービス — $geoNearオペレーターインデックスと 2dsphere インデックスをサポートする地理空間アプリケーションを実装します。
テキスト検索機能 — コンテンツ検出のニーズに応じて、組み込みのテキスト検索機能を使用します。

Amazon DocumentDB 互換性評価ツール

MongoDB から Amazon DocumentDB への互換性ツールは、GitHub で利用可能なオープンソースユーティリティです。MongoDB ログまたはアプリケーションのソースコードを分析することでAmazon DocumentDB との MongoDB ワークロードの互換性を評価するのに役立ちます。

主な特徴

ワークロードの MongoDB API 使用パターンを識別します
移行前に潜在的な互換性の問題にフラグを付けます
レコメンデーションを含む詳細な互換性レポートを生成します
ローカルで実行できるスタンドアロンユーティリティとして利用可能

評価方法

ログベースの評価

メリット:
- 実際のランタイム動作とクエリパターンをキャプチャします
- 実際の使用頻度とパフォーマンス特性を特定します
- ソースコードに表示されない可能性のある動的クエリを検出します
- アプリケーションのソースコードへのアクセスは不要
デメリット:
- プロファイリングを有効にして MongoDB ログにアクセスする必要があります
- ログ記録期間中に発生したオペレーションのみをキャプチャします
- 使用頻度の低い機能や季節的なワークロードを見逃す可能性がある

ソースコード分析

メリット:
- コードベースで考えられるすべての MongoDB オペレーションの包括的なカバレッジ
- ほとんど実行されないコードパスの問題を特定できる
- Amazon DocumentDB の違いの影響を受ける可能性のあるクライアント側のロジックを検出します
- 評価を実行するためにアプリケーションを実行する必要がない
デメリット:
- 存在するが本番環境で実行されないコードにフラグを付ける可能性がある
- 完全なアプリケーションソースコードにアクセスする必要があります
- 動的に構築されたクエリを分析する機能が限られている

最良の結果を得るには、移行前に互換性の課題の全体像を把握するために、可能であれば両方の評価方法を使用することをお勧めします。

ワークロードの検出

MongoDB から Amazon DocumentDB に移行するには、既存のデータベースワークロードを完全に理解する必要があります。ワークロード検出は、データベースの使用パターン、データ構造、クエリパフォーマンス、運用上の依存関係を分析し、中断を最小限に抑えながらシームレスな移行を確保するプロセスです。このセクションでは、MongoDB から Amazon DocumentDB への効果的な移行を容易にするためのワークロード検出に関連する主要なステップの概要を説明します。

トピック

既存の MongoDB デプロイの評価
データモデルの違いを特定する
クエリとパフォーマンスの分析
セキュリティとアクセスコントロールのレビュー
運用とモニタリングに関する考慮事項

既存の MongoDB デプロイの評価

移行前に、以下を含む現在の MongoDB 環境を評価することが重要です。

クラスターアーキテクチャ — ノード、レプリカセット、シャーディング設定の数を特定します。MongoDB から Amazon DocumentDB に移行する場合、Amazon DocumentDB はユーザー制御のシャーディングをサポートしていないため、MongoDB シャーディング設定を理解することが重要です。 Amazon DocumentDB シャーディングされた MongoDB 環境用に設計されたアプリケーションでは、Amazon DocumentDB がストレージベースのアーキテクチャで異なるスケーリングアプローチを使用するため、アーキテクチャの変更が必要になります。Amazon DocumentDB に移行するときは、データ分散戦略を適応させ、場合によってはシャードコレクションを統合する必要があります。
ストレージとデータボリューム — クラスターの合計データサイズとインデックスサイズを測定します。これを Oplog レビューツールで補完し、書き込みパターンとデータの増加速度を理解します。クラスターのサイズ設定の詳細については、「」を参照してくださいインスタンスのサイズ指定。
ワークロードパターン — 読み取りおよび書き込みスループット、クエリ実行頻度、インデックス作成効率を分析します。
運用上の依存関係 — MongoDB に依存するすべてのアプリケーション、サービス、統合を文書化します。

データモデルの違いを特定する

Amazon DocumentDB は MongoDB と互換性がありますが、サポートされている機能には次のような違いがあります。

トランザクション — Amazon DocumentDB は ACID トランザクションをサポートしますが、一部のを使用します制限。
スキーマ設計 — ドキュメント構造、埋め込みドキュメント、リファレンスが Amazon DocumentDB のベストプラクティスと一致していることを確認します。

クエリとパフォーマンスの分析

クエリの動作を理解することで、移行と移行後のパフォーマンスを最適化できます。分析すべき主な領域は次のとおりです。

スロークエリ — MongoDB のプロファイリングツールを使用して、実行時間が長いクエリを特定します。
クエリパターン — CRUD オペレーションや集計など、一般的なクエリタイプを分類します。
インデックスの使用 — インデックスが Amazon DocumentDB で効果的に使用されているか、最適化が必要かを評価します。Amazon DocumentDB でインデックスの使用状況を評価し、パフォーマンスを最適化するには、$indexStats集約パイプラインステージを重要なクエリの explain()メソッドと組み合わせて使用します。まずdb.collection.aggregate([{$indexStats{}}])、を実行して、使用されているインデックスを特定します。を使用して最も頻繁にクエリを実行することで、より詳細な分析を行うことができますexplainPlan。
同時実行とワークロードの分散 — 読み取りと書き込みの比率、接続プーリング、パフォーマンスのボトルネックを評価します。

セキュリティとアクセスコントロールのレビュー

認証と認可

MongoDB RBAC を Amazon DocumentDB IAM および RBAC にマッピング — MongoDB のロールベースのアクセスコントロールユーザーとロールを AWS Identity and Access Management (IAM) ポリシーと Amazon DocumentDB SCRAM 認証ユーザーにマッピングします。
ユーザー移行戦略 — データベースユーザー、カスタムロール、権限を Amazon DocumentDB でサポートされている認証メカニズムに移行する計画を立てます。
権限の違い — Amazon DocumentDB と同等のもの (クラスター管理ロールなど) を直接使用せずに MongoDB 権限を特定します。 Amazon DocumentDB
アプリケーション認証 — Amazon DocumentDB のパスワードポリシーの接続文字列と認証情報管理を更新します。シークレットマネージャーを使用して、認証情報を保存し、パスワードを更新できます。
サービスアカウント管理 — でサービスアカウントの認証情報を管理するプロセスを確立します AWS Secrets Manager。
最小特権の実装 — アクセスコントロールを確認して絞り込み、新しい環境に最小特権の原則を実装します。

Encryption

保管中および転送中の暗号化がコンプライアンス要件と一致していることを確認します。

ネットワーク構成

Virtual Private Cloud (VPC) のセットアップとセキュリティグループルールを計画します。

運用とモニタリングに関する考慮事項

システムの信頼性を維持するために、ワークロード検出には以下も含める必要があります。

バックアップと復元戦略 — 既存のバックアップ方法と Amazon DocumentDB のバックアップ機能を評価します。
AWS Backup 統合 — を活用して、Amazon DocumentDB を含む AWS のサービス全体で一元化されたバックアップ管理 AWS Backup を行います。
CloudWatch メトリクス — MongoDB モニタリングメトリクスを、CPU、メモリ、接続、ストレージの Amazon DocumentDB CloudWatch メトリクスにマッピングします。
Performance Insights — Amazon DocumentDB Performance Insights を実装して、データベースの負荷を視覚化し、詳細なクエリ分析でパフォーマンスの問題を分析します。
プロファイラー — Amazon DocumentDB MongoDB のプロファイラーに似ていますが、Amazon DocumentDB 固有の設定) をキャプチャするように Amazon DocumentDB プロファイラーを設定します。
- 適切なしきい値を持つパラメータグループを使用してを有効にします。
- プロファイラーデータを分析して最適化の機会を特定する
CloudWatch Events — Amazon DocumentDB クラスターイベントのイベント駆動型モニタリングを設定します。
- バックアップイベント、メンテナンスウィンドウ、フェイルオーバーの通知を設定します。
- アラートおよび自動応答のために Amazon SNS と統合 AWS Lambda します。
監査ログ記録 — ユーザーアクティビティとセキュリティ関連のイベントを追跡するための監査ログ記録設定を計画します。
拡張モニタリング — 1 秒間隔できめ細かな OS レベルのメトリクスの拡張モニタリングを有効にします。

インデックスの移行

MongoDB から Amazon DocumentDB への移行には、データだけでなくインデックスも転送してクエリパフォーマンスを維持し、データベースオペレーションを最適化する必要があります。このセクションでは、互換性と効率を確保しながら、MongoDB から Amazon DocumentDB にインデックスを移行するための詳細なstep-by-stepプロセスの概要を説明します。

Amazon DocumentDB インデックスツールの使用

インデックスツールのクローンを作成する


git clone https://github.com/aws-samples/amazon-documentdb-tools.git
cd amazon-documentdb-tools/index-tool


pip install -r requirements.txt

MongoDB からインデックスをエクスポートする (MongoDB から移行する場合）


python3 migrationtools/documentdb_index_tool.py --dump-indexes --dir mongodb_index_export --uri
'mongodb://localhost:27017'

Amazon DocumentDB からインデックスをエクスポートする (Amazon DocumentDB から移行する場合）


python3 migrationtools/documentdb_index_tool.py --dump-indexes --dir docdb_index_export --uri
'mongodb://user:password@mydocdb.cluster-cdtjj00yfi95.eu-west-
2.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=rds-combined-ca-
bundle.pem&replicaSet=rs0&retryWrites=false'

インデックスをインポートする


python3 migrationtools/documentdb_index_tool.py --restore-indexes --skip-incompatible --dir
mongodb_index_export --uri 'mongodb://user:password@mydocdb.cluster-cdtjj00yfi95.eu-west-
2.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=rds-combined-ca-
bundle.pem&replicaSet=rs0&retryWrites=false'

インデックスの検証


python3 migrationtools/documentdb_index_tool.py --show-issues --dir mongodb_index_export

ユーザー移行

MongoDB から Amazon DocumentDB にユーザーを移行することは、アクセスコントロール、認証、データベースセキュリティを維持する上で不可欠です。このセクションでは、Amazon MongoDB ユーザーのロールとアクセス許可を保持しながら、MongoDB ユーザーを正常に移行するための詳細な手順について説明します。 Amazon DocumentDB

Amazon DocumentDB ユーザーエクスポートツールの使用

は、ユーザーとロールを MongoDB または Amazon DocumentDB から JavaScript ファイルにExport Users toolエクスポートし、それを別のクラスターで再作成するために使用できます。

前提条件


# Clone the repository
git clone https://github.com/awslabs/amazon-documentdb-tools.git
cd amazon-documentdb-tools/migration/export-users


# Install required dependencies
pip install pymongo

ステップ 1: ユーザーとロールをエクスポートする


# Export users and roles to JavaScript files
python3 docdbExportUsers.py \
--users-file mongodb-users.js \
--roles-file mongodb-roles.js \
--uri "mongodb://admin:password@source-host:27017/"

ステップ 2: ユーザーファイルを編集する


// Example of how to update the users.js file
// Find each user creation statement and add the password
db.getSiblingDB("admin").createUser({
user: "appuser",
// Add password here
pwd: "newpassword",
roles: [
{ role: "readWrite", db: "mydb" }
]
})

ステップ 3: カスタムロールを Amazon DocumentDB に復元する


# Import roles first
mongo --ssl \
--host target-host:27017 \
--sslCAFile rds-combined-ca-bundle.pem \
--username admin \
--password password \
mongodb-roles.js

ステップ 4: Amazon DocumentDB にユーザーを復元する


# Import users after roles are created
mongo --ssl \
--host target-host:27017 \
--sslCAFile rds-combined-ca-bundle.pem \
--username admin \
--password password \
mongodb-users.js

重要な注意事項

セキュリティ上の理由からパスワードはエクスポートされないため、users.js ファイルに手動で追加する必要があります。
ロールを適切に割り当てるには、ユーザーの前にロールをインポートする必要があります。
このツールは、mongo シェルで直接実行できる JavaScript ファイルを生成します。
カスタムロールとその権限は移行中も保持されます。
このアプローチにより、インポート前にユーザーアクセス許可を確認および変更できます。

この方法は、MongoDB から Amazon DocumentDB にユーザーとロールを移行するための安全で柔軟なアプローチを提供し、移行プロセス中にパスワードをリセットできるようにします。

データ移行

トピック

オンライン移行
オフライン移行
前提条件
Amazon DocumentDB クラスターを準備する
データダンプを実行する (mongodump)
ダンプファイルを復元環境に転送する
Amazon DocumentDB (mongorestore) へのデータの復元

オンライン移行

このセクションでは、最小限のダウンタイムと継続的なレプリケーションを可能にする AWS DMS ために、を使用して MongoDB から Amazon DocumentDB へのオンライン移行を実行する詳細な手順について説明します。まず、Amazon DocumentDB クラスターをターゲットとして設定し、MongoDB インスタンスがソースとして適切に設定されていることを確認します。通常、変更データキャプチャにはレプリカセットモードが必要です。次に、DMS レプリケーションインスタンスを作成し、必要な接続の詳細を使用してソースエンドポイントとターゲットエンドポイントを定義します。エンドポイントを検証したら、フルデータロード、継続的なレプリケーション、またはその両方を含む移行タスクを設定して開始します。

ターゲットを設定する (Amazon DocumentDB)

注記

移行する Amazon DocumentDB クラスターを既にプロビジョニングしている場合は、このステップをスキップできます。

カスタムパラメータグループを作成する

「」の AWS Management Console 「」または AWS CLI 「」の手順を参照してください Amazon DocumentDB クラスターパラメータグループを作成する。

Amazon DocumentDB クラスターの作成

注記

このガイドには Amazon DocumentDB クラスターを作成する他の手順がありますが、このセクションの手順は、特に大量のデータを新しいクラスターに移行するタスクに適用されます。

にサインインし AWS Management Console、https://console.aws.amazon.com/docdb で Amazon DocumentDB コンソールを開きます。
ナビゲーションペインで クラスター を選択します。

ヒント
画面の左側にナビゲーションペインが表示されない場合は、ページの左上隅にあるメニューアイコン () を選択します。
Amazon DocumentDB マネジメントコンソールで、[クラスター] の下にある [作成] を選択します。
Amazon DocumentDB クラスターの作成ページのクラスタータイプセクションで、インスタンスベースのクラスターを選択します (これはデフォルトのオプションです）。
クラスター設定セクションで、次の操作を行います。
- [クラスター識別子] には、mydocdbcluster などの一意の名称を入力します。コンソールは、入力方法に関係なく、すべてのクラスター名を小文字に変更することに注意してください。
- エンジンバージョンで、5.0.0 を選択します。
クラスターストレージ設定セクションで、Amazon DocumentDB 標準設定をそのままにします (これはデフォルトのオプションです）。
インスタンス設定 セクション:
- DB インスタンスクラスの場合は、メモリ最適化クラス (r クラスを含む) を選択します (デフォルト）。
- インスタンスクラス では、ワークロードに基づいてインスタンスクラスを選択します。例:
  - db.r6g.large: 小規模なワークロード向け
  - db.r6g.4xlarge: 大規模なワークロード向け
  ベストプラクティスとして、最適なフルロードスループットを得るには、インスタンスを可能な限り大きく選択し、移行が完了したらスケールダウンすることをお勧めします。
- インスタンス数 で、インスタンスを 1 つ選択します。1 つのインスタンスを選択すると、コストを最小限に抑えることができます。フルロード移行が完了したら、高可用性のために 3 つのインスタンスにスケールすることをお勧めします。
認証セクションで、プライマリユーザーのユーザー名を入力し、セルフマネージドを選択します。パスワードを入力して確認します。
ネットワーク設定セクションで、VPC とサブネットグループを選択し、VPC セキュリティグループを設定します。インバウンドルールを更新して、Amazon DocumentDB セキュリティグループが DMS インスタンスのセキュリティグループからのインバウンド接続を許可していることを確認します。
Encryption-at-restセクションで、暗号化を有効にし (推奨）、KMS キーを選択または入力します。
Backup セクションで、バックアップ保持期間 (1～35 日) を設定します。
設定を確認し、クラスターの作成を選択します。

デプロイには通常 10～15 分かかります。

ソースを設定する

MongoDB と Amazon DocumentDB は、シナリオに応じて、どちらも移行ソースとして機能します。

ソースとしての MongoDB — オンプレミスまたはセルフマネージド MongoDB から Amazon DocumentDB または他の AWS データベースサービスに移行する場合に一般的です。移行中の変更データキャプチャをサポートするために、適切なサイズのオポログを使用してレプリカセットモードで実行する必要があります (フルロード中にすべてのオペレーションを保持するサイズになっていることを確認してください）。
ソースとしての Amazon DocumentDB — 通常、クロスリージョンレプリケーション、バージョンアップグレード、MongoDB Atlas などの他のデータベースサービスへの移行に使用されます。クラスターchange_stream_log_retention_durationパラメータグループのパラメータを設定して、移行中に進行中の変更をキャプチャ変更ストリームの有効化する必要があります。change_stream_log_retention_duration 設定がフルロードの完了に必要な時間をカバーするのに十分な大きさであることを確認します。

移行を開始する前に、 AWS DMS アクセスを許可するようにソースを設定します。

適切なアクセス許可を持つ MongoDB ユーザーを作成します。


db.createUser({
user: "dmsUser",
pwd: "yourSecurePassword",
roles: [{ role: "readAnyDatabase", db: "admin" }]
})

ネットワークと認証を設定します。

MongoDB から DMS への移行用のネットワーク接続を設定する場合：

EC2-hosted MongoDB ソース

EC2 セキュリティグループを変更して、DMS レプリケーションインスタンスのセキュリティグループからのインバウンドトラフィックを許可します。
TCP ポート 27017 (またはカスタム MongoDB ポート) のルールを追加します。
DMS レプリケーションインスタンスのセキュリティグループ ID を正確なアクセスコントロールのソースとして使用します。
EC2 インスタンスのサブネットに DMS レプリケーションインスタンスのサブネットへのルートがあることを確認します。

オンプレミス MongoDB ソース

DMS レプリケーションインスタンスのパブリック IP アドレスからのインバウンド接続を許可するようにファイアウォールを設定します。
AWS Direct Connect または VPN を使用している場合は、ネットワークと DMS インスタンスを含む VPC 間の適切なルーティングを確認してください。
DMS サブネットから MongoDB サーバーへの telnet または nc コマンドを使用して接続をテストします。

MongoDB Atlas ソース

DMS レプリケーションインスタンスの IP アドレスを MongoDB Atlas IP 許可リストに追加します。
Atlas が実行されている場合は AWS 、VPC と MongoDB Atlas VPC 間の VPC ピアリングを設定します AWS。
別のクラウドプロバイダーで実行されている場合は、プライベート接続 (エンタープライズ階層) AWS PrivateLink を設定します。
適切な読み取り/書き込みアクセス許可を持つ専用ユーザーを作成します。
SSL モードを「verify-full」に設定して MongoDB Atlas 接続文字列を使用します。
移行期間に十分なオプログサイズを確保します。

Amazon DocumentDB ソース

DMS レプリケーションインスタンスのセキュリティグループからのインバウンドトラフィックを許可するように、ソース Amazon DocumentDB セキュリティグループを設定します。

DMS レプリケーションインスタンスを作成する

最適な DMS 設定とインスタンスサイズで最適な移行インフラストラクチャを作成するため、DMS Buddy を使用して DMS インフラストラクチャをプロビジョニングすることをお勧めします。

を手動で設定する場合は、次の手順に従います。

DMS AWS コンソールを開き、レプリケーションインスタンスの作成を選択します。
レプリケーションインスタンスの詳細を入力します。
- インスタンス名: 一意の名前を選択します。
- インスタンスクラス: ワークロードに基づいて選択します。例: dms.r5.large (小規模なワークロード）、dms.r5.4xlarge (大規模なワークロード）。
- エンジンバージョン: 3.5.4
- 割り当てられたストレージ: デフォルトは 100GB (必要に応じて増加) です。これは、ドキュメントのサイズ、更新/秒、全ロード時間によって決まります。
- マルチ AZ 配置: 必要に応じて高可用性を有効にします。
- Amazon DocumentDB と同じ VPC を選択します。
- セキュリティグループがソースと Amazon DocumentDB からのインバウンドトラフィックを許可していることを確認します。
レプリケーションインスタンスの作成をクリックし、ステータスが使用可能になるまで待ちます。

DMS エンドポイントを作成する

ソースエンドポイントを作成する

MongoDB ソースの場合

DMS コンソールのナビゲーションペインで、移行またはレプリケートを選択し、エンドポイントを選択します。
[エンドポイントの作成] を選択します。
エンドポイントの作成ページで、ソースエンドポイントを選択します。
エンドポイント設定セクションで、次の操作を行います。
- 一意で意味のあるエンドポイント識別子 (「mongodb-source」など) を入力します。
- ソースエンジンとして MongoDB を選択します。
- [Access to endpoint database] (エンドポイントデータベースへのアクセス) では、[Provide access information manually] (アクセス情報を手動で提供) を選択します。
- サーバー名に、MongoDB サーバーの DNS 名/IP アドレスを入力します。
- ポートには、27017 (デフォルトの MongoDB ポート) と入力します。
- 認証モードでは、アプリケーションに適したモード (パスワード/SSL) を選択します (デフォルトは Secrets Manager)。
- 認証モードがパスワードの場合は、以下を指定します。
  - ユーザー名とパスワード: MongoDB 認証情報を入力します。
  - データベース名: ソースデータベース名。
  - 認証メカニズム: SCRAM-SHA-1 (デフォルト) または適切なメカニズム
メタデータモードでは、ドキュメントのデフォルト設定のままにします。
追加の接続属性：
- authSource=admin (認証データベースが異なる場合）
- replicaSet=<your-replica-set-name> (CDC に必須）

Amazon DocumentDB ソースの場合

DMS コンソールのナビゲーションペインで、移行またはレプリケートを選択し、エンドポイントを選択します。
[エンドポイントの作成] を選択します。
エンドポイントの作成ページで、ソースエンドポイントを選択します。
エンドポイント設定セクションで、次の操作を行います。
- 一意で意味のあるエンドポイント識別子 (「docdb-source」など) を入力します。
- Amazon DocumentDB をソースエンジンとして選択します。
- [Access to endpoint database] (エンドポイントデータベースへのアクセス) では、[Provide access information manually] (アクセス情報を手動で提供) を選択します。
- サーバー名に、ソース Amazon DocumentDB クラスターエンドポイントを入力します。
- ポートには、27017 (デフォルトの Amazon DocumentDB ポート) と入力します。
- SSL モードの場合は、verify-full (Amazon DocumentDB に推奨) を選択します。
- CA 証明書で、Amazon RDS ルート CA 証明書を選択します。
- 認証モードでは、アプリケーションに適したモード (パスワード/SSL) を選択します (デフォルトはシークレットマネージャー）。
- 認証モードがパスワードの場合は、以下を指定します。
  - ユーザー名とパスワード: Amazon DocumentDB 認証情報を入力します。
  - データベース名: ソースデータベース名。
  - 認証メカニズム: SCRAM-SHA-1 (デフォルト) または適切なメカニズム
メタデータモードでは、ドキュメントのデフォルト設定のままにします。

ターゲットエンドポイントを作成する (Amazon DocumentDB)

DMS コンソールのナビゲーションペインで、移行またはレプリケートを選択し、エンドポイントを選択します。
[エンドポイントの作成] を選択します。
エンドポイントの作成ページで、ターゲットエンドポイントを選択します。
エンドポイント設定セクションで、次の操作を行います。
- 一意で意味のあるエンドポイント識別子 (「docdb-target」など) を入力します。
- ターゲットエンジンとして Amazon DocumentDB を選択します。
- エンドポイントデータベースへのアクセス で、データベースへのアクセスを認証するために使用する方法を選択します。
  - AWS Secrets Manager を選択した場合は、Secret フィールドに Amazon DocumentDB 認証情報を保存するシークレットを選択します。
  - アクセス情報を手動で提供するを選択した場合：
    
    サーバー名に、ターゲット Amazon DocumentDB クラスターエンドポイントを入力します。
    ポートには、27017 (デフォルトの Amazon DocumentDB ポート) と入力します。
    SSL モードの場合は、verify-full (Amazon DocumentDB に推奨) を選択します。
    CA 証明書の場合は、SSL 検証用の CA 証明書バンドルをダウンロードして指定します。
    認証モードでは、アプリケーションに適したモード (パスワード/SSL) を選択します (デフォルトはシークレットマネージャー）。
    認証モードがパスワードの場合は、以下を指定します。
    
    ユーザー名とパスワード: Amazon DocumentDB 認証情報を入力します。
    データベース名: ソースデータベース名。
    認証メカニズム: SCRAM-SHA-1 (デフォルト) または適切なメカニズム
メタデータモードでは、ドキュメントのデフォルト設定のままにします。

レプリケーションタスクを作成する

DMS コンソールのナビゲーションペインで、移行またはレプリケートを選択し、タスクを選択します。
[Create task] (タスクの作成) を選択します。
「タスクの作成」ページの「タスク設定」セクションで、次の操作を行います。
- 一意で意味のあるタスク識別子 (mongodb-docdb-replication」など) を入力します。
- ソースデータベースエンドポイントドロップダウンメニューで、以前に作成したソースエンドポイントを選択します。
- ターゲットデータベースエンドポイントドロップダウンメニューで、以前に作成したターゲットエンドポイントを選択します。
- タスクタイプで、移行とレプリケートを選択します。
設定セクションで、次の操作を行います。
- ターゲットテーブル準備モードでは、デフォルト設定のままにします。
- 全ロードの完了後にタスクを停止するには、デフォルト設定のままにします。
- LOB 列の設定では、制限付き LOB モードの設定をそのままにします。
- データ検証の場合は、デフォルト設定の「オフ」のままにします。
- タスクログの場合は、CloudWatch ログをオンにするチェックボックスをオンにします。
- バッチ最適化適用の場合、デフォルト設定のはオフ (オフ) のままにします。
タスク設定セクションの上部に戻り、編集モードで JSON エディタを選択し、次の属性を設定します。
```
{
  "TargetMetadata": {
    "ParallelApplyThreads": 5
  },
  "FullLoadSettings": {
    "MaxFullLoadSubTasks": 16
  }
}
```
テーブルマッピングセクションで、新しい選択ルールを追加します。
- スキーマ名には、移行するソースデータベースを追加します。% を使用して複数のデータベースを指定します。
- スキーマテーブル名には、移行するソースコレクションを追加します。% を使用して複数のコレクションを指定します。
- アクションの場合、デフォルト設定の「含める」のままにします。
大規模なコレクション (100GB 以上) の場合は、テーブル設定ルールを追加します。
- スキーマ名には、移行するソースデータベースを追加します。% を使用して複数のデータベースを指定します。
- スキーマテーブル名には、移行するソースコレクションを追加します。% を使用して複数のコレクションを指定します。
- パーティションの数には、16 と入力します ( より小さくする必要がありますMaxFullLoadSubTask）。
移行前評価セクションで、オフになっていることを確認します。

オフライン移行

このセクションでは、 mongodumpおよびのネイティブ MongoDB ツールを使用して、セルフマネージド MongoDB インスタンスから Amazon DocumentDB へのオフライン移行を実行するプロセスの概要を説明しますmongorestore。

前提条件

ソース MongoDB の要件

適切なアクセス許可を持つソース MongoDB インスタンスへのアクセス。
必要に応じてをインストールmongodumpします (MongoDB のインストール中にインストールされます）。
ダンプファイルに十分なディスク容量があることを確認します。

Amazon DocumentDB のターゲット要件

Amazon DocumentDB クラスターがプロビジョニングされていることを確認します。
移行を容易にするために、Amazon DocumentDB と同じ VPC に EC2 インスタンスがあることを確認します。
ネットワーク接続は、ソース環境と Amazon DocumentDB の間で利用できる必要があります。
mongorestore は移行 EC2 インスタンスにインストールする必要があります。
Amazon DocumentDB にアクセスするには、適切な IAM アクセス許可を設定する必要があります。

一般的な要件

AWS CLI を設定する必要があります (中間ストレージに AWS サービスを使用している場合）
データ転送には十分な帯域幅が必要です。
ダウンタイムウィンドウは承認する必要があります (ライブ移行を行う場合は、他のアプローチを検討してください）

Amazon DocumentDB クラスターを準備する

で Amazon DocumentDB クラスターを作成します AWS。

ワークロードに基づいて適切なインスタンスサイズ。
VPC、サブネット、セキュリティグループを設定します。
パラメータグループを介して必要なパラメータを有効にします。

データダンプを実行する (mongodump)

ダンプファイルを作成するには、次のいずれかのオプションを選択します。

オプション 1: 基本


mongodump --
uri="mongodb://<source_user>:<source_password>@<source_host>:<source_port>/<database>" --
out=/path/to/dump

オプション 2: 制御とパフォーマンスの向上


mongodump \
--uri="mongodb://<source_user>:<source_password>@<sourcehost>:<source_port>" \
--out=/path/to/dump \
--gzip \# Compress output
--numParallelCollections=4 \# Parallel collections dump
--ssl \# If using SSL
--authenticationDatabase=admin \ # If auth is required
--readPreference=secondaryPreferred # If replica set

オプション 3: 大規模なデータベース


mongodump \
--host=<source_host> \
--port=<source_port> \
--username=<source_user> \
--password=<source_password> \
--db=<specific_db> \# Only dump specific DB
--collection=<specific_collection> \ # Only dump specific collection
--query='{ "date": { "$gt": "2020-01-01" } }' \ # Filter documents
--archive=/path/to/archive.gz \# Single archive output
--gzip \
--ssl

ダンプファイルを復元環境に転送する

ダンプサイズに基づいて適切な方法を選択します。

小規模 — 移行マシン (前に作成した EC2 インスタンス) に直接コピーします。
```
scp -r /path/to/dump user@migration-machine:/path/to/restore
```
Medium — Amazon S3 を中間ストレージとして使用します。
```
aws s3 cp --recursive /path/to/dump s3://your-bucket/mongodb-dump/
```
Large — 非常に大規模なデータベースの場合は、 AWS DataSync または物理的な転送を検討してください。

Amazon DocumentDB (mongorestore) へのデータの復元

復元プロセスを開始する前に、Amazon DocumentDB でインデックスを作成します。Amazon DocumentDB インデックスツールを使用して、インデックスをエクスポートおよびインポートできます。

データを復元するには、次のいずれかのオプションを選択します。

オプション 1: 基本的な復元


mongorestore --uri="mongodb://<docdb_user>:<docdb_password>@<docdb_endpoint>:27017"
/path/to/dump

オプション 2: 制御とパフォーマンスの向上


mongorestore \
--uri="mongodb://<docdb_user>:<docdb_password>@<docdb_endpoint>:27017" \
--ssl \
--sslCAFile=/path/to/rds-combined-ca-bundle.pem \ # DocumentDB CA cert
--gzip \# If dumped with gzip
--numParallelCollections=4 \# Parallel restoration
--numInsertionWorkersPerCollection=4 \# Parallel documents insertion
--noIndexRestore \# skip indexes as they are pre-created
/path/to/dump

オプション 3: 大規模なデータベースまたは特定のコントロール


mongorestore \
--host=<docdb_endpoint> \
--port=27017 \
--username=<docdb_user> \
--password=<docdb_password> \
--ssl \
--sslCAFile=/path/to/rds-combined-ca-bundle.pem \
--archive=/path/to/archive.gz \# If using archive format
--gzip \
--nsInclude="db1.*" \# Only restore specific namespaces
--nsExclude="db1.sensitive_data" \ # Exclude specific collections if needed
--noIndexRestore \# skip indexes as they are pre-created
--writeConcern="{w: 'majority'}" # Ensure write durability

モニタリング

このセクションでは、以下からの継続的な移行の進行状況、パフォーマンス、状態を追跡するための詳細なモニタリングプロセスについて説明します。

MongoDB から Amazon DocumentDB へ

Amazon DocumentDB から Amazon DocumentDB へ

モニタリングステップは、移行方法 (AWS DMS、mongodump/mongorestore、またはその他のツール) に関係なく適用されます。

AWS DMS 移行モニタリング (該当する場合）

次の主要な CloudWatch メトリクスをモニタリングします。

全ロードフェーズのメトリクス

FullLoadThroughputBandwidthTarget — 全ロード中のネットワーク帯域幅 (KB/秒）
FullLoadThroughputRowsTarget — 1 秒あたりにロードされた行/ドキュメントの数
FullLoadThroughputTablesTarget — 1 分あたりに完了したテーブル/コレクションの数
FullLoadProgressPercent — 全ロード完了の割合
TablesLoaded — 正常にロードされたテーブル/コレクションの数
TablesLoading — 現在ロードされているテーブル/コレクションの数
TablesQueued — ロードを待機しているテーブル/コレクションの数
TablesErrored — ロードに失敗したテーブル/コレクションの数

CDC フェーズメトリクス

CDCLatencyTarget — ソース変更とターゲットアプリケーション間の遅延時間 (秒）
CDCLatencySource — ソースの変更とそれを読み取る DMS の間の遅延時間 (秒）
CDCThroughputRowsTarget — 継続的なレプリケーション中に適用される 1 秒あたりの行数
CDCThroughputBandwidthTarget — CDC 中のネットワーク帯域幅 (KB/秒）
CDCIncomingChanges — ソースから受信した変更イベントの数
CDCChangesMemoryTarget — 変更をターゲット側に保存するために使用するメモリ (MB)

リソースメトリクス

CPUUtilization — レプリケーションインスタンスの CPU 使用率
FreeableMemory — レプリケーションインスタンスで使用可能なメモリ
FreeStorageSpace — レプリケーションインスタンスで使用可能なストレージ
NetworkTransmitThroughput — レプリケーションインスタンスのネットワークスループット
NetworkReceiveThroughput — レプリケーションインスタンスのネットワークスループット

エラーメトリクス

ErrorsCount — 移行中のエラーの合計数
TableErrorsCount — テーブル固有のエラーの数
RecordsErrorsCount — レコード固有のエラーの数

移行パフォーマンスが低下した場合に通知を受け取るCPUUtilizationには、 CDCLatencyTargetやなどの重要なメトリクスの CloudWatch アラームを作成します。

DMS ログ (CloudWatch ログ）

Amazon CloudWatch Logs コンソールに移動します。
ロググループでを検索して選択します。「dms-tasks –」のようになります。
エラー情報を含む可能性のあるログストリームを探します。
- 名前に「エラー」があるストリーム
- タスク IDs またはエンドポイント名を持つストリーム
- 移行中の最新のログストリーム
これらのストリーム内で、次のようなキーワードを検索します。
- 「エラー」
- 「例外」
- 「失敗」
- 「警告」

DMS タスクのステータス (使用 AWS CLI）


aws dms describe-replication-tasks --filters Name=replication-task id,Values=<task_id> --query
"ReplicationTasks[0].Status"

予想されるステータスフロー：

作成中 → 準備完了 → 実行中 → 停止中 → 停止 (または失敗）

を使用したモニタリング `docdb-dashboarder`

このdocdb-dashboarderツールは、重要なパフォーマンスメトリクスを含む CloudWatch ダッシュボードを自動的に生成することで、Amazon DocumentDB クラスターの包括的なモニタリングを提供します。これらのダッシュボードには、重要なクラスターレベルのメトリクス (レプリカラグ、オペレーションカウンター）、インスタンスレベルのメトリクス (CPU、メモリ、接続）、ストレージメトリクス (ボリューム使用量、バックアップストレージ) が表示されます。移行シナリオの場合、このツールは、CDC レプリケーションの遅延やオペレーションレートなどのメトリクスを使用して移行の進行状況を追跡する特殊なダッシュボードを提供します。ダッシュボードでは、複数のクラスターを同時にモニタリングし、NVMe-backed インスタンスのサポートを含めることができます。これらのメトリクスを視覚化することで、チームはパフォーマンスのボトルネックをプロアクティブに特定し、リソース割り当てを最適化し、Amazon DocumentDB デプロイのスムーズな運用を確保できます。このツールを使用すると、ダッシュボードを手動で作成する必要がなくなり、すべての環境で一貫したモニタリングが可能になります。セットアップ手順と高度な設定オプションについては、Amazon DocumentDB Dashboarder Tool GitHub リポジトリを参照してください。

検証

トピック

検証チェックリスト
スキーマとインデックスの検証
データサンプリングとフィールドレベルの検証
DataDiffer ツールを使用した検証

このセクションでは、以下から移行した後のデータ整合性、整合性、アプリケーションの互換性を確保するための詳細な検証プロセスについて説明します。

MongoDB から Amazon DocumentDB へ

Amazon DocumentDB から Amazon DocumentDB へ

検証ステップは、移行方法 (AWS DMS、mongodump/mongorestore、またはその他のツール) に関係なく適用されます。

検証チェックリスト

各コレクションのドキュメント数がソースとターゲットの間で一致することを確認します。

MongoDB ソース


mongo --host <source_host> --port <port> --username <user> -- password <password> --eval
"db.<collection>.count()"

Amazon DocumentDB ターゲット


mongo --host <target_host> --port <port> --username <user> -- password <password> --eval
"db.<collection>.count()"

スキーマとインデックスの検証

以下を確認してください。

すべてのコレクションがターゲットに存在します。
インデックスは正しくレプリケートされます。
スキーマ定義 (適用されている場合) は同じです。

コレクションを確認する (ソースとターゲット）


mongo --host <source_host> --eval "show collections"
mongo --host <target_host> --ssl --eval "show collections"

チェックインデックス (ソースとターゲット）


mongo --host <source_host> --eval" db.<collection>.getIndexes()"
mongo --host <target_host> --ssl –eval" db.<collection>.getIndexes()"

コレクションのリストを比較して、欠落しているコレクションや追加のコレクションがないことを確認します。

インデックス名、キー定義、一意の制約、TTL インデックス (存在する場合) を確認して、インデックスを検証します。

スキーマ検証ルールを確認する (MongoDB でスキーマ検証を使用する場合）


mongo --host <source_host> --eval" db.getCollectionInfos({name: '<collection>'})
[0].options.validator"
   mongo --host <target_host> --ssl –eval" db.getCollectionInfos({name: '<collection>'})[0].options.validator"

データサンプリングとフィールドレベルの検証

ドキュメントをランダムにサンプリングし、ソースとターゲットのフィールドを比較できます。

手動サンプリング

5 つのランダムドキュメント (ソース) を取得します。


mongo --host <source_host> --eval "db.<collection>.aggregate([{ \$sample: { size: 5 } }])"

同じドキュメント IDs (ターゲット) を取得します。


mongo --host <target_host> --ssl –eval "db.<collection>.find({ _id: { \$in: [<list_of_ids>] } })"

自動サンプリング


import pymongo
# Connect to source and target
source_client = pymongo.MongoClient("<source_uri>")
target_client = pymongo.MongoClient("<target_uri>", ssl=True)
source_db = source_client["<db_name>"]
target_db = target_client["<db_name>"]
# Compare 100 random documents
for doc in source_db.<collection>.aggregate([{ "$sample":
{ "size": 100 } }]):
target_doc = target_db.<collection>.find_one({ "_id":
doc["_id"] })
if target_doc != doc:
print(f"❌ Mismatch in _id: {doc['_id']}")
else:
print(f"✅ Match: {doc['_id']}")

DataDiffer ツールを使用した検証

DataDiffer ツールは、ソースデータベースとターゲットデータベース間でデータを比較する信頼性の高い方法を提供します。

前提条件

DataDiffer ツールをインストールする前に、次の前提条件を満たす必要があります。

Python 3.7 以上
PyMongo ライブラリ
ソース MongoDB クラスターとターゲット Amazon DocumentDB クラスターの両方へのネットワーク接続

セットアップとインストール

リポジトリのクローンを作成し、DataDiffer ディレクトリに移動します。


git clone https://github.com/awslabs/amazon-documentdb-tools.git
cd amazon-documentdb-tools/migration/data-differ

必要な依存関係をインストールする


pip install -r requirements.txt

データ検証の実行

接続の詳細を含む設定ファイル (config.json など) を作成する


{
"source": {
"uri": "mongodb://username:password@source-mongodb-
host:27017/?replicaSet=rs0",
"db": "your_database",
"collection": "your_collection"
},
"target": {
"uri": "mongodb://username:password@target-docdb-
cluster.region.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=global-
bundle.pem&replicaSet=rs0",
"db": "your_database",
"collection": "your_collection"
},
"options": {
"batch_size": 1000,
"threads": 4,
"sample_size": 0,
"verbose": true
}
}

DataDiffer ツールを実行する


python differ.py --config config.json

大規模なコレクションの場合、サンプリングを使用してデータのサブセットを検証する


python differ.py --config config.json --sample-size 10000

複数のコレクションを検証するには、個別の設定ファイルを作成するか、バッチモードを使用します。


python differ.py --batch-config batch_config.json

結果の解釈

ツールは以下を出力します。

ソースとターゲットの合計ドキュメント数
一致するドキュメントの数
欠落しているドキュメントの数
違いがあるドキュメントの数
差異の詳細レポート (存在する場合）

ベストプラクティス

DataDiffer ツールを使用する際のベストプラクティスは次のとおりです。

段階的に実行する — まずドキュメント数を検証し、次にキードキュメントのサンプルを作成し、最後に必要に応じて完全な比較を実行します。
スキーマの違いを確認する — Amazon DocumentDB には、MongoDB と比較していくつかの制限があります。ツールでは、互換性のないデータ型または構造が強調表示されます。
クワイエットピリオド中の検証 — 書き込みオペレーションが最小限であるときに検証を実行して整合性を確保します。
リソース使用状況のモニタリング — 比較プロセスはリソースを大量に消費する可能性があります。それに応じてバッチサイズとスレッド数を調整します。
インデックスの検証 — データの検証後、ターゲット Amazon DocumentDB クラスターで必要なインデックスがすべて作成されていることを確認します。
ドキュメントの検証結果 — 移行ドキュメントの一部として、各コレクションの検証結果を記録します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

「クイックスタートガイド」

DocumentDB のアップグレード

Amazon DocumentDB 移行ランブック

互換性

トピック

コア機能の互換性

包括的な機能サポート

拡張 AWS統合機能

最新のアーキテクチャの利点

Amazon DocumentDB 互換性評価ツール

評価方法

ワークロードの検出

トピック

既存の MongoDB デプロイの評価

データモデルの違いを特定する

クエリとパフォーマンスの分析

セキュリティとアクセスコントロールのレビュー

運用とモニタリングに関する考慮事項

インデックスの移行

Amazon DocumentDB インデックスツールの使用

ユーザー移行

Amazon DocumentDB ユーザーエクスポートツールの使用

データ移行

トピック

オンライン移行

ターゲットを設定する (Amazon DocumentDB)

注記

注記

ヒント

ソースを設定する

DMS レプリケーションインスタンスを作成する

DMS エンドポイントを作成する

ソースエンドポイントを作成する

ターゲットエンドポイントを作成する (Amazon DocumentDB)

レプリケーションタスクを作成する

オフライン移行

前提条件

Amazon DocumentDB クラスターを準備する

データダンプを実行する (mongodump)

ダンプファイルを復元環境に転送する

Amazon DocumentDB (mongorestore) へのデータの復元

モニタリング

AWS DMS 移行モニタリング (該当する場合）

DMS ログ (CloudWatch ログ）

DMS タスクのステータス (使用 AWS CLI）

を使用したモニタリング docdb-dashboarder

検証

トピック

検証チェックリスト

スキーマとインデックスの検証

データサンプリングとフィールドレベルの検証

DataDiffer ツールを使用した検証

前提条件

セットアップとインストール

データ検証の実行

結果の解釈

ベストプラクティス

を使用したモニタリング `docdb-dashboarder`