WordPress用のAMIMOTO AMIを運用しているEC2インスタンスにおいて、ディスク使用率が100%に達したため、ディスク容量の拡張とクリーンアップ作業を実施しました。本記事では、その手順と結果を記録します。

初期状態の確認

作業開始時点でのディスク状況は以下の通りでした。

/dev/nvme0n1p1   9GB  9.0GB  64KB  100%  /

ディスク使用率が100%に達しており、早急な対応が必要な状態でした。lsblkコマンドで確認したところ、EBSボリューム自体は12GBに拡張されていましたが、パーティションとファイルシステムはまだ9GBのままであることが判明しました。

ディスク拡張の実施

AMIMOTO AMIはNitroベースのインスタンスタイプを使用しているため、デバイス名は従来の/dev/xvdaではなく/dev/nvme0n1となります。また、ファイルシステムはEXT4ではなくXFSが採用されていました。

まず、パーティションの拡張を実施しました。

sudo growpart /dev/nvme0n1 1

このコマンドにより、パーティションサイズが9GBから12GBに拡張されました。

次に、ファイルシステムの拡張を行いました。XFSファイルシステムの場合、resize2fsではなくxfs_growfsコマンドを使用します。

sudo xfs_growfs /

この時点で、ディスク容量は12GB全体が使用可能となり、使用率は76%まで改善しました。

ディスク使用状況の分析

さらなる改善のため、ディスク使用状況を詳細に分析しました。duコマンドを使用して主要なディレクトリの使用量を確認したところ、以下の結果が得られました。

/varディレクトリが3.4GBと最も大きく、その内訳は以下の通りでした。

• /var/log/journal: 929MB
• /var/cache/yum: 486MB
• /var/www/vhosts: 1.4GB
• /var/lib/mysql: 273MB

クリーンアップ作業の実施

分析結果に基づき、不要なファイルの削減を実施しました。

まず、systemdのjournalログについて、過去のログが928MBも蓄積していることが判明しました。保存期間を7日分に制限し、サイズを100MBまで削減しました。

sudo journalctl --vacuum-size=100M

次に、yumのパッケージキャッシュを削除しました。

sudo yum clean all
sudo rm -rf /var/cache/yum

これらの作業により、/varディレクトリは3.4GBから2.1GBへと1.3GBの削減に成功しました。

改善結果

一連の作業により、以下の改善が達成されました。

ディスク容量は9GBから12GBに拡張され、使用率は100%から68%まで低下しました。空き容量は4.0GBが確保され、当面の運用には十分な余裕が生まれました。

削減内訳としては、ディスク拡張による3GBの容量追加に加え、journalログの削減で860MB、yumキャッシュの削減で486MBの空き容量を確保できました。