MongoDBインスタンスをスケーリングするタイミング

以前のブログ投稿で、MongoDBを使用した大規模なスケーリングの概要を説明しました。スケーリングは本質的に反応的である傾向があり、アプリケーションのパフォーマンスの低下や、さらに悪いことに、アプリケーション全体のダウンタイムなどの問題を引き起こします。これらの問題は、最終的にはビジネスに影響を与えるネガティブなカスタマーエクスペリエンスにつながります。では、収益に影響を与えないように、Mongoデータベースをスケーリングするのに適切な時期をどのようにして知ることができますか？

アプリに適したしきい値を見つける

アプリケーションの使用量の増加とトラフィックの急増をアプリケーションが確実に乗り切るには、負荷テストが不可欠です。 スケーリングなどの変更を本番システムに適用する前に、アプリケーションが処理できるしきい値を決定するシステム。多くの場合、このプロセスは見過ごされており、交通量の増加に伴う問題が発生した場合に避難訓練が行われます。

MongoDBの負荷テストを成功させるには、次の考慮事項を含める必要があります。

• ボトルネックを見つけるために監視する必要があるメトリックはどれですか？
• スケーリングするタイミングに関して、どのしきい値を使用する必要がありますか？
• 指標の分析にはどのツールを使用する必要がありますか？
• 負荷テストはどこで実行する必要がありますか？

ボトルネックを見つけるために監視する必要があるメトリックはどれですか？

まず、特定のアプリケーションに対する制限要因を見つけるために使用する基準を決定する必要があります。すべてのアプリケーションは異なります。これらの要件を知っていると、データベース側から監視する適切なメトリックを決定できます。

次にいくつかの例を示します。

• トラフィックが増加した場合、アプリケーションでは1秒あたりX回の挿入が必要です。
• データは100ミリ秒以内にユーザーに返される必要があります。
• 同時接続の数には制限があります。
• 高いCPUや平均負荷など、サーバーリソースには制限があります。

アプリケーション側のメトリックを決定できたら、データベース側で何を監視するかを決定できます。

たとえば、要件に特定の数の挿入リクエストがある場合は、次のような書き込みメトリックに焦点を当てます。

• サーバーI/O
• データベースのロック
• カウンター 、アクティブな書き込みの観点から
• ストレージエンジンとしてWiredTigerを実行している場合は、利用可能な書き込みチケット

指標の分析に使用されるツール

監視するメトリックを決定したら、データベース側からデータを収集する必要があります。負荷率の分析に使用できるユーティリティを次に示します。

• モンゴスタット ユーティリティは、キューのロック、読み取り、書き込みに関するリアルタイムのデータベースメトリックを表示します。
• db.currentOp（） ユーティリティは、現在アクティブな操作を決定します。
• モンゴトップ 上位のアクティブなコレクションを表示できます。
• topなどのサーバーユーティリティ 、 sar 、 iostat CPU使用率やディスクスループットなどの指標を表示します。

リアルタイム分析に加えて、MongoDBログをマイニングして、データベースアクティビティやエラー状態に関する追加の詳細を確認することもできます。デフォルトでは、MongoDBは実行に100ミリ秒以上かかるクエリをログに記録するため、パフォーマンスの低いクエリを特定するための優れたツールです。

負荷テストを実行する場所を決定する

データの収集に使用するものを決定したら、負荷テストの準備が整います。常識では、実稼働環境でテストをロードしてはならないことを示しています。環境を十分に速くスピンアップするのが難しい場合があるため、これがショーストッパーになることがあります。 ObjectRocketプラットフォームをまだ使用していない場合は、MongoDBテストクラスターを非常にすばやく起動できます。

助けが必要ですか？

MongoDB環境をいつスケーリングするかを知ることは、複雑になる可能性があります。 ObjectRocketのお客様は、最高のスケーリングとシャーディングのサポートを手に入れることができます。私たちのDBAは、クラスターのスケーリングのあらゆる側面を支援でき、私たちの支援は常に含まれています。開始するには、今すぐお問い合わせください。

これで、MongoDBインスタンスをいつスケーリングするかを決定できるようになりました。次のブログでは、MongoDBインスタンスをスケーリングする方法について説明します。