EC2インスタンスのBootドライブがいっぱいで起動できない時の対処法

現状

Bootドライブの空き容量がなくなり、サーバー内のアプリが起動できない
新たなファイルが一切追加できず、新規公開鍵追加による直接ログインも不可能な状況

用語解説

該当インスタンス
- ディスクフルとなって問題を引き起こしているEC2インスタンスのこと
該当ストレージ
- 該当インスタンスのBootドライブ（EBS）のこと
- 空き容量がほぼない
レスキューインスタンス
- 今回の問題を解決するため、一時的に作成する最小構成インスタンス
デタッチ
- インスタンスとEBSの結びつけを解除すること
アタッチ
- インスタンスとEBSを結びつけること

作業方針

該当インスタンスを停止
該当ストレージを該当インスタンスからデタッチ
レスキューインスタンスを作成し、追加ドライブとして該当ストレージをアタッチ
- この時点でレスキューインスタンスは2つのEBSが紐付けられる
該当ストレージ内のデータ容量を精査し、不必要なものは削除する
- 削除しても空き容量が十分に確保できない場合は、ストレージの大きさを拡張するために5と6の追加作業を行う
レスキューインスタンスから該当ストレージをデタッチ
AWS上から該当ストレージの容量を拡張する
該当ストレージを元のインスタンスにアタッチ
OS上からパーティションを拡張し、空き容量を確保する
本作業のために新たに作成したリソースを削除する

1.AWSでの作業

該当インスタンスの停止
- AWSコンソールから「EC2 > インスタンス > インスタンス」へ
- 該当インスタンスをシャットダウン
  - シャットダウンの仕方
  - - 可能であればインスタンスへログイン後に`sudo shutdown -h now`でも可
- それでも停止できない場合は強制終了
該当インスタンスに紐付いていたストレージをデタッチ
- 「EC2 > ELASTIC BLOCK STORE > ボリューム」へ
- 先程停止したインスタンスのインスタンスIDで検索するとよい
  - インスタンスIDの調べ方（これは EC2 > インスタンス > インスタンスで実施）
- デタッチ
- 完了後に念の為にスナップショットを取得しておくとよい
- - 誤った操作などによる今後のデータ破損にも対応できるため、面倒でも実施をおすすめします
新規インスタンスを作成
- OSはUbuntu18.04
- フレーバーはt3a.nano
- サブネットは救出対象と同じサブネットに所属させること
- SSDの容量は8GB
レスキューインスタンスに該当ストレージをアタッチする
- 「EC2 > ELASTIC BLOCK STORE > ボリューム」へ
- 該当ストレージを選択してアタッチ
- 対象インスタンスは今回のために作ったレスキューインスタンス

2.レスキューインスタンス内での作業

レスキューインスタンスへSSHでログイン

# マウントポイントの作成
$ mkdir add_extra
# ディスクの確認
$ lsblk
NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0         7:0    0  89M  1 loop /snap/core/7713
loop1         7:1    0  18M  1 loop /snap/amazon-ssm-agent/1480
nvme0n1     259:0    0   8G  0 disk
└─nvme0n1p1 259:1    0   8G  0 part /
nvme1n1     259:2    0   8G  0 disk
└─nvme1n1p1 259:3    0   8G  0 part
> この中でnvme1n1p1が今回追加でアタッチしたディスクフルの該当ストレージ
> 名前は異なる可能性があるので適時読み替えること
> この名前は後ほど使用するのでメモしておくこと
# マウント
$ sudo mount /dev/nvme1n1p1 add_extra
> 先程の名前をもとにマウントする
# 権限を変更
$ sudo chown ubuntu:ubuntu add_extra/
# 容量を大きく使用しているディレクトリ順に並べる
$ cd add_ectra
$ sudo du -m | sort -rn | head -50
> 不必要なものがあれば削除・圧縮する
> ここで十分な容量が確保でき、ストレージの増加が不要であると判断できた場合は 5.AWSでの作業 へ

3.AWSでの作業

レスキューインスタンスから該当ボリュームのデタッチ
- 「EC2 > ELASTIC BLOCK STORE > ボリューム」へ
EBS容量の拡張
- 先程と同じ画面から操作
- ここで容量増加後の容量を入力する
該当インスタンスをレスキューインスタンスへ再度アタッチ
- 先程と同じ画面から操作

4.レスキューインスタンス内での作業

# ディスクの確認
$ lsblk
# マウント
$ sudo mount /dev/nvme1n1p1 add_extra
# ファイルシステムの拡張
$ sudo growpart /dev/nvme1n1 1
# パーティションの拡張
$ sudo resize2fs /dev/nvme1n1p1
# 容量の確認
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            220M     0  220M   0% /dev
tmpfs            47M  744K   46M   2% /run
/dev/nvme0n1p1  7.7G  1.2G  6.6G  15% /
tmpfs           231M     0  231M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           231M     0  231M   0% /sys/fs/cgroup
/dev/loop0       90M   90M     0 100% /snap/core/7713
/dev/loop1       18M   18M     0 100% /snap/amazon-ssm-agent/1480
/dev/nvme1n1p1   20G  7.7G   12G  40% /home/ubuntu/add_extra
/dev/loop2       90M   90M     0 100% /snap/core/7917
tmpfs            47M     0   47M   0% /run/user/1000
> /dev/nvme1n1p1の容量が20Gとなっていることが確認できる

5.AWSでの作業

レスキューインスタンスの停止
- AWSコンソールから「EC2 > インスタンス > インスタンス」へ
- 該当インスタンスをシャットダウンします
- インスタンスログイン後に`sudo shutdown -h now`でも代用可能
スキューインスタンスからボリュームのデタッチ
- 「EC2 > ELASTIC BLOCK STORE > ボリューム」へ
該当インスタンへ該当ストレージのアタッチ
- 先程と同じ画面から操作
- 今回はBootドライブのアタッチのため、デフォルトの値ではなく`/dev/sda1`と入力すること
再起動
- AWSコンソールから「EC2 > インスタンス > インスタンス」へ

6.インスタンス内での作業

SSHでのログインができるか、アプリが動作するかなどを適時確認・修復を実施してください
- 本作業をここまで実施しても、全てが正常に起動するかは正直なところ「運」です
  - Bootドライブの空き容量が不足することはマシンにとってはかなり深刻な症状です
  - 必要なデータが書き込めず、データの整合性が取れなくなり、アプリが起動しなくなるだけではなくOSに深刻なダメージを与える可能性もあります
  - ストレージの監視やデータのローテーションを検討してください

7.AWSでの作業

レスキューインスタンスとBootストレージの削除
- デフォルトではレスキューインスタンスを削除すればBootドライブも一緒に削除されます
スナップショットの削除
- 念の為に残していおいても良いです
- わずかとはいえ、課金対象に含まれるので気になる方は削除したほうが良いです

8.最後に

お疲れさまでした。今回は以上で終了となります。
繰り返しとなりますが、Bootドライブのストレージフルはマシンにとってかなり深刻な状況となります。大事なアプリやデータを守る意味でも、監視や自動的に空き容量を確保する仕組みの構築を強くおすすめします。