DevOpsナレッジハブ
DevOpsナレッジハブ

MongoDBデプロイメントにおけるディスク容量の管理と解放

ディスク容量管理を習得することで、コストのかかるダウンタイムを防ぎ、MongoDBデプロイメントを安定させましょう。この包括的なガイドでは、不可欠な監視コマンド（`db.stats()`）、スペースを浪費するもの（断片化、インデックスのオーバーヘッド）を特定するための戦略、およびストレージを回復するための実用的な手法について詳述します。WiredTigerストレージエンジンでTTLインデックスを使用して、`mongodump`/`mongorestore`によるコンパクションの推奨される方法、インデックスの最適化方法、および自動データライフサイクル管理の実装方法を学びます。

35 ビュー

MongoDBデプロイメントにおけるディスク容量の管理と解放

ディスク容量の管理は、健全で高性能なMongoDBデプロイメントを維持するための重要な側面です。従来のリレーショナルデータベースとは異なり、MongoDBのストレージエンジンは容量の割り当てを動的に処理するため、削除後も物理ディスク容量はすぐには回復されないことがよくあります。管理されないまま放置すると、不要なストレージ消費により、予期せぬ停止、書き込みパフォーマンスの低下、特にクラウド環境では多大な経済的オーバーヘッドにつながる可能性があります。

このガイドでは、ストレージ使用率の監視、容量を大量に消費している原因（スペースホッグ）の特定、およびディスク容量を積極的に解放・管理するための効果的な方法（コンパクション、インデックスの最適化、堅牢な保持ポリシーなど）に関する専門的な戦略と実用的なコマンドを提供します。MongoDBがストレージをどのように利用するかを理解することで、管理者は長期的な安定性と効率性を確保できます。

ディスク容量使用率の監視

効果的な管理の第一歩は継続的な監視です。論理データサイズと物理ストレージサイズを区別する必要があります。

システムレベルの監視

MongoDBのデータ（dbPath）とジャーナルファイルが格納されているファイルシステムを常に監視してください。全体のディスク使用率が危険なしきい値（例：80〜90%）に達したときにアラートを出すには、標準的なオペレーティングシステムツールが必要です。

df -h /path/to/mongodb/data

MongoDB固有のメトリクス

MongoDB内部のストレージ使用量を理解するには、mongoshシェルを介してdb.stats()コマンドおよびdb.collection.stats()コマンドを使用します。

データベース統計 (db.stats())

このコマンドは、データベース全体の概要を提供します。

use myDatabase
db.stats()

注目すべき主要フィールド:

  • dataSize: すべてのコレクションにわたる生ドキュメントデータの合計サイズ（論理サイズ）。
  • storageSize: データおよびパディングによって消費されているディスク容量の総量（物理サイズ）。
  • indexSize: ディスク上のすべてのインデックスの合計サイズ。

コレクション統計 (db.collection.stats())

これは、容量を大量に消費している要素を特定するための、最も粒度の高い有用なツールです。

db.myCollection.stats(1024 * 1024) // サイズをメガバイトで返します

注目すべき主要フィールド:

  • size: コレクション内のドキュメントの論理サイズ。
  • storageSize: ディスク上のコレクションに割り当てられた物理容量。sizeとstorageSizeの間に大きな差がある場合、多くの場合、重大なフラグメンテーションまたは高いドキュメントのチャーンを示します。
  • totalIndexSize: このコレクションのインデックスのみによって消費されている物理ディスク容量。

ヒント: storageSizeがsizeよりも大幅に大きい場合は、非効率なストレージ割り当て（フラグメンテーションまたは過剰なパディング）を示しています。totalIndexSizeがsizeと比較して不釣り合いに大きい場合は、そのコレクションのインデックス戦略を見直してください。

スペースホッグの特定

MongoDBの容量消費は、通常、次の3つの要因によって引き起こされます。

1. 削除によるフラグメンテーション

ドキュメントが削除されると、MongoDB（特にWiredTiger）はスペースを利用可能としてマークしますが、すぐにオペレーティングシステムに解放しません。この空きスペースは、将来再利用するためにストレージエンジンによって割り当てられたファイル内に保持されます。高チャーンコレクション（頻繁な書き込みと削除）はフラグメンテーションの影響を非常に受けやすく、肥大化したstorageSizeメトリクスにつながります。

2. インデックスのオーバーヘッド

インデックスはデータドキュメントとは別に保存されます。複雑なインデックスや多数のインデックスは、コレクションに必要なストレージ要件を容易に2倍または3倍にします。未使用のインデックスを特定して削除することは、多くの場合、容量を解放する最も速い方法です。

3. コレクション構造とパディング

MongoDBは、更新中のドキュメントの増加に対応するために、データファイル内に余分なスペース（パディング）を割り当てます。これはパフォーマンスに役立ちますが（ドキュメントの再配置の必要性を減らす）、更新がまれである場合や、ドキュメントが作成後に不変である場合は、過剰なパディングによりストレージが非効率的に使用される可能性があります。

ディスク容量を解放するための戦略

1. コンパクションとデータの再配置

