Amazon DocumentDB への移行

Amazon DocumentDB (MongoDB 互換) は、MongoDB と互換性のあるフルマネージドデータベースサービスですAPI。このセクションで説明するプロセスを使用して、オンプレミスまたは Amazon Elastic Compute Cloud (Amazon ) で実行されている MongoDB データベースから Amazon DocumentDB にデータを移行できます。 MongoDB EC2

トピック

• 移行ツール
• 発見
• 計画: Amazon DocumentDB クラスターの要件
• 移行アプローチ
• 移行ソース
• 移行接続
• テスト
• パフォーマンステスト
• フェイルオーバーテスト
• 追加リソース
• 移行プレイブック: MongoDB から Amazon DocumentDB

移行ツール

Amazon DocumentDB に移行する場合、ほとんどのユーザーが使用する 2 つの主なツールは、AWS Database Migration Service (AWS DMS) と、mongodump や mongorestore のようなコマンドラインユーティリティです。ベストプラクティスとして、これらのオプションのいずれかのために、移行を開始する前に Amazon DocumentDB でインデックスを作成することをお勧めします。これにより、全体的な時間が短縮され、移行速度が向上します。これを行うには、Amazon DocumentDB インデックスツール が使えます。

AWS Database Migration Service

AWS Database Migration Service （AWS DMS) は、リレーショナルデータベースと非リレーショナルデータベースを Amazon DocumentDB に簡単に移行できるクラウドサービスです。を使用して AWS DMS 、オンプレミスまたは でホストされているデータベースから Amazon DocumentDB にデータを移行できますEC2。では AWS DMS、1 回限りの移行を実行したり、進行中の変更をレプリケートしてソースとターゲットを同期させることができます。

AWS DMS を使用して Amazon DocumentDB に移行する方法の詳細については、以下を参照してください。

• のソースとしての MongoDB の使用 AWS DMS

• のターゲットとしての Amazon DocumentDB の使用 AWS Database Migration Service

• ウォークスルー: MongoDB から Amazon DocumentDB への移行

コマンドラインユーティリティ

Amazon DocumentDB との間でデータを移行するための一般的なユーティリティには、mongodump、mongorestore、mongoexport、および mongoimport があります。通常、mongodump と mongorestore は、データベースのデータをバイナリ形式でダンプおよび復元するため、最も効率的なユーティリティです。これは通常、最適なオプションであり、論理エクスポートと比較してデータサイズが小さくなります。 mongoexport および mongoimportは、データが人間が読めるが、一般的に mongodump/mongorestore よりも遅く、データサイズが大きくなるCSVため、 JSONまたは などの論理形式でデータをエクスポートおよびインポートする場合に便利です。

以下の移行アプローチセクションでは、ユースケースと要件に基づいて、 AWS DMS とコマンドラインユーティリティを使用するのが最適なタイミングについて説明します。

発見

MongoDB のデプロイメントごとに、アーキテクチャの詳細と運用上の特性という 2 つのデータセットを識別し、記録する必要があります。この情報は、適切な移行方法とクラスターサイジングを選択する際に役立ちます。

アーキテクチャの詳細

• 名前

  このデプロイメントを追跡するための固有の名前を選択します。

   

• バージョン

  デプロイメントで実行している MongoDB のバージョンを記録します。バージョンを確認するには、mongo シェルを使用してレプリカセットメンバーに接続し、db.version() オペレーションを実行します。

   

• タイプ

  デプロイメントがスタンドアロンの mongo インスタンス、レプリカセット、シャードされたクラスターのいずれであるかを記録します。

   

• メンバー

  各クラスター、レプリカセット、またはスタンドアロンメンバーのホスト名、アドレス、およびポートを記録します。

   

  クラスター化されたデプロイメントの場合、シャードされたメンバーを確認するには、mongo シェルを使用して mongo ホストに接続し、sh.status() オペレーションを実行します。

   

  レプリカセットの場合は、メンバーを取得するには、mongo シェルを使用してレプリカセットのメンバーに接続し、rs.status() オペレーションを実行します。

   

