EC2 ディスクサイズの増量

必要になった経緯

インスタンスは起動しているが、EC2上で動かしているWEBページが落ちてしまっていた。

よくわからないまま、EC2を再起動してWEBページを再度たちあげたところ、数日後にまたもWEBページが落ちていた。

原因は、ディスク容量を使い果たしたことであった。

EC2を再起動すると、キャッシュなどが減ってディスクが1%空きが生まれたためWEBページが復活していたが、数日後にはすぐに100%になり、またWEBページが落ちるという事態になっていた。

ディスク100%ではファイルの書き込みや作成が一切不可になるため、ディスクの空きを作ってやる必要がある。

EC2インスタンスにSSH接続すると同時に、マシンに空き容量がないと警告が表示される

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


https://aws.amazon.com/amazon-linux-2/
/home/ユーザー名/.rbenv/libexec/rbenv-init: 行 131: ヒアドキュメント用一時ファイルを作成できません: No space left on device

ディスクの空き領域を確認して見ると100%になっている

[ユーザー名@ip-x-x-x-x ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         475M     0  475M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M   26M  467M    6% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1       8.0G  8.0G   20K  100% /
tmpfs             99M     0   99M    0% /run/user/1001

[ユーザー名@ip-x-x-x-x ~]$ df -i
ファイルシス   Iノード  I使用  I残り I使用% マウント位置
devtmpfs        121427    281 121146     1% /dev
tmpfs           125916      1 125915     1% /dev/shm
tmpfs           125916    365 125551     1% /run
tmpfs           125916     16 125900     1% /sys/fs/cgroup
/dev/xvda1      267752 267429    323   100% /
tmpfs           125916      1 125915     1% /run/user/1001

解決策

1. EC2を再起動

キャッシュや一時ファイルが削除されるので、場合によってはこれだけでディスク空き容量が大幅に増えることもあります。

これでもし十分な空き容量が確保できるようであれば解決です。

あまり変わらないようであれば、ディスクサイズを増やして解決しましょう。

2. ディスクサイズ(EBSボリュームサイズ)の増量

Amazon Elastic Block Store (EBS) は、Amazon Elastic Compute Cloud (EC2) と共に使用するために設計された、使いやすい高性能なブロックストレージサービスです。

必須条件 (参考: 公式ドキュメント)

・インスタンスタイプがElastic Bolumesのサポート対象であるか確認

    - すべての現行世代のインスタンス、もしくは次の旧世代のインスタンスであればOK: C1、C3、CC2、CR1、G2、I2、M1、M3、および R3

・2 TiB (2048 GiB) 以内でのブートボリュームのサイズ変更

    - 基本ないと思うが、2 TiB (2048 GiB) 以上のブートボリュームに変更したい場合、面倒だが公式ドキュメント見てやるしかない

・前回のボリューム変更から6時間以上経過

    - ボリュームに変更を加える場合、前回のボリューム変更後に6時間以上待機してから、そのボリュームの状態が in-use または available であることを確認

ボリュームを変更する場合は、次のプロセスで行います。

1. (任意) 重要なデータを含むボリュームを変更する前に、変更をロールバックする必要がある場合に備えて、ボリュームのスナップショットを作成するのが良い。

2. ボリュームの変更をリクエストします。

3. ボリューム変更の進行状況をモニタリングします。

4. ボリュームのサイズが変更された場合、増加されたストレージ容量を利用するには、ボリュームのファイルシステムを拡張します。

1. いざという時のためのロールバック用スナップショットを作成

AWSコンソールにログイン後、左側のナビゲーションバーからElastic Block Store下のボリュームをクリック

EC2にアタッチされているボリュームを探し、アクションからスナップショットの作成をクリック

2. ボリュームの変更をリクエスト

3. ボリューム変更の進行状況をモニタリング

EBSボリューム一覧で対象のボリュームを確認すると、状態列の値が変化しているはずです。 ボリュームの状態は modifying、optimizing、completed の順に変わるとのこと。ただ私の環境ではmodifyの状態は確認できず、すぐoptimizing（in-use - optimizing）になっていました。あまり大きく無いサイズだったからでしょうかね。 optimizing以降になっていれば次の操作が可能ですので、次に進みましょう。

4. ファイルシステムの拡張

筆者の場合は、何もせずファイルシステムに拡張されていたので作業終了だったのですが、ファイルシステム拡張の手順となる公式ドキュメントページを載せて起きます

公式ドキュメント https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

Linux初学者の場合はこちらの記事の方がわかりやすい https://qiita.com/mangano-ito/items/629b10ea5d1ab80f2cc6

変更確認

/dev/xvdaが、ボリュームが８GiB->10GiBに変わっていることを確認

[ユーザー名@ip-x-x-x-x ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         475M     0  475M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  420K  492M    1% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1        10G  8.0G  2.0G   81% /
tmpfs             99M     0   99M    0% /run/user/1001

[ユーザー名@ip-x-x-x-x ~]$ df -i
ファイルシス   Iノード  I使用   I残り I使用% マウント位置
devtmpfs        121427    281  121146     1% /dev
tmpfs           125916      1  125915     1% /dev/shm
tmpfs           125916    351  125565     1% /run
tmpfs           125916     16  125900     1% /sys/fs/cgroup
/dev/xvda1     4444760 267411 4177349     7% /
tmpfs           125916      1  125915     1% /run/user/1001

おまけ

ロールバックできるように作成したスナップショットがあれば、いつでもその時点の状態まで復元することができます。

スナップショットとは、ある時点でのソースコードや、ファイル、ディレクトリ、データベースファイルなどの状態を抜き出したもののこと

復元手順の参考記事 https://qiita.com/takahashi-kazuki/items/23a5a7c62fc086d51909