このドキュメントで説明されているベストプラクティスについて質問したいと思います。

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

複数のクエリルーターを使用します。複数のサーバーにまたがる複数のmongosプロセスを使用します。一般的な展開は、アプリケーションサーバー上のmongosプロセスを同じ場所に配置することです。これにより、アプリケーションとmongosプロセス間のローカル通信が可能になります。mongosプロセスの適切な数は、アプリケーションと展開の性質によって異なります。

展開についてのほんの少しの背景。多くのアプリケーションサーバーノードがあります。それらはそれぞれ、ステートレスRESTful WSで1つのJVMベースのプロセスを実行します。このベストプラクティスが示唆するように、すべての単一のアプリケーションサーバーノードは独自のmongosプロセスを実行します。つまり、JVMプロセスの数は常にプロセスの数に等しくなりmongosます。

すべてのmongosプロセスは、3つの構成サーバーと複数のmongo断片（各断片内にレプリカセットがある）に接続します。シャード展開を使用している場合でも、実際にはコレクションをシャーディングしていません。実際、作成時にすべてのシャードに分散する多数のデータベースがあります（これが現時点でのシャーディングの主な使用例です）。

ベストプラクティスでは「適切なmongosプロセスの数はアプリケーションとデプロイメントの性質に依存する」ことも示唆しているので、私たちの使用mongosが実際に適切かどうか、または複数の専用mongosノードを用意して、アプリサーバーはmongosローカルで実行せずに接続します。

mongosアプリケーションサーバーのインスタンス数またはMongoDBクラスターのサイズに関連して適切なインスタンスの数を決定するための最適なアプローチについて、あなたはどう思いますか？

最近、ステートレスWebサービスのクラスター管理を検討し始めました。つまり、Docker、Apache Mesos、Kubernetesなどのツールを意味します。Dockerを使用している場合、一般的にコンテナ内で複数のプロセスを実行することは推奨されません。この事実を考慮すると、アプリケーションサーバーコンテナとmongosコンテナを常に同じ物理ノードに配置し、同じ量のプロセスを確保することは非常に困難になります。これは、このベストプラクティスが今説明したクラスターアーキテクチャにまだ当てはまるのかと思います。そうでない場合は、mongosこのアーキテクチャでプロセスを見つけて展開するためのより良い方法を提案してください。

すでに回答が提出されており、有用で有効な回答がありますので、私はそれ自体の有用性から注意をそらしたくはありませんが、実際には短いコメントを超えてそれを上げるポイントがあります。したがって、この「拡張」を検討してください。これは有効であることが望まれますが、主に既に述べたことに加えてです。

真実は、「アプリケーションがデータをどのように使用するか」を実際に考慮し、これに影響する「シャード環境」および提案された「コンテナ環境」の要因を認識することです。

バックグラウンドケース

mongosプロセスをアプリケーションインスタンスと同じ場所に配置するための一般的な推奨事項は、アプリケーションがそのmongosプロセスと通信するために必要なネットワークオーバーヘッドを排除することです。もちろんmongos、「最も近い」ノードが何らかの理由で利用できない場合に、アプリケーション接続文字列でインスタンスの数を指定することも「推奨されるプラクティス」です。リモートノード。

あなたが言う「ドッカー」のケースは、いくぶんarbitrary意的です。コンテナの主要な目標の1つ（およびそれ以前のBSD jailやchrootのようなもの）は一般に、ある程度の「プロセス分離」を達成することですが、複数のプロセスを実行しても問題はありません。意味を理解します。

この特定のケースでmongosは、「軽量」であり、アプリケーションプロセスの「追加機能」として実行されることを意図しており、アプリケーション自体の「ペア」部分になっています。したがって、Dockerイメージ自体には「initd」のようなプロセスはありませんが、supervisordなどのプロセスコントローラーをコンテナーのメインプロセスとして実行しても、実際に問題はありません。そのコンテナも。「ペアプロセス」のこのような状況は合理的なケースであり、公式のドキュメントがあることを十分に求めることでもあります。

展開のためにそのような「ペア」操作を選択したmongos場合、実際には、アプリケーションサーバー自体と同じネットワーク接続と実際の「サーバーインスタンス」でインスタンスを維持する主要なポイントに対処します。また、何らかの方法で「全体のコンテナ」が失敗し、そのノード自体が単に無効になる場合と見なすこともできます。推奨するわけではありません。実際、他のmongosインスタンスが遅延を増加させるネットワーク接続を介してのみアクセスできる場合でも、他のインスタンスを探すように接続を構成する必要があります。