• oplog のサイズ

  レプリカセットまたはシャードされたクラスターの場合は、各レプリカセットメンバーの oplog のサイズを記録します。メンバーの oplog のサイズを確認するには、mongo シェルを使用してレプリカセットメンバーに接続し、ps.printReplicationInfo() オペレーションを実行します。

   

• レプリカセットメンバーの優先順位

  レプリカセットまたはシャードされたクラスターの場合は、各レプリカセットメンバーの優先順位を記録します。レプリカセットメンバーの優先順位を確認するには、mongo シェルを使用してレプリカセットメンバーに接続し、rs.conf() オペレーションを実行します。優先順位は priority キーの値として表示されます。

   

• TLS/SSL 使用量

  転送中の暗号化のために各ノードで Transport Layer Security (TLS)/Secure Sockets Layer (SSL) が使用されているかどうかを記録します。

運用上の特性

• データベース統計

  コレクションごとに、以下の情報を記録します。

  • 名前

  • データサイズ

  • コレクションカウント

   

  データベース統計を確認するには、mongo シェルを使用してデータベースに接続し、db.runCommand({dbstats: 1}) コマンドを実行します。

   

• コレクション統計

  コレクションごとに、以下の情報を記録します。

  • 名前空間

  • データサイズ

  • インデックスカウント

  • コレクションに上限があるかどうか

   

• インデックス統計

  コレクションごとに、以下のインデックス情報を記録します。

  • 名前空間

  • ID

  • サイズ

  • キー

  • TTL

  • スパース

  • 背景

   

  インデックス情報を確認するには、mongo シェルを使用してデータベースに接続し、db.collection.getIndexes() コマンドを実行します。

   

• opcounters

  この情報は、現在の MongoDB のワークロードパターン (読み取りが多い、書き込みが多い、またはバランスが取れている) を理解するのに役立ちます。また、最初の Amazon DocumentDB インスタンス選択に関するガイダンスも提供します。

   

  モニタリング期間中 (カウント/秒) に収集する重要な情報は以下のとおりです。

  • クエリ

  • 挿入

  • 更新

  • 削除

   

  この情報を取得するには、db.serverStatus() コマンドの出力を経時的なグラフにします。また、mongostat ツールを使用して、これらの統計の瞬間値を取得することもできます。ただしこのオプションを使用する場合は、使用状況がピーク負荷以外である期間に移行を計画するというリスクを冒すことになります。

   

• ネットワーク統計

  この情報は、現在の MongoDB のワークロードパターン (読み取りが多い、書き込みが多い、またはバランスが取れている) を理解するのに役立ちます。また、最初の Amazon DocumentDB インスタンス選択に関するガイダンスも提供します。

   

  モニタリング期間中 (カウント/秒) に収集する重要な情報は以下のとおりです。

  • 接続

  • ネットワーク受信 (バイト)

  • ネットワーク送信 (バイト)

   

  この情報を取得するには、db.serverStatus() コマンドの出力を経時的なグラフにします。また、mongostat ツールを使用して、これらの統計の瞬間値を取得することもできます。ただしこのオプションを使用する場合は、使用状況がピーク負荷以外である期間に移行を計画するというリスクを冒すことになります。

計画: Amazon DocumentDB クラスターの要件

移行を成功させるには、Amazon DocumentDB クラスターの設定とアプリケーションがクラスターにアクセスする方法の両方を慎重に検討する必要があります。クラスターの要件を決定する際には、次の各ディメンションを考慮してください。

• 現在利用できるリージョン

  Amazon DocumentDB は、フェイルオーバー として知られるプロセス中で、プライマリインスタンスに昇格させることのできるレプリカインスタンスのデプロイを通じて高可用性を実現します。レプリカインスタンスを異なるアベイラビリティーゾーンにデプロイすることで、より高いレベルの可用性を実現できます。

   

  次の表は、特定の可用性目標を達成するための Amazon DocumentDB デプロイ設定のガイドラインを示しています。

   

  可用性の目標	インスタンスの合計	レプリカ	アベイラビリティーゾーン
  99%	1	0	1
  99.9%	2	1	2
  99.99%	3	2	3

   

  システム全体の信頼性を確保するには、データベースだけでなく、すべてのコンポーネントを考慮する必要があります。システム全体の信頼性ニーズを満たすためのベストプラクティスと推奨事項については、AWS Well-Architected の信頼性の柱に関するホワイトペーパーを参照してください。

   

