MongoDBインスタンスをスケーリングすべきタイミングの見極め方

以前のブログ記事では、MongoDBによる大規模スケーリングの基礎をご紹介しました。スケーリングはどうしても受動的になりがちで、対応が遅れるとアプリケーションのパフォーマンス低下、最悪の場合にはシステム全体のダウンタイムといった問題につながります。その結果、顧客体験の悪化を招き、ビジネスへの悪影響も避けられません。では、ビジネスに損失を出さないために、MongoDBデータベースをスケールすべき適切なタイミングはどうやって見極めればよいのでしょうか。

アプリケーションに適した閾値を見つける

利用者の増加やトラフィックの急増という「嵐」を乗り切るためには、本番環境にスケーリングなどの変更を加える前に、負荷テストを実施して、アプリケーションが耐えられる限界(閾値)を把握しておくことが不可欠です。しかし実際にはこのプロセスがおろそかにされがちで、トラフィック増加時にトラブルが発生してから慌てて対処することになりかねません。

MongoDBの負荷テストを成功させるためには、以下のポイントを検討しておきましょう。

• ボトルネックを特定するために、どのメトリクスを監視すべきか
• スケーリングの判断基準として、どの閾値を採用すべきか
• メトリクスの分析にどのツールを使うべきか
• 負荷テストをどこで実行すべきか

ボトルネック発見のためには何を監視すべきか?

まずは、自社のアプリケーションにおける制約要因を特定するための基準を決める必要があります。アプリケーションごとに要件は異なるため、これらの要件を明確にすることで、データベース側で監視すべき適切なメトリクスを判断できるようになります。

以下はその一例です。

• トラフィック増加時にも、毎秒X件のインサート処理が必要である
• ユーザーへは100ミリ秒以内にデータを返却しなければならない
• 同時接続数に上限がある
• CPU使用率やロードアベレージなど、サーバーリソースに上限がある

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

たとえば、一定数のインサートリクエストを捌くことが要件であれば、書き込み関連のメトリクスに注目しましょう。

• サーバーのI/O状況
• データベースのロック状態
• アクティブな書き込み数としてのopcounters
• WiredTigerをストレージエンジンとして使用している場合の、利用可能なライトチケット数

メトリクス分析に使えるツール

監視対象のメトリクスを決めたら、次はデータベース側からデータを収集します。負荷状況の分析に活用できる主なツールは以下のとおりです。

• mongostat:ロック状況や読み取り・書き込みキューなど、リアルタイムのデータベースメトリクスを表示します。
• db.currentOp():現在実行中のアクティブな操作を確認できます。
• mongotop:最もアクティビティの高いコレクションを確認できます。
• top・sar・iostatなどのOS標準ユーティリティ:CPU使用率やディスクスループットなどを確認できます。

リアルタイム分析に加えて、MongoDBのログを調査すれば、データベースのアクティビティやエラー発生状況についてさらに詳細な情報を得ることができます。デフォルト設定では、実行に100ミリ秒以上かかったクエリがログに記録されるため、パフォーマンスの低いクエリを特定するのに非常に有効な手段となります。

負荷テストの実行場所を決める

データ収集に使うツールを決めたら、いよいよ負荷テストの実行です。常識的に考えて、本番環境での負荷テストは絶対に避けるべきです。ただし、テスト環境を迅速に立ち上げるのが難しい場合、ここがネックになることもあります。まだObjectRocketプラットフォームをご利用でない場合でも、MongoDBのテストクラスタであれば短時間で簡単に構築可能です。

サポートが必要ですか?

MongoDB環境をいつスケールすべきかの判断は、複雑になりがちです。ObjectRocketのご契約者様には、他社の追随を許さないスケーリングおよびシャーディングのサポートをご提供しています。経験豊富な当社のDBAが、クラスタのスケーリングに関するあらゆる側面をお手伝いし、そのサポート料金はサービス料金にすべて含まれています。まずは今すぐお気軽にお問い合わせください。

MongoDBインスタンスをスケールすべきタイミングの判断方法がわかったところで、次回のブログでは、実際にMongoDBインスタンスをどのようにスケールさせるかについて詳しく解説します。