MongoDB 6.0.13+ または 7.0.8+ のライブ移行(プル) Atlas へのクラスター化

ネットワーク アクセス

以下のコンポーネントのネットワーク権限を設定します。

移行前の検証

次のライブ移行手順を開始する前に、Atlas はソースクラスターと宛先クラスターの検証チェックを実行し、次のことを確認します。

• ソースクラスターと宛先クラスターの MongoDB バージョンは、少なくともFCV 6.0.13 + と一致しているか、少なくともFCV 7.0.8 + と 一致しています。

• ソースクラスターのデータベースユーザーには、「ソースクラスターのセキュリティ 」で説明されている適切な権限があります。

ソースクラスタのセキュリティ

さまざまな組み込みロールによって、十分な権限が付与されます。以下に例を挙げます。

ソース レプリカセット クラスターの場合、MongoDB ユーザーはreadAnyDatabase } ロールとbackupロールを持っている必要があります。

ソース シャーディングされたクラスターの場合、MongoDB ユーザーにはreadAnyDatabase 、 backup 、およびclusterMonitorロールが必要です。

ライブ移行プロセスを実行するデータベースユーザーがこれらのロールを持っていることを確認するには、 adminデータベースでdb.getUser()コマンドを実行します。 たとえば、レプリカセットの場合は、次を実行します。

use admin
db.getUser("admin")
{
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
  {
    "role" : "backup",
    "db" : "admin"
  },
  {
    "role" : "readAnyDatabase",
    "db" : "admin"
  }
 ]
} ...

ライブ移行手順のウォークスルー画面でプロンプトが表示されたら、Atlas にユーザー名とパスワードを指定します。

Atlas は、認証を強制するソースクラスターへの接続には SCRAM のみサポートします。

MongoDB のライブ移行サーバーの保護方法

Atlas へのプル タイプのライブ移行は、ライブ移行を実行するサーバーをAtlas が管理し、ソースから宛先クラスターにデータを送信します。

MongoDB では、Atlas に送信されるデータの整合性と機密性を保護するために、次の措置を講じています。

• MongoDB では、Atlas が管理するライブ移行サーバーと宛先クラスター間で転送されるデータは暗号化されます。ソースクラスターと Atlas が管理する移行サーバー間で転送されるデータの暗号化が必要な場合は、ソースクラスターで TLS を設定します。

• MongoDB では、Atlas の他の部分へのアクセスが保護されるのと同様に、Atlas が管理する移行サーバー インスタンスへのアクセスが保護されます。

• クリティカルなサービスの調査や復旧のために介入が必要となる稀なケースでは、MongoDB は最小権限の原則に準じ、クリティカルな問題を修復するために必要最小限の限られた時間だけ、少数の権限ユーザーのグループにお客様の Atlas クラスターへのアクセスを許可します。MongoDB では、これらのユーザーは Atlas クラスターにログインし、要塞ホスト経由で SSH 接続を確立するために MFA が必要です。この種の権限ユーザーにアクセス権を付与するには、MongoDB 上級管理職の承認が必要です。MongoDB では、他のいかなる MongoDB 担当者による、お客様の MongoDB Atlas クラスターへのアクセスは許可されていません。

• MongoDB では、特権アクティビティでのみ特権ユーザー アカウントの使用が許可されます。 非特権アクティビティを実行するには、特権ユーザーは別のアカウントを使用する必要があります。 特権ユーザー アカウントでは、共有認証情報を使用できません。 特権ユーザー アカウントは、 Atlas セキュリティのホワイトペーパーのセクション4.3.3に記載されているパスワードの要件に従う必要があります。

• Atlas では、権限ユーザーを含むすべての MongoDB 担当者による、お使いのクラスターへのアクセスを制限することができます。お客様がそのようなアクセス制限をすることを選択し、MongoDB がお問い合わせの問題を解決するためにアクセスが必要であると判断した場合、MongoDB はまずお客様へアクセス許可をリクエストする必要があります。そしてお客様は、最大 24 時間の権限ユーザーアクセスを一時的に復元するかどうかを決定できます。一時的な 24 時間のアクセス許可はいつでも取り消すことができます。この制限を有効にすると、お問い合わせの問題への対応とその解決にかかる時間が長くなり、その結果、Atlas クラスターの可用性に悪影響を及ぼす可能性があります。

• MongoDB では、権限ユーザーのアクセス承認を四半期ごとに確認します。さらに MongoDB では、不要となった権限ユーザーのアクセス権を取り消します。権限ユーザーのロールが変更となったり、会社を退職した場合は、 24 時間以内にアクセス権を取り消します。また、MongoDB の担当者によるお客様の Atlas クラスターへのアクセスを記録し、タイムスタンプ、アクター、アクション、出力を含んだ監査ログを少なくとも 6 年間保持します。MongoDBは、自動レビューと手動レビューの組み合わせを使用して、これらの監査ログを精査します。

Atlas セキュリティの詳細については、 Atlas セキュリティのホワイトペーパーを参照してください。特に、「MongoDB Atlas クラスターへの MongoDB 担当者のアクセス」セクションを確認してください。

ネットワークの暗号化

プル型のライブ移行中、ソースクラスターが自身のデータに対して TLS 暗号化を使用しない場合、ソースクラスターから Atlas へのトラフィックは暗号化されません。これが受け入れられるかどうかを、プル型のライブ移行手順を開始する前に判断してください。

データベースユーザーとロール

Atlas は、いかなるユーザー データーまたはロール データも宛先クラスターに移行しません。

ソースクラスターが認証を使用しない場合、Atlas でユーザーを作成する必要があります。Atlas では認証無しの実行がサポートされないためです。

