次の方法で共有

MongoDB から Azure Cosmos DB for MongoDB へのデータ移行の移行前手順

  • [アーティクル]

適用対象: MongoDB

重要

移行前の手順を実行する前に、このガイド全体をお読みください。

この MongoDB 移行前ガイドは、MongoDB の移行に関するシリーズの一部です。 MongoDB 移行の重要な手順は、このガイドに示すように、移行前、移行、そして移行後です。

移行前から移行後までの移行手順の図。

移行前の概要

実際にデータを移動する前に、移行に関する計画と意思決定を前もって行うことが重要です。 この最初の意思決定プロセスを、"移行前"と呼びます。

移行前の目標は次のとおりです。

  1. アプリケーションの要件を満たすようにAzure Cosmos DBを設定していることを確認し、そして
  2. 移行を実行する方法を計画します。

次の手順に従って、移行前の手順を詳細に実行します

  1. 既存の MongoDB リソースを検出し、データ移行のための既存の MongoDB リソースの準備状況を評価する
  2. 既存の MongoDB リソースを新しい Azure Cosmos DB リソースにマップする
  3. フルスケールのデータ移行を開始する前に、移行プロセスのロジスティクスを最初から最後まで計画する

次に、移行前の計画に従って移行を実行します。

最後に、カットオーバーと最適化の重要な移行後の手順を実行します。

移行を成功させるには、上記のすべての手順が不可欠です。

移行を計画するときは、可能な限りリソースごとのレベルで計画することをお勧めします。

移行前の評価

最初の移行前手順は、既存の MongoDB リソースを検出し、移行のためのリソースの準備状況を評価することです。

検出には、MongoDB データ資産内の既存のリソース (データベースまたはコレクション) の包括的な一覧を作成することも含まれます。

評価には、サポートされている機能と構文を使用しているかどうかを調べる必要があります。 また、 制限とクォータに従っていることを確認することも含まれます。 このステージの目的は、非互換性と警告がある場合に、その一覧を作成することです。 評価結果を得た後は、移行計画の残りの部分で結果に対処できます。

移行前評価を実行する方法は 3 つあります。Azure Cosmos DB Migration for MongoDB 拡張機能を使用することをお勧めします。

Azure Cosmos DB Migration for MongoDB 拡張機能

Azure Data Studio の Azure Cosmos DB Migration for MongoDB 拡張機能は、Azure Cosmos DB for MongoDB に移行するための MongoDB ワークロードを評価するのに役立ちます。 この拡張機能を使用して、ワークロードに対してエンドツーエンドの評価を実行し、Azure Cosmos DB でワークロードをシームレスに移行するために必要なアクションを確認することができます。 MongoDB エンドポイントの評価中に、この拡張機能は検出されたすべてのリソースをレポートします。

Note

サポートされている機能と構文、Azure Cosmos DB の制限とクォータを詳しく調べ、実際の移行の前に概念実証を実行することもお勧めします。

手動検出 (レガシ)

別の方法として、データ資産移行スプレッドシートを作成できます。 このスプレッドシートの目的は、生産性を向上させること、エンドツーエンドの移行を計画できるように支援することです。移行プロセス全体で追跡ドキュメントとしてこのスプレッドシートを使用してください。

  • このシートには、MongoDBデータ資産内の既存のリソース(データベースまたはコレクション)の包括的な一覧が含まれています。
  • スプレッドシートは、リスト形式の、データ資産リソースの記録として構成する必要があります。
  • 各行は、リソース (データベースまたはコレクション) に対応します。
  • 各列は、リソースのプロパティに対応します。少なくとも名前とデータサイズ(GB)を列として使用して開始します。
  • このガイドを読み進めながら、このスプレッドシートを移行計画を最初から最後まで追跡するドキュメントに仕上げ、必要に応じて列を追加します。

リソースの検出に使用できるツールをいくつかご紹介します:

スプレッドシートを調べて、サポートされている機能と構文、Azure Cosmos DB の制限とクォータと対照させて各コレクションを詳しく確認します。

Database Migration Assistant ユーティリティ (レガシ)

Note

Database Migration Assistant は、移行前の手順を支援するためのレガシ ユーティリティです。 Microsoft では、移行前のすべての手順に Azure Cosmos DB Migration for MongoDB 拡張機能を使用することを推奨しています。

移行前の手順を支援するために、Database Migration Assistant (DMA) ユーティリティを使用できます。

移行前のマッピング

