MongoDBを運用していて、「最初は速かったのに、データが増えるにつれてクエリが重くなってきた」「特定の時間帯だけレスポンスが極端に遅くなる」といった課題に直面していませんか？

スキーマレスで柔軟なMongoDBですが、パフォーマンスを引き出すには適切な設計とインデックス戦略が不可欠です。本記事では、実務で即効性のある7つのチューニング手法を解説します。

1. インデックスの最適化（ESRルールの適用）

スロークエリの最大の原因は、インデックスが適切に張られていないことによる「フルスキャン（COLLSCAN）」です。MongoDBでは、複合インデックスを作成する際にESRルールに従うのが鉄則です。

• E (Equality): find({status: "A"}) のような完全一致検索を最初に配置。
• S (Sort): sort({timestamp: -1}) のようなソートフィールドを次に配置。
• R (Range): $gt, $lt, $in などの範囲指定を最後に配置。

この順番を守ることで、B-Tree構造を最も効率的に走査でき、ソート処理をメモリ上ではなくインデックス内で行えるようになります。

2. カバードクエリ（Covered Query）の活用

クエリが必要とするすべてのフィールドがインデックスに含まれている状態を「カバードクエリ」と呼びます。MongoDB 5.0以降ではマルチキーインデックスの制限も緩和されており、より活用しやすくなっています。

Tips: find({user_id: 10}, {user_id: 1, _id: 0}) のように、プロジェクションを使って必要なフィールドのみに絞り込み、インデックス内だけで処理を完結させましょう。

3. ワーキングセットとRAMの管理

MongoDBは「頻繁にアクセスするデータ（ワーキングセット）」をRAM上にキャッシュします。メモリ不足によりディスクI/O（Page Faults）が発生すると、パフォーマンスは劇的に低下します。

• WiredTigerキャッシュ： デフォルトでは RAMの50% – 1GB が割り当てられます。
• db.serverStatus().wiredTiger.cache でキャッシュのヒット率を監視してください。

4. スキーマ設計の再考（埋め込み vs 参照）

MongoDBの柔軟性を活かし、「1つのドキュメントにどこまでまとめるか」を検討します。バージョン 4.0以降は多文書トランザクションがサポートされていますが、使いすぎはパフォーマンス低下を招きます。

• 埋め込み: クエリ1回で全データを取得できるため高速。
• 参照: $lookup（JOIN処理）が必要。集計パイプラインでの結合はCPU負荷が高いため、頻繁なクエリには不向きです。

5. 読み取り優先順位（Read Preference）の設定

レプリカセット構成では、読み取り負荷をセカンダリノードに逃がすことができます。

分析用の重いクエリには secondaryPreferred を設定しましょう。これにより、アプリケーションの主要なトラフィック（プライマリへの書き込み・読み取り）への影響を最小限に抑えられます。

6. スロークエリの特定とexplain()の実行

まずは原因を特定します。MongoDB 5.0以降のコンソールでも利用可能な explain() を活用しましょう。

db.collection.find({ status: "A" }).explain("executionStats")

チェック項目：

• stage: "COLLSCAN" が出ていたらインデックスが使われていません。
• totalKeysExamined（スキャン数）が nReturned（結果数）より大幅に多い場合は、インデックスの改善が必要です。

7. コネクションプーリングの最適化

リクエストごとに新しい接続を作るのは非効率です。ドライバの設定（maxPoolSize など）を調整し、適切なコネクション数を維持してください。特に最新のドライバでは、デフォルト設定が最適化されていますが、サーバーレス環境では依然として注意が必要です。

まとめ：継続的なモニタリングが鍵

MongoDB 7.0などの最新バージョンではクエリアナライザも進化していますが、基本は「インデックス」と「メモリ管理」に集約されます。

まずは ESRルールの適用 と explain()による現状把握 から始めてみてください。これだけで、多くの遅延問題は劇的に改善するはずです。