このドキュメントでは、Atlas Live Migration を使用して MongoDB を MongoDB Atlas に移行するのアーキテクチャをデプロイする方法について説明します。
このチュートリアルは、完全ホスト型の MongoDB サービスに関心があるか、MongoDB Atlas クラスタへの MongoDB のレプリカセット内の MongoDB データベース移行を担当している、データベース設計担当者、データベース管理者、データベース エンジニアを対象としています。
アーキテクチャ
次の図は、このチュートリアルで作成するデプロイ アーキテクチャを示しています。
図中の矢印は、Compute Engine で実行されているソース MongoDB レプリカセットから、Google Cloud 上の MongoDB Atlas で実行されているターゲット クラスタへのデータ移行パスを表します。アーキテクチャの詳細については、Atlas Live Migration を使用して MongoDB を MongoDB Atlas に移行するをご覧ください。
目標
- サンプルの MongoDB レプリカセットにドキュメントを作成して読み込むことで、セルフマネージド ソースを設定します。
- MongoDB Atlas で移行先のターゲット クラスタを設定します。
- Atlas Live Migration を使用して、セルフマネージドの MongoDB レプリカセットからフルマネージドの MongoDB Atlas クラスタにデータベースを移行します。
- テスト、カットオーバー、フォールバックの戦略を理解して選択します。
費用
このアーキテクチャのデプロイでは、課金対象である次の Google Cloud コンポーネントを使用します。
このアーキテクチャをデプロイするために、MongoDB Atlas の無料枠は使用できません。無料枠で使用可能なマシンタイプは、Atlas Live Migration には対応していません。最低限必要なマシンタイプ（このドキュメントの執筆時点では M10）には、MongoDB Atlas の 1 時間ごとの料金がかかります。料金の見積もりを生成するには、MongoDB Atlas の料金に移動し、Google Cloud の料金情報を確認してください。この移行を本番環境で実装する場合は、標準でホストされている MongoDB Atlas のバージョンの使用をおすすめします。
このデプロイの終了後は、作成したリソースを削除するとそれ以上の請求が発生しなくなります。詳細については、クリーンアップをご覧ください。
始める前に
Google Cloud コンソールの [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
Google Cloud プロジェクトの課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
セルフマネージド MongoDB レプリカセットの作成
デプロイを開始するには、MongoDB レプリカセットを Google Cloud にインストールします。このデータベースはソース データベースとして機能します。次に、ソース データベースが必要なすべての前提条件を満たしているかどうかを確認します。この前提条件の確認は、本番環境での移行の準備に役立ちます。本番環境に MongoDB レプリカがすでに存在している場合でも、前提条件を確認する必要があります。
前提条件のチェックが完了したら、認証を有効にして、ソース MongoDB インスタンスを再起動する必要があります。最後に、移行をテストするために、ターゲット データベースに移行するソース MongoDB インスタンスにサンプル データセットを追加します。
MongoDB レプリカセットをインストールする
Google Cloud Marketplace で、Compute Engine 上の MongoDB レプリカセットのインストールに移動します。
[運用開始] をクリックします。いくつかの Google Cloud APIs が有効になっているため、起動プロセスに時間がかかることがあります。
複数のプロジェクトに対する権限がある場合は、プロジェクトのリストが表示されます。MongoDB をインストールするプロジェクトを選択します。
MongoDB レプリカセットは、Deployment Manager テンプレートに従って一連の Compute Engine インスタンスにデプロイされます。
すべてのデフォルト設定を使用します。
[デプロイ] をクリックします。
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。
Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
SSH 接続を使用して、MongoDB プライマリを実行する Compute Engine インスタンスにログインします。
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM次のように置き換えます。
MONGODB_VM_NAME: MongoDB レプリカセットのプライマリ レプリカの名前PROJECT_ID: Google Cloud プロジェクトの名前。ZONE_OF_VM: 仮想マシン（VM）インスタンスが存在するゾーン。詳細については、地域とリージョンをご覧ください。
SSH 認証鍵が生成されると、パスフレーズの入力を求められます。パスフレーズを指定しない場合は、
Enterを押します。パスフレーズを指定する場合は、後で参照できるようメモしておいてください。Cloud Shell を使用して接続できない場合は、Deployment Manager で [サーバーの階層 VM への SSH] をクリックします。
mongoシェルを起動します。mongo既存のデータベースを一覧表示します。
show dbs出力は次のようになります。
admin 0.000GB config 0.000GB local 0.000GB今後のコマンドに備えて、
mongoシェルは開いたままにしておきます。
これで、MongoDB レプリカセットを作成してアクセスし、動作していることを確認できました。
ソース データベースの前提条件を確認する
Atlas Live Migration では、ソース MongoDB レプリカセットが特定の構成条件または前提条件を満たしている必要があります。このデプロイでインストールするソース MongoDB レプリカセットは、必要なバージョンを遵守していますが、本番環境ではチェックが必要です。前提条件のチェックについては、Atlas のドキュメントをご覧ください。
すべての前提条件が満たされているかどうかを確認するには、次の手順を行います。
mongoシェルで、MongoDB のバージョンが 2.6 以降であることを確認します。（本番環境のデータベース インスタンスでは、mongoシェルを開き、SSH 接続を使用して MongoDB サーバーに接続してから、次のコマンドを実行してバージョンを確認します）。db.version()出力にバージョンが表示されます。バージョンが 2.6 より前の場合は、アップグレードの手順に従う必要があります。
現在のデプロイが MongoDB レプリカセットであることを確認します。
rs.status()出力は、MongoDB レプリカセットのステータスです。次の出力は、MongoDB インスタンスが MongoDB レプリカセットをアクティブ化せずに開始したことを表します。
{ "ok" : 0, "errmsg" : "not running with --replSet", "code" : 76, "codeName" : "NoReplicationEnabled" }この場合、MongoDB レプリカセットを有効にして、MongoDB インスタンスを停止して再起動します。MongoDB のスタンドアロン インスタンスがある場合は、MongoDB レプリカセットに MongoDB インスタンスをアップグレードします。
ログインして次の手順を行い、ソースクラスタで認証が有効になっていることを確認します。
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin次のように置き換えます。
YOUR_ADMIN_USERNAME: デプロイの管理者ユーザー名
これより前に作成した MongoDB レプリカセットでは、認証が有効になっていません。
認証が有効になっていない場合は、認証を有効にする手順に沿う必要があります。認証を有効にするコマンドの例を次に示します。この例では、ユーザー名とパスワードを使用します。
use admin db.createUser( { user: "myUserAdmin", pwd: "myUserAdminPassword", roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase", "clusterMonitor" ] } )認証を有効にした後、
rs.status()を実行するには MongoDB のロールclusterMonitorが必要です。上記のコマンドでは、このロールを指定します。管理者ユーザーに、MongoDB レプリカセットのバージョンに応じた適切なロールが割り当てられていることを確認します。特定のバージョンに対応する役割のリストについては、Atlas Live Migration ドキュメントのソースクラスタのセキュリティに関する説明をご覧ください。
use admin db.getUser("YOUR_ADMIN_USERNAME")ユーザー名は引用符で囲む必要があります。
（省略可）MongoDB のデプロイが 4.2 より前のバージョンに基づく場合、1,024 バイトのインデックス キーの上限を超えるキーを使用するインデックスが含まれます。この場合、Atlas Live Migration の手順を開始する前に、MongoDB サーバー パラメータ
failIndexKeyTooLongをfalseに設定します。
前提条件を確認し必要な変更を行ったら、構成を完了してデータベースを再起動します。これは、次のセクションで説明します。
認証を有効にして MongoDB レプリカセットを再起動する
認証を有効にするには、鍵ファイルと管理者を作成します。本番環境では、スクリプトを使用してプロセスを自動化できます。
Cloud Shell で、鍵ファイルを作成します。
openssl rand -base64 756 > PATH_TO_KEY_FILE次のように置き換えます。
PATH_TO_KEY_FILE: SSH 認証鍵が格納されているロケーション（例:/etc/mongo-key）。
3 つの各 VM の承認を有効にします。
鍵ファイルを VM にコピーします。
gcloud compute copy-files PATH_TO_KEY_FILE NAME_OF_THE_VM:PATH_TO_KEY_FILE --zone=ZONE_OF_VM次のように置き換えます。
NAME_OF_THE_VM: レプリカセットのレプリカを実行している VM のうちの 1 つの名前。ZONE_OF_VM:NAME_OF_THE_VMで参照される VM が存在する Google Cloud ゾーン
SSH 接続を使用して VM にログインし、鍵ファイルの所有者とアクセス権限を変更します。
sudo chown mongodb:mongodb PATH_TO_KEY_FILE sudo chmod 400 PATH_TO_KEY_FILE任意のテキスト エディタで、
mongod.confファイルを編集モードで開きます。変更を元に戻すには、sudoコマンドを使用してテキスト エディタを起動することが必要な場合があります。mongod.confファイルのsecurityセクションを編集します。security: authorization: enabled keyFile: PATH_TO_KEY_FILEレプリカを再起動します。
sudo service mongod restart
MongoDB レプリカセットのプライマリにログインできることを確認します。
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
サンプルデータを挿入する
次の手順では、サンプルデータをソース データベースに挿入し、ドキュメントが正常に挿入されたことを確認します。
Cloud Shell で、
sshを使用して MongoDB プライマリ Compute Engine インスタンスに接続します。gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VMSSH 認証鍵のパスフレーズの指定が必要な場合があります。
mongoシェルを起動します。mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin管理者ユーザー名の作成時に指定したパスワードを入力します。
データベースを作成します。
use migrationコレクションを作成します。
db.createCollection("source")コレクションが空であることを確認します。
db.source.count()次の 5 つのドキュメントを初期データセットとして追加します。
db.source.insert({"document_number": 1}) db.source.insert({"document_number": 2}) db.source.insert({"document_number": 3}) db.source.insert({"document_number": 4}) db.source.insert({"document_number": 5})これらの各コマンドの出力は、次のようになります。
WriteResult({ "nInserted" : 1 })コレクションの移行に 5 つのドキュメントを正常に追加できたことを確認します。結果は 5 である必要があります。
db.source.count()データベースの移行をセットアップして開始すると、これらのドキュメントは MongoDB Atlas のターゲット クラスタに移行されます。
MongoDB Atlas にクラスタを作成する
MongoDB レプリカセットは、MongoDB Atlas でクラスタと呼ばれます。クラスタがターゲット データベースとしてセットアップされていない場合は、このセクションの手順を行ってください。これらの手順は、MongoDB のドキュメントに基づいています。すでにクラスタをターゲット データベースとして設定している場合は、このセクションをスキップできます。
Cloud Marketplace で、MongoDB Atlas - 無料枠のインストールページに移動します。
[Visit MongoDB Site to Sign Up] をクリックします。
[Launch your first cluster] をクリックします。
必要な情報を入力して [Get started free] をクリックします。入力した情報をメモします。
[Advanced Configuration Options] をクリックします。
[Cloud Provider & Region] で、[Google Cloud Platform] と [Iowa (us-central1)] を選択します。
[Cluster Tier] タブをクリックし、[M10] を選択します。
[Additional Settings] タブをクリックし、[MongoDB 4.0 or MongoDB 4.2] を選択して、バックアップをオフにします。
[Create Cluster] をクリックします。
クラスタの作成が完了するまで待ちます。プロジェクト名は
Project 0（空白スペースあり）、クラスタ名はCluster0（空白なし）です。
ターゲット クラスタは MongoDB Atlas でセットアップされ、実行されています。
MongoDB Atlas クラスタのフェイルオーバーをテストする
移行が完了すると、MongoDB Atlas のクラスタによってローリング再起動が実行されます。各クラスタ メンバーが順番に再起動します。このプロセスが機能していることを確認するには、フェイルオーバーをテストします。
ライブ マイグレーションを開始する
移行元から移行先のデータベースにデータを移行するには、次の手順を行います。
MongoDB Atlas にログインします。
[Clusters] ページに移動し、移行先のクラスタを選択します。
ターゲット クラスタ（
Cluster 0）ペインで、 をクリックします。[Migrate Data to this Cluster] を選択します。
表示されたウィンドウで情報を確認します。移行の準備ができたら、[I'm ready to migrate] をクリックします。
データの移行手順を示すウィンドウが表示されます。リスト上の IP アドレスが MongoDB レプリカセットにアクセスできる必要があります。これらのアドレスに対してファイアウォール ルールを作成していない場合、Cloud Shell を使用し、次のコマンド例に基づいてファイアウォール ルールを追加します。
gcloud compute firewall-rules create "allow-mongodb-atlas" --allow=tcp:27027 --source-ranges="35.170.231.208/32,3.92.230.111/32,3.94.238.78/32,54.84.208.96/32" --direction=INGRESS[Hostname:Port of the primary of your replica set] フィールドに、MongoDB レプリカセットのプライマリ IP アドレスとポートを入力します（
IP_ADDRESS:PORT_FOR_PRIMARYなど）。プライマリ インスタンスを確認するには、Google Cloud プロジェクトで実行されているいずれかのインスタンスの
mongoシェルで次のコマンドを実行します。rs.isMaster().primary対応する外部 IP アドレスを調べるには、Compute Engine の [VM instances] ページに移動します。標準の MongoDB ポートは
27017です。
MongoDB レプリカセットの管理者ユーザー名とパスワードを入力します。その他のすべての設定は、デフォルト値のままにします。
[Validate] をクリックして、次のいずれかを行います。
- 検証が成功したら、[Start Migration] をクリックします。
- 検証が成功しない場合は、提供された手順でトラブルシューティングを行います。たとえば、MongoDB Atlas を MongoDB レプリカセットに接続できない場合は、MongoDB Atlas が使用しようとしている接続元 IP アドレスが表示されます。これらのアドレスに対して、MongoDB レプリカセットのサーバー用のポート
27017で TCP トラフィックを許可するファイアウォール ルールを追加します。
MongoDB Atlas 画面に検証の進行状況が表示されます。進行状況バーに「Initial Sync Complete!」というメッセージが表示されるまで待ちます。
これで、MongoDB レプリカセットからの初期読み込みが完了しました。次のステップでは、初期読み込みが成功したことを確認します。
最初の移行が完了した後、MongoDB Atlas は、ターゲット クラスタへのカットオーバーの期限までの残り時間の予測を提供します。また、残り時間数や延長時間、指定された時間内に最終的なカットオーバーが行われなければ移行がキャンセルされるという内容を知らせる警告メールが MongoDB から届く場合もあります。
データベースの移行を確認する
データベースの移行が成功したかどうかを確認するデータベース移行検証戦略を設計、実装することは重要です。実際の検証戦略は個々のユースケースによって異なりますが、次のチェックを行うことをおすすめします。
- 完全性チェック。最初のドキュメント セットがソース データベースから正常に移行されたことを確認します（初期読み込み）。
- 動的チェック。ソース データベースの変更がターゲット データベースに転送されていることを確認します（進行中の移行）。
まず、初期読み込みが成功したことを確認します。
[MongoDB Atlas] で [Clusters] をクリックします。
[Collections] をクリックします。
migrationsという名前のデータベースが存在し、sourceという名前のコレクションに 5 つのドキュメントがあることを確認します。
次に、ソース データベースへの進行中の変更がターゲット データベースに反映されていることを確認します。
Cloud Shell で、SSH 接続を使用してソース MongoDB レプリカセットのプライマリ VM にログインします。
mongoシェルを起動します。mongo別のドキュメントを挿入します。
use migration db.source.insert({"document_number": 6})移行コレクションの [MongoDB Atlas Collections] ページで、[Refresh] をクリックして、コレクション
sourceに 1 つのドキュメントが追加されていることを確認します。
これで、Atlas Live Migration によってソースの元のデータがすべて移行され、ソースに進行中の変更が自動的に適用されることを確認できました。
Atlas ターゲット クラスタをテストする
本番環境では、ターゲット データベースにアクセスするアプリケーションをテストして、正しく機能することを確認する必要があります。このセクションでは、いくつかのテスト戦略について説明します。
ターゲット データベースを使用して移行中にアプリケーションをテストする
前のセクションで説明したように、データベース移行の進行中にアプリケーションのテストを実行できます。このアプローチは、アプリケーションがソース データベースから移行されるデータと矛盾するかたちでターゲットを変更しない場合に有効です。このアプローチは環境や依存関係によって省略することもできます。テスト アプリケーションがターゲット データベースにデータを書き込むと、進行中の移行で競合が発生する可能性があります。
一時的なターゲット データベースを使用してアプリケーションをテストする
本番環境でのデータベースの移行中にアプリケーションをテストできない場合は、テスト専用の一時的なターゲット データベースにデータを移行し、テスト移行後にテスト ターゲットを削除します。
この方法では、ある時点でテスト移行を停止し（データベースの移行が完了したかのように）、これらのテスト データベースに対してアプリケーションをテストします。テストが完了したら、前述のターゲット データベースを削除して本番環境のデータベースの移行を開始し、データを永続的なターゲット データベースに移行します。この戦略の利点は、テスト専用のため、ターゲット データベースの読み取りや書き込みができることです。
移行完了後にターゲット データベースを使用してアプリケーションをテストする
前述のどちらの戦略も実行できない場合、移行の完了後にデータベース上でアプリケーションをテストする戦略があります。すべてのデータがターゲット データベースに格納されたら、ユーザーに提供する前にアプリケーションをテストします。テストにデータの書き込みを含める場合は、本番環境のデータの不整合を避けるため、本番環境データではなく、テストデータを書き込むことが重要です。ターゲット データベースにデータの不整合や不要なデータが発生しないように、テストの完了後にテストデータを削除する必要があります。
ターゲット データベースは、アプリケーション システムから本番環境にアクセスする前にバックアップすることをおすすめします。この手順により、必要に応じて再作成可能な、一貫した開始点を設定できます。
ソース MongoDB レプリカセットからターゲット クラスタに切り換える
テストを完了し、進行中の変更がターゲット データベースに反映されていることを確認したら、カットオーバーを計画できます。
まず、Atlass Live Migration が移行していない変更をターゲットにドレインできるよう、ソース データベースの変更を停止する必要があります。すべての変更がターゲットに取り込まれたら、Atlas Live Migration のカットオーバー プロセスを開始できます。このプロセスが完了したら、クライアントをソースからターゲット データベースに切り替えます。
[MongoDB Atlas] で [Clusters] をクリックします。
[
Cluster0] ペインで、[Prepare to Cutover] をクリックします。カットオーバー プロセスのステップごとの説明と、ターゲット クラスタへの接続文字列が表示されます。[Cut over] をクリックします。
移行が完了すると、「Success! Your cluster migration is complete.」というメッセージが表示されます。
これで、MongoDB レプリカセットを MongoDB Atlas クラスタに正常に移行できました。
フォールバック戦略を準備する
カットオーバーが終了すると、ターゲット クラスタが記録システムになります。それによって、ソース データベースは期限切れとなり、最終的に削除されます。ただし、新しいターゲット データベースで重大な障害が発生した場合は、ソース データベースにフォールバックすることもできます。たとえば、アプリケーションのビジネス ロジックがテスト中に実行されず、後で正しく機能していない場合、エラーが発生する可能性があります。パフォーマンスやレイテンシの動作がソース データベースと一致せず、エラーが発生する場合もあります。
このようなエラーの際にフォールバックするには、ターゲット データベースの変更とともに元のソース データベースを最新の状態に保つことをおすすめします。Atlas Live Migration ではフォールバック メカニズムを使用できません。フォールバックの戦略について詳しくは、データベースの移行: コンセプトと原則（パート 2）をご覧ください。
クリーンアップ
以降のセクションでは、このデプロイで使用した Google Cloud プロジェクトと MongoDB リソースについて、今後料金が発生しないようにする方法について説明します。
Google Cloud プロジェクトを削除する
このデプロイで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、Google Cloud プロジェクトを削除します。
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
MongoDB Atlas クラスタを一時停止または終了する
MongoDB Atlas クラスタの課金を回避するには、クラスタを一時停止または終了する必要があります。課金への影響について詳しくは、クラスタの一時停止または終了をご覧ください。
次のステップ
- Google Cloud のデータ移行コンテンツを確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。