■ はじめに
前回までは本サイト（WordPress＋AWS）のバックアップの自動化についてやりました。
（前回の記事はこちら）
バックアップファイルをみてみると、１つで約350MB。
意外と大きいな。記事の画像をアップしているからかな・・と。
だとすると増え続けるEC2の空き容量が心配・・とりあえず現状のEC2のディスク使用状況を把握してみましょう！
■ まずは全体の容量を確認する
まずはEC2に入ってディスク使用状況を確認します。
SSM Session Managerで接続するので、AWSコンソールから、EC2からインスタンスを選んで「接続」ー「SSM Session Manager」ー「接続ボタン」で、EC2にログインします。そうしたら
df -hを実行します。dfはdisk free（ディスクの空き容量）で空き容量を出すコマンド。-hはhuman readable（人間が読みやすい単位） にしてくれという意味です。結果は・・
sh-4.2$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 8.0G 5.9G 2.2G 74% /というわけで8.0GB中、5.9GB使用で74%使っているということですね。思ったより使っているといった印象です。
では続いて、何が容量を使っているのか？の調査に移ります。
■ WordPressが原因か？
まず疑ったのはWordPress本体です。これが大きかったらどうしようもないですからね。調べておかないと。下記のコマンドを実行します。
du -h --max-depth=1 /var/www/htmlこれはざっくりいうとduはDiskUseなので「WordPressの各フォルダがどれくらい容量使ってるかを見る」 コマンドです。結果はこちら
sh-4.2$ du -h --max-depth=1 /var/www/html
11M /var/www/html/wp-admin
468M /var/www/html/wp-content
56M /var/www/html/wp-includes
534M /var/www/htmlhtmlフォルダの中にフォルダが３つなので、WordPressの利用容量は現在534MBでしょうか。全体の使用が6GBだったことを思うとWordPressがクリティカルな原因ではないように思えます。
■ ディスク全体を調査する
WordPressじゃなきゃなんなんだってことで今度は全体で調査します。
sudo du -h --max-depth=1 /全体なのでSudoでコマンドを実行します。結果はこちら。（ちょっと省略してます。）
sh-4.2$ sudo du -h --max-depth=1 /
35M /etc
416K /run
4.0K /tmp
2.3G /var
1.5G /usr
65M /boot
20M /home
1.5M /opt
44K /root
5.8G /とりあえず/varが2.3Gで一番多くて、ここにWordPressの534MBが入っていたとしても、1.7GBは何かが食い潰しているということがわかりました。というわけで今度は/varの中身について詳しくみていきます。下記のコマンドを実行。
sudo du -h --max-depth=1 /var結果はこちら。
sh-4.2$ sudo du -h --max-depth=1 /var
741M /var/cache
944M /var/log
76M /var/lib
172K /var/spool
534M /var/www
2.3G /varというわけで/var/cache、/var/log が多いですね。名前からしてキャッシュとログってわけですね。これで1.7GBくらいは使っていそうです。
では、そもそも/var/cache、/var/logとは何者なのか、チャッピーに聞いてみました。
以下チャッピーより
/var/log はサーバーの動作を記録するログが保存されるディレクトリです。
/var/cache は処理を高速化するための一時データが保存されるディレクトリです。
どちらも自動的にデータが増えていくため、定期的な整理が必要になります。とのこと。ログは仕事であれば別のところにコピーして残しておく必要がありそうですが、これは私の個人的趣味なので一旦不要ですかね。キャッシュも一時データなので不要かも？必要であればまた勝手に入るでしょう。ということで、どちらもなんらかの対策は必要そうですが、当座はいらないので、今回は一旦、クリアすることを目的にしたいと思います。
■ ログとキャッシュをクリアする
まずはログをクリアしてみます。コマンドはこちら。
sudo journalctl --vacuum-size=100Mこれは「systemdログを「合計100MBになるまで削除する」コマンド」。古いログをクリアします。ちなみにスイッチを調整することでいろいろ条件を変えられるみたいです。
キャッシュのクリアは単純にフォルダ内を削除します。
sudo rm -rf /var/cache/*削除なんで勇気が要りますが、チャッピーが言った通りやってみます。自己責任です。キャッシュなので消したら動かないということはなく、多少遅くなる機能があっても、必要なものは再度ここにたまると思います。なので一旦消して様子をみます！
で、上記コマンドを実行してから状況を再度確認してみます。
sh-4.2$ sudo du -h --max-depth=1 /var
0 /var/cache
240M /var/log
76M /var/lib
172K /var/spool
534M /var/www
849M /varということで、/var/cache は741MBから0に。/var/logは944MBから240MBに。そして全体が2.3GBから849MBに削減しました。動作確認でサイトの動きを見てみましたが、とりあえず問題はなさそうです。ちなみに全体の利用容量も74%から56%まで低下しました。
■ まとめ
今回はバックアップファイルのサイズが大きいことをきっかけに、EC2のディスク容量を調査しました。
当初はWordPressの画像やコンテンツが原因だと考えていましたが、実際には /var/log に蓄積されたOSのログと /var/cache のキャッシュデータ が大きな割合を占めていました。
今回のポイントは以下の通りです。
- df -h でディスク全体の使用状況を確認する
- du -h でディレクトリごとの使用量を調査する
- WordPressだけでなく、OS側のログやキャッシュも確認する
特に、systemdのログ（/var/log/journal）は放置すると大きくなりやすいため、定期的に整理しないとダメですね。最終的には必要なログをどこかに保持してEC2の容量は定期的にクリアして余裕を持たせるという運用にしたいです。また、/var/cache のようなキャッシュデータは削除しても必要であれば再生成される（と思う）ので、定期的にクリアして必要なものだけ残るようにするといいですね。
今後は、ログもちゃんと運用したいんですが、プライオリティ的にはだいぶ後ですかね。とりあえず次回はバックアップができずに止まっていたWordPressのバージョンアップをしたいと思います！
ではまた。