ソースクラスターが認証を強制する場合、アプリケーションが宛先の Atlas クラスターで使用する認証情報を再び作成する必要があります。Atlas ではユーザー認証に SCRAM が使用されます。詳細については、「データベースユーザーの設定」を参照してください。

ソースクラスターと宛先クラスターのバランサー

移行中の書込みパフォーマンスへの影響を回避するため、Atlas は手順の開始時にソースクラスターと宛先クラスターのシャーディングされたクラスターのバランサーを停止し、手順の最後にバランサーを起動します。

ライブ移行をキャンセルすると、Atlas はソースクラスターと宛先クラスターのバランサーを再起動します。

Atlas がライブ移行の成功の最後にソースクラスターまたは宛先クラスターのロード バランサーを再起動できない場合、警告バナーはソースまたは宛先クラスターのバランサーを手動で再起動する必要があることを示します。

宛先クラスターの構成

宛先クラスターを構成する際には、次の点を考慮してください。

• ライブ移行プロセスでは、MongoDB が管理するライブ移行サーバーを介してデータがストリーミング転送されます。各サーバーは、ソースクラスターに最も近いリージョンでホストされているインフラストラクチャ上で動作します。次のリージョンがご利用いただけます。

  ヨーロッパ

  • フランクフルト

  • アイルランド

  • London

  Americas

  • アメリカ東部

  • アメリカ西部

  APAC

  • ムンバイ

  • 香港

  • シドニー

  • Tokyo

• Atlas の宛先クラスターには、アプリケーションサーバーまたはソースクラスターでホストされている配置と比較して、ネットワークレイテンシーが最も低いクラウドリージョンをお使いください。理想的なのは、アプリケーションのサーバーは、宛先の Atlas クラスターのプライマリ リージョンと同じリージョンのクラウドで実行されていることです。詳細については、「クラウドプロバイダー」を参照してください。

• Atlas の宛先クラスターは、RAM、CPU、およびストレージの点でソースとなる配置と同じかそれを上回る必要があります。移行プロセスと予想されるワークロードの両方に対応できるように、適切なサイズの宛先クラスターをプロビジョニングするか、宛先クラスターをより処理能力、帯域幅、またはディスク IO のある階層にスケールアップします。

• 移行のパフォーマンスを最大化するには、宛先クラスターに少なくとも 1 つの M40 クラスターを使用してください。大規模なデータセットを移行する場合は、6000 IOPS 以上のディスクを搭載した M80 クラスターを使用してください。

  移行プロセスの実行中に宛先 Atlas クラスターのサイズを一時的に増やすことも選択できます。

  アプリケーションのワークロードを Atlas のクラスターに移行したら、コストを最小限に抑えるために宛先クラスターのさらなるパフォーマンス調整とサイズ設定に関するサポートを受けるため、サポートにお問い合わせください 。

• 予期しないサイズ変更を避けるため、宛先クラスターでオートスケーリングを無効にします。詳細については、「クラスターの管理」を参照してください。

• oplog コレクションの無制限の増加を防ぎ、ライブ移行のラグ ウィンドウが oplog レプリケーション ラグ ウィンドウの範囲内に収まるようにするには、ライブ移行プロセスの実行中に十分な固定値の oplog サイズ を設定します。

  詳しくは以下を参照してください。

  • クラスターの増加

  • Atlas 構成オプション

  • Cluster-to-Cluster Sync ドキュメントの oplog サイズ設定 。

  これらの推奨事項に従っていてもパフォーマンスの問題が見られる場合は、サポートにお問い合わせください 。

• M0（無料階層）または M2/M5 共有階層クラスターをライブ移行の宛先クラスターとして選択することはできません。

• Atlas ライブ移行の実行中は、featureCompatibilityVersion フラグを変更しないでください。

宛先クラスターでワークロードを避ける

宛先クラスターでは、ライブ移行プロセスと重複しない名前空間で実行されうるワークロードを含め、いかなるワークロードも実行しないでください。このアクションにより、ライブ移行プロセス中に発生する可能性のあるロックの競合やパフォーマンスの低下を回避できます。

同じ宛先クラスターに対して、複数の移行を同時に実行しないでください。

ライブ移行プロセスの同期中は、アプリケーションの宛先クラスターへのカットオーバーのプロセスを開始しないでください。

クラウドバックアップを避ける

Atlas は、ライブ移行中に宛先クラスターのオンデマンド クラウドバックアップのスナップショットの取得を停止します。このページに記載されているライブ移行手順のカットオーバーのステップが完了すると、Atlas はバックアップ ポリシーに基づいてクラウドバックアップのスナップショットの取得を再開します。

選挙を避ける

ライブ移行プロセスは、ソースクラスターまたは宛先クラスターで一時的にネットワークの中断が発生したり、選挙が行われても、移行が継続されるように最善を尽くします。ただし、これらのイベントによりライブ移行プロセスが失敗する可能性があります。ライブ移行プロセスが自動的に回復しない場合は、最初からやり直してください。

移行前チェックリスト

ライブ移行手順を開始する前に、

• 宛先クラスターがまだない場合は、新しい Atlas 配置を作成し、必要に応じて構成します。Atlas クラスターの作成に関する詳細なドキュメントについては、「クラスターの作成」を参照してください。

• Atlas クラスターを配置した後に、アプリケーションを実行するすべてのクライアント ハードウェアからこのクラスターに接続できることを確認します。接続文字列のテストをすることによって、データ移行プロセスが最小限のダウンタイムで完了することを確認できます。

  1. まだインストールしていない場合は、代表のクライアント マシンに mongosh ダウンロードしてインストールします。

  2. Atlas UI から接続文字列を使用して宛先クラスターに接続します。詳細については、「mongosh 経由で接続」を参照してください。

  宛先クラスターへの接続を確認したら、ライブ移行手順を開始します。

手順