デザイン＆エンジニアリング部の大和です。
来たる健康診断に備えてイオンに併設されたスポーツジムへ通い始めましたが、帰り道のファストフード店で夕飯を済ませており若干の違和感がなくもない日々を送っております。

さて、Amazon Aurora Serverless v2がGAしてから2年ほどが経ちました。
リレーショナルデータベースをオートスケールさせる、という特徴はかなり魅力的でServerless v2のGA以降のAWS利用案件では必ずと言っていいほど検討対象に挙がり、プロダクトオーナーから指定されることもありました。
Serverless v2は負荷に応じて自動でスケールアップ・スケールダウンし、細かい設定も不要、スケールアップは数秒〜十数秒程度で実行されます。
手動でリーダーインスタンスを増減させなければならない”固定スペック”のインスタンスタイプより、機能面においては優れているように感じます。
それではすべてのシステムでServerless v2を選択すればよいのか？と考えたくなりますが、公式ドキュメントを読み、実際に導入した結果、Serverless v2ならではの制約やコストについても学びその上で採用可否を判断しなければならないことが分かりました。

本記事では私がServerless v2を選択するべきか検討する際に注意した点や判断ポイントを記します。特に次のような方に向けた内容になっています。

  • 今後Serverless v2を選択しようとしている方
  • 特にコストの面で「オートスケールにすれば安くなる」と思っている方

Amazon Aurora Serverless v2の特徴と言われているもの

（まず少し座学です。Amazon Aurora Serverless v2について多少調べている方はこの章は飛ばしていただいて構いません。）
Amazon Auroraは、AWSが提供するリレーショナルデータベースのマネージドサービスであるAmazon RDSにおいて選択できる性能・可用性・コスト効率に優れたデータベースエンジンです。
Amazon Auroraについて https://aws.amazon.com/jp/rds/aurora/
このAmazon Auroraには、Serverless v2という”オートスケールに対応”したインスタンスタイプが存在します。

AWSでアプリケーションサーバをオートスケールさせるにはいくつか選択肢がありますが、リレーショナルデータベースをオートスケールさせるにはこのインスタンスタイプを選択する必要があります。

Serverless v2には、”固定スペック”のインスタンスタイプと比較して以下のようなメリットがあります。

  • アクセス集中時や大量データのバッチ処理時に、データベースへのアクセス量（負荷）に応じて自動でスケールアップ
  • 負荷が下がったら自動でスケールダウン
  • スケールアップ・スケールダウンのためのモニタリングが不要
  • スケールアップ・スケールダウン時のダウンタイムも無い

このようにとても優秀なスケーリング機能を持ったServerless v2ですが、諸手を挙げて採用できない理由としてコスト・コネクション数・エンジンバージョンがあります。

Amazon Aurora Serverless v2のコストの考え方

（こちらも座学寄りの内容です。）
Amazon Auroraは”コスト効率”に優れたデータベースエンジンであると公式HPでも謳われていますが、Serverless v2が”低コスト”であるという意味には繋がりません。
Serverless v2のコストについて考えるには、まず”ACU”という単位について知る必要があります。

詳細は公式HPに譲り、本記事に必要な以下の情報のみ記載します。
「各 ACU では、約 2 ギビバイト （GiB) のメモリと、対応する CPU、ネットワークが組み合わせられています。」
引用： https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html

ACUは、Amazon Aurora構築時に最小ACU及び最大ACUを定義できます。
そして実際のACUの割り当て容量×1ACU当たりの単価でコスト計算されます。
ACUという単位は、スペックを表す単位であると同時にコストを表す単位でもあります。

Amazon RDS Proxyのコストにも要注意

Amazon Auroraと同時にAmazon RDS Proxyを利用する場合、そのコストも大きく影響します。
https://aws.amazon.com/jp/rds/proxy/pricing/

