Atlas のマルチリージョン配置を使用すると、レイテンシを削減してパフォーマンスを向上させることができます。次のセクションでは、レイテンシ を削減するためにできる要因と構成の選択について説明します。
物理距離
物理距離はレイテンシの主な原因です。ユーザーとアプリケーション、アプリケーションとデータ、クラスター ノード間の距離はすべて、システムレイテンシとアプリケーションパフォーマンスに影響。
読み取り操作のレイテンシを軽減するには、アプリケーションとデータの両方を地理的にユーザーに近いものに配置することが重要です。
レプリケーション構成
レプリケーションとは、プライマリノードからセカンダリ ノードへのデータのコピーです。レプリケーションの構成方法は、レイテンシに影響します。次の要因を考慮してください。
書込み保証 (write concern) レベル: 書込み (write) 耐久性と書込みレイテンシ)の間にはトレードオフがあります。設定する書込み保証 (write concern)レベル（例、
w: "majority"）は、複数のデータセンターにわたるレプリケーションを定義し、より耐久性のある書込みのレイテンシを増加させる可能性があります。ただし、これによりすべてのデータがセカンダリにコミットされ、フェイルオーバーイベントに書込み (write) をロールバックするのを防ぐことができます。リージョンの優先順位: 構成内のリージョンの順序によって、プライマリノードのロケーションの優先順位が決まります。これは、ユーザーがどこで行われるかによって書込みレイテンシに影響可能性があります。例、ユーザーのほとんどがメンバーである場合は、メンバーがプライマリに選出されるように、メンバーに最も優先優先順位を設定する必要があります。
ミラーリングされた読み取り: ミラーリングされた読み取りは、セカンダリ ノードのキャッシュを事前にウォームアップすることで、停止時後のプライマリ選挙の影響を軽減します。詳細については、「 ミラーリングされた読み取り 」を参照してください。
読み込み設定:デフォルトでは 、アプリケーションは読み取り操作を プライマリノードに送信します。ただし、読み込み設定 (read preference)を構成して、読み取り操作をセカンダリ ノードに送信できます。こうすることで、読み取りは地理的に最も近いクラスターに送信されるようになります。ニーズに最適な構成の実装に関するガイダンスについては、 MongoDB の MongoDB の プロフェッショナル サービスチーム にお問い合わせください。
重要
レプリケーションラグが原因で、セカンダリノードが古いデータを返す可能性があることに注意してください。読み取り整合性と分離 の構成の詳細については、「 読み取り保証 」を参照してください。
データ分散:レプリカセットまたはシャーディングされたクラスターを使用してリージョン間でデータを分散することは、データが地理的に指向している場合に効果的なアプローチです。例、EU からのみ読み取られるデータと、記述されたデータが記述されたデータを適切に分散するクラスターを作成できます。
ネットワーク構成
プライベートエンドポイント を使用すると、セキュリティを強化し、レイテンシを削減できる可能性があります。プライベートエンドポイントは、アプリケーションの仮想ネットワークと Atlas クラスター間で直接かつ安全な接続を確立し、ネットワーク コストを削減し、レイテンシ を改善する可能性があります。
レイテンシの監視とテスト
Atlas は、さまざまなリージョンのレイテンシメトリクスを観察するために リアルタイム パフォーマンス パネル（RTPP） を提供します。また、アプリケーションレベルのモニタリングを実装して、アプリケーションとの間のエンドツーエンドのレイテンシを追跡することもできます。最終本番環境に配置する前に、さまざまな マルチリージョンシナリオでパフォーマンス テストを実行し、レイテンシのボトルネックを特定して対処することをお勧めします。
接続構成オプション
可能な限り、アプリケーションのプログラミング言語の最新のドライバー バージョンに構築された接続メソッドを使用することをお勧めします。Atlas が提供するデフォルトの接続文字列を開始するのに適していますが、特定のアプリケーションと配置アーキテクチャのコンテキストでのパフォーマンスを高めるために、これを調整することをお勧めします。
エンタープライズ レベルのアプリケーション配置の場合、アプリケーションの接続プール設定を調整して、追加の 運用レイテンシを発生させることなくユーザーの需要に対応できるようにすることが特に重要です。データベースクライアント接続を開始すると大量のネットワークオーバーヘッドが発生するため、データベースクライアント接続の過半数がどのように開くか、またいつ接続プールを開き、接続プールの設定を自分の設定に一致するように構成することが重要です。 接続プールオプションを使用して、アプリケーションのスタートアップ時に開くデータベースクライアント接続の数を指定できます。これらの初期接続後、接続プールはオンデマンドでソケットを開き、 MongoDBへの同時要求をサポートし、minPoolSizemaxPoolSize の接続数が満たされるまで、
minPoolSize と maxPoolSize の値が似ている場合、データベースクライアント接続の過半数はアプリケーションのスタートアップ時に開きます。例、minPoolSize が 10 に設定され、maxPoolSize が 12 に設定されている場合、10クライアント接続はアプリケーションのスタートアップ時に開き、2 個の接続のみがアプリケーションの実行中に開くことができます。 。これにより、アプリケーションの実行中に必要に応じて動的に発生するのではなく、アプリケーションのスタートアップ時にネットワークコストの過半数が発生します。アプリケーションの実行中に新しいデータベース接続プールを起動すると、リクエストが急増し、大量の追加の接続を一度に開く必要がある場合、エンドユーザーの運用レイテンシに影響可能性があります。
アプリケーションのアーキテクチャは、この考慮事項の中心となります。例、アプリケーションを マイクロサービス として配置する場合は、接続プールの動的な拡張と縮小を制御する方法として、どのサービスが Atlas を直接呼び出すかを検討してください。あるいは、 Amazon Web Services Lambdaなどのアプリケーション配置でシングルスレッド リソースを活用している場合、アプリケーションは1 つのクライアント接続しか開いて使用できないため、minPoolSize と maxPoolSize の両方を { に設定する必要があります。 1。
接続プールを作成して使用する方法と場所、および接続プール設定を指定する場所の詳細については、「 接続プールの概要 」を参照してください。
クエリ レイテンシ オプション
配置にグローバルおよび操作レベルのデフォルトタイムアウト制限を設定して、アプリケーションがタイムアウトするまでの応答を待つ時間を短縮できます。
また、配置にグローバルな読み取り保証（read concern）を設定して、読み取り操作の成功が報告される前にデータが複製される必要があるノードの数を指定することもできます。 Atlas のデフォルトの読み取り保証 (read concern)は ローカル です。つまり、クエリ時に、Atlas はクラスター内の 1 つのノードのみからデータを検索し、レプリカセットのノードの過半数にデータが書き込まれたことを保証することなく、より高い可用性とより低いレイテンシを提供します。
シャーディングされたワークロードの分散
シャー増やすにより、クラスターを水平方向にスケーリングできます。 MongoDBを使用すると、一部のコレクションをシャーディングしながら、同じクラスター内の他のコレクションはシャーディングされないままにできます。 新しいデータベースを作成すると、クラスター内のデータ量が最も少ないシャードがデフォルトでそのデータベースのプライマリシャードとして選択されデフォルト。 そのデータベースのシャーディングされていないコレクションは、デフォルトでそのプライマリシャードに配置されます。 これにより、特にワークロードロードの増加がプライマリシャードのシャーディングされていないコレクションに集中する場合、ワークロードの増加に伴いプライマリシャードへのトラフィックが増加する可能性があります。
このワークロードをより分散するために、 MongoDB 8.0では、 moveCollectionコマンドを使用して、シャーディングされていないコレクションをプライマリシャードから他のシャードに移動できます。 これにより、アクティブで多目的なコレクションを、リソース使用量の少ないシャードに配置できます。 これを使用すると、次のことが可能になります。
大規模で複雑なワークロードのパフォーマンスを最適化します。
リソース使用率の向上を実現します。
シャード間で日付をより均等に分散します。
次の状況では、コレクションを分離することをお勧めします。
高スループットのシャーディングされていないコレクションが複数あるためにプライマリシャードに重大なワークロードが発生した場合。
シャーディングされていないコレクションでは将来、増加が予想され、他のコレクションのボトルネックになる可能性があります。
クラスターごとに 1 コレクションの配置設計を実行中していて、優先順位やワークロードに基づいてそれらのカスタマーを分離したいと考えています。
シャードには、シャーディングされていないコレクションの数が含まれているため、データ量が按分されています。
mongoshを使用してシャーディングされていないコレクションを移動する方法については、「コレクションの移動 」を参照してください。