バージョン固有/用途固有

そのポイントが作成されたので、ここでの他の考慮事項はmongos、ネットワーク遅延の目的でプロセスをアプリケーションと同じ場所に配置するという最初の考慮事項に戻ります。2.6より前のMongoDBのバージョンでは、特に集約フレームワークなどの操作に関して、多くのネットワークトラフィックがあり、その後mongos、異なるシャードからのデータを処理するプロセスによって実行される処理後の作業がある場合がありました。「ルーター」に「蒸留」する前に、これらのシャード自体に対して大量の処理ワークロードを実行できるようになったので、今ではそうではありません。

もう1つのケースは、シャーディングに関するアプリケーションの使用パターン自体です。つまり、プライマリワークロードが複数のシャードに「書き込みを分散」するのか、実際に読み取り要求を統合する「スキャッター/ギャザー」アプローチであるのかを意味します。それらのシナリオでは

テスト、テスト、そしてもう一度テスト

したがって、ここでの最後のポイントは本当に自明であり、あなたの質問に対する正気な回答の基本的なコンセンサスに帰着します。これはMongoDBやその他のストレージソリューションにとって新しいことではありませんが、実際の展開環境は、コアコンポーネントから期待される機能の「単体テスト」と同じくらい実際の現実に近い「使用パターン」でテストする必要があります。全体的な結果をテストする必要があります。

実際にアプリケーションのパフォーマンスと信頼性について「実際に最適に動作する」ものをテストすることとは別に、「このように構成する」または「このように使用する」と言う「決定的な」文はありません。

もちろん、「ベストケース」は常にmongos、「多くの」アプリケーションサーバーソースからのリクエストでインスタンスを「混雑させない」ことです。しかし、その後、選択可能な「リソースのプール」を持つために利用可能なリソースワークロードによって分散できるいくつかの自然な「パリティ」を許可し、実際には多くの場合、理想的には追加の「ネットワークトランスポートのオーバーヘッド」。

それが目標ですが、理想的には、最終的な展開ソリューションに「最適な」ソリューションを提供するために、さまざまな知覚構成を「ラボテスト」できます。

また、すでに述べたように、あなたの知識レベルに関係なく、「ビール」などの「無料」コースを強くお勧めします。多くの場合、さまざまな教材が「隠れた宝石」を提供して、あなたが考慮していなかったり見落としたりしていない可能性があるものについてより多くの洞察を与えることがわかります。前述のM102クラスは、MongoDBおよびその他のデータアーキテクチャの大規模な展開に関する高度な知識があることを証明できるAdam Commerfordによって構築および実施されています。少なくとも、あなたがすでに知っていると思うかもしれないことについて、新鮮な視点を検討する価値があります。

ベストプラクティスでは「適切なmongosプロセスの数はアプリケーションと展開の性質に依存する」ことも示唆しているため、mongosの使用が実際に適切かどうか疑問に思い始めました。

これはドキュメンテーションが言及しているように、最終的にはあなただけが答えることができる質問だと思います。

推奨される戦略の1つは、mongos各アプリケーションノードでサービスを提供することです。さらに、可用性を高めるために、場合によっては専用のノードを追加することもできます。これを現在お持ちのように、現在の展開には何の問題もありません。アーキテクチャに変化がなければ、現在のベストプラクティスの範囲内です。しかしながら...

Dockerを使用している場合、一般的にコンテナ内で複数のプロセスを実行することは推奨されません。

このmongosプロセスはリソースをあまり消費しないため、各シャードにインスタンスを配置して、各mongodノードをノードとして機能させることもできmongosます。アプリケーションサーバーアーキテクチャを少し複雑にする場合、これはより意味があります。

私は個人的にこれらの製品に精通していませんが、mongos並行して実行できる他のほとんどのプロセスよりも集中力が低い可能性があるため、ベンダーの推奨事項についても確認します。

最後に、mongos規模、リソースなどに応じて、常にプロセスの専用ノードを使用することもできますが、これもベストプラクティスの範囲内に収まります。ここで重要なことは、どこかにたくさんのmongosプロセスがある限り、うまくやっているということです。

ただし、実際の数は、展開のサイズとSLA要件に依存します。シャードを使用する場合、十分以上のものがありますが、専用ノードを使用する場合は、アプリケーションノードの数をできる限り一致させるようにします。

MongoDB M102オンラインコースのこのビデオをご覧ください。これらのトピックについて説明し、次回のセッション（無料、オンライン）でDBAクラスのM102にサインアップしてみてください。