MongoDBは、ロードバランサーの背後に配置するように構成できますか？
この投稿 によれば：
単一のレプリカセットでは、書き込みを分散できません。それらはすべてプライマリに移動する必要があります。必要に応じて、[読み取り設定]を使用して、すでにセカンダリに読み取りを配布できます。ドライバーは、プライマリとセカンダリを追跡し、クエリを適切にルーティングします。
Mongo docs によれば：
Mongosインスタンスのグループをデプロイし、アプリケーションとmongosの間でプロキシ/ロードバランサーを使用することもできます。これらの展開では、単一のクライアントからのすべての接続が同じモンゴに到達するように、クライアントアフィニティのロードバランサーを構成する必要があります。
つまり、基本的に、3つのノードの単一のレプリカセットがある場合、すべての書き込みはプライマリに行く必要があり、クライアントアフィニティが必要なので、プロキシ/ロードバランサーを実際に使用することはできません...すべての読み取りまた、プライマリに移動する必要があります。
しかし私が考えているのは、アプリケーションをロードバランサーに接続させることが可能かもしれないということです。ロードバランサーはすべてのリクエストをプライマリにルーティングします（あまりバランスが取れていないが、何でも）...プライマリがダウンするまで/ダウンしない限り-ロードバランサーはリクエストを「新しいプライマリ」にルーティングし始めます。
これが可能かどうかはわかりませんが、ロードバランサはどのプライマリサーバーが新しいプライマリに選出されたのか（したがって、新しいリクエストをどこにルーティングする必要があるのか）をどのようにして知るのでしょうか。
可能であると仮定すると、プライマリがダウンした場合に備えて、これはある程度の冗長性を実現します...また、ネットワークパーティション時に古い書き込み を回避するという副作用もあると思いますロードバランサー（およびすべてのDBクライアント）は単一のプライマリにのみ接続するため、発生します 。
またはこれは愚かな質問ですか...
よく読む必要があります。 mongosは、シャーディングされたクラスターへのアクセスを提供するクエリルーターです。 mongosは、基になるレプリカセット、（再）選択、および最後に重要なことに、どのノードがシャードのレプリカセットのプライマリであるかを十分に認識しています。
複数のモンゴを持つことにはさまざまな利点があります。通常の設定では、アプリケーションサーバーごとに1つのmongosを使用します。たとえば、負荷に基づいてアプリケーションサーバーを自動スケーリングしているため、この設定は望ましくない場合があります。 mongosクエリルーターを使用して複数のマシンをセットアップし、allを渡すことができます。アプリケーションサーバーへの接続文字列を介してこれらのインスタンスの。ここでの問題は、すべてのクエリが最初にリストされたmongosに移動することです。これを回避するために、tcpロードバランサーをmongosインスタンスの前に置くことができます。
レプリカセットの場合、これは必要ありません。まず、（ほとんどがすべて主要な）ドライバーは、 適切に構成されている の場合、レプリカセットに接続しているという事実を十分に認識しています。レプリカセット対応ドライバーを使用すると、書き込みの現在のプライマリが自動的に決定されます。一種の負荷分散のために、 読み取り優先 と呼ばれる概念があります。簡略化：クエリごとに、セカンダリから読み取ることを選択でき、 最終的な整合性 に従って古いデータを読み取る可能性を受け入れます。繰り返しになりますが、（ほとんどの）ドライバーはそれを認識しており、ロードバランサーは必要ありません。
最近、モンゴ大学M202が提供するオンラインコースに参加しました。第3章のフォールトトレランスと可用性では、次の2つの質問について具体的に説明しています。
- レプリカセットを備えたロードバランサー。
- シャーディング環境でのロードバランサー。
ロードバランサーが実際のプライマリサーバーを認識している必要があり、クラスター内の読み取り設定についても認識している必要があるため、ロードバランサーを持つレプリカセット内にはお勧めしません。
そのため、最初の質問についての回答は、いいえ、レプリカセットクラスター上に外部ロードバランサーを配置することはできないということです。
2番目の質問の答えは、シャードシステムの前にロードバランサーを配置することは可能ですが、注意すべき点は1つだけです。つまり、ロードバランサーは、対応するmongosにスティッキーなままでいる必要があります。 Webアプリケーションのセッションアフィニティ。
理由は、リクエスト中、つまりカーソルからの読み取り中に、ロードバランサーが以前に選択されたものとは異なるモンゴを使用する場合、次の要素の取得が失敗するためです。