MongoDB から Azure DocumentDB にデータを移行するオプションは何ですか?

この記事は、MongoDB から Azure DocumentDB への移行の計画と実行に役立ちます。 利用可能な移行ツール、移行の主要なフェーズ、およびリスクを軽減し、ダウンタイムを最小限に抑えるためのベスト プラクティスについて説明します。

オンプレミスの MongoDB サーバー、クラウドホスト型 VM、またはマネージド MongoDB サービスから移行する場合でも、この記事の移行オプション、ガイダンス、ベスト プラクティスが適用されます。

主要な移行フェーズ

移行が成功した場合は、これらの個別のフェーズに従います。 各フェーズには、特定の目標と成功基準があります。

1. 評価

Azure DocumentDB Migration 拡張機能を使用して、ソース MongoDB の自動スキャンを実行して、サポートされていない機能、コマンド、クエリ構文、インデックスの種類を特定します。 評価では、MongoDB のバージョン、ライセンス、インスタンスの種類、データベースとコレクションのメトリックの概要も示します。 これらの結果を使用して、スキーマの変更を計画し、移行前に必要なリファクタリングを特定します。

ヒント

サポートされている MongoDB クエリ言語 (MQL) の機能と構文を詳細に確認し、実際の移行の前に概念実証を実行することをお勧めします。

2. 準備する

評価レポートを分析し、ソース TPS (1 秒あたりのトランザクション数) を測定します。 代表的なデータに対して試用版の移行を実行して、ターゲットのコンピューティング 層、ストレージ層、シャード数を確立します。 パフォーマンス テストを実施して、ターゲット構成が要件を満たしていることを確認します。

3. 絞り込み

運用クエリ パターンに一致する適切なシャード キーとインデックスを使用してターゲット コレクションを準備します。 複数のシャードを使用する場合は、負荷を分散し、シャード間の操作を最小限に抑えるために、コレクションをシャード間で分散する方法を決定します。

4. 移行

移行ジョブを実行して、オフライン モードまたはオンライン モードでデータを移動します。

  • オフライン移行: 開始時にソースのスナップショットを取得し、ターゲットに一括コピーします。 スナップショットのコピー後にソースで追加、更新、または削除されたデータはコピーされません。 必要なダウンタイムは、一括コピーにかかる時間によって異なります。
  • オンライン移行: オフラインと同じ一括コピーを実行しますが、プロセス全体の変更ストリームも監視します。 移行中に行われた変更はターゲットにレプリケートされるため、必要なアプリケーションのダウンタイムは最小限です。 ソースには変更ストリームと十分に大きなオプログが必要です。

ヒント

オンライン移行の場合は、変更ストリームが有効になっており、移行期間中のすべての変更をキャプチャするために、ソース MongoDB で操作ログのサイズが適切に設定されていることを確認します。

使用可能なツールについては、「 移行ツール」を参照してください。

5. 検証

最新の更新プログラムを含め、すべてのデータがコピーされたことを検証します。 ドキュメントの数を比較し、サンプル ベースの検証を実行し、インデックスとデータ構造がターゲットの期待値と一致することを確認します。 自動スクリプトを使用して、検証を繰り返し可能で一貫性のあるものにします。

6. カットオーバー

読み取りトラフィックをターゲットに移動し、機能またはパフォーマンスの問題がないことを確認します。 読み取り検証が成功したら、書き込みトラフィックをターゲットに移動します。 カットオーバー 期間中に異常が発生した場合は、注意深く監視します。

移行ツール

この記事で説明するツールは、次のソースから MongoDB ワークロードを移行する際に役立ちます。

  • MongoDB 仮想マシン
  • MongoDB Atlas
  • AWS DocumentDB

Azure DocumentDB 移行拡張機能

Visual Studio CodeAzure DocumentDB Migration Extension (Public Preview)を使用して移行ジョブを作成および管理します。これは、シンプルさ、セキュリティ、そしてダウンタイムなしのために設計されたソリューションです。

このツールは、サービスを中断することなくワークロードを移行するのに役立つ、明確で詳細なガイダンスを提供します。 次のようにすることができます。

  • 移行する特定のデータベースとコレクションを選択する
  • 使い慣れた VS Code インターフェイス内のすべての手順を実行する
  • プロセス全体を通じて セキュリティで保護された接続 を確保する
  • 拡張機能を使用するための ゼロ コスト をお楽しみください