検出と評価の手順が完了すれば、MongoDB 側の作業は終了です。 次は、Azure Cosmos DB 側の計画を立てる番です。 本番用の Azure Cosmos DB リソースをどのように設定および構成する予定ですか。 計画は、"リソース単位" で立てるようにします。つまり、計画用のスプレッドシートには以下の列を追加する必要があります。

  • Azure Cosmos DB マッピング
  • シャード キー
  • データ モデル
  • 専用 vs 共有スループット

詳細については、次のセクションを参照してください。

容量計画

Azure Cosmos DB への移行のための容量計画を実行しようとしていますか?

Azure Cosmos DB の MongoDB 用 API を使用する場合の考慮事項

Azure Cosmos DB のデータ資産を計画する前に、次の Azure Cosmos DB の概念を理解しておく必要があります。

  • 容量モデル:Azure Cosmos DB のデータベース容量は、スループットベースのモデルに基づいています。 このモデルは要求ユニット/秒に基づいています。これは、1 秒ごとにコレクションに対して実行できるデータベース操作の数を表す単位です。 この容量は、データベースまたはコレクション レベルで割り当てることができます。また、割り当てモデルに対してプロビジョニングすることも、自動スケーリングでプロビジョニングされたスループットを使用してプロビジョニングすることもできます。
  • 要求ユニット:すべてのデータベース操作には、Azure Cosmos DB に関連付けられた要求ユニット (RU) コストがあります。 実行すると、指定された秒で使用可能な要求ユニット レベルから要求ユニットが減算されます。 要求に、現在割り当てられている RU/秒よりも多くの RU が必要な場合、問題を解決するための 2 つの選択肢があります。つまり、RU の数を増やすか、次の秒が開始されるまで待機してから操作を再試行します。
  • エラスティック容量:特定のコレクションまたはデータベースの容量は、いつでも変更できます。 この柔軟性により、データベースをワークロードのスループット要件に柔軟に適応させることができます。
  • 自動シャーディング:Azure Cosmos DB では、シャード (またはパーティション キー) のみを必要とする自動パーティション分割システムが提供されます。 自動パーティション分割メカニズムは、すべての Azure Cosmos DB API 間で共有されます。これにより、水平分布を通じて、シームレスなデータおよびスループットのスケーリングが可能になります。

Azure Cosmos DB データ資産を計画する

どの Azure Cosmos DB リソースを作成するかを確認します。 このプロセスでは、データ資産の移行スプレッドシートのステップを実行し、既存の MongoDB リソースを新しい Azure Cosmos DB リソースにマッピングする必要があります。

  • 各 MongoDB データベースが Azure Cosmos DB データベースになることを想定します。
  • 各 MongoDB コレクションが Azure Cosmos DB コレクションになることを想定します。
  • Azure Cosmos DB リソースの名前付け規則を設定します。 データベースとコレクションの構造に変更がない限り、通常は同じリソース名を保持することが適しています。
  • Azure Cosmos DB でシャード化コレクションとシャード化されていないコレクションのどちらを使用するかを決定します。 シャード化されていないコレクションの制限は20 GBです。 一方、シャーディングは、多くのワークロードのパフォーマンスにとって重要な水平スケールを実現するのに役立ちます。
  • シャード コレクションを使用している場合は、"MongoDB コレクションのシャード キーが Azure Cosmos DB コンテナーのパーティション キーになるとは想定しないでください"。 既存の MongoDB データ モデルのドキュメント構造が、Azure Cosmos DB で使用するのと同じモデルであるはずとは想定しないでください。
    • シャード キーは、Azure Cosmos DB のスケーラビリティとパフォーマンスを最適化するために最も重要な設定であり、データ モデルはその次に重要です。 これらの設定はどちらも変更不可で、設定後に変更することはできません。そのため、計画フェーズで最適化することが非常に重要です。 詳細については、「変更できない決定事項」セクションのガイダンスに従ってください。
  • Azure Cosmos DB では、上限付きコレクションなど、特定の MongoDB のコレクション型は認識されません。 これらのリソースの場合は、通常の Azure Cosmos DB 作成してください。
  • Azure Cosmos DB には、共有スループットと専用スループットという、2 種類のコレクションがあります。 共有と専用のスループットは、計画段階で行う必要がある重要で変更できない決定の 1 つです。 詳細については、「変更できない決定事項」セクションのガイダンスに従ってください。

変更できない決定事項

次の Azure Cosmos DB リソースを作成した後に、選択した Azure Cosmos DB の構成を変更することはできません。したがって、移行を開始する前に、移行前の計画でこれらの構成の選択を正しく行うことが重要です。

保有コスト

