EBS でボリュームサイズ/タイプ変更時のパフォーマンスを検証してみた
こんにちは、菊池です。
今週発表されたアップデートにより、EC2にアタッチされたEBSがオンラインでサイズ/タイプの変更が可能になりました。
- Amazon EBS Update – New Elastic Volumes Change Everything
- 【遂に来た！】EBS でボリュームサイズを変更できるようになりました（ボリュームタイプ変更も）
はじめに
これまで、容量や性能の不足で悩んでいた方には嬉しいアップデートですね！本番環境での移行を検討されている場合には、まず以下のドキュメントをみて、注意事項をよく理解した上で実施するのがいいでしょう。
ドキュメントによると以下の点に注意が必要です。
- ボリュームのデタッチまたはインスタンスの停止が必要なケースがある
- 変更時にエラーメッセージが表示された場合
- 旧世代のインスタンスにアタッチされたボリューム
- 旧世代のマグネティックボリュームでは変更がサポートされない
- 一度変更した後、同じボリュームは6時間は変更ができない
また、オンラインで変更するにあたり、以下の点も気になるかと思います。
- 変更時にパフォーマンスの劣化などがないか
- 変更後、どの程度の時間でパフォーマンスが変化するか
という訳で、変更タイミングでのパフォーマンスがどのように推移するか検証しましたので紹介します。
検証内容
EC2にアタッチしたEBSにI/Oをかけ続けた状態で、パフォーマンスを計測します。
検証環境
- 利用したAMI：Amazon Linux AMI 2016.09.1 (HVM), SSD Volume Type
- インスタンスタイプ：c4.large（EBS最適化）
- ファイルシステム：ext4
- EBSはルートボリュームではなく、追加アタッチしたボリュームで実施
検証方法
fioでランダムWriteを継続している状態で、1秒ごとにiostatの値を取得
fioコマンド
# fio -filename=/data/testfio.file -direct=1 -ioengine=libaio -rw=randwrite -bs=16k -size=12G -group_reporting -name=randread -numjobs=64 -runtime=18000
iostatコマンド
# iostat -xnc 1
検証シナリオ
上記のI/O負荷が発生している状態で、以下の3つのケースで測定
- GP2（汎用SSD）：100GB でクレジット枯渇後、容量を250GBに拡張
- GP2：250GB から ST1（スループット最適化）：500GBに変更
- GP2：100GB から IO1（プロビジョンドIOPS）/4000IOPSに変更
いずれも、EBSの拡張/変更のみでファイルシステムの拡張は実施していません。
検証結果
1. GP2容量拡張
バースト状態の3000 IOPSから、100GBのベースラインである300 IOPSに低下した後、ボリュームサイズを250GBに変更しました。変更実行後、およそ10秒程度で再びバースト状態のパフォーマンスが発揮されるようになりました。
また、変更後に約2400秒間、バーストパフォーマンスが継続しました。これは、250GBのボリュームでの最大バースト時間と一致します。
つまり、容量変更によってクレジットが100%まで回復していると推測できます。この時のCloudwatch上のバーストバランスの推移は以下のようになりました。5分間隔のプロットの間なので正確ではないですが、クレジットも回復していることが確認できます。
2. GP2 -> ST1
バースト中にHDDのボリュームであるST1に変更しました。こちらも変更実行後10秒程度で新しいボリュームタイプのパフォーマンスに変化しました。
3. GP2 -> IO1(4000IOPS)
このケースではクレジット枯渇後にIO1に変更しています。このケースでも変更実行後10秒程度でパフォーマンスが変更されました。
まとめ
今回の検証から以下のことがわかりました。
- 容量/タイプ変更に伴うパフォーマンスの劣化はない
- ただし、ファイルシステム変更を実施する場合は別途検証が必要です
- 変更に伴うパフォーマンスの変化は10秒程度で適用される
- GP2で変更を実施した場合、バーストクレジットは最大まで回復する
パフォーマンス劣化がないことやクレジットの回復はありがたいですね。急激な負荷がかかりパフォーマンスの追加が必要な時には有効な手段となりそうです。
ただし、一度変更した場合には次の変更まで6時間以上空ける必要があることには注意が必要です。6時間経過前に変更しようとするとエラーとなって変更できませんでした。
あくまでも計画的に変更・拡張を実施するのがよいでしょう。
