EBS ボリュームタイプを gp2 から gp3 に変更する際に検討したこと #reinvent
コンバンハ、千葉（幸）です。
re:Invent 2020 の Key Note にて新たな EBS ボリュームタイプ gp3 が発表されました。
発表直後は「ブートボリュームとして指定できない」「 AMI が作成できない」などの制約がありましたが、すぐに解消されました。変更を試してみた内容もこちらに載っています。
せっかくなら現状 gp2 で動いているボリュームを新しいものに変更してみたい、と思い、いくつかの観点で検討を行いました。
- コスト
- オンラインでの変更可否
- IOPS
- スループット
変更を検討されている方の参考になれば幸いです。
先にまとめ
- gp2 と同等の性能を確保する限り、コストは gp3 の方が安い
- 多くの場合オンライン（無停止）での変更が可能
- インスタンスタイプが旧世代の場合は変更を避けた方がよい（2020/12/16時点）
- 変更中に IOPS パフォーマンスが下がることはない
- gp2 の場合と異なり IOPS やスループットは明示的に指定する必要がある
- AWS Compute Optimizer を活用して適切な値を確認しよう
- 検証機で試して所要時間や影響の確認を取ろう
コストはどうなるか
「 gp2 と同等の性能を確保する」という観点で考えると、どのようなパターンでも gp3 の方が安くなります。
こちらは弊社の菊池が検討・作成した資料となります。
JAWS-UG 横浜 re:Invent re:Cap week1 EC2ストレージパフォーマンスの進化より
IOPS や スループットについては後述しますが、ひとまず「同等以上の性能」を確保する場合には常に gp3 の方がコストが低い、という部分を押さえていただければと思います。
現状の EBS ボリュームの IOPS やスループットなどの使用状況を確認したい場合は、 AWS Compute Optimizer を使用するとよいでしょう。
オンラインでの変更はできるか
冒頭で引用したエントリではオンライン（無停止）での変更を行なっています。
細かい制約はもちろんあるのですが、検討の第一ステップとしてものすごく大雑把に言えば、「旧世代のインスタンスでなく、2017年以降に作成されたものであれば可能」と捉えてください。
オンラインの変更のための要件はあるか
オンラインでの EBS ボリュームの動的な変更は、Amazon EBS Elastic Volumes と呼ばれる機能によって実現されます。ドキュメントは以下が該当するため、こちらを確認していきましょう。
サポートされるインスタンスタイプとして以下の記載があります。
- すべての現行世代のインスタンス
- 旧世代のインスタンスのうち、C1、C3、CC2、CR1、G2、I2、M1、M3、R3
旧世代のインスタンスとは以下を指します。以下に記載がなければ現行世代と考えてください。（ CC2 と CR1 は旧世代だけど記載がない、というイレギュラーですが見ないことにします。）
| タイプ | Sizes |
|---|---|
| C1 | c1.medium | c1.xlarge |
| C3 | c3.large | c3.xlarge | c3.2xlarge | c3.4xlarge | c3.8xlarge |
| G2 | g2.2xlarge | g2.8xlarge |
| I2 | i2.xlarge | i2.2xlarge | i2.4xlarge | i2.8xlarge |
| M1 | m1.small | m1.medium | m1.large | m1.xlarge |
| M2 | m2.xlarge | m2.2xlarge | m2.4xlarge |
| M3 | m3.medium | m3.large | m3.xlarge | m3.2xlarge |
| R3 | r3.large | r3.xlarge | r3.2xlarge | r3.4xlarge | r3.8xlarge |
| T1 | t1.micro |
（旧世代の場合は Elastic Volumes に対応していないだけでなく、 gp3 との組み合わせで起動に失敗する、という例を聞いています。 gp3 の対応状況について現時点でドキュメントに記載は確認できませんでした。今後解消されたりドキュメントに記載が追加される可能性はあるかと思いますが、現時点では旧世代のインスタンスでの gp3 への変更は避けた方がよいかと考えます。）
また、Linux で 2 TiB 以上のブートボリュームを使用している場合には、考慮が必要な場合があります。
加えて、制約事項のうち「 gp2 から gp3 への変更」という操作に関係しそうな部分として以下があります。
- マルチアタッチが有効な EBS ボリュームでは不可
- ボリュームが 2016 年 11 月 3 日 23:40 (UTC) 以前にアタッチされていた場合は、Elastic Volumes サポートを初期化する必要がある
- ボリュームサイズを小さくすることはできない
最後に、 Elastic Volumes 一般の注意事項として「ボリュームのデタッチやインスタンスの停止が必要になる場合もある」という記述もあります。今のところ筆者は gp2 から gp3 への変更でこのような事象に遭遇したことはないのですが、可能性も踏まえ、先に検証機で試すなどの計画を立てるとよいでしょう。
ロールバックに備えて実施の前にスナップショットをとっておくというのも大事な観点です。
暗号化の有無による影響はあるか
Elastic Volumes において、暗号化の有無やその実装方式が制約となることはありません。暗号化していないボリュームでもしているボリュームでも、特に気にせず変更を行えます。
（ちなみに Elastic Volumes によって暗号化の有無を変更することはできません。）
どの程度時間がかかるか
こちらは使用状況・環境による部分が大きいので一概には言えませんが、ボリュームサイズに影響を受ける部分が大きそうです。
冒頭のブログでは「 8 GiB のボリュームで 10 分程度」変更にかかったとのことです。厳密には計測できていませんが、筆者の直近の実績では「 60GiB のボリュームで 1 時間弱程度」かかりました。
ドキュメントでは以下の記述があります。
新しい設定が有効になるには最大 24 時間かかり、場合によっては (ボリュームが完全に初期化されていない場合など) それ以上かかることがあります。通常、完全に使用された 1 TiB ボリュームが新しいパフォーマンス設定に移行するまでには約 6 時間かかります。
こちらも検証機などで事前に確認しておくとよいでしょう。
変更中のパフォーマンスへの影響はあるか
所要時間がそれなりにかかるとなると、その間のパフォーマンスの影響が気になります。こちらは特に低下を考慮する必要はありません。
ボリュームが
optimizing状態である場合、ボリュームのパフォーマンスはソースとターゲットの設定仕様の中間にあります。過渡的なボリュームのパフォーマンスは、ソースボリュームのパフォーマンスより劣ることはありません。
なお、ここでのパフォーマンスとは IOPS のことを指しています。
IOPS はどうなるか
gp2 の場合は以下のような考え方でした。
- 1 GiB あたり 3 IOPS のベースラインパフォーマンス
- 例えば 100 GiB であれば 300 IOPS
- 最小は 100 IOPS
- ベースラインパフォーマンスが 3,000 IOPS 以下の場合、3,000 IOPS までバースト可能
- つまり 1,000 GiB 以下のボリュームが該当
- 最大 IOPS は 16,000
これは自動的に設定されるもので、カスタマー側での指定はできません。
グラフで表した場合のイメージは以下です。
20190320 AWS Black Belt Online Seminar Amazon EBSより
gp3 の場合、以下のように変更になります。
- 最小で 3,000 IOPS のベースラインパフォーマンス
- バーストという考え方はなし
- カスタマー側で明示的に指定が必要
- 最大 IOPS は 16,000
「 1 GiB あたり 3 IOPS 」という考え方はありませんので、 3,000 以上の IOPS が必要な場合には明示的に追加（指定）する必要があります。とは言え、それによって gp2 と値段が逆転することはない、というのは先述で確認した通りです。
gp2 の時点で割り当てられていた IOPS が 3000 を超えていた場合には、 gp3 でも同じ値をそのまま踏襲する、というのも一つの手でしょう。
既存の IOPS を確認するには
チューニングをきちんと行いたい、という場合には既存の IOPS の実績を確認するのもよいかと思います。
先述の AWS Compute Optimizer が一番手っ取り早い手法となります。
昔ながらの手法では、 CloudWatch メトリクスから確認することもできます。
IOPS は 以下メトリクスから計算することができます。
VolumeReadOpsVolumeWriteOps
上記のメトリクスの合算を例えば 「 5 分間」の「合計」で確認し、300（秒）で割れば求められます。
Metric Math を使用して、グラフ描画させると見やすいかもしれませんね。以下では(m1+m2)/300という式で計算しています。（m1やm2はグラフ化したメトリクスに自動的に採番される ID で、変更も可）
例えば上記のイメージではピーク時でも 111 程度なので、 gp3 のデフォルトベースライン 3000 でも全く問題ない、と考えられます。
スループットはどうなるか
gp2 の場合は以下のような考え方でした。
- ボリュームサイズが 170 GiB 以下の場合、128 MiB/s
- ボリュームサイズが 170 GiB より大きく 334 GiB 未満の場合、バーストにより最大 250 MiB/s
- ボリュームサイズが 334 GiB 以上の場合、バーストに関係なく 250 MiB/s
これらはカスタマー側では設定できなく、IOPS と違い設定値も表示されません。
20190320 AWS Black Belt Online Seminar Amazon EBSより
gp3 の場合、以下のような考え方に変更となります。
- 最小で 125 MiB/s のベースラインスループット
- 最大 1,000 MiB/s までプロビジョニング可能
- カスタマー側で明示的に追加（指定）が必要
ベースラインスループット 125 MiB/s のままだと、数値上では gp2 の場合より性能が下がることになります。必要に応じて追加のスループットをプロビジョニングしましょう。
こちらも IOPS 同様、 gp2 と同程度まで追加のプロビジョニングをしてもトータルのコストは gp3 の方が安くなります。
既存のスループットを確認するには
果たしてベースライン以上のスループットを割り当てる必要があるのか？というところを細かく押さえたい場合には、既存の実績を確認しましょう。
こちらも AWS Compute Optimizer から確認するのが一番手っ取り早いです。
しかしながら、せっかくなのでここでも昔ながらの CloudWatch メトリクスから確認するパターンをやってみます。スループットの場合は以下のメトリクスを参照します。
VolumeReadBytesVolumeWriteBytes
同じようにグラフ描画して確認してみました。
グラフで描画する際に自動で割り当ててくれる単位は MB（メガバイト）であり、 MiB（メビバイト）ではありません。厳密に計算したい場合にはご注意ください。（ざっくり 0.953 くらいを掛けてあげるといいかもしれません）
ボリュームタイプ変更時の操作イメージ
冒頭のエントリとほとんど変わりませんが、参考までに操作イメージを載せておきます。
変更前のボリュームはこちら。
- サイズ：8 GiB
- ボリュームタイプ：gp2
- IOPS：100（自動割り当て）
- スループット：指定なし（不可）
ボリュームの変更を選択。
変更前の状態が以下。
ボリュームタイプとして gp3 を選択すると、スループットを入力する欄が増えます。それぞれ必要な値を指定して、変更を実行します。
（コンソール上だとスループットの単位が MB/s なのですが、ドキュメンでは MiB/s なので、ここで指定した値は MiB/s として設定されるものと認識しています。）
変更に関する注意点を確認して実行します。
変更リクエストが成功しました。
実際にはmodifyingというステータスを遷移しているはずですが、確認する間も無くoptimizingというステータスに遷移していました。
ここで進捗具合をパーセンテージで確認できます。
完全に油断してましたが気づいたらin-useに遷移していました。きちんと測っていないですが 8 分程度だったかと思います。
AWS CLI による変更を行うパターンは以下に記載しましたのであわせてご参照ください。
終わりに
EBS ボリュームタイプの gp2 から gp3 への移行についての検討でした。
gp2 の時には明示的に設定できなかった IOPS やスループットが gp3 では指定できるようになっているので、どのような値を設定するのが適切なのか？と迷う部分もあり、そこも含めてまとめてみました。
AWS Compute Optimizer の存在をすっかり忘れていましたが、上記のパラメータを検討する際には有効活用できそうです。 gp3 に変更した後も計測はできますので、ひとまずベースライン（最小値）で設定してから必要に応じて上げていく、というアプローチもアリかと思います。
変更自体はスムーズに行けば無影響で行うことができますので、コストが気になる方は移行を検討してはいかがでしょうか。とは言え、いきなり本番で全台、というわけではなく検証機などで確認を行うことをお勧めします。
以上、千葉（幸）がお送りしました。
