以前、AWSコスト削減とリソース管理 | 外道父の匠 のEBSの項では、そもそも不要なEBS・スナップショットの判断をしましょうってのと、gp3 にして安く高性能にしましょうと書きました。
今回はそのうちの gp3化 についての外伝ということで、さらりとまとめておきます。
費用差
gp2 が $0.12/GB 月、gp3 が $0.096/GB 月 なので、gp2 から gp3 に変更すると 20％ の費用削減になります。性能に関しては、gp3 の 125 MiB/s 3000 IOPS が判断基準となる数値で、もし gp2 の時に、それ以上の性能を使い込むタイミングがある場合、gp3 にしただけで安く速くなったと安易に喜ぶことはできなくなります。
よほど読み書きが盛んなボリュームの場合は、メトリクスをチェックするべきですが、まぁほぼ全てに近い割合で、それとは程遠く小さい使用量だと思いますので、一応注意しておきましょう、というくらいです。
既存ボリュームの変更
ここで言う既存ボリュームとは、（Autoscaling所属ではない）単発のインスタンスが既にアタッチして利用中のモノと、デタッチ状態で放置されているモノを指しています。デタッチ状態のボリュームは、基本は削除するかスナップショット化するかになりますが、ボリュームとして残しておく場合を想定して、ということにします。これらの gp3化 は簡単で、ノーリスクで管理画面から変更できます。一応、どのような内容かは目を通しておいたほうがよいでしょう。
- EBS ボリュームへの変更のリクエスト – Amazon Elastic Compute Cloud
- EBS ボリュームタイプを gp2 から gp3 に変更する際に検討したこと #reinvent | DevelopersIO
よっぽど古臭い環境でない限りは変更自体は問題ないですが、それでも初変更なら不安かもなので、その場合はいきなり本番ではなく影響の少ないテスト環境などで試して確認するとよいです。
そんなにサクッと変更完了するわけではなく、それなりに時間もかかるので、初手本番で無駄に不安にならないようにしましょう。
AMIの情報
次の話に行く前に、AMI とボリュームの関係について確認をしておきます。これはどのように gp3 への変更対処をするかに関わってくるところです。インスタンスを起動する際、AMI の選択をします。この時、選択した AMI に応じて、管理画面ならボリュームのタイプやサイズ、デバイス名がデフォルト値になりますし、API なら無指定の場合にそれになります。
つまり、AMI ごとにボリューム情報を含んでおり、Amazon Linux 2 なら gp2, 8GB, /dev/xvda と決まっています。ただし、これを gp3 などに変更して起動することは可能で、変更して起動したインスタンスから採取した新AMI は、変更後の設定を踏襲するので gp3 をデフォルト設定とします。
ついでにデバイス名について補足しておくと、まずドキュメントがこれで
今は HVM 主流で /dev/sda1 or /dev/xvda になっているはずです。もしボリューム設定を変更する場合は、デバイス名を同一にして上書きする必要があるので注意が必要です。
仮想化が出始めの頃は準仮想化の方が、オーバーヘッド少なく高速だったのですが、今は HVM 優位って覚えておけばよいでしょう。
新規EC2・Autoscaling所属のボリューム
新しくEC2 を作成したり、同様に AutoscalingGroup で自動増減して新しく起動される場合は、gp3 で起動するように変更します。gp2 AMIの場合
AMI が gp2 をデフォルトとする場合、その起動方法に応じて上書き指定する必要があります。管理画面なら、プルダウン等で変更するだけです。Python boto3 の場合、run_instances で最低限、このくらいは追加指定することになります。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
response = client.run_instances( ImageId = 'ami-04f0680f68f076681', # AmazonLinux 2 BlockDeviceMappings = [ { 'DeviceName': '/dev/xvda', 'Ebs': { 'VolumeType': 'gp3', 'VolumeSize': 8, 'DeleteOnTermination': True, }, }, ], |
Terraform の LaunchTemplate だと
|
1 2 3 4 5 6 7 8 9 10 |
resource "aws_launch_template" "default" { ... block_device_mappings { device_name = "/dev/xvda" ebs { volume_type = "gp3" volume_size = 8 delete_on_termination = true } } |
デバイス名は必須なので、ルートになるデバイス名と同一にして、細かい設定を上書きする形にになります。ここでデバイス名を別の──例えば /dev/sda1 にしても、それはセカンダリ・ボリュームとして追加されるので意図した構成になりません。
gp3 AMIの場合
元が gp2 だと上記のように設定を上書きする必要があり面倒ですが、そもそも使う AMI が gp3 として作成されていれば、これらの上書きは必要なくなります。指定しなければ、デフォルト値で起動されるからです。そのため、オススメとしては上書き設定を追加するのではなく、AMI 自体を更新してしまい、指定する AMI を新ami-id に変更してしまう方がキレイに収まるはずです。
Autoscaling なら LaunchTemplate の image_id を変更しておくだけで、日常の自動増減によって、１日前後で全て gp3 に入れ替わることになるでしょう。
TBクラスのボリュームなら、単発でも十分にコスト削減の効果はありますし、小さなOSとしてのボリュームでもチリツモで安くなるのは確実です。
というか金額の多寡よりも、設定をちょっと変えるだけで安くなる＆gp3の方が高性能なので、こういうところからコツコツ適用していくのは、コスト削減において重要な姿勢です。
慣れれば調査から含めて半日１日程度で変更していけるので、あなたの１人日費用をつぎ込むだけで、その後の数ヶ月数年においてボリュームが 20％ 安くなるとしたら、どう考えても早くやってしまった方が良いと思いませんか:-)
