Ubuntu 16.04で作ったEC2のEBS容量を縮小する

しがひ

2018.02.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

昨年の初頭から作成後のEBSのボリュームタイプの変更とサイズの拡張が可能になりましたが、このアップデートにボリュームサイズの縮小は含まれていません。

ベルリンオフィスでブロックチェーン関連のサーバーを立てると、立ち上げのスナップショット同期時に確保していたEBSが運用時に無駄になるケースが多いため、容量の縮小方法を検討しました。

やってみた

元のEBSボリューム26GBを10GBに減らします。いくつかやり方がありますが、今回はAMIを経由せず、かつ元のEC2インスタンス以外に作業用インスタンスを作成しないで行います。

まず目的のEC2を停止してEBSをデタッチ、そのスナップショットを作成します。なおDockerがデタッチドモードで動いている場合はdownで落としておいたほうが無難です。

同じアベイラビリティゾーンに縮小後のサイズに仕立てたカラのボリューム（new）と、スナップショットから起こしたボリューム（snapshot）を作成します。これを元のEBSボリューム（original）と一緒に次のデバイス名で元のEC2インスタンスにアタッチします。

original --> /dev/sda1
new --> /dev/sdf
snapshot --> /dev/sdg

インスタンスを起動してSSHでディスクデバイスの状態をみてみます。

:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             1015424       0   1015424   0% /dev
tmpfs             204680    3052    201628   2% /run
/dev/xvdg1      26362600 5032792  21313424  20% /
tmpfs            1023384       0   1023384   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            1023384       0   1023384   0% /sys/fs/cgroup
tmpfs             204680       0    204680   0% /run/user/1000

:~$ ll /dev/xvd*
brw-rw---- 1 root disk 202,  0 Feb 11 20:30 /dev/xvda   //snapshotボリューム
brw-rw---- 1 root disk 202,  1 Feb 11 20:30 /dev/xvda1  
brw-rw---- 1 root disk 202, 80 Feb 11 20:37 /dev/xvdf   //newボリューム  --> xvdf1がないのでファイルシステムを持たないカラのnewボリュームだとわかる
brw-rw---- 1 root disk 202, 96 Feb 11 20:30 /dev/xvdg   //original （起動）ボリューム
brw-rw---- 1 root disk 202, 97 Feb 11 20:30 /dev/xvdg1

起動ディスクが/dev/xvdg1になっていることがわかります。Linuxのカーネルが/dev/sd●●を/dev/xvd●●に書き換えるのは正常ですが、このようにxvdaではなく本来はセカンダリ以降に割り振られるxvdg1が当たることもあるので、必ず確認した上で作業を進めます。以降はこの状態を前提にコマンドを書きます。

new用のext4ファイルシステムを作成します。

:~$ sudo mkfs.ext4 /dev/xvdf

ディレクトリを作ってsnapshot とnew をマウントします。

:~$ sudo mkdir /mnt/new
:~$ sudo mkdir /mnt/snapshot
:~$ sudo mount /dev/xvdf /mnt/new
:~$ sudo mount -t ext4 /dev/xvda1 /mnt/snapshot

そうするとこういう感じのデバイス構成になります。

:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             1015424       0   1015424   0% /dev
tmpfs             204680    8140    196540   4% /run
/dev/xvdg1      26362600 5037948  21308268  20% /
tmpfs            1023384       0   1023384   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            1023384       0   1023384   0% /sys/fs/cgroup
tmpfs             204680       0    204680   0% /run/user/1000
/dev/xvdf       10190136   23028   9626436   1% /mnt/new
/dev/xvda1      26362600 3703288  22642928  15% /mnt/snapshot

起動ディスクのレーベルを確認します。

:~$ sudo e2label /dev/xvdg

おそらく cloudimg-rootfs という値が帰ってくるので、xvdfを同名で命名します。

:~$ sudo e2label /dev/xvdf cloudimg-rootfs

snapshotをnewにrsync します。

:~$ sudo rsync -ax /mnt/snapshot/ /mnt/new/

ブートローダGRUBをxvdfにインストールします。

:~$ sudo grub-install --root-directory=/mnt/new/ --force /dev/xvdf

newをアンマウントします。

:~$ sudo umount /mnt/new

UUIDを確認します。

:~$ sudo blkid
/dev/xvda1: LABEL="cloudimg-rootfs" UUID="xxxxxxx-xxxxx-xxxxx-xxxx-xxxxxxx" TYPE="ext4" PARTUUID="xxxxxxx-01"
/dev/xvdf: LABEL="cloudimg-rootfs" UUID="yyyyyyyy-yyyyy-yyyyy-yyyy-yyyyyyy" TYPE="ext4" PTTYPE="dos"
/dev/xvdg1: LABEL="cloudimg-rootfs" UUID="xxxxxxx-xxxxx-xxxxx-xxxx-xxxxxxx" TYPE="ext4" PARTUUID="xxxxxxx-01"

xvdfのUUIDをxvdg1と同じに書き換えます。

:~$ sudo tune2fs -U xxxxxxx-xxxxx-xxxxx-xxxx-xxxxxxx /dev/xvdf

書き換わっているか確認します。

:~$ sudo blkid
/dev/xvda1: LABEL="cloudimg-rootfs" UUID="xxxxxxx-xxxxx-xxxxx-xxxx-xxxxxxx" TYPE="ext4" PARTUUID="xxxxxxx-01"
/dev/xvdf: LABEL="cloudimg-rootfs" UUID="xxxxxxx-xxxxx-xxxxx-xxxx-xxxxxxx" TYPE="ext4" PTTYPE="dos"
/dev/xvdg1: LABEL="cloudimg-rootfs" UUID="xxxxxxx-xxxxx-xxxxx-xxxx-xxxxxxx" TYPE="ext4" PARTUUID="xxxxxxx-01"

ここまでの作業が終わったらインスタンスをstopし、全てのボリュームをデタッチし、newを/dev/sda1にアタッチし直してインスタンスを起動します。

:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             1015424       0   1015424   0% /dev
tmpfs             204680    3040    201640   2% /run
/dev/xvda       10190136 3729512   5919952  39% /   // 今回はxvdaに割り当たった
tmpfs            1023384       0   1023384   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            1023384       0   1023384   0% /sys/fs/cgroup
tmpfs             204680       0    204680   0% /run/user/1000

見事に10GにリサイズされたEBSで起動しました。

とはいえ、コンソールで簡単にできる容量拡張とは違い、縮小はこのようにLinuxのパーティションの操作が必要でリスクを伴いますので、ブロックチェーンノードのような特殊な場合以外ではお勧めできるオペレーションではありませんし、大きくコストを削減できるわけでもありません。柔軟な伸縮ができる構成とシミュレーションに基づいたサイジングでしっかり計画を立てることが肝要です。

クラスメソッドでは、日本、バンクーバー、ベルリンで一緒に働く仲間を募集しています！採用情報｜クラスメソッド株式会社