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

適用対象: MongoDB 用 Azure Cosmos DB API

重要

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

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

移行手順の図。

移行前の概要

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

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

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

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

  1. 既存のMongoDBリソースを検出し、それらを追跡するためのデータエステートスプレッドシートを作成する
  2. データ移行に向けて既存の MongoDB リソースの準備状態を評価する
  3. 既存の MongoDB リソースを新しい Azure Cosmos DB リソースにマップする
  4. フルスケールのデータ移行を開始する前に、移行プロセスのロジスティクスを最初から最後まで計画する

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

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

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

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

Database Migration Assistant (DMA)は、計画の検出評価の段階を支援します。

移行前の検出

移行前の最初の手順は、リソース探索です。 この手順では、データ資産移行スプレッドシートを作成する必要があります。

  • このシートには、MongoDBデータ資産内の既存のリソース(データベースまたはコレクション)の包括的な一覧が含まれています。
  • このスプレッドシートの目的は、生産性を向上させ、移行を最初から最後まで計画するのに役立ちます。
  • このドキュメントを拡張し、移行プロセス全体を通じて追跡ドキュメントとして使用することをお勧めします。

Database Migration Assistantを使用したプログラムによる検出

Database Migration Assistant (DMA)を使用して、探索ステージを支援し、プログラムでデータ資産移行シートを作成できます。

Azure Data Studioクライアントを使用してDMAを簡単にセットアップして実行できます。 ソースMongoDB環境に接続されている任意のマシンから実行できます。

データ資産移行スプレッドシートとして、次のいずれかのDMA出力ファイルを使用できます。

  • workload_database_details.csv - ソースワークロードのデータベースレベルのビューを提供します。 ファイル内の列は、データベース名、コレクション数、ドキュメント数、平均ドキュメントサイズ、データサイズ、インデックス数、インデックスサイズです。
  • workload_collection_details.csv - ソースワークロードのコレクションレベルのビューを提供します。 ファイル内の列は、データベース名、コレクション名、ドキュメント数、平均ドキュメントサイズ、データサイズ、インデックス数、インデックスサイズ、インデックス定義です。

これがDMAによって作成されたサンプルのデータベースレベルの移行スプレッドシートである、データ資産スプレッドシートの例です。

手動検出

または、上記のサンプルスプレッドシートを参照し、同様のドキュメントを自分で作成することもできます。

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

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

移行前の評価

次に、移行計画の前段階として、移行のためのデータ資産内のリソースの準備状況を評価します。

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

Database Migration Assistantを使用したプログラムによる評価

Database Migration Assistant (DMA) は、移行前計画の評価段階にも役立ちます。

DMAのセットアップと実行方法については、「Database Migration Assistantを使用したプログラムによる検出」セクションを参照してください。

DMAノートブックは、ソースMongoDBから収集するリソースリストに対していくつかの評価規則を実行します。 評価結果には、移行を続行するために必要な変更と推奨される変更が一覧表示されます。

結果はDMAノートブックの出力として印刷され、CSVファイルassessment_result.csvに保存されます。

注意

Database Migration Assistantは、移行前の手順を支援するための暫定的なユーティリティです。 エンドツーエンドの評価は実行されません。 DMAの実行に加えて、サポートされている機能と構文Cosmos DBの制限とクォータを詳細に調べ、実際の移行の前に概念実証を実行することもお勧めします。

移行前のマッピング

検出と評価の手順が完了すれば、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 リソースの名前付け規則を設定します。 データベースやコレクションの構造に変更が無い限り、通常は、同じリソース名を維持することをお勧めします。
  • 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 Capacity Calculator を使用すると、データベース アカウントの構成、データの量、ドキュメント サイズ、1 秒あたりの必要な読み取りと書き込みに基づいて、要求ユニットの量を確認できます。

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

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

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

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

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

    db.runCommand({getLastRequestStatistics: 1})

    このコマンドでは、以下のような JSON ドキュメントが出力されます。

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

  • 診断設定を使用して、Azure Cosmos DB に対して実行されるクエリの頻度とパターンを理解することもできます。 診断ログの結果は、ストレージ アカウント、EventHub インスタンスまたは 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 Bulk Executor ライブラリを使用します
    • 大規模なデータセットに適し、ライブ変更のレプリケーションを処理します
    • 他の MongoDB ソースでのみ機能します
    オフライン Azure Database Migration Service • Azure Cosmos DB Bulk Executor ライブラリを使用します
    • 大規模なデータセットに適し、ライブ変更のレプリケーションを処理します
    • 他の MongoDB ソースでのみ機能します
    オフライン Azure Data Factory • セットアップが簡単で、さまざまなソースをサポートします
    • Azure Cosmos DB Bulk Executor ライブラリを使用します
    • 大規模なデータセットに適しています
    • チェックポイントがなく、移行の途中で問題が発生した場合、移行プロセスを全部やり直す必要があります
    • 配信不能キューがなく、エラーが含まれるファイルがいくつかあっただけで移行プロセス全体が停止することがあります
    • 特定のデータ ソースの読み取りスループットを向上させるためのカスタム コードが必要です
    オフライン 既存の Mongo ツール (mongodump、mongorestore、Studio3T) • セットアップと統合が簡単です
    • スロットルのカスタム処理が必要です
    オフライン/オンライン Azure Databricks と Spark • 移行速度とデータ変換を完全に制御
    • カスタム コーディングが必要
    • リソースをオフラインで移行することが可能な場合は、以下の図を参考に適切な移行ツールを選択してください。

    オフラインの移行ツール。

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

    オンラインの移行ツール。

    前述の移行ソリューションの概要とデモについては、この動画をご覧ください。

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

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

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

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

移行の種類

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

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

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

特定の MongoDB バージョンから移行する場合、サポートされるツールは以下のとおりです:

移行ツールでサポートされている MongoDB バージョン。

移行後

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

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

次の手順