io2ボリュームタイプのEBSのIOPSを変更して結果が反映されるまでの時間を確認しました

io2のIOPSを増減してEBSのパフォーマンスとして反映されるまでの時間を知りたかったので手を動かしました。検証結果を紹介します。

#Amazon EBS

#AWS

大村保貴

2021.10.16

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

長時間安定した高IOPS確保したくEBSのボリュームタイプio2を検討していました。

「io2」新しいEBS(プロビジョンド IOPS)が利用可能になりました | DevelopersIO

以下のリンクから指定したIOPSの値を変更できることはわかりました。設定変更後の値がEBSのパフォーマンスとして反映されるまでの時間を知りたかったので確認してみました。

You can only increase volume size. You can increase or decrease volume performance.

Request modifications to your EBS volumes - Amazon Elastic Compute Cloud

Icons made by Freepik from www.flaticon.com

結論

ボリュームパフォーマンスは増減できる
io2のIOPS増減の変更は1分程度で結果が反映され、パフォーマンスアップ、ダウンできる

ちなみにボリュームサイズは増やすことしかできませんのでご注意ください。また、ボリュームサイズ変更、パフォーマンス変更の変更操作を連続して行えません。次の変更操作まで6時間の空き時間が必要です。高いIOPSを指定し過剰だったから戻そう！と思っても戻す変更操作を行えるのは6時間後です。

検証してみた

検証用のインスタンスを準備します。インスタンスのスペックで足を引っ張らないようにEBS最適化インスタンスからc5.9largeを選択しました。OSはAmazon Linux2です。

Amazon EBS–optimized instances - Amazon Elastic Compute Cloud

EBSは以下の様にio2のボリュームタイプを追加でアタッチしました。io2のIOPSは1000指定しました。

追加したEBSは以下のリンクを参考に/mnt/io2へマウントしています。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs          35G     0   35G    0% /dev
tmpfs             35G     0   35G    0% /dev/shm
tmpfs             35G  540K   35G    1% /run
tmpfs             35G     0   35G    0% /sys/fs/cgroup
/dev/nvme0n1p1   8.0G  1.5G  6.6G   19% /
tmpfs            6.9G     0  6.9G    0% /run/user/1000
/dev/nvme1n1      10G   43M   10G    1% /mnt/io2

追加EBSをマウントしたディレクトリに対してランダム書き込み発生させます。書き込み負荷を上げた状態のままEBSに対してIOPSの変更をかけ、CloudWatchのメトリクスからIOPSの変化を確認します。

sudo yum install fio -y
fio -filename=/mnt/io2/testfio.file -direct=1 -ioengine=libaio -rw=randwrite -bs=16k -size=5G -group_reporting -name=randread -numjobs=64 -runtime=18000

IOPS上げる

書き込み対象のEBSのIOPSを確認します。1分間隔で取得したメトリクスでVolumeWriteOpsが63,213なので63213 / 60 = 1037IOPSとなります。 1000IOPS指定のio2なので上限までI/O負荷（Write only）かかっていることを確認できました。

io2のIOPSを1000から2000へ変更します。

「パフォーマンスの変更が完全に反映されるまでに時間がかかることがあります。」

ランダム書き込みは継続中です。VolumeWriteOpsが120,972なので120972 / 60 = 2016IOPSとなります。上限までI/O負荷かかっていることが確認できました。

さて、IOPS変更から何分で反映されたのでしょうか？確認してみましょう。

CloudTrailからEBSのIOPSを変更したイベントを確認します。今回の変更操作したイベントModifyVolumeが10:09:40（JST）に記録されていました。

CloudWatchのメトリクスから確認すると1分単位なので正確な秒数までは確認できないのですが10:10（JST）のメトリクスで2000IOPSになっています。1分もあればパフォーマンスの変更が適用されていることがわかりました。なにを以て「完全に反映された」と判定すればよいのかはわかりませんが、メトリクスからは変更要求したIOPSの値を確認できました。

変更操作の注意事項として、EBSの変更操作は6時間の間隔を空けないとボリュームサイズ、パフォーマンスを変更できないので注意してください。

IOPSを下げたときの様子を確認したいですが同じEBSに対して連続操作はできません。

After modifying a volume, you must wait at least six hours and ensure that the volume is in the in-use or available state before you can modify the same volume. This is sometimes referred to as a cooldown period.

引用: Requirements when modifying volumes - Amazon Elastic Compute Cloud