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上で動いているワークロードへどういった影響があるかは不安が付きまとうと思います。
本番環境で切替えを実施する前に、一度試験環境で変更→確認を経ての実施をお勧めします。　
　　
　　

AWSコスト最適化：実践編（EBSボリュームのgp3化）