MongoDB：mongosプロセスをアプリケーションサーバー上に配置
このドキュメントで説明されているベストプラクティスについて質問します。
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を実行しなくても、アプリサーバーがそれらに接続できるようにします。
アプリケーションサーバーインスタンスの数またはMongoDBクラスターのサイズに関連して、適切なmongosインスタンスの数を決定するための最良のアプローチについてどう思いますか？
最近、私たちはステートレスWebサービスのクラスター管理を検討し始めました。つまり、Docker、Apache Mesos、Kubernetesなどのツールです。 Dockerを使用している場合は、コンテナー内で複数のプロセスを実行することはお勧めしません。この事実を考慮すると、アプリケーションサーバーコンテナーとmongosコンテナーが常に同じ物理ノードに同じ場所に配置され、等しい数のプロセスを持つことを確認するのは非常に困難になります。これは、このベストプラクティスが今説明したクラスターアーキテクチャにも当てはまるかどうか疑問に思います。そうでない場合は、このアーキテクチャでmongosプロセスを見つけてデプロイするためのより良い方法を提案していただけますか？
すでに回答が提出されており、有用で有効なものがあるので、私はそれ自体の有用性から気を散らしたくはありませんが、実際には、短いコメントだけでなく、それ以上の点を指摘する必要があります。ですから、この「拡張」について考えてみてください。これは有効であると期待されますが、主にすでに述べられている内容に追加されます。
真実は、「アプリケーションがデータをどのように使用するか」を実際に検討し、「シャーディング環境」およびこれに影響を与える提案された「コンテナ環境」の要因にも注意することです。
背景のケース
mongosプロセスとアプリケーションインスタンスを同じ場所に配置することに関する推奨事項は、アプリケーションがmongosプロセスと通信するために必要なネットワークオーバーヘッドを取り除くことです。もちろん、「最も近い」ノードが何らかの理由で利用できない場合にアプリケーション接続文字列でmongosインスタンスの数を指定することも「推奨される方法」ですが、リモートノードに接続する際のオーバーヘッドの可能性。
あなたが言及する「ドッカー」事件は幾分恣意的であるようです。コンテナーの主な目的の1つ（それ以前は、BSDのjailやchrootのようなもの）は一般にある程度の「プロセスの分離」を達成することですが、複数のプロセスを実行しても、何も問題はありません。意味を理解します。
この特定のケースでは、mongosは「軽量」であり、アプリケーション自体の「ペア」部分となるようにアプリケーションプロセスの「追加機能」として実行されることを意図しています。したがって、Dockerイメージ自体には「initd」のようなプロセスはありませんが、コンテナのメインプロセスとして supervisord （たとえば）のようなプロセスコントローラーを実行しても、実際には何も問題はありません。また、そのコンテナに対するプロセス制御のポイントです。この「ペアになったプロセス」の状況は合理的なケースであり、 公式ドキュメント があることを十分によく尋ねられます。
デプロイメントにそのような「ペア」操作を選択した場合、実際には、同じネットワーク接続でmongosインスタンスを維持する主要なポイントと、アプリケーションサーバー自体として「サーバーインスタンス」を維持します。また、「コンテナ全体」が失敗した場合、そのノード自体が単に無効になる場合と見なすこともできます。私がそれをお勧めするわけではありません。実際、他のmongosインスタンスがネットワーク接続経由でしかアクセスできない場合でも、接続を構成してレイテンシを増やす必要があります。
バージョン固有/使用固有
その時点で、ここでのもう1つの考慮事項は、mongosプロセスをネットワーク遅延の目的でアプリケーションと同じ場所に配置するという最初の考慮事項に戻ります。 2.6より前のバージョンのMongoDBでは、特に集約フレームワークなどの操作に関しては、mongosプロセスによって実行された後の処理作業の後に、さらに多くのネットワークトラフィックが発生する場合がありました。異なるシャードのデータを処理する。 「ルーター」に「蒸留」する前に、シャード自体に対して大量の処理ワークロードを実行できるようになったため、これは現在のケースではそれほど多くありません。
もう1つのケースは、シャーディングに関するアプリケーションの使用パターン自体です。これは、プライマリワークロードが複数のシャードに「書き込みを分散」することであるか、それとも実際に読み取りリクエストを統合する際の「スキャッター/ギャザー」アプローチであるかを意味します。それらのシナリオでは
テスト、テスト、そして再度テスト
したがって、ここでの最後のポイントは本当に自明であり、あなたの質問に対する正気な応答の基本的な合意に帰着します。これはMongoDBやその他のストレージソリューションの新機能ではありませんが、実際のデプロイメント環境は、コアコンポーネントから期待される機能の「単体テスト」と同じくらい実際に近い「使用パターン」でテストする必要があります。全体的な結果テストする必要があります。
「このように構成する」または「このように使用する」と言う「明確な」ステートメントは実際にはありません。実際にアプリケーションのパフォーマンスと信頼性に対して期待どおりに「実際に最もよく機能する」ものをテストすることとは別に意味があります。
もちろん、「多くの」アプリケーションサーバーソースからのリクエストでmongosインスタンスを「混雑させない」ことが常に「ベストケース」になります。しかし、選択可能な「少なくとも」の「リソースのプール」を持つことで利用可能なリソースワークロードによって分散できるいくつかの自然な「パリティ」を許可し、実際には多くの場合理想的には追加の誘導を行う必要をなくします。 「ネットワーク転送オーバーヘッド」。
それが目標ですが、理想的には、最終的な展開ソリューションに「最適な」ソリューションを実現するために、認識されたさまざまな構成を「ラボテスト」することができます。
また、あなたの知識レベルに関係なく、既に述べたように「ビール」のような（無料の）コースを利用することを強くお勧めします。さまざまな教材のソースが、「隠された宝石」を提供して、あなたが考慮していない、または見過ごされていない可能性のある事柄に対する洞察を提供することがよくあります。言及された M102 Class は Adam Commerford によって構築され、実行されています。私が証明できるのは、MongoDBや他のデータアーキテクチャの大規模な展開に関する高いレベルの知識を持っているということです。あなたがすでに知っていると思うかもしれないことについて、少なくとも新鮮な視点を検討する価値があります。
ベストプラクティスでは、「mongosプロセスの適切な数は、アプリケーションとデプロイメントの性質に依存すること」も示唆しているため、mongosの使用が実際に適切かどうか疑問に思い始めました
ドキュメントが参照するように、これは最終的にはあなたしか答えられない質問だと思います。
推奨される戦略の1つは、各アプリケーションノードにmongosサービスを配置し、場合によっては追加の可用性のために専用のノードを1つ追加することです。現在これを使用しているので、現在の展開に問題はありません。アーキテクチャに変更がない場合は、現在、ベストプラクティスの範囲内です。しかしながら...
Dockerを使用している場合は、コンテナー内で複数のプロセスを実行することはお勧めしません。
mongosプロセスはリソースをあまり消費しないため、各シャードにそのインスタンスを配置し、各mongodノードをmongosノードとしても機能させることもできます。これは、アプリケーションサーバーのアーキテクチャを少し複雑にする場合に、より意味があります。
私は個人的にこれらの製品に精通していませんが、mongosは並行して実行できる他のほとんどのプロセスよりも負荷が少ない可能性があるため、推奨事項についてベンダーに確認します。
最後に、スケールやリソースなどに応じて、mongosプロセスの専用ノードを常に使用することもできます。これもベストプラクティスに十分含まれます。ここでの本当の要点は、mongosプロセスのどこかにたくさんある限り、うまくやっているということです。
実際にどれだけの数がデプロイメントのサイズとSLA要件に依存します。シャードを使用する場合、十分すぎる数になりますが、専用ノードを使用する場合はアプリケーションノードの数をできるだけ一致させるようにします。
あなたはこれをチェックすることができます MongoDB M102オンラインコースからのビデオ これらのトピックを網羅しており、次回セッション中に M102 for DBAs class へのサインアップを試してみたいかもしれません（無料オンライン）。