スループットの見積り

  • Azure Cosmos DBでは、スループットは事前にプロビジョニングされ、1秒あたりの要求ユニット(RU)で測定されます。 VM やオンプレミス サーバーとは異なり、RU はいつでも簡単にスケールアップしたりスケールダウンしたりすることができます。 プロビジョニングされた RU の数をすぐに変更することができます。 詳細については、「Azure Cosmos DB の要求ユニット」を参照してください。

  • Azure Cosmos DB 容量計算ツールを使用して、使用する要求ユニットの数を決定できます。 この数は、Azure Cosmos DB Capacity Calculator を使用すると、データベース アカウントの構成、データの量、ドキュメントのサイズ、1 秒あたりの必要な読み取りと書き込みに基づきます。

  • 必要な RU 数に影響する主な要因は、次のとおりです。

    • ドキュメントのサイズ: 項目またはドキュメントのサイズが増加すると、その項目またはドキュメントの読み書きに消費される RU 数も増加します。

    • ドキュメント プロパティの数: ドキュメントの作成または更新で消費される RU の数は、そのプロパティの数、複雑さ、長さに関連します。 インデックス付きのプロパティ数を制限すると、書き込み操作で消費される要求ユニットを削減できます。

    • クエリ パターン: クエリの複雑さは、そのクエリが消費する要求ユニット数に影響します。

  • クエリのコストを理解する最良の方法は、Azure Cosmos DB でサンプル データを使用し、消費される RU の数を出力する getLastRequestStastistics コマンドを使って MongoDB Shell からサンプル クエリを実行して、要求の料金を取得することです。

    db.runCommand({getLastRequestStatistics: 1})

    *このコマンドを使用すると、次の例のような JSON ドキュメントが出力されます。

    {
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}

  • 診断設定を使用して、Azure Cosmos DB に対して実行されるクエリの頻度とパターンを理解することもできます。 診断ログの結果は、ストレージ アカウント、Event Hubs インスタンスまたは Azure Log Analytics に送信できます。

移行前のロジスティクス計画

最後に、既存のデータ資産のビューと新しい Azure Cosmos DB データ資産の設計ができたので、移行プロセスを最初から最後まで実行する方法を計画する準備ができました。 繰り返しになりますが、計画はリソース単位で立て、スプレッドシートに列を追加して、このセクションに示されているロジスティック ディメンションを把握します。

実行ロジスティック

  • 既存の各リソースを MongoDB から Azure Cosmos DB に移行するための責任者を割り当てます。 移行を完了させるために、チームのリソースをどのように適用するかは、お客様次第です。 小規模な移行では、1 つのチームが移行全体を開始し、その進捗を監視することができます。 大規模な移行では、リソースを移行および監視するために、リソースごとにチームメンバーに責任を割り当てることができます。

  • リソースの移行の担当者を決定したら、次は移行に適した移行ツールを選択します。 小規模な移行では、MongoDB ネイティブ ツールや Azure DMS などの移行ツールを使用して、一度にすべてのリソースを移行することができるかもしれません。 大規模な移行や特殊な要件のある移行の場合は、リソースごとの粒度で移行ツールを選択することをお勧めします。

    • 使用する移行ツールを計画する前に、利用可能なオプションについて理解しておくことをお勧めします。 Azure Cosmos DB の MongoDB 用 API の Azure Database Migration Service では、フル マネージド ホスティング プラットフォーム、移行の監視オプションおよび自動調整処理を提供することで、データの移行を簡略化するメカニズムが提供されます。 オプションの完全な一覧を次に示します。

      移行の種類 ソリューション 考慮事項
      オンライン Azure Database Migration Service • Azure Cosmos DB 用バルク エグゼキューター ライブラリを使用します
      • 大規模なデータセットに適し、ライブ変更のレプリケーションを処理します
      • 他の MongoDB ソースでのみ機能します
      オフライン Azure Database Migration Service • Azure Cosmos DB 用バルク エグゼキューター ライブラリを使用します
      • 大規模なデータセットに適し、ライブ変更のレプリケーションを処理します
      • 他の MongoDB ソースでのみ機能します
      オフライン Azure Data Factory • Azure Cosmos DB 用バルク エグゼキューター ライブラリを使用します
      • 大規模なデータセットに適しています
      • セットアップが簡単で、さまざまなソースをサポートします
      • チェックポイントがなく、移行中に問題が発生した場合、移行プロセスを全部やり直す必要があります
      • 配信不能キューがなく、エラーが含まれるファイルがいくつかあっただけで移行プロセス全体が停止することがあります
      • 特定のデータ ソースの読み取りスループットを向上させるためのカスタム コードが必要です
      オフライン 既存の Mongo ツール (mongodump、mongorestore、Studio3T) • セットアップと統合が簡単です
      • スロットルのカスタム処理が必要です
      オフライン/オンライン Azure Databricks と Spark • 移行速度とデータ変換を完全に制御
      • カスタム コーディングが必要

    • リソースをオフラインで移行することが可能な場合は、この図を参考に適切な移行ツールを選択してください。

      ツールのサイズに基づいてオフライン移行ツールを使用する図。

    • リソースをオンラインで移行する必要がある場合は、この図を参考に適切な移行ツールを選択してください。

      ターンキーまたはカスタム ソリューションの優先設定に基づくオンライン移行ツールの使用の図。

    • 移行ソリューションの概要とデモの動画を見ます。

  • 各リソースの移行ツールを決定したら、次は移行するリソースの優先順位を決めます。 優先順位を適切につけることで、移行をスケジュール通りに進めることができます。 移行に最も時間がかかるリソースを優先的に移行することをお勧めします。これらのリソースを最初に移行することで、完了までの時間を短縮できます。 さらに、これらの時間のかかる移行には一般的に多くのデータが含まれ、移行ツールのリソースをより多く必要とするため、移行パイプラインの問題を早期に発見できる可能性が高くなります。 このようにすると、移行パイプラインに問題があるためにスケジュールが遅れる可能性を最小限に抑えることができます。

  • 移行が開始された後の移行の進行状況を監視する方法を計画します。 チームでデータ移行作業を調整している場合は、チーム間で定期的に同期も行うように計画し、優先度の高い移行作業の進捗状況を総合的に把握できるようにします。

