1. はじめに
今回は、コスト最適化の勘所で紹介したストレージオプションの内、弊社内で最近実施した EBSボリュームの gp3 化について実例を交えて紹介します。
2. 背景
弊社内では、月次でAWS費用集計を行っているのですが、EBS全体の費用が他費用と比較して相対的に高いことに目が留まりました。
よくよく調べると、アカウント全体で200台を超えるEC2の内95%がgp2のまま…
弊社システムサーバは大半を汎用SSDボリュームで構成しており、デフォルトのgp2でそのまま構築をしていました。
一つ一つの金額は小さく、地味かもしれませんが塵も積もれば山となる！
今回は、そんな地味で細かいけれど確かな効果があるEBSボリュームをgp2 → gp3化した事例を紹介します。
地味な削減効果かもしれませんが、こういった小さく変更が簡易な物ほど早めに手を打つべきかと考えます。勿論初期構築の段階で、コスト/パフォーマンス両面から最適なEBSボリュームが選択出来ていればそれに越したことはありません。
本記事はコストに焦点を当てて、汎用SSDのgp2をgp3に単純に切替えるシナリオとなります。
本来はEC2上で実施されるワークロードに対して、最適な性能とコストのEBSボリュームが初期構築時点で選択されるべきかと思います。
3. 最初に押さえるべき事
3.1. gp2 と gp3の違いと注意点
EBSボリュームの種類や違いについては AWS公式ドキュメント に比較表があります。
スループットの設定値による費用比較などは Googleで調べると様々出てくるかと思いますので詳細は割愛しますが、一番大きな注意点として「gp3はバーストクレジットが存在しない」(※1)(※2)があると考えています。
つまり、gp2の時点でバーストクレジットを頻繁に消費しているボリュームは単純切替えが難しい。 という事になります。
※1…「バーストとは」については コチラ を参照してください。
※2… gp3がバーストを利用できない件は コチラ を参照してください。
4. 準備
4.1. まずはリストアップ
AWS config のメニューにある「高度なクエリ」を使ったことはあるでしょうか。(※3)
実はそこに標準でgp2のEBSボリュームを一覧化するクエリ「EC2 Volumes by type」が用意されています。
※3… 高度クエリについてはAWS configコンソール内に多数のサンプルがありますが、コチラ にもクエリ例の記載があります。
ただ、これだけだとちょっと情報として足りません。
なので、クエリを以下の様に修正して実行します。
SELECT
resourceId,
resourceType,
configuration.volumeType,
configuration.volumeId,
configuration.iops,
configuration.size
WHERE
resourceType = 'AWS::EC2::Volume'
AND configure.volumeType = 'gp2'
修正内容としては以下の通りです。
- Volume IDを追加
- IOPS数値を追加
- Volume sizeを追加
- availavilityzone情報を削除
- tag情報を削除
4.2. 対象の選定
4.2.1. バーストしているボリュームの除外
リストアップした対象のgp2の内、バーストクレジットを消費しているか？ をまずは確認します。
これは、バーストクレジットを消費している場合、 バーストクレジットが使えないgp3への単純な切替えではなく、性能の見直しが必要になるからです。
ボリュームにおける バースト の発生有無は cloudwatch メトリクスから 「EBS」 を選択し「BurstBalance」メトリクスを見る事で確認できます。
メトリクスを確認した結果、バーストクレジットの消費が激しいボリューム（上記グラフの数値が 0% に近い状態）のものは除外します。
4.2.2. バーストが無い or 非常に軽微なボリューム
AWSの公式ドキュメントに参考となる 指標 があります。
詳細はリンク先をご確認ください。
リンク先の指標を受けて最終的に以下の方針で整理を実施しました。
| 対象 | 対応方針 | 補足 |
|---|---|---|
| 頻繁にバーストが発生している or バーストクレジットが枯渇しかけているボリューム | 変更しない | gp3はバーストクレジットが無い為除外 |
| ボリュームサイズ1,000GB未満 | gp3へ変更 | スループットはgp2相当に指定 IOPSはデフォルト(3,000IOPS) |
| ボリュームサイズ1,000GB以上 | gp3へ変更 | スループットは最大値（250MiB/s）を指定し IOPSはgp2相当の値を指定 |
5. 実践
変更自体はEBSボリュームのコンソールからオンラインで可能です。
対象のEBSボリュームをAWSコンソール上で選択し、[変更]ボタンから変えられます。
gp3を選択すると設定できるパラメータが増えますが、これはgp2時の性能に準拠すればOK。
対象のボリューム数が多く、一括変更したい場合は AWS CLI を活用することで作業を簡略化できると思います。
以下のコマンドで変更は可能です。
aws ec2 modify-volume --volume-id {Volume-ID} --volume-type gp3 --iops {IOPS} --throughput {Throuput}
- {Volume-ID}：先ほど AWS Config で取得した volumeid を指定します
- {IOPS} ：ボリュームのIOPSを指定します
- {Throuput} ：ボリュームのスループット値を指定します
対象のEBSボリュームをアタッチしているEC2でオートスケールを組んでいるパターンがあるかと思います。
その場合、起動テンプレートも忘れずに設定変更してください。
6. 効果と影響
6.1. いくら下がったの？
あるシステムで試験的に実施したところ、35台（総ボリュームサイズ 2,760GB）のgp3切り替えで \$220/month だったEBSの利用料金がおよそ $175/month まで削減されました
削減効果としてはおおよそ -20% 程度の効果が期待できるのかと思います。
6.2. 切り替えた影響はなかったの？
基幹システムや外部公開コンテンツのサーバ等、多数のEBSボリュームをオンラインでgp3に切替えていますが現時点で問題は発生していません。
念の為試験・検証環境から実施し、切り替え時に処理影響がない事を確認の上で実施しています。
オンライン変更が可能とはいえEBSボリュームを利用しているEC2上で動いているワークロードへどういった影響があるかは不安が付きまとうと思います。
本番環境で切替えを実施する前に、一度試験環境で変更→確認を経ての実施をお勧めします。