「オートスケールするなら安く済む」は本当か Aurora Serverless v2で見直すクラウドDBの判断軸：＠IT Techブログ PickUp（TISインテックグループ編）

Aurora Serverless v2は、オートスケールできるクラウドDBとして魅力的な選択肢です。一方で、「オートスケールするなら安く済む」と考えて選ぶと、想定外のコストや接続数の制約に直面することもあります。本稿ではAurora Serverless v2を題材に、機能の新しさだけではなく、負荷特性、コスト、運用性をどう結び付けて判断すべきかを整理します。

[Fintan]

注目のテックブログから「現場の知恵」をあなたに――

各社のエンジニアが発信する「テックブログ」。その熱量を＠IT編集部がピックアップ。 生成AI前提時代に向けて環境が激変する中、“隣のエンジニア”は何を感じ、何を考え、どうアクションしているのか？――試行錯誤のプロセス、成功の鍵、変化に立ち向かうマインドなど現場のリアル、ナレッジを凝縮してお届けします。

本稿はTISインテックグループが運営する、開発現場から生まれた技術ノウハウを公開するサイト「Fintan」上で2024年7月12日に掲載した記事を転載するものです。そのため、用字用語の統一ルールなどが、＠ITのものと異なります。ご了承ください。

連載目次

　Amazon Aurora Serverless v2は、オートスケールできるリレーショナルデータベースとして魅力的な選択肢です。実際、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について

　このAmazon Auroraには、Serverless v2という”オートスケールに対応”したインスタンスタイプが存在します。AWSでアプリケーションサーバをオートスケールさせるにはいくつか選択肢がありますが、リレーショナルデータベースをオートスケールさせるにはこのインスタンスタイプを選択する必要があります。

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

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

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

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

　Amazon Auroraは「”コスト効率”に優れた」データベースエンジンであると公式HPでも謳われていますが、それは必ずしも「低コストで使える」ことを意味しません。

　Serverless v2のコストについて考えるには、まず”ACU”という単位について知る必要があります。詳細は公式HPに譲り、本稿に必要な以下の情報のみ記載します。

　「各 ACU では、約 2 ギビバイト （GiB) のメモリと、対応する CPU、ネットワークが組み合わせられています。」引用： Aurora Serverless v2 の仕組み

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

Amazon RDS Proxyを利用する場合は下限コストに注意

　Amazon Auroraと同時にAmazon RDS Proxyを利用する場合、そのコストも大きく影響します。

• 参考：Amazon Relational Database Service Proxy の料金

　Amazon RDS Proxyのスペックは、接続されるデータベースのスペックに比例して拡張され、Serverless v2であればACUに比例します。ただし、RDS Proxyには最低料金が設定されており、最低でも8ACUの料金が発生します。そのため、Amazon Aurora本体が0.5ACUや1ACUで稼働していても、Proxy側の料金は同じ水準まで下がりません。

　コストを下げたいと思って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（常時８GB）：$0.225×2台×730h/月＝$328.5/月

　この条件では、Serverless v2は固定スペックのおよそ2倍のコストをかけて、高負荷時に固定スペックと同程度のスペックを確保している計算になります。

　また、本当に「最小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/台

　このように、0.5ACU相当のコストに近い水準でも、固定スペックであればメモリが4倍のインスタンスを構えることができました。以上から、最小ACU近辺で稼働し続けることはServerless v2では期待されないことが分かります。

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

　次はコネクション数の観点から検討をします。

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

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

　公式ドキュメント（クラスターに Aurora Serverless v2 の最小容量設定を選択する）によると、コネクションの最大数について次の記述があります。「PostgreSQL 互換 DB インスタンスで 0.5 ACU の最小容量を指定すると、max_connections の最大値は 2,000 に制限されます。」

　Serverless v2を最低コストで運用したい場合、この制約には注意が必要です。最小ACUで稼働し続ける見込みである以上、コネクションが多数発生することは想定されないかもしれません。それでも、ピーク時のコネクション数が2,000を超えないか確認する必要があります。

　許容できない場合は、最小ACUを1に引き上げたうえで、最大ACUで最大コネクション数をチューニングすることになります。この時点で、ベースラインだった最小ACUが0.5から1の2倍になるため、ベースとなるコストが倍増することになります。このため、固定のインスタンスタイプを採用した事例もありました。

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

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

　採用にあたり、注意点は2つあります。

　まず、先述の理由から最小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）向けシステムであり、想定ユーザ数が限られバッチ処理も夜間に時間を長くとれる
  ⇒”固定スペック”を採用

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

元ブログもチェック！

元記事はコチラ。ぜひチェックしてみてください！