DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

MongoDBのパフォーマンスボトルネックを予防する：プロアクティブなアプローチ

適切なスキーマ設計、複合インデックス、クエリプラン、実用的な監視アラートにより、MongoDBのボトルネックを防ぎます。

MongoDBのパフォーマンスボトルネックを防ぐ：プロアクティブなアプローチ

MongoDBのパフォーマンスボトルネックは、データベースが完全に障害を起こすずっと前に、通常はページの遅延、キューイングの増加、またはディスクの過負荷として現れます。クエリに基づいてドキュメントを設計し、実際のワークロードにインデックスを付け、適切なメトリクスを早期に監視することで、これらの多くを防ぐことができます。

このガイドでは、一般的な問題点（低速クエリ、レプリケーションラグ、大きなワーキングセット、リソースプレッシャー）に焦点を当てます。

基礎：最適化されたスキーマ設計

MongoDBの柔軟なスキーマは強力な機能ですが、クエリ効率とデータの局所性に直接影響を与える慎重な設計選択が必要です。不適切なスキーマ設計は、インデックスに関係なく、高コストなルックアップや大きなドキュメントの読み取りを必要とする可能性があります。

1. 埋め込みと参照のバランス

最も重要なスキーマの決定は、関連データをいつ埋め込むか（同じドキュメントに保存する）と、いつ参照するか（別のドキュメントに保存する）を決定することです。

埋め込み（高い読み取り局所性）

埋め込みは、1対少数または1対多の関係で、埋め込まれたデータが親ドキュメントと一緒に頻繁に読み取られ、埋め込まれたデータへの更新が頻繁でない場合に推奨されます。

  • 利点： 完全なデータを取得するために必要なクエリの数を減らし、読み取りパフォーマンスを向上させます。
  • 例： ユーザーの現在の配送先住所をuserドキュメント内に直接保存する。

参照（高い書き込み頻度または大規模データ）

参照は、埋め込まれたリストが無制限に成長する可能性がある場合、または関連データが大きく、親ドキュメントとは独立して頻繁に更新される場合に、1対多の関係で必要です。

  • 利点： ドキュメントの成長を防ぎ、各更新が書き換える必要のあるデータ量を減らします。
  • 例： すべての注文を顧客ドキュメント内に埋め込むのではなく、customer_idを参照するorderドキュメントを保存する。

ヒント： 16MBのBSONドキュメントサイズ制限に近づくドキュメントを作成しないでください。I/Oコストの増加により、この制限に達するずっと前にパフォーマンスが低下することがよくあります。

2. 適切なデータ型の選択

フィールドが常に正しいBSONデータ型を使用して一貫して保存されていることを確認してください。日付に文字列を使用したり、数値IDに文字列を使用したりすると、パフォーマンスとインデックス作成が著しく妨げられます。

フィールドの目的 推奨BSON型 理由
タイムスタンプ/日付 ISODate 効率的な範囲クエリと時間ベースのインデックス作成を可能にします。
一意の識別子 ObjectID または Long/Int 小さなインデックスフットプリントと高速な比較を保証します。
通貨/正確な値 Decimal128 Doubleで一般的な浮動小数点エラーを回避します。

効果的なインデックス戦略

インデックスは、MongoDBにおけるクエリ最適化のための最も強力なツールです。インデックスにより、データベースはコレクション全体をスキャンすることなく（COLLSCAN）、データを迅速に特定できます。これはパフォーマンス低下の特徴的な指標です。

1. explain() を使用した低速クエリの特定

インデックスを追加する前に、ワークロードをプロファイリングして低速な操作を特定します。explain() メソッドを使用してクエリプランを分析します。

db.collection.find({ 
  status: "active", 
  priority: { $gte: 3 }
}).sort({ created_at: -1 }).explain("executionStats")

目標： winningPlan が IXSCAN（インデックススキャン）を示し、totalDocsExamined が nReturned の値に近いことを確認します。

2. 複合インデックスのESRルール

複合インデックス（複数フィールドのインデックス）を作成する場合は、Equality, Sort, Range (ESR) ルールに従って効率を最大化します。

  1. Equality（等価性）： 完全一致（$eq、$in）に使用されるフィールド。これらを最初に配置します。
  2. Sort（ソート）： 結果のソートに使用されるフィールド（.sort()）。これを2番目に配置します。
  3. Range（範囲）： 範囲クエリ（$gt、$lt、$gte、$lte）に使用されるフィールド。これらを最後に配置します。
