はじめに
本記事では、Dockerコンテナやイメージによるディスク圧迫が原因でElasticsearchにエラーが発生した事例と、その調査・対処方法について記録します。同様の問題に直面している方の参考になれば幸いです。
🔍 問題の発生
運用中のElasticsearchで以下のエラーが発生しました。
初期調査により、インデックスが close 状態になっており、ディスク容量不足が疑われました。
📊 ディスク使用状況の調査
ルートディレクトリの使用量確認
まず、システム全体のディスク使用状況を確認しました。
実行結果：
/var ディレクトリが50GBと異常に大きいことが判明しました。
/var ディレクトリの詳細調査
実行結果：
/var/lib がほぼ全容量を占めているため、さらに詳細を調査しました。
実行結果：
原因特定： Dockerのデータが49GBを占有していることが判明しました。
🐳 Dockerのディスク使用状況分析
Dockerの詳細な使用状況を確認しました。
実行結果：
分析結果
- Images : 38個中33個（約36GB）が未使用
- Build Cache : 3GB全てが削除可能
- Containers : アクティブなものがほとんどで削除対象外
- Volumes : ほぼ使用中
🧹 クリーンアップの実行
一括クリーンアップコマンド
以下のコマンドで未使用リソースを一括削除しました。
このコマンドは以下を削除します：
- 停止中のコンテナ
- 未使用のイメージ（
-aオプションでタグ付けされていないものも含む） - 未使用のネットワーク
- 未使用のボリューム（
--volumesオプション） - ビルドキャッシュ
実行結果
0
約39GBの空きディスク容量を確保できました。
🛡️ 再発防止策
Dockerログローテーションの設定
Dockerコンテナのログが無制限に蓄積されることを防ぐため、/etc/docker/daemon.json を編集しました。
1
設定説明：
max-size: 1つのログファイルの最大サイズmax-file: 保持するログファイル数
設定の反映
2
定期クリーンアップの検討
運用環境では、定期的なクリーンアップの自動化も検討できます。
3
📋 結果と学習事項
解決結果
- Elasticsearchのエラーが解消
- ディスク使用量が60GB → 21GBに削減
- システムの安定性が向上
学習事項
- 定期的な監視の重要性 : ディスク使用量の定期監視が必要
- Dockerの運用管理 : 開発環境では特に未使用リソースが蓄積しやすい
- ログ管理の重要性 : ログローテーションの設定は必須
- 予防的メンテナンス : 問題が発生する前の定期クリーンアップが効果的
まとめ
Dockerを使用する環境では、イメージやコンテナ、ビルドキャッシュが蓄積されやすく、定期的なクリーンアップが重要です。本記事で紹介した調査方法と対処法を参考に、適切な運用管理を行うことをお勧めします。
今回の対応により、サーバーの安定稼働を復旧できました。同様の問題に直面している方の解決の一助となれば幸いです。
参考コマンド一覧
4