すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB for MongoDB:MongoDB における高 IOPS 使用率のトラブルシューティング

最終更新日:Jul 18, 2026

IOPS 使用率は MongoDB インスタンスにとって重要なメトリックです。この値が 100% に達する、または近づくと、アプリケーションの応答が遅くなり、サービスが利用できなくなる可能性があります。本ガイドでは、IOPS 使用率の確認方法、高使用率の一般的な原因、および最適化戦略について説明します。

背景情報

クラウドデータベースプロバイダーは通常、cgroups (Control Groups) などの技術を用いて、共有ホスト上の I/O 競合を防ぐため、インスタンスごとに I/O 隔離および IOPS (Input/Output Operations Per Second) 制限を適用します。そのため、各インスタンスタイプには特定の最大 IOPS 容量が設定されています。

重要事項

IOPS 使用量および IOPS 使用率のメトリックは、スタンドアロンインスタンス、およびクラウドディスクを使用する MongoDB 4.2 のレプリカセットまたはシャードクラスターインスタンスでは利用できません。

これらのインスタンスでは、ApsaraDB for MongoDB コンソールの Monitoring Information ページに表示される IOPS使用量 および IOPS使用量 のメトリックは常に 0 を示します。この値は実際の IOPS データを反映していません。

IOPS 使用率の確認

モニタリングチャートまたはコマンドを実行することで、IOPS 使用率を確認できます。

  • ApsaraDB for MongoDB コンソール にログインします。基本情報 ページの Specification Information セクションで、インスタンスの最大 IOPS を確認します。インスタンスタイプ別の IOPS 制限については、「インスタンスタイプ」をご参照ください。

  • ApsaraDB for MongoDB コンソール にログインします。Monitoring Information ページで、IOPS使用量 および IOPS使用量 のメトリックを確認し、インスタンスが IOPS 制限に近づいているかどうかを判断します。IOPS 関連メトリックの詳細については、「メトリック」をご参照ください。

I/O 問題の一般的な原因

MongoDB インスタンスにおけるディスク I/O の高騰は、通常以下の要因に起因します。

  • メモリ不足:I/O パフォーマンスは WiredTiger キャッシュサイズに大きく依存します。キャッシュが大きいほどホットデータを多く保持でき、ディスク I/O を削減し、ボトルネックのリスクを低減します。一方、キャッシュが小さいとダーティページをディスクに頻繁にフラッシュする必要があり、I/O 負荷が増大します。

  • 不適切な構成:ジャーナルやランタイムログの頻繁なフラッシュ、非効率な ジャーナリング 設定、不適切な Write Concern レベル、またはシャードクラスターにおける moveChunk エラーなどが、高 I/O の原因となることがあります。

I/O 問題に対する最適化戦略

ApsaraDB for MongoDB インスタンスの I/O 問題に対処するには、適切なインスタンスタイプを選択し、インデックスを最適化し、アプリケーションの書き込みパターンを改善してください。

  • 適切なインスタンスタイプの選択

    デプロイメント前にホットデータとキャッシュサイズの理想的な比率を予測するのは困難な場合が多いです。一般的な指針として、ビジネス要件を満たしつつ、日常的なピーク時の CPU 使用率および IOPS 使用率を 50% 以下に保てるインスタンスタイプを選択してください。

  • インデックスの最適化

    フルテーブルスキャンや非効率なインデックスを使用したクエリは、大量の I/O を消費します。たとえば、コレクション全体をエクスポートすると I/O が急増することがあります。また、過剰なインデックスはディスク上のデータサイズを増加させ、WiredTiger キャッシュが保持できるホットデータ量を減少させます。書き込み操作ごとにインデックスを更新するための追加 I/O が必要となり、パフォーマンスがさらに低下します。これらの問題を軽減するには、クエリパターンに応じた適切な インデックス を作成してください。

  • アプリケーションアーキテクチャおよび操作の最適化

    ディスク I/O がアプリケーションレベルのボトルネックとならないように、以下の最適化を検討してください。

    • 同時書き込みおよび読み取りスレッドの制御

      MongoDB はマルチスレッドアプリケーションです。同時書き込み数が多い、または複雑なクエリが多いと、I/O ボトルネックが発生し、セカンダリノードで持続的なレプリケーションラグが生じる可能性があります。書き込み量の多さが I/O ボトルネックを引き起こす場合は、データを水平方向に分散することで書き込みパフォーマンスを線形にスケーリングできるシャードクラスターへのアップグレードを検討してください。

    • 書き込みの急増を可能な限り回避

      一部のアプリケーションでは、定期的な書き込みやバッチでのデータ永続化により、IOPS が急激に上昇することがあります。現在のインスタンスがピークロードを処理できない場合は、書き込み操作をより均等に分散させてください。たとえば、各バッチ書き込み操作に小さなランダム遅延を追加します。IOPS峰值数据

    • ピーク時間帯にメンテナンス操作を実施しない

      特定のメンテナンス操作はパフォーマンスに大きな影響を与え、IOPS を急激に上昇させる可能性があります。このような操作は、可能な限りオフピーク時間帯にスケジュールしてください。高 I/O を伴う操作には、バッチでのデータ変更(書き込み、更新、削除)、インデックス作成、コレクションのコンパクション、および大量データのエクスポートが含まれます。