• パフォーマンス

  Amazon DocumentDB インスタンスを使用すると、クラスターのストレージボリュームとの間で読み書きすることができます。クラスターインスタンスにはさまざまなタイプのメモリと v がありCPU、クラスターの読み取りおよび書き込みパフォーマンスに影響します。検出フェーズで収集した情報を使用して、ワークロードのパフォーマンス要件をサポートできるインスタンスタイプを選択してください。サポートされているインスタンスタイプについては、インスタンスクラスの管理を参照してください。

   

  Amazon DocumentDB クラスターのインスタンスタイプを選択するときには、ワークロードのパフォーマンス要件のうち、以下の点を考慮してください:

  • vCPUs— 接続数を増やす必要があるアーキテクチャは、v が多いインスタンスからメリットを得る可能性がありますCPUS。

     

  • メモリ - 可能な限り、作業データセットをメモリに保存しておくと、最大のパフォーマンスを得られます。最初のガイドラインは、Amazon DocumentDB エンジン用にはインスタンスのメモリの 3 分の 1 を確保し、作業データセット用には 3 分の 2 を確保することです。

     

  • 接続数 — 最適な最小接続数は、Amazon DocumentDB インスタンス v あたり 8 接続ですCPU。Amazon DocumentDB インスタンスの接続制限ははるかに高くなりますが、追加の接続のパフォーマンス上の利点は、v あたり 8 つの接続を上回って低下しますCPU。

     

  • ネットワーク - クライアントまたは接続の数が多いワークロードでは、挿入および取得されるデータに必要なネットワークパフォーマンス全体を考慮する必要があります。一括オペレーションでは、ネットワークリソースをより効率的に使用できます。

     

  • 挿入パフォーマンス - 単一のドキュメント挿入は、一般的に最も遅い Amazon DocumentDB へのデータ挿入方法です。一括挿入オペレーションは、単一挿入より大幅に高速になる可能性があります。

     

  • 読み取りパフォーマンス - 作業メモリからの読み取りは、ストレージボリュームから返される読み取りより常に高速です。そのため、インスタンスメモリサイズを最適化して作業セットをメモリに保持することが理想的です。

     

  プライマリインスタンスから読み取りが提供されるのに加えて、Amazon DocumentDB クラスターが自動的にレプリカセットとして設定されます。読み取り専用クエリをリードレプリカにルーティングするには、MongoDB ドライバーの読み取り設定を変更します。読み取りトラフィックをスケールするには、レプリカを追加し、プライマリインスタンスの全体的な負荷を減らします。

   

  同じクラスターに異なるインスタンスタイプの Amazon DocumentDB レプリカをデプロイすることができます。ユースケースの例としては、一時的な分析トラフィックを処理するためにより大きなインスタンスタイプを持つレプリカを作成することがあります。インスタンスタイプの組み合わせをデプロイする場合、各インスタンスのフェイルオーバー優先度を設定することを確認します。これにより、フェイルオーバーが発生すると、書き込み負荷を処理するために十分な竿時のレプリカを常に昇格します。

   

• 復旧

  Amazon DocumentDB は、データが書き込まれると、データを継続的にバックアップします。バックアップ保持期間 と呼ばれる、設定可能な 1～35 日以内に point-in-time リカバリ (PITR) 機能を提供します。 デフォルトのバックアップ保持期間は 1 日です。Amazon DocumentDB はストレージボリュームの毎日のスナップショットも自動的に作成します。これは、設定されたバックアップ保持期間保持されもします。

   

  バックアップ保持期間を超えてスナップショットを保持する場合は、 AWS Management Console と AWS Command Line Interface () を使用していつでも手動スナップショットを開始できますAWS CLI。詳細については、「Amazon DocumentDB でのバックアップと復元」を参照してください。

   

  移行を計画する際には、次の点を考慮してください。

  • 目標復旧時点 () を満たす 1～35 日間のバックアップ保持期間を選択しますRPO。

  • 手動スナップショットが必要かどうか、また、必要な場合はその間隔を決定します。

