SRE部 佐竹です。
本日は現在開催中の re:Invent2020 から、Amazon Elastic Block Store (EBS) の gp3 についてコスト比較結果を記載します。
はじめに
弊社ブログの記事の通りですが、gp3 という新しい EBS Volume のタイプがリリースアナウンスされました。本 gp3 ボリュームは現在既に東京リージョンでも利用が可能です。公式のブログページは以下になります。
利用料金を比較する
以下の料金ページを見る限り、 gp3 は gp2 と比較してコストが安価となっております。
必要な箇所だけを抜き出しました。額は東京リージョンのものとなっております。
種類 | 単位 | gp3 | gp2 | 差額 | 削減率 |
---|---|---|---|---|---|
Storage | /GB-month | $0.096 | $0.120 | -$0.024 | -20% |
そのため、gp3 への切り替えによる EBS Volume のコスト削減が可能となりました。今回はこの切替においてコスト削減効果が正しく得られるようグラフを用いて確認します。
IOPSについて
gp3 は gp2 と比較して IOPS の部分が特に変化しています。先ほどの表に追記してみました。
種類 | 単位 | gp3 | gp2 | 差額 |
---|---|---|---|---|
Storage | /GB-month | $0.096 | $0.120 | -$0.024 |
IOPS | IOPS-month | 最低3,000から最大16,000。3,000よりサイズを増やす場合は追加の1IOPSあたり$0.006を支払う | 最低100から最大16,000。IOPSは確保したGiB×3倍であり3,000まではバーストクレジットを持つ | 3,000で固定する場合は差額なし |
上記の通りです。ここから推測される結論としては、1,000 GiB 以下の gp2 の場合、gp3 に切り替えることで IOPS が3,000まで上昇する上にコストが削減されます。そのため、1,000 GiB 以下の gp2 ボリュームはすぐにでも gp3 に切り替えていくのが良いと考えます。1,000 GiB 移行するだけで毎月$24.00 のコスト削減可能です。10 TiB切り替えられれば約25万円/月の削減になります。
注意点(2020年12月4日修正)
2020年12月2日 発表現在 gp3 ボリュームタイプは、ブートボリュームに指定できません。そのため、データボリューム(WindowsでいうところのDドライブ~)での切り替えを検討ください。
2020年12月4日 現在 gp3 ボリュームタイプがブートボリュームにも利用可能になりました。
グラフで比較:IOPS を3000で固定した場合
このグラフは gp3 の IOPS を3,000で固定することで追加料金を発生させないようにした場合に、0 GiB から 6,000 GiB までの gp3 と gp2 のコスト及び IOPS の比較となります。
横軸は確保した EBS ボリュームのサイズであり、0からスタートして 6,000 GiB が最大となっています。左の縦軸は利用料(コスト)です。IOPS のグラフは色が黄色で、かつ縦軸は右(黄色の数字)となります。
青色(gp3)とオレンジ色(gp2)のグラフを比較してわかる通りですが、青色(gp3)のほうが常にオレンジ色(gp2)よりも常に下にきており、コストがより安いことがわかります。
注意して見て頂きたいのは、gp2 はストレージのサイズ×3倍のIOPSを持つため、5,334 GiB まで(16,000に到達するまで)はIOPSが自動的に増加する点です。
ここで気になるのは「gp2 から gp3 に切り替えることで低下したIOPSの影響が気になるためIOPSの値は gp2 時の値のまま維持したい」というシナリオです。ということで、IOPSの追加料金(1IOPSあたり$0.006)を支払ってIOPSを元のまま維持した場合の金額でも比較してみました。
グラフで比較:IOPS を追加した場合
濃い青色の線が修正後の(IOPSのコスト増加を加味した) gp3 の利用料です。IOPS(黄色)のグラフは 3,000 以降でお互いが重なります。グラフの通りですが、IOPSの追加料金を支払った場合でも gp3 が gp2 よりも利用料の安いタイプであることがわかります。
補足ですが、1,000GiB までは先のグラフと同じ傾きのままですため、変化が現われるのは 1,000 GiB より大きいサイズからとなっています。
グラフで比較:スループットを加味した場合(2020年12月16日 修正)
今まで設定ができなかったスループットが gp3 では設定可能となっています。このスループットを比較表に追加すると以下の通りになります。
種類 | 単位 | gp3 | gp2 | 差額 |
---|---|---|---|---|
Storage | /GB-month | $0.096 | $0.120 | -$0.024 |
IOPS | IOPS-month | 最低3,000から最大16,000。3,000よりサイズを増やす場合は追加の1IOPSあたり$0.006を支払う | 最低100から最大16,000。IOPSは確保したGiB×3倍であり3,000まではバーストクレジットを持つ | 3,000で固定する場合は差額なし |
スループット | MB/s-month | 最低125から最大1,000。125より増やす場合は追加の1スループットあたり$0.048を支払う | 最大250(変更はできない) | 125で固定する場合は差額なし |
gp2 の最大250を加味し、gp3 への切り替えにあたり+125 スループットとすると、+$6.00が追加となります。これをグラフに反映してみました。
緑色のグラフが今回新たに追加したスループットを加味した線です。先ほどの青い線よりも +$6.0 切片が移動するため、少し上に配置されるグラフになっています。
なお、gp2 から gp3 に切り替えにあたり、スループットを125追加する場合ですが 250 GiB で ±0 となり(gp3 が $24.0 で gp2 が $30.0 となり、その差額が $6.0 のため)それ未満のサイズの gp3 ではコストパフォーマンスが悪く、マイナスになってしまいます。
参考として、0 GiB から 600 GiB までのコストの増加だけに常時を拡大してみました。250 GiB のところでブレイクイーブンしているのが確認いただけると存じます。
※IOPSは削除しています
ただし、gp2 には最大スループットの計算式による制限があるため実際はこの通りにはなりません。
AWS 公式ドキュメントより引用しますと、以下の計算式によって gp2 のスループットパフォーマンスは計算され、334 GiB で最大の250 MiB/s に到達します。
Throughput in MiB/s = (Volume size in GiB) × (IOPS per GiB) × (I/O size in KiB)
これを gp3 と比較してグラフ化すると以下の通りになります。
gp3 は常に125 MiB/s を提供するため、横一直線になりますが、gp2 は 334 GiB で頭打ちするまで増加し続けます。スループットパフォーマンスの値が 125 MiB/sで一致するのは、334 GiB の半分となる 167 GiB です。
このため、167 GiB 未満のボリュームサイズであれば、gp3 は常に gp2 のスループットを上回ります。つまり、既存の gp2 の性能が必要であれば差額を支払う必要がありません。
また 167 GiB から 334 GiB までは、IOPSの差額を支払う場合、その最大スループットによって支払う額が $6.0 以下にできます。具体的には、仮に gp2 が 200 GiB とすると 最大スループットは 150 MiB/sとなるため、gp3 の 125 MiB/s に不足するのは 25 MiB/s のみでよく、それを加味して支払う場合は $0.048 *25 = $1.2 となります。これを加味して再計算したグラフは以下の通りとなります。
本グラフの通り、最大スループットを加味した場合でも、常に gp3 がよりコストを削減して利用が可能なことがわかります。
Compute Optimizer の活用
AWS Compute Optimizer では gp3 のスループット不足に対して指摘を行う機能が実装されていることが判明しております。
そのため、ひとまず 125 MiB/sの設定で gp2 から gp3 に移行した後、改めて Compute Optimizer の結果をもって最適なスループットパフォーマンスを探るというのも1つ取れる選択肢と存じます。
まとめ
最後に結果をまとめます。
- gp2 を gp3 へ切り替えるにあたり、1,000 GiB 以下のボリュームは積極的に切り替えたい。理由はIOPSが3,000以下から最低3,000へと向上し、かつコストが削減(最大2割引)可能なため
- 同切り替えにあたり、1,000 GiB より大きいボリュームの移行時に元のIOPSの設定値を加味した場合でも切り替えによるコスト削減が可能
- 同切り替えにあたり、スループットを加味する場合は 167 GiB 未満では追加不要、168 GiB 以上では必要に応じて追加を検討する
ワークロード次第ではありますが、データ用のボリュームはほとんどが IOPS=3,000、スループット=125 の設定にて gp3 に変更することでコスト削減が可能なのではと考えております。またこの切り替えは Elastic Volumes に対応しており「Modify」コマンドにてサーバの停止なしに可能です。
なお、リリースされたばかりのボリュームタイプのためすぐに本番に適用するのは避けて頂き、検証環境にてある程度運用期間を持っていいただいたほうが良いと考えます。
re:Invent2020 はこれからもまだまだ続きますので、引き続き何かアップデートがあればお知らせしたいと思います。
2020年12月10日 旧世代インスタンスでの注意事項(解消済)
現在、旧世代(Previous generation instances)のインスタンスタイプでは gp3 に変更(Modify)を行うと変更がスタックしてしまうという事象が発生しております。事象が発生してしまった場合、以下の手順で対応可能です。
- EC2 インスタンスを停止し、当該のボリュームをデタッチする
- modifying 状態が解消されたことを確認後、gp3 以外のボリュームタイプ(gp2から変更したのであればgp2)に変更する
- EC2 インスタンスに再度アタッチを行い、インスタンスを起動(Start)する
そのため、旧世代のインスタンスをご利用されている場合は、現時点では gp3 への変更は控えて頂くようお願いします。補足しますと、旧世代は、 C1, C3, G2, I2, M1, M2, M3, R3, T1
のファミリーが該当します。
なお、旧世代のインスタンスでは、gp3 をアタッチして正常に利用することもできない状況です。
2021年2月24日 旧世代インスタンスでも利用可能になりました
下記の通り、旧世代インスタンスでの利用も問題がなくなったことが確認できましたのでお知らせします。
ではまたお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。