翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon DocumentDB 移行ランブック
このランブックは、 AWS Database Migration Service (DMS) を使用して MongoDB データベースを Amazon DocumentDB に移行するための包括的なガイドを提供します。これは、最初の検出から移行後の検証まで、エンドツーエンドの移行ジャーニーを通じてデータベース管理者、クラウドエンジニア、開発者をサポートするように設計されています。
MongoDB と Amazon DocumentDB の間の実装とサポートされている機能の違いを考慮すると、このランブックは構造化された体系的なアプローチを強調しています。重要な移行前評価を概説し、互換性に関する考慮事項を強調し、最小限の中断で移行を成功させるために必要な主要なタスクについて詳しく説明します。
ランブックは、以下のトピックで構成されています。
+ **[互換性](#mig-runbook-compatibility)** — Amazon DocumentDB でサポートされている MongoDB 機能とデータ型を理解し、潜在的な非互換性を特定します。
+ **[ワークロードの検出](#mig-runbook-workload)** — 読み取り/書き込みパターン、データボリューム、パフォーマンスベースラインなど、既存の MongoDB ワークロードを分析します。
+ **[インデックスの移行](#mig-runbook-index)** — Amazon DocumentDB で最適なパフォーマンスを得るために MongoDB インデックスを抽出および変換するための戦略を分析します。
+ **[ユーザー移行](#mig-runbook-user)** — データベースユーザー、ロール、アクセスコントロールを Amazon DocumentDB に移行するためのアプローチについて詳しく説明します。
+ **[データ移行](#mig-runbook-data)** — 全ロードおよび変更データキャプチャ (CDC) など AWS DMS、 を使用したデータ移行のさまざまな方法について説明します。
+ **[モニタリング](#mig-runbook-monitoring)** — DMS またはネイティブツールを使用して移行する際のさまざまなモニタリングアプローチについて詳しく説明します。
+ **[検証](#mig-runbook-validation)** — 移行後のデータ整合性チェック、機能検証、パフォーマンス比較の手順を提供します。
このランブックのガイダンスに従うことで、チームはアプリケーションの機能を維持し、リスクを最小限に抑えながら、Amazon DocumentDB へのスムーズで安全かつ効率的な移行を確保できます。
## 互換性
**Topics**
+ [コア機能の互換性](#w2aac23b9c13c13)
+ [Amazon DocumentDB 互換性評価ツール](#w2aac23b9c13c15)
MongoDB から Amazon DocumentDB に移行する場合、移行を成功させるには、徹底的な初期評価と機能の互換性チェックが不可欠です。このプロセスは、集約パイプライン演算子、クエリパターン、インデックス、データモデルなど、MongoDB 機能の包括的なインベントリから始まります。
Amazon DocumentDB は MongoDB 3.6、4.0、5.0、8.0 API と互換性があるため、新しい MongoDB 固有の機能を使用するアプリケーションではリファクタリングが必要になる場合があります。評価する重要な領域には、シャーディングメカニズム (Amazon DocumentDB は異なるアプローチを使用）、トランザクション実装、変更ストリームの機能、インデックスタイプ (特にスパースインデックスと部分インデックス) などがあります。
パフォーマンス特性も異なり、Amazon DocumentDB は予測可能なパフォーマンスを持つエンタープライズワークロード向けに最適化されています。テストでは、両方のシステムに対して代表的なワークロードを実行して、最適化が必要なクエリパターンを特定する必要があります。
評価フェーズでは、潜在的なパフォーマンスギャップを検出するための実行計画のモニタリングが重要です。これにより、明確な移行ロードマップを作成し、必要なアプリケーションの変更を特定し、スムーズな移行のための現実的なタイムラインを確立できます。
### コア機能の互換性
#### 包括的な機能サポート
+ **CRUD オペレーション** — 一括演算子やクエリ演算子など、すべての基本的な作成、読み取り、更新、および削除オペレーションを完全にサポートし、シームレスなアプリケーションの互換性を実現します。
+ **豊富なインデックス作成機能** — 単一フィールド、複合、TTL、部分、スパース、および 2dsphere インデックスの包括的なサポートを活用して、テキストベースのルックアップのクエリパフォーマンスとテキストインデックス (バージョン 5) を最適化します。
+ **エンタープライズグレードのレプリケーション** — リードレプリカを備えた堅牢な自動フェイルオーバーメカニズムにより、運用上のオーバーヘッドなしで優れた高可用性を実現できます。
+ **高度なバックアップソリューション** — データ保護のためのポイントインタイムリカバリ (PITR) とオンデマンドの手動スナップショットを備えた自動バックアップシステムにより、安心して使用できます。
#### 拡張 AWS統合機能
+ **効率的な集約** — エンタープライズワークロードのパフォーマンスが最適化された、最も一般的に使用される集約ステージ (`$match`、`$group`、`$sort`、`$project` など) を活用します。
+ **トランザクションのサポート** — マルチドキュメントトランザクションとマルチコレクショントランザクションを実装し、ほとんどのビジネスアプリケーションのニーズに最適です。
+ **リアルタイムデータ追跡** — シンプルなコマンドで変更ストリームを有効にし、リアルタイムのデータ変更モニタリングのためのシンプルなパラメータグループ設定で変更ストリームの保持期間を延長します。
+ **位置情報ベースのサービス** — `$geoNear` 演算子および 2dsphere インデックスをサポートする地理空間アプリケーションを実装します。
+ **テキスト検索機能** — コンテンツ検出のニーズに応じて、組み込みのテキスト検索機能を利用します。
#### 最新のアーキテクチャの利点
+ **クラウドネイティブ設計** — MapReduce AWSなどのレガシー機能を、より効率的な集約パイプラインオペレーションに置き換える、エンゲージ最適化アーキテクチャ。
+ **セキュリティの強化** — AWS Identity and Access Management (IAM)、SCRAM-SHA-1, SCRAM-SHA-256、X.509 証明書認証、パスワードベースの認証の利点があります。
+ **予測可能なパフォーマンス** — 特にエンタープライズワークロード向けに最適化された一貫したパフォーマンスを体験できます。
Amazon DocumentDB の機能の包括的な概要については、「[Amazon DocumentDB でサポートされている MongoDB API、オペレーション、およびデータ型](mongo-apis.md)」および「[機能の違い: Amazon DocumentDB と MongoDB](functional-differences.md)」を参照して、データベースの可能性を最大化してください。
Amazon DocumentDB は、MongoDB が提供するすべてのインデックスをサポートしているわけではありません。互換性を確認するための無料の [インデックスツール](https://github.com/awslabs/amazon-documentdb-tools/blob/master/index-tool/README.md) が用意されています。インデックスツールを使用して非互換性を評価し、それに応じて回避策を計画することをお勧めします。
### Amazon DocumentDB 互換性評価ツール
[MongoDB から Amazon DocumentDB への互換性ツール](https://github.com/awslabs/amazon-documentdb-tools/blob/master/compat-tool/README.md) は、GitHub で利用可能なオープンソースユーティリティです。MongoDB ログまたはアプリケーションのソースコードを分析することで Amazon DocumentDB との MongoDB ワークロードの互換性を評価するのに役立ちます。
**主な特徴**
+ ワークロードの MongoDB API 使用パターンを識別します
+ 移行前に潜在的な互換性の問題にフラグを付けます
+ レコメンデーションを含む詳細な互換性レポートを生成します
+ ローカルで実行できるスタンドアロンユーティリティとして利用可能
#### 評価方法
**ログベースの評価**
+ メリット:
+ 実際のランタイム動作とクエリパターンをキャプチャします
+ 実際の使用頻度とパフォーマンス特性を特定します
+ ソースコードに表示されない可能性のある動的クエリを検出します
+ アプリケーションのソースコードへのアクセスは不要です
+ デメリット:
+ プロファイリングを有効にして MongoDB ログにアクセスする必要があります
+ ログ記録期間中に発生したオペレーションしかキャプチャしません
+ 使用頻度の低い機能や季節的なワークロードを見逃す可能性があります
ソースコード分析
+ メリット:
+ コードベースで考えられるすべての MongoDB オペレーションの包括的なカバレッジ
+ ほとんど実行されないコードパスの問題を特定できます
+ Amazon DocumentDB の違いの影響を受ける可能性のあるクライアント側のロジックを検出します
+ 評価を実行するためにアプリケーションを実行する必要がありません
+ デメリット:
+ 存在するけれども本番環境では決して実行されないコードにフラグを付ける可能性があります
+ 完全なアプリケーションソースコードにアクセスする必要があります
+ 動的に構築されたクエリを分析する機能が限られています
最良の結果を得るには、移行前に互換性の課題の全体像を把握するために、可能であれば両方の評価方法を使用することをお勧めします。
## ワークロードの検出
MongoDB から Amazon DocumentDB に移行するには、既存のデータベースワークロードを完全に理解する必要があります。ワークロード検出は、データベースの使用パターン、データ構造、クエリパフォーマンス、運用上の依存関係を分析し、中断を最小限に抑えながらシームレスな移行を確保するプロセスです。このセクションでは、MongoDB から Amazon DocumentDB への効果的な移行を容易にするためのワークロード検出に関連する主要なステップを概説します。
**Topics**
+ [既存の MongoDB デプロイの評価](#w2aac23b9c15b7)
+ [データモデルの違いを特定する](#w2aac23b9c15b9)
+ [クエリとパフォーマンスの分析](#w2aac23b9c15c11)
+ [セキュリティとアクセスコントロールの確認](#w2aac23b9c15c13)
+ [運用とモニタリングに関する考慮事項](#w2aac23b9c15c15)
### 既存の MongoDB デプロイの評価
移行前に、以下を含む現在の MongoDB 環境を評価することが重要です。
+ **クラスターアーキテクチャ** — ノード、レプリカセット、およびシャーディング設定の数を特定します。MongoDB から Amazon DocumentDB に移行する場合、Amazon DocumentDB はユーザー制御のシャーディングをサポートしていないため、MongoDB シャーディング設定を理解することが重要です。シャーディングされた MongoDB 環境用に設計されたアプリケーションでは、Amazon DocumentDB がストレージベースのアーキテクチャで異なるスケーリングアプローチを使用するため、アーキテクチャの変更が必要になります。Amazon DocumentDB に移行するときは、データ分散戦略を適応させ、場合によってはシャードコレクションを統合する必要があります。
+ **ストレージとデータボリューム** — クラスターの合計データサイズとインデックスサイズを測定します。これを [Oplog レビューツール](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/mongodb-oplog-review) で補完し、書き込みパターンとデータの増加速度を理解します。クラスターのサイジングの詳細については、「[インスタンスのサイズ指定](best_practices.md#best_practices-instance_sizing)」を参照してください。
+ **ワークロードパターン** — 読み取りおよび書き込みスループット、クエリ実行頻度、インデックス作成効率を分析します。
+ **運用上の依存関係** — MongoDB に依存するすべてのアプリケーション、サービス、統合を文書化します。
### データモデルの違いを特定する
Amazon DocumentDB は MongoDB と互換性がありますが、サポートされている機能には次のような違いがあります。
+ **トランザクション** — Amazon DocumentDB は ACID トランザクションをサポートしますが、一部の [制限](transactions.md#transactions-limitations) があります。
+ **スキーマ設計** — ドキュメント構造、埋め込みドキュメント、およびリファレンスが [Amazon DocumentDB のベストプラクティス](https://d1.awsstatic.com/product-marketing/Data%20modeling%20with%20Amazon%20DocumentDB.pdf) と一致していることを確認します。
### クエリとパフォーマンスの分析
クエリの動作を理解することで、移行と移行後のパフォーマンスを最適化できます。分析すべき主な領域は次のとおりです。
+ **スロークエリ** — 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 のパスワードポリシーに対応するように接続文字列と認証情報管理を更新します。Secrets Manager を使用して、認証情報を保存し、パスワードを更新できます。
+ **サービスアカウント管理** — でサービスアカウントの認証情報を管理するプロセスを確立します AWS Secrets Manager。
+ **最小特権の実装** — アクセスコントロールを確認して絞り込み、新しい環境に最小特権の原則を実装します。
**暗号化**
保管中および転送中の暗号化がコンプライアンス要件と一致していることを確認します。
**ネットワーク構成**
[仮想プライベートクラウド (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) のセットアップとセキュリティグループルールを計画します。
### 運用とモニタリングに関する考慮事項
システムの信頼性を維持するために、ワークロード検出には以下も含める必要があります。
+ **バックアップと復元戦略** — 既存のバックアップ方法と Amazon DocumentDB のバックアップ機能を評価します。
+ **AWS Backup 統合** — を活用して AWS Backup 、Amazon DocumentDB を含む AWS のサービス全体で一元化されたバックアップ管理を行います。
+ **CloudWatch メトリクス** — MongoDB モニタリングメトリクスを、CPU、メモリ、接続、ストレージの Amazon DocumentDB CloudWatch メトリクスにマッピングします。
+ **Performance Insights** — Amazon DocumentDB Performance Insights を実装して、データベースの負荷を視覚化し、詳細なクエリ分析でパフォーマンスの問題を分析します。
+ **プロファイラー** — 実行速度の遅いオペレーションをキャプチャするように Amazon DocumentDB プロファイラーを設定します (MongoDB のプロファイラーに似ていますが、Amazon DocumentDB 固有の設定があります）。
+ 適切なしきい値を持つパラメータグループを使用して有効にします。
+ プロファイラーデータを分析して最適化の機会を特定する
+ **CloudWatch Events** — Amazon DocumentDB クラスターイベントのイベント駆動型モニタリングをセットアップします。
+ バックアップイベント、メンテナンスウィンドウ、およびフェイルオーバーの通知を設定します。
+ アラートおよび自動応答のために Amazon SNS と統合 AWS Lambda します。
+ **監査ログ記録** — ユーザーアクティビティとセキュリティ関連のイベントを追跡するための監査ログ記録設定を計画します。
+ **拡張モニタリング** — 1 秒間隔できめ細かな OS レベルのメトリクスの拡張モニタリングを有効にします。
## インデックスの移行
MongoDB から Amazon DocumentDB に移行するには、データだけでなくインデックスも転送して、クエリパフォーマンスを維持し、データベースオペレーションを最適化する必要があります。このセクションでは、互換性と効率を確保しながら、MongoDB から Amazon DocumentDB にインデックスを移行するための詳細なステップ倍ステップのプロセスを概説します。
### Amazon DocumentDB インデックスツールの使用
**[インデックスツール](https://github.com/awslabs/amazon-documentdb-tools/blob/master/index-tool/README.md) のクローンを作成する**
```
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 ユーザーを、 Amazon DocumentDB エクスポートユーザーツールを使用して、彼らのロールとアクセス許可を保持しながら正常に移行する詳細な手順を概説します。
### Amazon DocumentDB ユーザーエクスポートツールの使用
[https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/export-users](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/export-users) は、ユーザーとロールを MongoDB または Amazon DocumentDB から JavaScript ファイルにエクスポートし、それを別のクラスターで再作成するために使用できます。
**前提条件**
```
# 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 に移行するための安全で柔軟なアプローチを提供し、移行プロセス中にパスワードをリセットできるようにします。
## データ移行
**Topics**
+ [オンライン移行](#w2aac23b9c21b5)
+ [オフライン移行](#w2aac23b9c21b7)
+ [前提条件](#w2aac23b9c21c11)
+ [Amazon DocumentDB クラスターを準備する](#w2aac23b9c21c13)
+ [データダンプを実行する (mongodump)](#w2aac23b9c21c15)
+ [ダンプファイルを復元環境に転送する](#w2aac23b9c21c17)
+ [Amazon DocumentDB (mongorestore) にデータを復元する](#w2aac23b9c21c19)
### オンライン移行
このセクションでは、最小限のダウンタイムと継続的なレプリケーションを可能にする AWS DMS ために、 を使用して MongoDB から Amazon DocumentDB へのオンライン移行を実行する詳細な手順について説明します。まず、Amazon DocumentDB クラスターをターゲットとしてセットアップし、MongoDB インスタンスがソースとして適切に設定されていることを確認します。通常、変更データキャプチャにはレプリカセットモードが必要です。次に、DMS レプリケーションインスタンスを作成し、必要な接続の詳細を使用してソースエンドポイントとターゲットエンドポイントを定義します。エンドポイントを検証したら、フルデータロード、継続的なレプリケーション、またはその両方を含む移行タスクを設定して開始します。
#### ターゲットを設定する (Amazon DocumentDB)
**注記**
移行する Amazon DocumentDB クラスターを既にプロビジョニングしている場合は、このステップをスキップできます。
**カスタムパラメータグループを作成する**
「」の AWS マネジメントコンソール 「」または AWS CLI 「」の手順を参照してください [Amazon DocumentDB クラスターパラメータグループを作成する](cluster_parameter_groups-create.md)。
**Amazon DocumentDB クラスターを作成する**
**注記**
このガイドには Amazon DocumentDB クラスターを作成する他の手順がありますが、このセクションの手順は、特に大量のデータを新しいクラスターに移行するタスクに適用されます。
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) で Amazon DocumentDB コンソールを開きます。
1. ナビゲーションペインで **クラスター** を選択します。
**ヒント**
画面の左側にナビゲーションペインが表示されない場合は、ページの左上隅にあるメニューアイコン (![\[Hamburger menu icon with three horizontal lines.\]](http://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/images/docdb-menu-icon.png)) を選択します。
1. Amazon DocumentDB マネジメントコンソールで、[**クラスター**] の下にある [**作成**] を選択します。
1. 「**Amazon DocumentDB クラスターの作成**」ページの [**クラスタータイプ**] セクションで、[**インスタンスベースのクラスター**] を選択します (これはデフォルトのオプションです)。
1. [クラスター設定] セクションで次を行います。
+ **[クラスター識別子]** には、**mydocdbcluster** などの一意の名称を入力します。コンソール操作では、入力方法に関係なくクラスター名のすべての文字が小文字に変換されることにご留意ください。
+ **[エンジンバージョン]** で、[5.0.0] を選択します。
1. **[クラスターストレージ設定]** セクションでは、**[Amazon DocumentDB 標準]** 設定をそのままにします (デフォルトのオプションです)。
1. **インスタンス設定** セクション:
+ **[DB インスタンスクラス]** では、**メモリ最適化クラス (r クラスを含む) ** を選択します (デフォルト）。
+ **[インスタンスクラス]** では、ワークロードに基づいてインスタンスクラスを選択します。例えば、次のようになります。
+ db.r6g.large: 小規模なワークロード向け
+ db.r6g.4xlarge: 大規模なワークロード向け
ベストプラクティスとして、最適なフルロードスループットを得るには、インスタンスを可能な限り大きく選択し、移行が完了したらスケールダウンすることをお勧めします。
+ **[インスタンスの数]** は、[1] を選択します。1 つのインスタンスを選択すると、コストを最小限に抑えることができます。フルロード移行が完了したら、高可用性のために 3 つのインスタンスにスケールすることをお勧めします。
1. **[認証]** セクションで、プライマリユーザーのユーザー名を入力し、**[セルフマネージド]** を選択します。パスワードを入力して確認します。
1. **[ネットワーク設定]** セクションで、VPC とサブネットグループを選択し、VPC セキュリティグループを設定します。インバウンドルールを更新して、Amazon DocumentDB セキュリティグループが DMS インスタンスのセキュリティグループからのインバウンド接続を許可していることを確認します。
1. **[Encryption-at-rest]** セクションで、暗号化を有効にし (推奨)、KMS キーを選択または入力します。
1. **[バックアップ]** セクションで、バックアップ保持期間を [1～35 日] に設定します。
1. 設定を確認し、[**クラスターの作成**] を選択します。
デプロイには通常 10～15 分かかります。
#### ソースを設定する
MongoDB と Amazon DocumentDB は、シナリオに応じて、どちらも移行ソースとして機能します。
+ **ソースとしての MongoDB ** — オンプレミスまたはセルフマネージド MongoDB から Amazon DocumentDB または他の AWS データベースサービスに移行する場合に一般的です。移行中の変更データキャプチャをサポートするために、適切なサイズの oplog を使用してレプリカセットモードで実行する必要があります (フルロード中にすべてのオペレーションを保持するサイズになっていることを確認してください）。
+ **ソースとしての Amazon DocumentDB** — 通常、クロスリージョンレプリケーション、バージョンアップグレード、または MongoDB Atlas などの他のデータベースサービスへの移行に使用されます。クラスターパラメータグループの `change_stream_log_retention_duration` パラメータを設定して、移行中に進行中の変更をキャプチャするために [変更ストリームの有効化](change_streams.md#change_streams-enabling) が必要です。`change_stream_log_retention_duration` 設定がフルロードの完了に必要な時間をカバーするのに十分な大きさであることを確認します。
移行を開始する前に、 AWS DMS アクセスを許可するようにソースを設定します。
適切なアクセス許可を持つ MongoDB ユーザーを作成します。
```
db.createUser({
user: "dmsUser",
pwd: "yourSecurePassword",
roles: [{ role: "readAnyDatabase", db: "admin" }]
})
```
ネットワークと認証を設定します。
MongoDB から DMS への移行用のネットワーク接続を設定する場合:
**EC2 がホストする MongoDB ソース**
+ EC2 セキュリティグループを変更して、DMS レプリケーションインスタンスのセキュリティグループからのインバウンドトラフィックを許可します。
+ TCP ポート 27017 (またはカスタム MongoDB ポート) のルールを追加します。
+ DMS レプリケーションインスタンスのセキュリティグループ ID を正確なアクセスコントロールのソースとして使用します。
+ EC2 インスタンスのサブネットに DMS レプリケーションインスタンスのサブネットへのルートがあることを確認します。
**オンプレミス MongoDB ソース**
+ DMS レプリケーションインスタンスのパブリック IP アドレスからのインバウンド接続を許可するようにファイアウォールを設定します。
+ 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 接続文字列を使用します。
+ 移行期間に十分な oplog サイズを確保します。
**Amazon DocumentDB ソース**
DMS レプリケーションインスタンスのセキュリティグループからのインバウンドトラフィックを許可するように、ソース Amazon DocumentDB セキュリティグループを設定します。
#### DMS レプリケーションインスタンスを作成する
最適な DMS 設定とインスタンスサイズで最適な移行インフラストラクチャを作成するため、[DMS Buddy](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/dms_buddy) を使用して DMS インフラストラクチャをプロビジョニングすることをお勧めします。
手動で設定する場合、次の手順に従います。
1. DMS AWS コンソールを開き、**レプリケーションインスタンスの作成**を選択します。
1. レプリケーションインスタンスの詳細を入力します。
+ **[インスタンス名]**: 一意の名前を選択します。
+ **[インスタンスクラス]**: ワークロードに基づいて選択します。例: dms.r5.large (小規模なワークロード)、dms.r5.4xlarge (大規模なワークロード)。
+ **[エンジンバージョン]**: 3.5.4
+ **[割り当てられたストレージ]**: デフォルトは 100GB (必要に応じて増加) です。これは、ドキュメントのサイズ、更新/秒、およびフルロード時間によって決まります。
+ **マルチ AZ 配置**: 必要に応じて高可用性を有効にします。
+ Amazon DocumentDB と同じ VPC を選択します。
+ **セキュリティグループ** がソースと Amazon DocumentDB からのインバウンドトラフィックを許可していることを確認します。
1. **[レプリケーションインスタンスの作成]** をクリックし、ステータスが使用可能になるまで待ちます。
#### DMS エンドポイントを作成する
##### ソースエンドポイントを作成する
**MongoDB ソースの場合**
1. DMS コンソールのナビゲーションペインで、**[移行またはレプリケート]** を選択し、**[エンドポイント]**を選択します。
1. **エンドポイントの作成** を選択します。
1. **[エンドポイントの作成]** ページで、**[ソースエンドポイント]** を選択します｡
1. **[エンドポイント設定]** セクションで、次の操作を行います。
+ 一意で意味のある **エンドポイント識別子** (「mongodb-source」など) を入力します。
+ **[ソースエンジン]** として **MongoDB** を選択します。
+ **[Access to endpoint database]** (エンドポイントデータベースへのアクセス) では、**[Provide access information manually]** (アクセス情報を手動で提供) を選択します。
+ **[サーバー名]** では、*[MongoDB サーバーの DNS 名/IP アドレス]* を入力します。
+ **[ポート]** では、**27017** (デフォルトの MongoDB ポート) と入力します。
+ **[認証モード]** では、アプリケーションに適したモード (パスワード/SSL) を選択します (デフォルトは Secrets Manager)。
+ **[認証モード]** が **[パスワード]** の場合は、以下を指定します。
+ **[ユーザー名]** と **[パスワード]**: MongoDB 認証情報を入力します。
+ **[データベース名]**: ソースデータベースの名前。
+ **[認証メカニズム]**: SCRAM-SHA-1 (デフォルト) または適切なメカニズム
1. **[メタデータモード]** では、**[ドキュメント]** のデフォルト設定のままにします。
1. 追加の接続属性:
+ authSource=admin (認証データベースが異なる場合)
+ replicaSet= (CDC に必須)
**Amazon DocumentDB ソースの場合**
1. DMS コンソールのナビゲーションペインで、**[移行またはレプリケート]** を選択し、**[エンドポイント]**を選択します。
1. **エンドポイントの作成** を選択します。
1. **[エンドポイントの作成]** ページで、**[ソースエンドポイント]** を選択します｡
1. **[エンドポイント設定]** セクションで、次の操作を行います。
+ 一意で意味のある **エンドポイント識別子** (「docdb-sourc」など) を入力します。
+ **[ソースエンジン]** として **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) を選択します (デフォルトは Secrets Manager)。
+ **[認証モード]** が **[パスワード]** の場合は、以下を指定します。
+ **[ユーザー名]** と **[パスワード]**: Amazon DocumentDB 認証情報を入力します。
+ **[データベース名]**: ソースデータベースの名前。
+ **[認証メカニズム]**: SCRAM-SHA-1 (デフォルト) または適切なメカニズム
1. **[メタデータモード]** では、**[ドキュメント]** のデフォルト設定のままにします。
##### ターゲットエンドポイント (Amazon DocumentDB) を作成する
1. DMS コンソールのナビゲーションペインで、**[移行またはレプリケート]** を選択し、**[エンドポイント]**を選択します。
1. **エンドポイントの作成** を選択します。
1. **[エンドポイントの作成]** ページで、**[ターゲットエンドポイント]** を選択します。
1. **[エンドポイント設定]** セクションで、次の操作を行います。
+ 一意で意味のある **エンドポイント識別子** (「docdb-target」など) を入力します。
+ **[ターゲットエンジン]** として **[Amazon DocumentDB]** を選択します。
+ **[エンドポイントデータベースへのアクセス]** で、データベースへのアクセスを認証するために使用する方法を選択します。
+ **[AWS シークレットマネージャー]** を選択した場合は、**[シークレット]** フィールドに Amazon DocumentDB 認証情報を保存するシークレットを選択します。
+ **[アクセス情報を手動で提供]** を選択する場合:
+ **[サーバー名]** では、*[ターゲット Amazon DocumentDB クラスターエンドポイント]* を入力します。
+ **[ポート]** では、**27017** (Amazon DocumentDB のデフォルトのポート) を入力します。
+ **[SSL モード]** では、**verify-full** (Amazon DocumentDB に推奨) を選択します。
+ **[CA 証明書]** では、SSL 検証用の CA 証明書バンドルをダウンロードして指定します。
+ **[認証モード]** では、アプリケーションに適したモード (パスワード/SSL) を選択します (デフォルトは Secrets Manager)。
+ **[認証モード]** が **[パスワード]** の場合は、以下を指定します。
+ **[ユーザー名]** と **[パスワード]**: Amazon DocumentDB 認証情報を入力します。
+ **[データベース名]**: ソースデータベースの名前。
+ **[認証メカニズム]**: SCRAM-SHA-1 (デフォルト) または適切なメカニズム
1. **[メタデータモード]** では、**[ドキュメント]** のデフォルト設定のままにします。
#### レプリケーションタスクを作成する
1. DMS コンソールのナビゲーションペインで、**[移行またはレプリケート]** を選択し、**[タスク]** を選択します。
1. **[Create task]** (タスクの作成) を選択します。
1. **[タスクの作成]** ページの **[タスク設定]** セクションで、次の操作を行います。
+ 一意で意味のある **[タスク識別子]** (「mongodb-docdb-replication」など) を入力します。
+ 前に作成したソースエンドポイントを **[ソースデータベースエンドポイント]** ドロップダウンメニューで選択します。
+ 前に作成したターゲットエンドポイントを **[ターゲットデータベースエンドポイント]** ドロップダウンメニューで選択します。
+ **[タスクタイプ]** では、**[移行とレプリケート]** を選択します。
1. **[設定]** セクションで、次の操作を行います。
+ **[ターゲットテーブルの準備モード]** では、デフォルト設定のままにします。
+ **[フルロードの完了後にタスクを停止]** では、デフォルト設定のままにします。
+ **[LOB 列の設定]** では、**[制限付き LOB モード]** 設定をそのままにします。
+ **[データ検証]** では、デフォルト設定の **[オフにする]** のままにします。
+ **[タスクログ]** の場合は、**[CloudWatch ログをオンにする]** チェックボックスをオンにします。
+ **[バッチ最適化の適用]** では、デフォルト設定のチェックなし (オフ) のままにします。
1. **[タスク設定]** セクションの上部に戻り、**[編集モード]** で、**[JSON エディタ]** を選択し、次の属性を設定します。
```
{
"TargetMetadata": {
"ParallelApplyThreads": 5
},
"FullLoadSettings": {
"MaxFullLoadSubTasks": 16
}
}
```
1. [**テーブルマッピング**] セクションで、新しい選択ルールを追加します。
+ **[スキーマ名]** では、移行するソースデータベースを追加します。% を使用して複数のデータベースを指定します。
+ **[スキーマテーブル]** 名では、移行するソースコレクションを追加します。% を使用して複数のコレクションを指定します。
+ **[アクション]** では、デフォルト設定の **[含める]** のままにします。
1. 大規模なコレクション (100GB 以上) では、**[テーブル設定ルール]** を追加します。
+ **[スキーマ名]** では、移行するソースデータベースを追加します。% を使用して複数のデータベースを指定します。
+ **[スキーマテーブル]** 名では、移行するソースコレクションを追加します。% を使用して複数のコレクションを指定します。
+ **[パーティションの数]** では、16 と入力します (`MaxFullLoadSubTask` より小さくする必要があります)。
1. **[移行前評価]** セクションでは、オフになっていることを確認します。
### オフライン移行
このセクションでは、`mongodump` および `mongorestore` のネイティブ MongoDB ツールを使用して、セルフマネージド MongoDB インスタンスから Amazon DocumentDB へのオフライン移行を実行するプロセスを概説します。
### 前提条件
**ソース MongoDB の要件**
+ 適切なアクセス許可を持つソース MongoDB インスタンスへのアクセス。
+ 必要に応じて `mongodump` をインストールします (MongoDB のインストール中にインストールされます)。
+ ダンプファイルに十分なディスク容量があることを確認します。
**ターゲット Amazon DocumentDB の要件**
+ Amazon DocumentDB クラスターがプロビジョニングされていることを確認します。
+ 移行を容易にするために、Amazon DocumentDB と同じ VPC に EC2 インスタンスがあることを確認します。
+ ネットワーク接続は、ソース環境と Amazon DocumentDB の間で利用できる必要があります。
+ **mongorestore** は、移行 EC2 インスタンスにインストールする必要があります。
+ Amazon DocumentDB にアクセスするには、適切な IAM アクセス許可を設定する必要があります。
**一般的な要件**
+ AWS CLI を設定する必要があります (中間ストレージに AWS サービスを使用している場合)
+ データ転送には十分な帯域幅が必要です。
+ ダウンタイムウィンドウを承認する必要があります (ライブ移行を行う場合は、他のアプローチを検討してください)
### Amazon DocumentDB クラスターを準備する
AWSに Amazon DocumentDB クラスターを作成します。
+ ワークロードに基づいた適切なインスタンスサイズ。
+ VPC、サブネット、セキュリティグループを設定します。
+ パラメータグループを介して必要なパラメータを有効にします。
### データダンプを実行する (mongodump)
ダンプファイルを作成するために、次のいずれかのオプションを選択します。
+ **オプション 1: 基本**
```
mongodump --
uri="mongodb://:@:/" --
out=/path/to/dump
```
+ **オプション 2: より良い制御とパフォーマンス**
```
mongodump \
--uri="mongodb://:@:" \
--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= \
--port= \
--username= \
--password= \
--db= \# Only dump specific DB
--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
```
+ **中規模** — Amazon S3 を中間ストレージとして使用します。
```
aws s3 cp --recursive /path/to/dump s3://your-bucket/mongodb-dump/
```
+ **Large** — 非常に大規模なデータベースの場合は、 AWS DataSync または物理的な転送を検討してください。
### Amazon DocumentDB (mongorestore) にデータを復元する
復元プロセスを開始する前に、Amazon DocumentDB でインデックスを作成します。[Amazon DocumentDB インデックスツール](https://github.com/awslabs/amazon-documentdb-tools/tree/master/index-tool) を使用して、インデックスをエクスポートおよびインポートできます。
データを復元するには、以下のいずれかのオプションを選択します。
+ **オプション 1: 基本的な復元**
```
mongorestore --uri="mongodb://:@:27017"
/path/to/dump
```
+ **オプション 2: より良い制御とパフォーマンス**
```
mongorestore \
--uri="mongodb://:@: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= \
--port=27017 \
--username= \
--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** — レコード固有のエラーの数
移行パフォーマンスが低下した場合に通知を受け取るには、 `CDCLatencyTarget` や `CPUUtilization` などの重要なメトリクスの CloudWatch アラームを作成します。
#### DMS ログ (CloudWatch ログ)
1. Amazon CloudWatch Logs コンソールに移動する。
1. ロググループで検索して選択します。「dms-tasks –」のようになります。
1. エラー情報を含む可能性のあるログストリームを探します。
+ 名前に「error」が含まれるストリーム
+ タスク ID またはエンドポイント名を含むストリーム
+ 移行中の最新のログストリーム
1. これらのストリーム内で、次のようなキーワードを検索します。
+ 「エラー」
+ 「例外」
+ 「失敗」
+ 「警告」
#### DMS タスクのステータス (使用 AWS CLI)
```
aws dms describe-replication-tasks --filters Name=replication-task id,Values= --query
"ReplicationTasks[0].Status"
```
予想されるステータスフロー:
作成中 → 準備完了 → 実行中 → 停止中 → 停止 (または失敗)
#### `docdb-dashboarder` の使用によるモニタリング
この `docdb-dashboarder` ツールは、重要なパフォーマンスメトリクスを含む CloudWatch ダッシュボードを自動的に生成することで、Amazon DocumentDB クラスターの包括的なモニタリングを提供します。これらのダッシュボードには、重要なクラスターレベルのメトリクス (レプリカラグ、オペレーションカウンター)、インスタンスレベルのメトリクス (CPU、メモリ、接続)、ストレージメトリクス (ボリューム使用量、バックアップストレージ) が表示されます。移行シナリオの場合、このツールは、CDC レプリケーションラグや運用率などのメトリクスを使用して移行の進行状況を追跡する特殊なダッシュボードを提供します。ダッシュボードでは、複数のクラスターを同時にモニタリングし、NVMe-backed インスタンスのサポートを含めることができます。これらのメトリクスを視覚化することで、チームはパフォーマンスのボトルネックをプロアクティブに特定し、リソース割り当てを最適化し、Amazon DocumentDB デプロイの円滑な運用を確保できます。このツールを使用すると、ダッシュボードを手動で作成する必要がなくなり、すべての環境で一貫したモニタリングが可能になります。セットアップ手順と高度な設定オプションについては、[Amazon DocumentDB Dashboarder ツール](https://github.com/awslabs/amazon-documentdb-tools/tree/master/monitoring/docdb-dashboarder) GitHub リポジトリを参照してください。
## 検証
**Topics**
+ [検証チェックリスト](#w2aac23b9c25c15)
+ [スキーマとインデックスの検証](#w2aac23b9c25c17)
+ [データサンプリングとフィールドレベルの検証](#w2aac23b9c25c19)
+ [DataDiffer ツールを使用した検証](#w2aac23b9c25c21)
このセクションでは、以下から移行した後のデータ整合性、完全性、アプリケーションの互換性を確保するための詳細な検証プロセスについて説明します。
**MongoDB** から **Amazon DocumentDB**
または
**Amazon DocumentDB** から **Amazon DocumentDB**
検証手順は、移行方法 (AWS DMS、mongodump/mongorestore、またはその他のツール) に関係なく適用されます。
### 検証チェックリスト
各コレクションのドキュメント数がソースとターゲットの間で一致することを検証します。
**MongoDB ソース**
```
mongo --host --port --username -- password --eval
"db..count()"
```
**Amazon DocumentDB ターゲット**
```
mongo --host --port --username -- password --eval
"db..count()"
```
### スキーマとインデックスの検証
以下を確認してください。
+ すべてのコレクションがターゲットに存在します。
+ インデックスが正しくレプリケートされています。
+ スキーマ定義 (強制されている場合) が同じです。
**コレクションを確認する (ソースとターゲット)**
```
mongo --host --eval "show collections"
mongo --host --ssl --eval "show collections"
```
**インデックスを確認する (ソースとターゲット)**
```
mongo --host --eval" db..getIndexes()"
mongo --host --ssl –eval" db..getIndexes()"
```
コレクションのリストを比較して、欠落しているコレクションや余分なコレクションがないことを確認します。
インデックス名、キー定義、一意の制約、TTL インデックス (存在する場合) を確認して、インデックスを検証します。
**スキーマ検証ルールを確認する (MongoDB でスキーマ検証を使用する場合)**
```
mongo --host --eval" db.getCollectionInfos({name: ''})
[0].options.validator"
mongo --host --ssl –eval" db.getCollectionInfos({name: ''})[0].options.validator"
```
### データサンプリングとフィールドレベルの検証
ドキュメントをランダムにサンプリングし、ソースとターゲットのフィールドを比較できます。
**手動サンプリング**
5 つのランダムドキュメント (ソース) を取得します。
```
mongo --host --eval "db..aggregate([{ \$sample: { size: 5 } }])"
```
同じドキュメント ID (ターゲット) を取得します。
```
mongo --host --ssl –eval "db..find({ _id: { \$in: [] } })"
```
**自動サンプリング**
```
import pymongo
# Connect to source and target
source_client = pymongo.MongoClient("")
target_client = pymongo.MongoClient("", ssl=True)
source_db = source_client[""]
target_db = target_client[""]
# Compare 100 random documents
for doc in source_db..aggregate([{ "$sample":
{ "size": 100 } }]):
target_doc = target_db..find_one({ "_id":
doc["_id"] })
if target_doc != doc:
print(f"❌ Mismatch in _id: {doc['_id']}")
else:
print(f"✅ Match: {doc['_id']}")
```
### DataDiffer ツールを使用した検証
[DataDiffer ツール](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/data-differ) は、ソースデータベースとターゲットデータベース間でデータを比較する信頼性の高い方法を提供します。
#### 前提条件
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 クラスターに作成されていることを確認します。
+ **ドキュメントの検証結果** — 移行ドキュメントの一部として、各コレクションの検証結果を記録します。