移行アプローチ

データを Amazon DocumentDB に移行するための主なアプローチは 3 つあります。

注記

Amazon DocumentDB ではインデックスの作成はいつでも行うことができますが、大規模なデータセットの場合は、インポート前に行うほうがより高速です。ベストプラクティスとして、以下の各アプローチでは、移行を実行する前に Amazon DocumentDB でインデックスを作成することをお勧めします。これを行うには、Amazon DocumentDB インデックスツール が使えます。

オフライン

オフライン アプローチは、mongodump および mongorestore のツールを使用して、ソース MongoDB デプロイから Amazon DocumentDB クラスターにデータを移行します。オフライン方法は最も簡単な移行アプローチですが、クラスターのダウンタイムが最も長くなります。

オフライン移行の基本的なプロセスは以下のとおりです。

1. Quiesce は MongoDB ソースに書き込んでいます。

2. ソース MongoDB デプロイから収集データとインデックスをダンプします。

3. エラスティック クラスター に移行する場合は、sh.shardCollection() コマンドを使用してシャードコレクションを作成します。インスタンスベースのクラスターに移行する場合は、ここを飛ばして次のステップへ進んでください。

4. インデックスを Amazon DocumentDB クラスターに復元します。

5. 収集データを Amazon DocumentDB クラスターに復元します。

6. Amazon DocumentDB クラスターに書き込むようにアプリケーションエンドポイントを変更します。

オンライン

オンラインアプローチは AWS Database Migration Service (AWS DMS) を使用します。ソースの MongoDB デプロイから Amazon DocumentDB クラスターにデータの完全ロードを実行します。次に、変更をレプリケートするデータキャプチャ (CDC) モードに切り替えます。オンラインアプローチは、クラスターのダウンタイムを最小限に抑えますが、3 つの方法のうち最も遅い方法です。

オンライン移行の基本的なプロセスは以下のとおりです。

1. アプリケーションはソース DB を通常使用しています。

2. エラスティック クラスター に移行する場合は、sh.shardCollection()コマンドを使用してシャードコレクションを作成します。インスタンスベースのクラスターに移行する場合は、ここを飛ばして次のステップへ進んでください。

3. Amazon DocumentDB クラスターにインデックスを事前に作成します。

4. AWS DMS タスクを作成して全ロードを実行し、ソース MongoDB デプロイCDCから Amazon DocumentDB クラスターに を有効にします。

5. AWS DMS タスクがフルロードを完了し、Amazon DocumentDB に変更をレプリケートしたら、アプリケーションのエンドポイントを Amazon DocumentDB クラスターに切り替えます。

AWS DMS を使用して移行する方法の詳細については、「 ユーザーガイド」の「 のターゲットとしての Amazon DocumentDB AWS Database Migration Service https://docs.aws.amazon.com/dms/latest/userguide/target.docdb.tutorial.htmlの使用」および関連するチュートリアルを参照してください。 AWS Database Migration Service

ハイブリッド

ハイブリッド アプローチは、mongodump および mongorestore のツールを使用して、ソース MongoDB デプロイから Amazon DocumentDB クラスターにデータを移行します。次に、 AWS DMS CDCモードで を使用して変更をレプリケートします。ハイブリッドアプローチでは、移行速度とダウンタイムのバランスをとることができますが、このアプローチは 3 つのアプローチの中で最も複雑です。

ハイブリッド移行の基本的なプロセスは以下のとおりです。

1. アプリケーションはソース MongoDB デプロイを通常使用しています。

2. ソース MongoDB デプロイから収集データとインデックスをダンプします。

3. インデックスを Amazon DocumentDB クラスターに復元します。

4. エラスティック クラスター に移行する場合は、sh.shardCollection() コマンドを使用してシャードコレクションを作成します。インスタンスベースのクラスターに移行する場合は、ここを飛ばして次のステップへ進んでください。

5. 収集データを Amazon DocumentDB クラスターに復元します。

6. ソース MongoDB デプロイCDCから Amazon DocumentDB クラスターに対して を有効にする AWS DMS タスクを作成します。

