この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
長時間安定した高IOPS確保したくEBSのボリュームタイプio2を検討していました。
以下のリンクから指定したIOPSの値を変更できることはわかりました。設定変更後の値がEBSのパフォーマンスとして反映されるまでの時間を知りたかったので確認してみました。
You can only increase volume size. You can increase or decrease volume performance.
-
Icons made by Freepik from www.flaticon.com
結論
- ボリュームパフォーマンスは増減できる
- io2のIOPS増減の変更は1分程度で結果が反映され、パフォーマンスアップ、ダウンできる
ちなみにボリュームサイズは増やすことしかできませんのでご注意ください。 また、ボリュームサイズ変更、パフォーマンス変更の変更操作を連続して行えません。次の変更操作まで6時間の空き時間が必要です。高いIOPSを指定し過剰だったから戻そう！と思っても戻す変更操作を行えるのは6時間後です。
検証してみた
検証用のインスタンスを準備します。インスタンスのスペックで足を引っ張らないようにEBS最適化インスタンスからc5.9largeを選択しました。OSはAmazon Linux2です。
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=18000IOPS上げる
書き込み対象の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
IOPS下げる
せっかちなので新しいio2のEBSを同じインスタンスにマウントして検証を続けます。
5000IOPSを指定したio2のEBSです。311038 / 60 = 5184IOPSとなり、上限までI/O負荷かかっていることが確認できます。
io2のIOPSを5000から100（下限値）へ変更します。
CloudTrailからEBSのIOPSを変更したイベントを確認します。ModifyVolumeイベントが10:31:09（JST）に記録されていました。
CloudWatchのメトリクスから確認すると10:31（JST）のメトリクスで100IOPSになっています。1分かからずパフォーマンスの変更が適用されていることが確認できました。
おわりに
EBSのメトリクスはEC2の詳細モニタリング的なものなしに1分単位で確認できたかと疑問でした。io2は昔から1分単位で確認でき、その他gp3なども含め2021年1月から1分単位で確認できるようになっていることを知りました。加えて、追加料金も発生しないのは嬉しいポイントですね。
4