Amazon RDS Proxyのスペックは接続されるデータベースのスペックに比例して拡張され、Serverless v2であればACUに比例します。
これがコスト面でかなり痛手な点であり、Amazon Auroraが0.5や1ACUで稼働していてもAmazon RDS Proxyは下限値である8ACUのコストがかかります。
コストを下げたいと思ってServerless v2を選択しようとしている人は、この下限値のためAmazon RDS Proxyを避けるアーキテクチャを余儀なくされます。
例）8ACU×$0.025/h/ACU×730h/月＝$146/月（2024/6/11時点、東京リージョン。Amazon Auroraとは別にAmazon RDS Proxy単体でかかる最低料金）

では、いつAmazon Aurora Serverless v2を使うべきか

ここからは、ユースケースの視点からServerless v2を選択すべきか検討します。

オートスケールとコストの関係

Serverless v2を採用することでコストが抑えられるのは、オートスケールが有効に機能する場合に限られます。
しかし、オンラインアクセスのピーク時やバッチ処理の負荷はあまりないがとにかくインフラコストを抑えたい、という要求があるときにもServerless v2が議題に挙がることがあります。（新規サービスの開発など）
このケースでは、正直お勧めできないことが多いです。選択する場合は、以下の検討が必要です。

想定される最大コストが許容できるか（最小ACUで稼働し続けることを期待してしまっていないか）

データベース負荷のピーク時に合わせて最大ACUを設定することになりますが、想定以上のアクセス数が発生したり、バッチ処理が想定より長くなったりした場合、最大ACU近辺でデータベースが稼働し続けるコスト面のリスクがあります。
そしてコスト変動を恐れて最大ACUを下げてしまうと、固定のインスタンスタイプと比べて性能が劣化しただけのデータベースが出来上がります。
このコスト変動の幅が許容できない場合は、ある程度のスペックを持つ”固定スペック”のインスタンスタイプを選択するべきとなります。

では、高負荷時に同じスペックになるServerless v2と”固定スペック”のコストを比べてみましょう。

例）平時で合計メモリ4GB、ピーク時に合計8GBのスペックとしたい場合（2024/7/8時点、PostgreSQL互換エディション、東京リージョン、2AZ。）

Serverless v2のケース

Serverless v2（4ACU、8GB）：4ACU×$0.20/h/ACU×2台×730h/月＝$1,168/月
Serverless v2（2ACU、4GB）：2ACU×$0.20/h/ACU×2台×730h/月＝$584/月
毎晩2時間バッチが走り高負荷（最大4ACU×2台）となり、日中も毎日1時間ピーク時間帯（最大4ACU×2台）があるが、それ以外も一定の負荷（平均2ACU×2台）がかかる場合：$146（高負荷）+$511（低負荷）＝$657/月

“固定スペック”のケース

db.t4g.large（常時4GB）：$0.225×2台×730h/月＝$328.5/月

”固定スペック”のおよそ倍のコストで、高負荷時に”固定スペック”と同等のスペックになるだけのデータベースになってしまいました。

また、本当に「最小ACU相当(以下)のコスト」で稼働し続けてほしいというケースであれば、「最小ACU相当(以下)のコストの”固定スペック”」のインスタンスタイプを選択することが最適解です。

例）0.5ACUコスト相当の”固定スペック”のインスタンスタイプ（2024/6/11時点）

Serverless v2のケース

Serverless v2（0.5ACU, 1GB）：0.5ACU×$0.2/h/ACU＝$0.1/h/台

“固定スペック”のケース

db.t4g.medium（2vCPU, 4GB）：$0.113/h/台

最低ACU相当のコストで、メモリが4倍のインスタンスを構えることができました。
このように、最小ACU近辺で稼働し続けることはServerless v2では期待されないことが分かります。

Amazon RDS　Proxy無しの構成でピーク時にコネクション数が耐えられるか

次はコネクション数の観点での検討をします。
先述の通り、コストを理由にServerless v2を選ぼうとしている場合、最小ACUが8のAmazon RDS Proxyを導入することは予算的にほぼ不可能です。
データベース側にProxyがないアーキテクチャ構成を採用することになるため、オンラインアプリケーションサーバ・バッチサーバを含めてピーク時にAmazon Aurora本体の最大コネクション数を超えないかの机上計算（サイジング）は行っておく必要があります。

