1. 導入
コンテナ環境において、ディスク容量の圧迫や予期せぬI/O遅延に悩まされたことはありませんか？その原因の多くは、Dockerのデフォルトストレージドライバである「Overlay2」の特性を理解していないことに起因します。Overlay2は、コンテナのレイヤー構造を効率的に管理する仕組みですが、その動作原理を知ることで、ストレージコストの最適化やパフォーマンスチューニングが可能になります。本記事では、実務で役立つOverlay2の内部構造と、トラブルシューティングの勘所を解説します。
2. 基礎知識
Overlay2は「Union File System（UnionFS）」の一種です。これは、複数のディレクトリ（レイヤー）を重ね合わせ、一つの統合されたファイルシステムとして見せる技術です。
レイヤー構造の仕組み:
・LowerDir: ベースとなるイメージ層。読み取り専用です。
・UpperDir: コンテナ実行時に書き込みが発生する層。コンテナ固有の変更が格納されます。
・MergedDir: LowerDirとUpperDirを統合し、コンテナから見える実際のファイルシステムです。
コンテナでファイルを作成・更新すると、LowerDirのファイルをUpperDirにコピーする「コピーオンライト（CoW）」が発生します。これがディスク容量を消費する主な要因です。
3. 実装/解決策
Overlay2の現状を確認し、ディスク消費を特定するには、以下のコマンドを活用します。まずは、Dockerがどのストレージドライバを使用しているかを確認してください。
docker info | grep “Storage Driver”
また、コンテナごとのディスク使用量は以下のコマンドで可視化できます。
docker ps -s
もし、特定のコンテナが大量のディスクを消費している場合、それは「UpperDir」に巨大なログや一時ファイルが書き込まれている証拠です。これらを特定するには、ホスト側の /var/lib/docker/overlay2 配下を直接調査します。
4. サンプルプログラム
以下は、Overlay2のパフォーマンスに影響を与える「コンテナ内の書き込み量」を監視し、特定の閾値を超えた場合に警告を出すためのスクリプト例です。
コンテナIDを指定して、コンテナ内の書き込みによるディスク消費量を取得するコマンド例
現場での監視スクリプトの一部として活用してください
1. コンテナのUpperDirパスを特定
CONTAINER_ID=”対象のコンテナID”
UPPER_DIR=$(docker inspect –format='{{.GraphDriver.Data.UpperDir}}’ $CONTAINER_ID)
2. UpperDirのサイズを計算（KB単位）
USED_SIZE=$(du -sk $UPPER_DIR | cut -f1)
3. 閾値チェック（例: 1GB = 1048576KB を超えたら警告）
THRESHOLD=1048576
if [ $USED_SIZE -gt $THRESHOLD ]; then
echo “警告: コンテナ $CONTAINER_ID の書き込み層が肥大化しています: ${USED_SIZE}KB”
# ここにSlack通知やログ出力などの処理を記述
else
echo “コンテナ $CONTAINER_ID は正常範囲内です: ${USED_SIZE}KB”
fi
5. 応用・注意点
現場でOverlay2を運用する上で、以下の点に注意してください。
・不要な書き込みの抑制: コンテナ内のログ出力は標準出力（stdout）に出し、ホスト側でログドライバ（json-fileやfluentdなど）を使って回収してください。コンテナ内にファイルを書き続けると、UpperDirが肥大化し、イメージのビルド効率も低下します。
・ファイルロックの問題: Overlay2はファイルシステムレベルでファイルを操作するため、ホストとコンテナで同じファイルを激しく読み書きすると、予期せぬロック競合が発生することがあります。共有が必要なデータは、必ず「Volume（ボリューム）」や「Bind Mount」を使い、Overlay2のレイヤー外で管理してください。
・定期的な掃除: `docker system prune` を実行し、不要な停止中コンテナや未使用イメージを削除することで、LowerDirの断片化やディスク枯渇を未然に防ぐことが重要です。
コメント