Azure DocumentDB 移行拡張機能を使用すると、インフラストラクチャや複雑さを増すことなく、制御とセキュリティを維持しながら移行の過程を効率化できます。

Web アプリ ユーティリティ (オンライン)

効率、信頼性、使いやすさのために設計されたツールMongoMigrationwebBasedUtilityを使用して、Azure DocumentDB への移行を効率化します。 リポジトリには、ワークロードを移行するための詳細な手順が用意されています。 このツールは、オンラインとオフラインの両方のデータ移行にシームレスなエクスペリエンスを提供します。 このプロセスはユーザー フレンドリであり、ソースとターゲットの詳細のみを指定する必要があります。 これにより、制御、セキュリティ、スケーラビリティを維持しながら MongoDB コレクションを簡単に移行でき、Azure DocumentDB の可能性を最大限に引き出します。

主な機能は次のとおりです。

  • セキュリティを強化するために、仮想ネットワーク内のプライベートデプロイをサポートします
  • 接続の損失または一時的なエラーがある場合の自動再開機能
  • ユーザーフレンドリなインターフェイス
  • GitHubでの C# ソース コードへのアクセス

このツールは柔軟なデプロイ オプションをサポートし、他のAzure リソースに依存せずに独立して動作します。 さらに、カスタマイズ可能なAzure Web アプリの価格プランでスケーラブルなパフォーマンスを提供します。

ネイティブ MongoDB ツール (オフライン)

mongodump/mongorestoremongoexport/mongoimport などのネイティブ MongoDB ツールを使用して、データセットをオフライン (ライブ変更をレプリケートせずに) Azure DocumentDB オファリングに移行することもできます。

Scenario MongoDB ネイティブ ツール
データベース データのサブセットを移動する (JSON/CSV ベース) mongoexport と mongoimport
データベース全体を移動する (BSON ベース) mongodump と mongorestore
  • "mongoexport と mongoimport" は、MongoDB データベースのサブセットを移行するための最適な移行ツールのペアです。
    • mongoexport は、既存のデータを人間が判読できる JSON ファイルまたは CSV ファイルにエクスポートします。 mongoexport は、エクスポートする既存のデータのサブセットを指定する引数を受け取ります。
    • mongoimport は JSON または CSV ファイルを開き、その内容をターゲット データベース インスタンス (この場合は DocumentDB Azure) に挿入します。
    • JSON と CSV はコンパクトな形式ではありません。mongoimportが DocumentDB にデータを送信すると、過剰なネットワーク料金 Azureが発生する可能性があります。
  • "mongodump と mongorestore" は、MongoDB データベース全体を移行するための最適な移行ツールのペアです。 コンパクトな BSON 形式では、データが DocumentDB に挿入されるため、ネットワーク リソースAzure効率的に使用できます。
    • mongodump は、既存のデータを BSON ファイルとしてエクスポートします。
    • mongorestore は、BSON ファイル ダンプを DocumentDB Azureインポートします。

MongoDB ネイティブ ツールでは、ホスト ハードウェアで可能な速度でのみデータを移動できます。

移行のベスト プラクティス

これらのベスト プラクティスを使用して、リスクを軽減し、容量をより正確に見積もり、移行速度を向上させ、カットオーバーを安全に実行します。

障害を減らす

  • 接続文字列で URL でエンコードされたパスワードを使用します。 @#:などの特殊文字は、エンコードされていない場合に解析を中断する可能性があります。 URL エンコードは、評価と移行の実行中に接続エラーを回避するのに役立ちます。

  • 移行前に事前移行評価を実行します。 評価は、サポートされていない機能、互換性のギャップ、潜在的な阻害要因を早期に特定するのに役立ちます。 移行前に結果を解決して、カットオーバー中の再作業を減らします。

  • 本番環境の前に移行とカットオーバーをテストします。 非運用環境で 1 つ以上のリハーサル移行を実行します。 プラクティスにより、生産カットオーバー中のタイミングの精度、チームの準備性、信頼性が向上します。