// クエリ: find({ user_id: 123, type: "payment" }).sort({ date: -1 }).limit(10)
// ESRに従ったインデックス:
db.transactions.createIndex({ 
  user_id: 1, 
  type: 1, 
  date: -1 
})

警告： インデックスはメモリとディスク容量を消費し、書き込み操作ごとに影響を受けるすべてのインデックスを更新する必要があるため、書き込みペナルティが発生します。重要なクエリで頻繁に使用されるインデックスのみを作成してください。

3. 部分インデックスとTTLインデックスの活用

  • 部分インデックス： フィルターを指定して、コレクション内のドキュメントのサブセットのみにインデックスを作成します。これにより、インデックスサイズと書き込みペナルティが大幅に削減されます。
    // 'archived' が false のドキュメントのみにインデックスを作成
db.logs.createIndex( { timestamp: 1 }, { partialFilterExpression: { archived: false } } )
  • TTL（Time-to-Live）インデックス： 一定期間後にドキュメントを自動的に期限切れにします。これは、ログ、セッションストア、または一時キャッシュでのデータ成長を管理し、ディスク容量のボトルネックを防ぐために重要です。

プロアクティブな監視とアラート

予防には、データベースの運用状態を継続的に可視化する必要があります。包括的な監視により、ユーザーに影響を与える前に、レイテンシの突然の急上昇やキャッシュパフォーマンスの低下などの新たな問題を発見できます。

継続的に追跡すべき主要メトリクス

1. クエリパフォーマンス

95パーセンタイルおよび99パーセンタイル（P95/P99）のクエリレイテンシを監視します。ここでの突然の増加は、非効率的なクエリ、インデックスのミス、またはハードウェアの競合を示しています。

2. キャッシュ使用率（WiredTiger）

キャッシュ読み取り、ダーティバイト、エビクションアクティビティ、ディスク読み取りレイテンシを追跡します。MongoDBのWiredTigerストレージエンジンは内部キャッシュに大きく依存していますが、単一の普遍的なヒット率しきい値は単純すぎます。キャッシュヒット率の低下、エビクションプレッシャーの上昇、または通常のトラフィック中の持続的なディスク読み取りは、ワーキングセットがメモリに快適に収まらなくなったことを意味する可能性があります。

3. レプリケーションヘルス

レプリケーションラグは、レプリカセットで監視するために重要です。主要なメトリクスはOplog Window（操作ログのサイズ）です。Oplog Windowの減少または高いレプリケーションラグ（秒単位で測定）は、セカンダリが追いつくのに苦労していることを示しており、読み取りの遅延、古いデータ、またはセカンダリが遅れすぎた場合に追いつけなくなる可能性があります。

4. システムリソースとロック

  • CPUおよびI/O待機： 高いI/O待機は、多くの場合、不適切なインデックス作成または不十分なキャッシュサイズを示しています。
  • 並行性プレッシャー： キューイングされた読み取り/書き込み、長時間実行操作、ストレージエンジンチケットを監視します。最新のMongoDBは古いグローバルロックバージョンのようには動作しないため、1つの一般的なロックパーセンテージではなく、現在の待機とレイテンシのメトリクスに焦点を当ててください。

実用的なアラートの設定

即時アクションを可能にするために、適切なしきい値でアラートを設定します。

問題のトリガー プロアクティブなしきい値
P95クエリレイテンシ 5分間、サービスの目標を超えた場合
WiredTigerキャッシュプレッシャー エビクションとディスク読み取りが通常のベースラインを超えた場合
レプリケーションラグ 読み取りの陳腐化またはフェイルオーバーの許容範囲を超えた場合
利用可能なディスク容量 拡張およびバックアップの安全マージンを下回った場合

ツール： db.serverStatus() による組み込み監視、またはMongoDB Atlas Monitoring、MongoDB Exporterを使用したPrometheus、Datadogなどの専門プラットフォームを利用して、詳細な履歴傾向分析を行います。

まとめ

MongoDBのパフォーマンスボトルネックを防ぐことは、継続的なサイクルです。アクセスパターンに合わせてデータをモデル化し、explain("executionStats") でクエリプランを確認し、自身のベースラインからの変化をアラートで通知します。ユーザーに最も影響を与えるクエリから始め、トラフィックが問題を強制する前に、インデックスとドキュメントの成長を確認します。