マルチリージョン Atlas 配置とは、複数のリージョンにまたがって設定されるクラスターです。マルチリージョン配置では、同じ地理的条件内に複数のリージョン（大陸や国のような大きな面積）内に複数のリージョンが存在する場合、または 複数の地理的条件にある複数のリージョンが存在する場合があります 。マルチリージョン配置:
リージョン停止時が発生した場合に、トラフィックを自動的に別のリージョンにルーティングして保護を強化し、継続的な可用性とスムーズなユーザー エクスペリエンスを実現します。
データをユーザーの近くに配置することで、一部のアプリケーションのパフォーマンスと可用性を向上させます。
マルチリージョン配置が適しているかどうかを検討する場合は、アプリケーションの重要性と、それがさまざまな RTO/RPO 要件にどのように対応しているかを評価する必要があります。回復力は、マルチリージョン配置のゼロダウンタイムから単一リージョン配置のさまざまなバックアップスケジュールまでの範囲に存在します。その反面、可用性は高くなりますが、コストが高くなります。
マルチリージョン配置がワークロードに適しているかどうかに関する詳細なガイダンスについては、「 信頼性 」セクションを参照してください。
注意
マルチリージョン配置は、M10 以上の専用クラスターでのみ使用できます。
マルチリージョン配置戦略
次の図には、2+2+1トポロジーの 2 の例が示されています。これについて詳しくは、以下で詳しく説明します。[5]5 3の異なるリージョンに ノードを含む単一クラスターが表示されます。2 US12US2の ノード、1 の ノード、 のUS3 ノード。
5-ノード、3-リージョン アーキテクチャ（2+2+1）
リージョン停止時た場合にほぼ確実に回復するには、3 リージョンに分散された 以上の 5 ノードで構成されるアーキテクチャを推奨します。このアーキテクチャにより、2 番目のリージョンへのフェイルオーバーを強制せずに定期的なメンテナンス操作を実行できると同時に、完全なリージョン停止時が発生した場合に自動フェイルフェイルオーバーとデータ損失保護が確保されます。
次の図は、このアーキテクチャの詳細を示しています。
メモと考慮事項
プライベートエンドポイント を使用してクラスターと、アプリケーションサーバーVPC 間のVPCピアリングに接続します。 VPCピアリングにより、ネットワーク接続が中断された場合でも、そのリージョンの Atlas がダウンした場合でも、アプリケーション層は引き続き プライマリノードにルーティングでき、最初はVPCピアリング、次にプライベートエンドポイントを経由します。
このアーキテクチャでは、リージョン間のネットワーク トラフィックと 5 以上のデータを保持するノードがあるため、コストが最も高くなります。
このアーキテクチャは、最高の回復力を提供します。 Atlas の操作中に中断されることはありません（自動アップグレードなど）。アプリケーションは、中断や手動介入を必要とせずに、完全なリージョン障害を維持できます。
このアーキテクチャでは、リージョン間のネットワーク トラフィックと 5 以上のデータを保持するノードがあるため、コストが最も高くなります。
5-ノード、2-リージョン アーキテクチャ（2+3）
会社が2 リージョンのみに限定されている場合は、5-ノードと 3-リージョン アーキテクチャのバリエーションを使用できます。ここでは 2 つのリージョンに分散された 5 ノードがあります。プライマリ リージョンには 2 の選択可能なノードがあり、セカンダリ リージョンには 1 の選挙可能な ノードと 2 の読み取り専用（投票権のない）ノードがあります。
過半数のリージョンが失敗した場合にオペレーターがフェイルオーバーオーバーを手動で中断する必要があるため、3 リージョンを使用できる場合は通常推奨されません。ただし、承認されたリージョンが 2 のみのカスタマーのオプションです。
メモと考慮事項
このアーキテクチャでは、データ損失に対する保護が強化されます。少数リージョンが失われた場合でも、過半数のリージョンは完全に機能するクラスターのままであるため、ユーザーのアクションは必要ありません。過半数リージョンが失われた場合でも、ノードの過半数が選択可能な状態になるまで、システムは読み取り専用モードで使用可能なままになります。ただし、障害発生後に一部のデータがまだセカンダリノードに複製されていない場合は、完全なデータ損失保護を提供しない可能性があります。この場合、プライマリ リージョンが復元されるまで、そのデータは使用できません。
このアーキテクチャには、いくつかの警告があります。
過半数リージョンが失われると、少数リージョンは完全に機能するクラスターではなくなります。プライマリがないため、読み取りのみを受け入れることができますが、書込みはできません。
投票権のあるノードの過半数が存在しないため、プライマリはなく、読み取りのみを受け入れることができます（書込みはしない）。
機能するクラスターを復元するには、管理者は 読み取り専用ノードを 選択可能なノード に再構成する必要があります。ただし、データが失われる可能性があります。停止時時 、セカンダリへの新しい書き込みは、手動回復のために特別なコレクションに配置されます。ただし、プライマリがダウンする前に少なくとも 1 つのセカンダリノードに複製されなかった プライマリ への書込みは失われます。詳細については、「 リージョン停止時にレプリカセットを再構成する2 」を参照するか、 acceptDataRisksAndForceReplicaSetReconfig APIパラメーターを使用してください。
シャーディングされたクラスターでは、 MongoDBプロセスがチャンクの移行を複製しなかった場合、データの不整合により孤立したドキュメントが発生する可能性があります。
低コストのバリエーション
さらにコストを節約するには、2 読み取り専用ノードを使用せずにこのアーキテクチャを設計できます。上記に記載された警告に加えて、クラスターに新しいノードを追加するたびにデータをセカンダリに同期する必要があるため、データサイズは決定に大きな影響を与えます。例、1 TB のデータは平均 1 時間の復元と同期時間になります。少数リージョンに 2 の読み取り専用ノードを用意することをお勧めします。これらはすでに完全に同期されており、完全に機能するクラスターへの回復には 秒から 分しかないためです。
3-ノード、3-リージョン アーキテクチャ（1+1+1）
中断を許容できるクリティカルではないワークロードの場合は、各 3 リージョンで 1ノードを使用することで、より低コストのアーキテクチャを活用できます。各リージョンに選挙可能な ノードがあるため、プライマリノードが使用できない場合は、クラスターは新しいリージョンにフェイルオーバーして、継続的な可用性を確保します。ただし、元のプライマリ リージョンのアプリ階層が引き続きユーザーのリクエストを処理している場合は、リクエストが複数のリージョンにルーティングされるため、レイテンシが増加します。さらに、ノードを再構築する 場合には、最適化された最初の同期を実行する能力はありません。
注意
Atlas ノードの定期的かつ計画的なメンテナンスにより一時的なレイテンシの急増が発生するため、通常この構成は推奨されません。
マルチリージョン配置に関する推奨事項
マルチリージョン配置の構成方法と、追加できるさまざまなタイプのノードの詳細については、Atlas ドキュメントの「 高可用性とワークロード分離の構成 」を参照してください。
Atlasクラウド配置の推奨事項を見つけるには、次のリソースを参照してください。