AWS メモリ不足時のEBSボリュームのファイルシステムを拡張

はじめに

Capistorano　を使った自動デプロイの実装中、
”bundle exec cap production deploy”を実行すると悲惨なエラーが起こりました。
一瞬、「不能」が「無能」に見えて心が折れそうでした。

（中略）
ar: vendor: mkdir 不能: No space left on device
 DEBUG [7d5bfec5] 	tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/README.md: open 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib: mkdir 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib/websocket: mkdir 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
 DEBUG [7d5bfec5] 	tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib/websocket/extensions.rb: open 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib/websocket/extensions: mkdir 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
（中略）

「No space left on device」　とある通り、インスタンスのストレージの問題なんだろうなぁ、、、と思っていましたがそうでした。
対応をまとめたので是非参考に。

チェック

本当にボリュームがいっぱいか、確認していきます。
インスタンスに接続してEC2サーバーで以下のコマンドを実行します。

lsblk コマンドはボリュームに拡張が必要なパーティションがあるかどうかを確認します。

$ lsblk 
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /

インスタンスにアタッチされているブロックデバイスに関する情報を表示されています。
ルートボリュームxvda　にはパーティション /dev/xvda1 が存在し、初期設定通り８GBサイズであることが確認できます。

---

df -h コマンドは各ボリュームのファイルシステムのサイズを確認します。

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

/dev/xvda1 の使用率が100％で拡張の必要性があることが分かります。
いくつかの記事を見た限り、100％でなくても80％を超えると挙動が重たくなったりエラーが発生したり、拡張の必要があることもあるようです。

ボリューム変更

AWS Linux インスタンス用ユーザーガイド EBSボリュームへの変更のリクエストを参考に、AWSのEC2マネジメントコンソールからボリューム変更します。

パーティションの拡張

再度、 lsblkコマンドで増加したボリュームサイズがパーティションに反映されていることを確認します。
（反映には時間がかかることもあるそうですが、私は1分程度で反映されていました。）

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  16G  0 disk 
└─xvda1 202:1    0   8G  0 part /

ルートボリュームxvda には変更時点で自動的に新しいサイズ (16 GB) が反映されますが、パーティションxvda1には元のサイズ (8 GB) が反映されるため、ファイルシステムを拡張する前に拡張する必要があります。

lsblk -f コマンドでマウントポイントに関する詳細情報も確認できます。

$ lsblk -f
NAME    FSTYPE LABEL UUID                                 MOUNTPOINT
xvda                                                      
└─xvda1 xfs    /     55ee5a5f-d155-47e0-9121-e6f4522cb2bf /

xvda1 がXFSタイプのファイルであることが分かります。
　
　
「No space left on a block device (ブロックデバイスに空きスペースがありません)」エラーを回避するには、一時ファイルシステムである tmpfs を /tmp マウントポイントにマウントします。これにより、10 M の tmpfs が /tmp にマウントされます。

$ sudo mount -o size=10M,rw,nodev,nosuid -t tmpfs tmpfs /tmp

　
growpart コマンドを実行して、ルートパーティション(xvda1)のサイズを拡大します。/dev/xvda 1 をルートパーティションに置き換えます。
※　"xvda 1"にスペースが含まれることに注意。

$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=33550303 end=33554399

lsblk コマンドを実行して、パーティションが16GiBに拡張されていることを確認します。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  16G  0 disk 
└─xvda1 202:1    0  16G  0 part /

　
次に、ファイルシステムを展開します。ルートパーティション「/」のファイルシステムを確認します。
以下では、XFSタイプのファイルシステムが展開されています。

$ sudo xfs_growfs -d /
meta-data=/dev/xvda1             isize=512    agcount=4, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1 spinodes=0
data     =                       bsize=4096   blocks=2096635, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2096635 to 4193787

　
最後にdf -h コマンドを使用して追加したスペースがOS上で表示されることを確認します。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         482M     0  482M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  412K  492M    1% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1        16G  8.0G  8.0G   51% /
tmpfs             99M     0   99M    0% /run/user/1001
tmpfs             10M     0   10M    0% /tmp
[kanji@ip-10-0-0-36 ~]$ sudo umount /tmp
[kanji@ip-10-0-0-36 ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         482M     0  482M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  412K  492M    1% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1        16G  8.0G  8.0G   51% /
tmpfs             99M     0   99M    0% /run/user/1001

　
unmount コマンドを実行して、tmpfs ファイルシステムをアンマウントします。

$ sudo umount /tmp

以上でエラーが解決します。

参考文献

・AWS ボリュームサイズ変更後の Linux ファイルシステムの拡張
・AWS ファイルシステムに空きスペースがないというエラーが表示された際に、EBS ボリュームのサイズを増やすにはどうすればよいですか?

puts 'I hope my article helps you.'