7. AWS DMS タスクが許容範囲内の変更をレプリケートしている場合は、Amazon DocumentDB クラスターに書き込むようにアプリケーションエンドポイントを変更します。

重要

AWS DMS タスクは現在、1 つのデータベースのみを移行できます。移行元の MongoDB に多数のデータベースがある場合は、移行タスクの作成を自動化するか、オフラインの方法を検討する必要があります。

選択した移行方法に関係なく、データを移行する前に Amazon DocumentDB クラスターでインデックスを事前に作成しておくことが最も効率的です。これは、Amazon DocumentDB インデックスは並行してデータに挿入されるが、既存データのインデックス作成はシングルスレッドのオペレーションであるためです。

AWS DMS はインデックスを移行しないため (データのみ）、インデックスを 2 回目に作成しないようにするための追加のステップは必要ありません。

移行ソース

MongoDB ソースがスタンドアロンの mongo プロセスで、オンラインまたはハイブリッドの移行アプローチを使用する場合は、まずスタンドアロンの mongo をレプリカセットに変換して、 をCDCソースとして使用するように oplog を作成します。

MongoDB レプリカセットまたはシャードされたクラスターから移行する場合は、移行元として使用する各レプリカセットまたはシャードに対して連鎖または非表示のセカンダリを作成することを検討してください。データダンプを実行すると、作業セットデータがメモリ不足になり、本番インスタンスのパフォーマンスに影響を与える可能性があります。このリスクを軽減するには、本番データを提供していないノードから移行します。

移行元のバージョン

移行元の MongoDB データベースのバージョンが移行先の Amazon DocumentDB クラスターの互換バージョンと異なる場合は、移行を成功させるために追加の準備ステップを実行する必要があります。最も一般的に生じる 2 つの要件は、移行元の MongoDB インストールをサポートされているバージョン (MongoDB バージョン 3.0 以降) にアップグレードして移行可能にすること、および移行先の Amazon DocumentDB のバージョンをサポートするようにアプリケーションドライバーをアップグレードすることです。

これらの要件のいずれかが該当する場合は、移行計画にそれらのステップを含めて、ドライバーの変更をアップグレードし、テストしてください。

移行接続

データセンターで実行されているソース MongoDB デプロイ、または Amazon EC2インスタンスで実行されている MongoDB デプロイから Amazon DocumentDB に移行できます。で実行されている MongoDB からの移行EC2は簡単で、セキュリティグループとサブネットを正しく設定するだけで済みます。

オンプレミスデータベースから移行するには、MongoDB デプロイと仮想プライベートクラウド () 間の接続が必要ですVPC。これを行うには、仮想プライベートネットワーク (VPN) 接続を使用するか、 AWS Direct Connect サービスを使用します。インターネット経由で に移行することはできますがVPC、セキュリティの観点からは、この接続方法は最も望ましくない方法です。

次の図は、オンプレミスソースからVPN接続経由で Amazon DocumentDB に移行する方法を示しています。

以下は、 AWS Direct Connectを使用してオンプレミスの移行元から Amazon DocumentDB への移行を示しています。

オンラインおよびハイブリッド移行アプローチでは、インスタンスを使用する必要があります。インスタンスは AWS DMS Amazon の Amazon EC2で実行する必要がありますVPC。すべてのアプローチで、mongodump と mongorestore を実行するための移行サーバーが必要です。通常、Amazon Amazon DocumentDB クラスターが起動VPCされている の Amazon DocumentDBEC2インスタンスで移行サーバーを実行する方が簡単です。

テスト

移行前のテストの目標は以下のとおりです。

• 選択したアプローチで目的の移行結果を得られることを検証する。

• インスタンスタイプと読み取り設定の選択がアプリケーションのパフォーマンス要件を満たしていることを検証する。

• フェイルオーバー中のアプリケーションの動作を検証する。

移行計画のテストに関する考慮事項

Amazon DocumentDB の移行計画をテストする際には、以下の点を考慮してください。

インデックスの復元

デフォルトでは、mongorestore はダンプされたコレクションのインデックスを作成しますが、作成するのはデータのリストア後です。データがクラスターにリストアされる前に、Amazon DocumentDB でインデックスを作成する方が全体的に高速です。これは、データのロード中にインデックス作成オペレーションが並列化されるためです。

インデックスの事前作成を選択した場合、mongorestore データをリストアするときにインデックス作成ステップをスキップするには、-–noIndexRestore オプションを指定します。

ダンプデータ

mongodump ツールは、ソースの MongoDB デプロイメントからデータをダンプするために推奨される方法です。移行インスタンスで使用可能なリソースに応じて、mongodump を高速化するには、–-numParallelCollections オプションを使用して、ダンプされる並列接続数をデフォルトの 4 から増やします。

データの復元

mongorestore のツールは、ダンプされたデータを Amazon DocumentDB インスタンスにリストアするための推奨される方法です。リストアのパフォーマンスを向上させるには、-–numInsertionWorkersPerCollection オプションを使用して、リストア中に各コレクションのワーカー数を増やします。Amazon DocumentDB クラスターのプライマリインスタンスの vCPU ごとに 1 人のワーカーを起動することをお勧めします。

Amazon DocumentDB は現在、mongorestore ツールの --oplogReplay オプションをサポートしていません。

デフォルトでは、mongorestore は挿入エラーをスキップし、リストアプロセスを続行します。これは、サポートされていないデータを Amazon DocumentDB インスタンスにリストアしている場合に発生する可能性があります。たとえば、null 文字列が使用されているキーまたは値を含むドキュメントがあるとします。リストアエラーが発生した場合に mongorestore オペレーションを完全に失敗させるには、--stopOnError オプションを使用します。

Oplog のサイズ設定

MongoDB オペレーションログ (oplog) は、データベースに対するすべてのデータ変更を含む上限付きコレクションです。oplog のサイズとそれに含まれる時間範囲を表示するには、レプリカセットまたはシャードされたメンバーに対して db.printReplicationInfo() オペレーションを実行します。

オンラインアプローチまたはハイブリッドアプローチを使用している場合は、各レプリカセットまたはシャードのオログが、データ移行プロセス全体 ( mongodump または AWS DMS タスクのフルロード経由かにかかわらず) に加え、妥当なバッファを含むのに十分な大きさであることを確認してください。詳細については、MongoDB のドキュメントの Check the Size of the Oplog (oplog のサイズの確認) を参照してください。必要な最小 oplog サイズを判別するために、mongodump または mongorestore プロセス、あるいは AWS DMS 全ロードタスクの最初のテスト実行に要した経過時間を記録します。

AWS Database Migration Service 設定

AWS Database Migration Service ユーザーガイド は、移行元の MongoDB データを Amazon DocumentDB クラスターに移行するために必要なコンポーネントとステップが記載されています。 AWS DMS を使用してオンライン移行またはハイブリッド移行を実行するための基本的なプロセスを次に示します。

を使用して移行を実行するには AWS DMS

1. MongoDB ソースエンドポイントを作成します。詳細については、AWS DMSのソースとしての MongoDB の使用を参照してください。

2. Amazon DocumentDB ターゲットエンドポイントを作成します。詳細については、AWS DMS エンドポイントの使用を参照してください。

   ターゲットエンドポイントを Elastic クラスターとして設定する場合、既存の Amazon DocumentDB SSL証明書は Elastic クラスターでは機能せず、次の手順を使用して新しいSSL証明書をエンドポイントにアタッチする必要があることに注意してください。

   a。https://www.amazontrust.com/repository/SFSRootCAG2.pem にアクセスし、内容をSFSRootCAG2「.pem」ファイルとして保存します。この証明書ファイルは、以降の手順でインポートする必要があります。

   b。エラスティッククラスターエンドポイントを作成するときは、[エンドポイント設定] で [新しい CA 証明書を追加] を選択します。

   • [証明書識別子] については、「SFSRootCAG2.pem」 を入力します。

   • [Import certificate file (証明書ファイルのインポート)] で、[Choose file (ファイルの選択)] を選択し、以前にダウンロードした SFSRootCAG2.pem ファイルに移動します。ファイルを選択して開きます。[証明書をインポートする] を選択し、次に [証明書を選択する] のドロップダウンから「SFSRootCAG2.pem」を選択します。

3. 少なくとも 1 つの AWS DMS レプリケーションインスタンスを作成します。詳細については、AWS DMS 「レプリケーションインスタンスの使用」を参照してください。

4. 少なくとも 1 つの AWS DMS レプリケーションタスクを作成します。詳細については、AWS DMS タスクの使用を参照してください。

   オンライン移行の場合、移行タスクでは移行タイプ [Migrate existing data and replicate ongoing changes (既存データの移行と進行中の変更のレプリケート)] を使用します。

   ハイブリッド移行の場合、移行タスクでは移行タイプ [Replicate data changes only (データ変更のレプリケートのみ)] を使用します。CDC 開始時刻を選択して、mongodumpオペレーションのダンプ時間に合わせて調整できます。MongoDB の oplog はべき等です。変更が欠落しないように、mongodump終了時刻とCDC開始時刻の間に数分のオーバーラップを残すことをお勧めします。

シャードされたクラスターからの移行

MongoDB シャードクラスターから Amazon DocumentDB インスタンスにデータを移行するためのプロセスは、本質的には複数のレプリカセットを並行して移行するプロセスです。シャードされたクラスターの移行をテストする際の重要な考慮事項は、一部のシャードが他のシャードより頻繁に使用される可能性がある点です。この状況により、データ移行の経過時間が変わります。計画とテストの際には、各シャードの oplog の要件を必ず評価してください。

以下は、シャードされたクラスターを移行するときに考慮する必要がある設定上の問題です。

• mongodump を実行したり、 AWS DMS 移行タスクを開始したりする前に、シャードされたクラスターのバランサーを無効にして、インプロセス移行が完了するまで待つ必要があります。詳細については、MongoDB ドキュメントの Disable the Balancer (バランサーを無効にする) を参照してください。

• AWS DMS を使用してデータをレプリケートする場合は、移行タスクを実行する前に、各シャードで cleanupOrphaned コマンドを実行します。このコマンドを実行しないと、ドキュメント が重複しているため、タスクが失敗する可能性がありますIDs。このコマンドはパフォーマンスに影響を与える可能性があることに注意してください。詳細については、MongoDB ドキュメントcleanupOrphanedの「」を参照してください。

• mongodump ツールを使用してデータをダンプする場合は、シャードごとに 1 つの mongodump プロセスを実行する必要があります。最も時間効率の良い方法として、ダンプパフォーマンスを最大化するために、複数の移行サーバーが必要になることがあります。

• AWS Database Migration Service を使用してデータをレプリケートする場合は、シャードごとにソースエンドポイントを作成する必要があります。また、移行するシャードごとに 1 つ以上の移行タスクを実行してください。最も時間効率の良い方法として、移行パフォーマンスを最大化するために、複数のレプリケーションインスタンスが必要になることがあります。

パフォーマンステスト

データをテスト用の Amazon DocumentDB クラスターに正常に移行したら、クラスターに対してテストワークロードを実行します。Amazon CloudWatch メトリクスを通じて、パフォーマンスが MongoDB ソースデプロイの現在のスループットを満たしているか超えているかを確認します。

以下のキーとなる Amazon DocumentDB のメトリクスを確認します。

• ネットワークスループット

• 書き込みスループット

• 読み取りスループット

• レプリカラグ

詳細については、「Amazon DocumentDB のモニタリング」を参照してください。

フェイルオーバーテスト

Amazon DocumentDB フェイルオーバーイベント中のアプリケーションの動作が可用性の要件を満たしていることを検証します。コンソールで Amazon DocumentDB クラスターの手動フェイルオーバーを開始するには、クラスター ページで、アクション メニューに関する フェイルオーバー アクションを選択します。

AWS CLIから failover-db-cluster オペレーションを実行してフェイルオーバーを開始することもできます。詳細については、 AWS CLI リファレンスのfailover-db-clusterAmazon DocumentDB」セクションの「」を参照してください。

追加リソース

AWS Database Migration Service ユーザーガイドの次のトピックを参照してください。

• のターゲットとしての Amazon DocumentDB の使用 AWS Database Migration Service

• ウォークスルー: MongoDB から Amazon DocumentDB への移行