インフラストラクチャのサイズを正確に設定する

  • 小規模で代表的なデータセットに対して試用版の移行を実行します。 試用版を使用して、現実的なスループット、待機時間、およびリソースの消費量をキャプチャします。 代表的なサンプルは、合成テスト データよりも適切な見積もりを提供します。

  • 試用結果を推定して、コンピューティング レベル、ストレージ層、シャード数を見積もります。 観察された試用メトリックを使用して、完全なデータセット ボリュームに基づいて最終的なサイズ設定のニーズを予測します。 運用環境のデータ分布がサンプルと異なる場合は、見積もりを見直します。

  • 運用環境に似た設定で、代表的なドキュメント数、サイズ、構造を使用します。 コストや移行期間を過小評価しないように、試用中に運用インデックス作成とシャーディングの設定を一致させます。 非運用環境の設定では、誤解を招く結果が生じる可能性があります。

  • ソースとターゲットのサイズが等しいと想定するのではなく、試用結果からターゲット ストレージを見積もります。 ソースとコピー先のストレージフットプリントは、インデックス定義とデータ レイアウトの違いにより異なる場合があります。 試用結果を使用して、安全なバッファーを使用してストレージを計画します。

移行速度を最適化する

  • 可能な場合は、同じリージョン内で移行します。 ソースとターゲットを同じリージョンに保持すると、ネットワークの待機時間が短縮され、データ転送のパフォーマンスが向上します。 また、リージョン間のデータ転送コストを削減することもできます。

  • 移行中にスケールアップし、カットオーバー後にスケールダウンします。 たとえば、移行スループットを向上させるために、ターゲット クラスターを一時的に M200 にスケーリングできます。 移行後、安定した状態のワークロードでサポートされている範囲内の適切なレベルにスケールダウンします。

  • 書き込みを高速化するために、IOPS が高いディスクを選択します。 IOPS が高いほど、書き込み負荷の高い移行パフォーマンスが大幅に向上します。 通常、ディスク サイズは後でスケールダウンできないため、計画中はディスク サイズを慎重に選択してください。

カットオーバーを慎重に計画する必要があります、なぜならロールバックができないからです

  • トラフィックの少ない時間帯のダウンタイムを計画します。 必要なダウンタイムは、移行が追いついた後の検証手順にかかる時間によって異なります。 トラフィックが少ない期間では、ビジネスへの影響が軽減されます。

  • カットオーバーの直前にソースへのすべての書き込みを停止します。 この手順により、ソースとターゲットの間の最後の分の相違が防止されます。 カットオーバーを完了する前に、書き込みアクティビティが完全に一時停止されていることを確認します。

  • 書き込みを移動する前に、移行されたデータを検証します。 ドキュメント数を比較してから、ランダムサンプルドキュメント比較 (ハッシュベースのチェックなど) を実行します。 可能な場合はスクリプトを使用して、検証を繰り返し可能にします。

  • アプリケーション接続文字列を更新し、ターゲットでテストします。 ターゲットリードとテスト トラフィックに対して機能およびパフォーマンスの検証を実行した後、運用環境で書き込みを有効にします。 クリティカル パスが期待どおりに動作するように確認します。

  • 検証が成功した後にのみ、書き込みトラフィックを移動します。 テスト結果が成功し、一貫性がある場合にのみ、運用環境の書き込みをターゲットにシフトします。 アプリケーション アーキテクチャでサポートされている場合は、段階的なロールアウトを使用します。

シームレスな移行のためにチーム間で調整する

  • すべての利害関係者、すなわちアプリ、データ、インフラストラクチャ、セキュリティ、ネットワーク、管理チームからの合意を確保します。 期待と責任を早期に調整します。 共有所有権により、実行中の誤解と遅延が軽減されます。

  • 計画と試用の実行を使用して、チームの信頼度を高め、手順を調整します。 スムーズな移行へのショートカットはありません。 試行では、リスクの低い環境で問題を把握し、チームに練習する機会を提供します。

  • カットオーバーは重要で時間の影響を受けやすいものとして扱います。 カットオーバーには、正確な連携と明確なコミュニケーションが必要です。 意思決定者を指定し、開始する前にエスカレーション パスを確立します。

  • 各ステップを実行するユーザー、実行するタイミング、ダウンタイムを最小限に抑える方法を把握します。 責任を割り当て、タイムラインを確立し、成功基準に合わせます。 切り替えのランブックを文書化し、すべての参加者と共有します。

  • カットオーバーで複数のワークロードの更新が同時に必要な場合は、すべての関係者と調整します。 すべてのチームに対して機能するメンテナンス期間中にカットオーバーをスケジュールします。 金曜日の夜や主要なビジネス イベントに近い期間は避けてください。

  • 急いだり、デューデリジェンスの手順をスキップしたりしないでください。ロールバックはありません。 徹底的な検証と慎重な実行により、コストのかかる間違いを防ぎます。 カットオーバーには時間がかかることを受け入れます。速度に重点を置いたショートカットはリスクを生み出します。