容量がいっぱいでAWSにデプロイできなかった時の対処方法

＊ 2021年1月23日追記
この記事を書いた後、調べてみると
「/var/www/アプリケーション名/shared/log」に置かれている「production.log」というログファイルが3Gも使用していたことがわかりました。
そのため、production.logの中身を一度空にし、ログローテートの設定をすることで、今回の容量に関する問題は解決することができました。
詳しくは、以下の記事で解説しています。よろしければご覧ください。

AWSでproduction.logが肥大化した時の対処方法 & ログローテート方法

今回発生した問題

AWS初学者です。

今回は
「AWS内の『/dev/xvda1』の容量がいっぱいだったためにデプロイできなかった」
という問題が発生したので、その解決策をメモしておきたいと思います。

結果的に
「logファイルを500MBほど削除すること」
により、無事デプロイすることができました。

背景

個人で作っているRailsアプリをAWSにデプロイしようとした時のことです。
いつものようにターミナルから「bundle exec cap production deploy」でデプロイしたところ、
「SSHKit::Command::Failed」　といったエラーが表示され、デプロイできませんでした。

しかし、AWS EC2へのSSH接続は問題なくできました。

ターミナル

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
3 package(s) needed for security, out of 7 available
Run "sudo yum update" to apply all updates.
/home/ec2-user/.rbenv/libexec/rbenv-init: 行 131: ヒアドキュメント用一時ファイルを作成できません: No space left on device

ん？
「No space left on device」とありますね。
調べたところ、「空き容量が不足しているよ」と知らせてくれているようです。

SSH接続したままで「df -h」を実行して、空き容量を確認してみます。

ターミナル

$ df -h
ファイルシス        サイズ  使用    残り  使用%  マウント位置
devtmpfs         474M     0  474M     0%  /dev
tmpfs            492M     0  492M     0%  /dev/shm
tmpfs            492M  428K  492M     1%  /run
tmpfs            492M     0  492M     0%  /sys/fs/cgroup
/dev/xvda1       8.0G  8.0G    0M   100%  /
tmpfs             99M     0   99M     0%  /run/user/0
tmpfs             99M     0   99M     0%  /run/user/1000

dfコマンドは、ファイルシステムの全容量、使用中の容量、残りの容量、使用率（%）、マウント位置を表示するコマンドです。
「-h」というオプションをつけると、「K、M、G」などの単位がついた状態で表示され、わかりやすくなります。

その結果、「/dev/xvda1」が使用率100%になっており、デプロイするための容量が全く残っていないことがわかりました。したがって、容量を空けるために、不要なファイルを整理しなければなりません。

※ ちなみにマウント位置の意味に関しては勉強中です。
今わかっていることとして、マウントの意味は、「コンピュータに接続した機器やメディアをコンピュータに認識させ、使える状態にすること」、
マウント位置は「新たに追加したストレージ装置などにアクセスできるように仮想的なディレクトリとして登録したもの」だそうです。

解決した方法

まずは容量が大きいディレクトリを調査

まずは、duコマンドでどこのディレクトリの容量が大きいのかを調べます。
そのままでは、権限の関係で一部のディレクトリが読み込めないため、頭にsudoコマンドをつけて全てのディレクトリを読み込めるようにしましょう。

ターミナル

