Amazon DocumentDB
開発者ガイド

Amazon DocumentDB への移行

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

検出

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

     

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

    • vCPUs — アーキテクチャで必要な接続数が増えるほど、より多くの vCPUS を持つインスタンスからメリットを得られる可能性があります。

       

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

       

    • 接続 — 最適な最小接続数は、Amazon DocumentDB インスタンスの vCPU あたり 8 接続です。Amazon DocumentDB インスタンスの接続制限ははるかに高まりますが、追加の接続によるパフォーマンス上のメリットは、vCPU あたり 8 接続を超えると低下します。

       

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

       

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

       

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

       

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

     

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

     

  • 復旧

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

     

    バックアップ保持期間を超えてスナップショットを保持するには、AWS マネジメントコンソール および AWS Command Line Interface (AWS CLI) を使用していつでも手動スナップショットを開始できます。詳細については、「Amazon DocumentDB のバックアップと復元」を参照してください。

     

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

    • 目標復旧ポイント (RPO) を満たす 1〜35 日のバックアップ保持期間を選択します。

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

移行アプローチ

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

注記

Amazon DocumentDB ではインデックスの作成はいつでも行うことができますが、大規模なデータセットの場合は、インポート前に行う方が高速です。

オフライン

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

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

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

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

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

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

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


               図: オフラインアプローチによる Amazon DocumentDB への移行

オンライン

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

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

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

  2. 必要に応じて、Amazon DocumentDB クラスターでインデックスを事前に作成します。

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

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


               図: オンラインアプローチのよる Amazon DocumentDB への移行

AWS DMS を使用した移行の詳細については、「Amazon DocumentDB を AWS Database Migration Service のターゲットとして使用する」および AWS Database Migration Service ユーザーガイド で関連するチュートリアルを参照してください。

ハイブリッド

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

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

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

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

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

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

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

  6. AWS DMS タスクによって許容可能な期間内で変更がレプリケートされているときは、Amazon DocumentDB クラスターに書き込むようにアプリケーションエンドポイントを変更します。


               図: ハイブリッドアプローチによる Amazon DocumentDB への移行

重要

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

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

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

移行元

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

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

移行元のバージョン

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

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

重要

AWS DMS は現在、MongoDB 4.0 以降を移行元としてサポートしていません。

移行の接続

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


            図: 移行元の Amazon EC2 から Amazon DocumentDB への移行

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

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


            図: オンプレミスの移行元から Amazon DocumentDB への移行 (VPN)

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


            図: オンプレミスの移行元から Amazon DocumentDB への移行 (AWS Direct Connect)

オンラインおよびハイブリッドの移行アプローチでは、AWS DMS インスタンスを使用する必要があり、これは Amazon VPC 内の Amazon EC2 上で実行する必要があります。すべてのアプローチで、mongodumpmongorestore を実行するための移行サーバーが必要です。Amazon DocumentDB クラスターが起動されている VPC の Amazon EC2 インスタンスで移行サーバーを実行する方が、Amazon DocumentDB クラスターへの接続が大幅に単純化されるため、一般的に簡単です。

テスト

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

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

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

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

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

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() オペレーションを実行します。

オンラインまたはハイブリッドのアプローチを使用している場合は、各レプリカセットまたはシャードの oplog が、データ移行プロセス (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 エンドポイントの使用を参照してください。

  3. AWS DMS レプリケーションインスタンスを 1 つ以上作成します。詳細については、AWS DMS レプリケーションインスタンスを使用するを参照してください。

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

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

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

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

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

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

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

     

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

その他のリソース

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