🎃

Dockerによるディスク圧迫の調査と対処法【Ubuntu 22.04 運用事例】

に公開
Docker
Elasticsearch
tech

はじめに

本記事では、Dockerコンテナやイメージによるディスク圧迫が原因でElasticsearchにエラーが発生した事例と、その調査・対処方法について記録します。同様の問題に直面している方の参考になれば幸いです。

🔍 問題の発生

運用中のElasticsearchで以下のエラーが発生しました。

{
  "error": {
    "type": "search_phase_execution_exception",
    "reason": "all shards failed",
    "phase": "query",
    ...
  },
  "status": 503
}

初期調査により、インデックスが close 状態になっており、ディスク容量不足が疑われました。

📊 ディスク使用状況の調査

ルートディレクトリの使用量確認

まず、システム全体のディスク使用状況を確認しました。

sudo du -h --max-depth=1 / | sort -hr | head -n 20

実行結果：

60G     /
50G     /var
4.7G    /usr
2.1G    /home
1.2G    /opt
...

/var ディレクトリが50GBと異常に大きいことが判明しました。

/var ディレクトリの詳細調査

sudo du -h --max-depth=1 /var | sort -hr

実行結果：

50G     /var
49G     /var/lib
342M    /var/log
240M    /var/cache
128M    /var/spool
...

/var/lib がほぼ全容量を占めているため、さらに詳細を調査しました。

sudo du -h --max-depth=1 /var/lib | sort -hr

実行結果：

49G     /var/lib
49G     /var/lib/docker
256M    /var/lib/snapd
128M    /var/lib/apt
...

原因特定： Dockerのデータが49GBを占有していることが判明しました。

🐳 Dockerのディスク使用状況分析

Dockerの詳細な使用状況を確認しました。

docker system df

実行結果：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          38        5         39.8GB    35.99GB (90%)
Containers      5         4         10.44MB   0B (0%)
Local Volumes   2         1         646MB     32.57kB (0%)
Build Cache     129       0         2.972GB   2.972GB (100%)

分析結果

  • Images: 38個中33個（約36GB）が未使用
  • Build Cache: 3GB全てが削除可能
  • Containers: アクティブなものがほとんどで削除対象外
  • Volumes: ほぼ使用中

🧹 クリーンアップの実行

一括クリーンアップコマンド

以下のコマンドで未使用リソースを一括削除しました。

docker system prune -a --volumes

このコマンドは以下を削除します：

  • 停止中のコンテナ
  • 未使用のイメージ（-a オプションでタグ付けされていないものも含む）
  • 未使用のネットワーク
  • 未使用のボリューム（--volumes オプション）
  • ビルドキャッシュ

実行結果

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N] y

Total reclaimed space: 39.2GB

約39GBの空きディスク容量を確保できました。

🛡️ 再発防止策

Dockerログローテーションの設定

Dockerコンテナのログが無制限に蓄積されることを防ぐため、/etc/docker/daemon.json を編集しました。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

設定説明：

  • max-size: 1つのログファイルの最大サイズ
  • max-file: 保持するログファイル数

設定の反映

sudo systemctl restart docker

定期クリーンアップの検討

運用環境では、定期的なクリーンアップの自動化も検討できます。

# 例：週次で未使用イメージを削除
0 2 * * 0 /usr/bin/docker image prune -f

📋 結果と学習事項

解決結果

  • Elasticsearchのエラーが解消
  • ディスク使用量が60GB → 21GBに削減
  • システムの安定性が向上

学習事項

  1. 定期的な監視の重要性: ディスク使用量の定期監視が必要
  2. Dockerの運用管理: 開発環境では特に未使用リソースが蓄積しやすい
  3. ログ管理の重要性: ログローテーションの設定は必須
  4. 予防的メンテナンス: 問題が発生する前の定期クリーンアップが効果的

まとめ

Dockerを使用する環境では、イメージやコンテナ、ビルドキャッシュが蓄積されやすく、定期的なクリーンアップが重要です。本記事で紹介した調査方法と対処法を参考に、適切な運用管理を行うことをお勧めします。

今回の対応により、サーバーの安定稼働を復旧できました。同様の問題に直面している方の解決の一助となれば幸いです。

参考コマンド一覧

# ディスク使用量調査
sudo du -h --max-depth=1 /path | sort -hr

# Dockerリソース確認
docker system df
docker images
docker ps -a

# クリーンアップ
docker system prune -a --volumes  # 一括削除
docker image prune                # 未使用イメージのみ
docker container prune            # 停止コンテナのみ

Discussion