WiredTigerストレージエンジンを使用している最新のMongoDBデプロイメントでは、フラグメント化されたスペースを回復するための主な方法は2つあります。

A. compactの使用（注意が必要）

compactコマンドは、コレクション内のデータを再編成して、フラグメント化されたスペースを回復し、インデックスを再構築します。ただし、これは影響を受けるコレクションのすべての読み取り/書き込みをブロックする、リソースを大量に消費する重い操作です。

db.runCommand({ compact: 'myCollection' })

警告: コンパクションは、絶対に必要でない限り、本番環境では一般的に避けるべきであり、できれば、制御されたメンテナンスウィンドウ中にレプリカセットのセカンダリメンバーで実行してください。

B. mongodump / mongorestore方式（推奨）

深刻にフラグメント化されたコレクションの場合、ディスク容量を回復する最も信頼性の高い方法は、データをダンプしてリストアすることです。このプロセスはデータを順次書き換えるため、内部フラグメンテーションが解消されます。

  1. データのダンプ:
    bash mongodump --db myDatabase --collection myCollection --out /path/to/dump
  2. コレクションのドロップ: (このステップの前に完全なバックアップがあることを確認してください)
    javascript db.myCollection.drop()
  3. データのリストア: (リストアプロセスはストレージを効率的に割り当てます)
    bash mongorestore --db myDatabase --collection myCollection /path/to/dump/myDatabase/myCollection.bson

2. インデックスの最適化

非効率なインデックスを再構築またはドロップすることで、大幅な容量節約につながる可能性があります。

未使用のインデックスのドロップ

プロファイラまたはdb.collection.getIndexes()を使用してクエリパターンを分析し、まったく使用されていないか、めったに使用されていないインデックスを特定します。

db.myCollection.dropIndex('index_name_to_drop')

インデックスの再構築

インデックス自体もフラグメント化する可能性があります。セカンダリメンバーでインデックスを再構築すると、物理的なフットプリントが削減される場合があります。

db.myCollection.reIndex()

ベストプラクティス: ダウンタイムを最小限に抑えるため、プライマリで操作を実行する前に、必ずセカンダリメンバーでインデックスを再構築またはドロップし、レプリケーションが完了するのを待ってください。

3. データ保持およびアーカイブポリシー

無制限の増加を防ぐことが、ディスク容量の問題に対する最良の防御策です。

TTL（Time-To-Live）インデックスの使用

ログ、セッション、または時系列データの場合、TTLインデックスは定義された期間が経過するとドキュメントを自動的に期限切れにし、手動での介入なしにデータ保持ポリシーが適用されるようにします。

db.logEvents.createIndex(
   { "createdAt": 1 }, 
   { expireAfterSeconds: 86400 } // ドキュメントは24時間後に期限切れになります
)

アーカイブの実装

元のドキュメントをプライマリデプロイメントから削除する前に、mongoexportなどのツールやカスタムアーカイブスクリプトを使用して、古く、アクセス頻度の低いデータを低速のストレージ階層（S3やGlacierなど）に移動します。

高度なストレージエンジンの考慮事項 (WiredTiger)

最新のMongoDBデプロイメントでは、デフォルトでWiredTigerストレージエンジンが使用されます。これは、古いMMAPv1エンジンと比較して、優れた圧縮機能と同時実行性を提供します。

圧縮設定

WiredTigerはデフォルトで圧縮（通常はSnappy）を有効にしています。ディスク容量が極度に制約されている場合は、アルゴリズムを切り替えること（例：zlibへ）により、CPU使用率を犠牲にして圧縮率を高めることができる可能性があります。

この構成は、起動時に設定するか、特定のコレクションに対して動的に設定されます。

db.runCommand({
   collMod: "myCollection",
   storageEngine: {
      wiredTiger: {
         configString: "compression_engine=zlib"
      }
   }
})

事前割り当てとスペースの再利用

WiredTigerは、通常2GBのチャンクで事前に割り当てられたデータファイルを使用します。これは最初は無駄なスペースに見えるかもしれませんが、ファイルシステムのフラグメンテーションを減らすことでパフォーマンスを向上させます。重要な点は、このスペースが内部的に管理されており、ドキュメントが削除されたとしても、新しいチャンクが割り当てられる前にデータベースによって再利用されるということです。

警告: MongoDBデータファイルを縮小したり、ジャーナルファイルをファイルシステムから直接削除しようとしないでください。これはデータの破損を確実に引き起こします。制御された容量の回復には、mongodumpやmongorestoreなどのMongoDBに組み込まれたツールを使用してください。

結論

MongoDBにおけるプロアクティブなディスク容量管理は、継続的な監視とスマートなデータ保持の慣行にかかっています。論理データサイズと物理ストレージサイズの違いを定期的に確認し、不要なインデックスを最適化し、TTLインデックスによる自動クリーンアップを活用することで、管理者は運用コストを大幅に削減し、過剰なストレージフラグメンテーションによって引き起こされるパフォーマンスのボトルネックを防ぐことができます。深刻なフラグメンテーションの場合、mongodump/mongorestoreサイクルは、容量を回復するための最も効果的で安全かつ堅牢なソリューションであり続けます。