$ sudo du -sh /*

(容量の少ないものは省略)
/var 4.9G
/usr 1.7G

duコマンドは、指定したファイルやディレクトリの使用容量を表示してくれるコマンドです。

-sオプションは「総計を表示する」という役割があるそうです。これをつけないとサブディレクトリまで全て表示されるため、とんでもない量が表示されてしまいます。

-hオプションはさっきと同じです。「K、M、G」などの単位がついた状態で表示されます。

/*は「0文字以上のディレクトリ」という意味があります。つまり、全てのディレクトリを表示させることができます。

duコマンドの結果、/var（4.9G）と/usr(1.7G)の容量が大きいことがわかったため、ここを整理すればよさそうです。

varディレクトリを調査

それでは、「cd var」でvarディレクトリに移動した後、duコマンドで容量が大きい、上位5位までのディレクトリを表示してみます。

ターミナル

$ cd /var
[var]$  sudo du -sm ./* | sort -rn | head -5

3971    ./www
733	    ./log
217	    ./cache
86	    ./lib
1	    ./tmp

-sは、先ほど説明したオプションです。
-mオプションは、M（メガバイト）単位で表示してくれます。

sortコマンドは、テキストファイルを並び替えるコマンドです。デフォルトは昇順で並べるため、-rオプションにより降順で表示します。
さらに、-nオプションをつけることで、数字が大きいものから順に表示されるようになります（-nオプションがなければ、「86 → 733 → 3971 → 217 → 1」と表示されてしまう）。

headコマンドは、テキストファイルの先頭10行を表示するコマンドです。今回は「-5」というオプションをつけているので、容量の大きさが上位5つのディレクトリが表示されます。

容量が大きい上位5つを表示した結果、wwwディレクトリとlogディレクトリが大きいことがわかりました。
しかし、wwwディレクトリにはアプリのディレクトリ本体が入っているため、削除できるファイルが思いつきませんでした。

そのため、2番目に多いlogファイルを整理してみることにしました。

さらにlogファイルを調査

「cd log」でlogファイルに移動し、その中でどのディレクトリの容量が大きいのか調べていきます。先ほどのvarディレクトリと同じように、容量が大きい上位5つのディレクトリを調べていきます。

ターミナル

$ cd log
[log]$ sudo du -sm ./* | sort -rn | head -5

633	./journal
37	./audit
17	./sa
10	./btmp
8	./secure-20201227

その結果、journalディレクトリが最も大きいことがわかりました。journalディレクトリには、システムのログなどが記録されているようです。ここ最近のログさえ残っていれば問題ないと考えたため、journalディレクトリ内を整理することにしました。

journalctlコマンドを用いて削除

journalctlコマンドを用いることで、ジャーナルファイルの容量を確認したり、ジャーナルファイルの削除を行うことができます。
今回は、ここ3日分のログだけ残して、それより古いものは削除したいと思います。
以下のコマンドで実行できます。

ターミナル

$ cd journal
[journal]$ sudo journalctl --vacuum-time=3days 

ちなみに、「sudo journalctl --vacuum-size=100M」で「100M分残し削除する」といった方法もあるようです。

削除が終わったら、logディレクトリに戻り、容量を確認してみます。

ターミナル

$ cd /var
[var]$ cd log
[log]$ sudo du -sm ./* | sort -rn | head -5

57	./journal
37	./audit
17	./sa
10	./btmp
8	./secure-20201227

これで550M以上削除できました！

「df -h」での容量の確認もしてみると…

ターミナル

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         474M     0  474M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  428K  492M    1% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1       8.0G  7.5G  555M   94% /
tmpfs             99M     0   99M    0% /run/user/0
tmpfs             99M     0   99M    0% /run/user/1000

/dev/xvda1の使用率が100% → 94%になりました！

この後、「sudo yum update」と「bundle exec cap production deploy」を実行すると、無事デプロイすることができました。

今後の目標

今回は何とかなりましたが、使用率は94%と多いままなので、また100%に戻ってデプロイできない、という事態になるかもしれないですね。

僕自身も、「このファイルなら削除してもいい」ということがまだわかっていないため、「不要なファイルを判断できるようになること」が目標ですね。

または、「AWSの容量自体を拡張する」という対処も考えた方がよさそうです。

あとは、「古いログファイルを定期的に削除する」ということも大事だと感じました。

参考記事

以下、参考にさせていただいた記事です。
ありがとうございました。

ディスク空き容量が不足してきた件：
https://www.souichi.club/aws/out-of-disk-space/

journalctlログを削除する：
https://mebee.info/2020/07/18/post-14146/