15
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

NRI OpenStandiaAdvent Calendar 2024

Day 1

AuroraからAurora Serverlessに移行してコスト削減できるかを試算してみた

Last updated at Posted at 2024-11-30

はじめに

Aurora Serverless はAWSのデータベースサービスの1つです。
従来からあった Aurora は事前に決めたインスタンスタイプで常時稼働するのに対し、Aurora Serverlessはワークロードに応じて自動でスケーリングを行うのが特徴です。

Auroraのr6iインスタンスを例にするとインスタンスサイズは9種類(large→xlarge→2xlarge→4xlarge→8xlarge→12xlarge→16xlarge→32xlarge)から選ぶことになります。
一方、Aurora Serverlessは0.5ACU単位で最大256ACUなので、512段階で細かくスケールすることになります。そして使用量に応じた従量課金制のため、使ってない分は課金されません。
なので、うまくハマればAuroraと比較してコストを低減できる可能性があります。

ということで、Auroraで稼働しているシステムをAurora Serverlessにした場合、どれくらいコスト削減できそうかを試算してみました。

AuroraとAurora Serverlessの特徴を比較

AuroraもAurora ServerlessもMySQL互換とPostgreSQL互換のものが選択できます。
今回はMySQL互換をベースにいくつかの項目を比較します。

項目 Aurora(MySQL) Aurora Serverless v2(MySQL)
アーキテクチャ 常時稼働のDBクラスター オンデマンドで自動スケーリングするDB
ユースケース 常に高負荷または予測可能なワークロード向け 可変的な負荷やアイドルタイムが多い場合向け
スケールの粒度 DBインスタンス単位でスケール(手動・自動) ACU(Aurora Capacity Unit )単位でスケール(秒単位)
コスト プロビジョニングされたリソースに基づく 使用量に応じた従量課金
最大サイズ 128vCPU、メモリ1024GB(db.r6i.32xlargeの場合) 256ACU(メモリ512GB、db.r6i.16xlarge相当)※2024年10月に最大128ACUから引き上げ
最大容量 128TBまで 128TBまで
高可用性 マルチAZ、GlobalDBに対応 マルチAZ、GlobalDBに対応
リードレプリカ スケールアウトにより対応可 スケールアウトにより対応可
パフォーマンス 高いパフォーマンスを常時発揮 負荷に応じた自動スケールのため、瞬間的な負荷には対応が遅れる場合がある

ユースケースのところにあるように、可変的な負荷があるシステムに向いているので、例えば深夜帯はあまり利用されないけど日中は利用者が多いというような場合に向いていると言えます。

コスト単価を比較

AuroraとAurora Serverlessの同スペックのコストを比較します。
なお、Aurora ServerlessにはACU(Aurora Capacity Unit)という概念がありますが、メモリ512GBが256ACUに相当するので、以下をほぼ同スペックと考えました。
コスト単価は東京リージョンのものを利用します。

なお、この記事を書いている最中である2024年11月27日頃、Aurora Serverless v2の東京リージョンの価格が25%値下げされ、1ACUあたり\$0.20/時間から\$0.15/時間になりました。

  • Aurora(MySQL) (db.r6i.16xlarge: 64vCPU, メモリ512GB):$11.20/時間
  • Aurora Serverless v2(MySQL)(256ACU:メモリ512GB):$0.15 × 256ACU = $38.40/時間

これだけみると、Aurora Serverlessが3.42倍ほど高額となります。

ちなみに価格改定前だと、\$0.20 × 256ACU = \$51.20/時間で、差は約4.57倍でした

バージニア北部リージョンだと、Auroraが\$9.28/時間、Aurora Serverlessが \$0.12 × 256ACU = \$30.72/時間で、差は約3.31倍に縮まります

加えて、Auroraはリザーブドインスタンス(RI)が使えるので3~6割程度安くできる余地があります。

だとすると、Aurora Serverlessでコスト削減できるというのは幻想なのでしょうか??

実際のワークロードに照らして比較

あるシステムのワークロードを例とします。
このシステムではdb.r6i.8xlargeのAuroraインスタンスを3台(ライター1台、リーダー2台)常時稼働で運用しています。
ただ深夜はあまり使われておらず、夕方頃に利用者が増えて負荷が高くなる傾向があります。
とある1日のDBインスタンス3台の1分ごとのCPU使用率をCloudWatchメトリクスからCSVでエクスポートして積み上げグラフで表しました。

image.png

このとき薄いベージュ色で塗っている全ての面積がAuroraでかかっているコストです。
一方、緑・オレンジ・青で表している波形の面積は実際にAuroraのCPUが使われた部分になります。
Aurora Serverlessにすると、負荷に合わせて柔軟にスケールするので、波形の面積がAurora Serverlessでかかるコストに近いと考えられます。(実際は波形というより、512段階の階段上にスケールアップ・ダウンすると思われます)
全体の面積に対して波形の部分の面積が占める割合を求めると約8.8%でしたので、この数字を踏まえて1日のコストを比較します。

  • Aurora(MySQL) (db.r6i.8xlarge):$5.60 × 24時間 × 3台 = $403.20/日
  • Aurora Serverless v2(MySQL):$403.20 × 0.088 × 3.31 = $117.44/日

今回の例だと、Aurora Serverlessにすることで約71%コスト削減できる という試算になりました。

ちなみに価格改定前だと、\$403.20 × 0.088 × 4.57 = \$162.15/日となり、約60%コスト削減できるという試算でした

本当にAurora Serverlessでコスト削減できる?

実際のワークロードに照らした試算だとAurora Serverlessで約7割コスト削減できるという結果になりました。
とはいえ、Auroraについては別の手段でのコスト削減策があるので、Auroraのほうが安くなるケースも十分に考えられます。

  • AutoScalingの導入により、利用率が低い深夜帯はインスタンス数を減らす
  • まだリソースに余裕があるので1つ下のdb.r6i.4xlargeにスケールダウンする
  • リザーブドインスタンスを購入しディスカウントを効かせる

これらの手段を組み合わせれば、Auroraのままでも7割コスト削減は可能だと思われるので、コスト削減だけを目的にAurora Serverlessにするのはなかなか厳しいかもしれません。

ただ、Aurora Serverlessにはコスト以外のメリットもあります。
例えば、開発環境用途など通常時はほとんどワークロードがない環境の場合、最小キャパシティ0(≒自動停止・再開) に対応していることで人手を介さずコストを節約できます。
また、実際のCPU、メモリなどのリソースを定期的にチェックして、インスタンスサイズや台数を細かくチューニングする必要もなくなり、ある程度AWSに任せることができます。
これらを踏まえると、Aurora Serverlessにすることにより、AWS費用のコスト削減だけでなく、人手がかかる運用面のコスト削減にも貢献できると考えることもできます。

さいごに

このように、Aurora Serverlessにすることによりコスト削減ができるかはケース・バイ・ケースです。
今回Aurora Serverlessのコスト試算はあくまで机上での計算なので、実際にいくらになるかは本番のワークロードに近い状況を再現してテストをしないと正確にはわからないです。
ただ、そこまでやるのは難しいと思いますので、コスト比較のアプローチ方法として参考になれば幸いです。

参考

15
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
15
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?