サポートされる移行シナリオ

採用すべき最適な MongoDB 移行ツールは、移行シナリオによって異なります。

移行の種類

移行シナリオごとに互換性のあるツールの一覧を次に示します。

source 宛先 プロセスに関する推奨事項
• MongoDB オンプレミス クラスター
• IaaS VM クラスター上の MongoDB
• MongoDB Atlas クラスター - オフライン		 Azure Cosmos DB Mongo API • <10 GB のデータ: MongoDB ネイティブ ツール
• < 1 TB のデータ:Azure DMS
• > 1 TB データ: Spark
• MongoDB オンプレミス クラスター
• IaaS VM クラスター上の MongoDB
• MongoDB Atlas クラスター - オンライン		 Azure Cosmos DB Mongo API • < 1 TB のデータ:Azure DMS
• >1 TB のデータ: Spark + Mongo Changestream
• 移行中にスキーマを変更する必要がある
前述のツールよりも高い柔軟性が必要		 Azure Cosmos DB Mongo API • ADF は DMS よりも柔軟性が高く、移行中のスキーマ変更をサポートし、ほとんどの移行元と移行先の組み合わせをサポートします
• DMS はスケールの面で優れています (移行の高速化など)
• JSON ファイル Azure Cosmos DB Mongo API • MongoDB ネイティブ ツール (特に mongoimport)
• CSV ファイル Azure Cosmos DB Mongo API • MongoDB ネイティブ ツール (特に mongoimport)
• BSON ファイル Azure Cosmos DB Mongo API • MongoDB ネイティブ ツール (特に mongorestore)

MongoDB バージョンのツール サポート

特定の MongoDB バージョンから移行する場合、各バージョンでサポートされているツールをここに示します。

移行元 MongoDB バージョン 移行先 Azure Cosmos DB for MongoDB バージョン サポートされているツール サポートされないツール
<2.x、>4.0 3.2、3.6、4.0 MongoDB ネイティブ ツール、Spark DMS、ADF
3.2、3.6、4.0 3.2、3.6、4.0 MongoDB ネイティブ ツール、DMS、ADF、Spark なし

移行後

移行前のフェーズでは、少し時間を費やして、アプリの移行と移行後の最適化に向けて、どのようなステップを踏むのかを計画します。

  • 移行後のフェーズでは、既存の MongoDB データ資産の代わりに Azure Cosmos DB を使用するために、アプリケーションのカットオーバーを実行します。
  • インデックス、グローバル分散、一貫性、その他の "変更可能な" Azure Cosmos DB のプロパティをリソース レベルごとに計画するよう最善を尽くします。 ただし、これらの Azure Cosmos DB の構成設定は後で変更することが "可能" なので、これらの設定は今後調整することも想定されます。 これらの変更可能な構成は、移行後に適用します。
  • 移行後のガイドとして、Azure Cosmos DBのMongoDB用API使用時の移行後の最適化手順を参照してください。

次のステップ