最小ACUを0.5にしようとしている場合は、コネクション数のサイジングが必要

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.min_capacity_considerations
「PostgreSQL 互換 DB インスタンスで 0.5 ACU の最小容量を指定すると、max_connections の最大値は 2,000 に制限されます。」
Serverless v2を最低コストで運用したい場合、この制約は注意する必要があります。
最小ACUで稼働し続ける見込みである以上、コネクションが多数発生することは想定されないかもしれませんが、ピーク時のコネクション数が2,000を超えないか確認する必要があります。
許容できない場合は最小ACUを1にして、最大ACUで最大コネクション数をチューニングすることになります。この時点で、ベースラインだった最小ACUが0.5から1の2倍になるため、ベースとなるコストが倍増することになり固定のインスタンスタイプを採用した事例もありました。

ピーク時と平時の負荷の差が大きいためオートスケールさせたい

イベントやキャンペーンなどでオンラインアクセスの集中が想定される場合、”固定スペック”のインスタンスタイプだとかなり大きなスペックを構えておくことになってしまいます。
この要求が最もServerless v2に適しています。

注意点は以下です。（経験ベースの注意点です。）
先述の理由のため最小ACUは1以上を設定しましょう。最大ACUはある程度で初期構築し、性能テストを実施してチューニングすることを推奨します。（性能テスト実施時のメトリクスが最大ACUで張り付いていないかを確認します。）
また、最大ACUを大きくし過ぎると、高負荷テストを行う際にその最大ACUで張り付きがちになり、開発期間のインフラコストが跳ね上がるため注意してください（平常時と支払いの桁が変わることもありました…）。

コストメリットを発揮できる条件は？

ここまでで、サーバレスだからと言ってあらゆるシーンでコストが安くなるわけではないことが分かりました。
それでは、公式HPが謳っている”コスト効率”がよいケースを考えます。
先の例で、ピーク時は合計8GBにしたいが「低負荷時（平時）は0.5ACU(1GB)×2台までスケールダウンできる」場合を考えます。

Serverless v2（0.5ACU、1GB）：0.5ACU×0.20/h/ACU×2台×730h/月＝$146/月
ピーク時間が合計3時間：$146（高負荷）＋$127.75（低負荷時）＝$273.75/月

このように、db.t4g.large（$328.5/月）よりも16%程度安いコストで高負荷時に備えることができました。

エンジンバージョンが対応しているか？

少し視点がずれますが、Amazon Auroraで選択できるPostgreSQL又はMySQLのバージョンは、最新に対応していないことがほとんどです（本家がリリースされてから追従する形でAmazon Auroraが対応するため）。
事前にAmazon Auroraの新規作成画面で、希望するエンジンバージョンが選択できるかをご確認ください。

おわりに

オートスケールするリレーショナルデータベースという選択肢が目新しく、とにかくオートスケールするものをと選びたくなりますが、ドキュメントを読み進めるとそう単純な話でもないことが分かりました。
特にコストを抑えるためにServerless v2を検討している場合は、実際に導入しようとしているシステムの要件に応じてピーク時及び平時のアクセス数や想定されるピーク時間帯を仮置きして試算する必要があります。

ご参考までにこれまで私が相談を受けたシステムでは、以下のように導入の是非を判断しました。

  • エンドユーザ（toC）向けシステムであり、リリース直後若しくは1年後の想定ユーザ数が数百万人のため、日中の平均負荷が高い or 読めない（がシステムを落としたくない）⇒Serverless v2を採用
  • エンドユーザ（toC）向けシステムであるが、想定ユーザ数はある程度の数に収まり日中も負荷があまり高くならない⇒”固定スペック”を採用
  • 社内若しくは企業向け（toB）向けシステムであり、想定ユーザ数が限られバッチ処理も夜間に時間を長くとれる⇒”固定スペック”を採用

エンドユーザ向けシステムでは成長を期待するものなので数年後の想定ユーザ数が多くなりがちですが、それでも足元の採算性を無視してよいことにはならないかと思います。サービスが成長したころにシステムメンテナンスを行いインスタンスタイプを変更することも視野に検討いただくことで、本当にそのシステムに合ったデータベースを選定できるかと思います。