AIエージェントが並列にツールを呼び出すと、普段は静かなデータベースへ短時間だけクエリが集中します。夜間バッチやキャンペーン開始時にも、似た形の負荷が現れます。

2026年8月14日、Aurora Serverlessには、需要を検知すると現在容量へ12 Aurora Capacity Units（ACU）を1秒以内に追加するスケーリング改善が入りました。では、もう最小ACUを高めに置いたり、プロビジョンドインスタンスと比較したりする必要はないのでしょうか。

結論から言うと、短くなったのは主にバースト直後の容量不足です。最大容量、バッファキャッシュ、接続、クエリ特性まで自動的に解決する変更ではありません。どこまで任せられ、どこから負荷試験が必要なのかを切り分けます。

12 ACUの即時追加はバースト直後の「待ち」を短くする

Aurora Serverlessは負荷に応じてCPU、メモリ、ネットワークをまとめたACUを増減します。1 ACUは約2 GiBのメモリと対応するCPU・ネットワークの組み合わせなので、12 ACUはメモリ換算で約24 GiB分に相当する幅です。ただし、ACUからCPU数やネットワーク帯域を個別に換算することはできません。

新しい挙動は、負荷が求める場合に現在値へ12 ACUを1秒以内に加え、設定済みの最大ACUへ達するまで継続してスケールします。即時追加は設定した最小・最大の範囲内で働くため、最大値を越えて増えるわけではありません。

AWSの1つ目の検証は、Aurora PostgreSQL、platform version 4、0.5〜12 ACUのクラスターです。Sysbenchでデータを入れた後にソートを含むクエリを実行すると、ServerlessDatabaseCapacityは0.5 ACUから上限の12 ACUへ1秒以内に到達しました。

ここで変わったのは「256 ACUへ1秒で到達する」ことではありません。最初の一歩を最大12 ACU分だけ大きくし、その後も需要に合わせて上限まで増やす仕組みです。

2022年のv2公開からスケーリングの課題は段階的に狭まった

Aurora Serverless v2が一般提供されたのは2022年4月21日です。従来より細かな単位で、接続を保ったまま容量を増減できる構成として登場しました。2026年4月には名称がAurora Serverlessへ変更されていますが、移行作業は不要です。

その後、2024年10月には上限が128 ACUから256 ACUへ拡大しました。扱えるピークは大きくなりましたが、低い容量から上限へ登る時間は別の問題として残ります。

2026年4月のplatform version 4では、前世代比で最大30%の性能改善と、全platform versionで従来比2倍の既定スケーリングレートが案内されました。同記事の0.5〜256 ACU試験では、上限到達が40分から22分へ短縮されています。今回の12 ACU即時追加は、その長い上り坂の入口をさらに短くする更新だと捉えると分かりやすいですね。

1秒で容量が増えてもバッファキャッシュは同時に温まらない

2つ目の検証では、platform version 4のAurora PostgreSQLを4〜16 ACUに設定し、プロビジョンドのdb.r8g.xlargeと120秒間の書き込み負荷を比較しています。Sysbenchのoltp_write_only.lua、合計16 GiBの100テーブル、256スレッドという限定された条件です。

16 ACUはメモリ換算で約32 GiBです。比較対象のdb.r8g.xlargeも32 GiBメモリ、4 vCPUなので、メモリ規模は近い設定でした。とはいえ、ACUとプロビジョンドクラスは同一仕様ではなく、この対応だけで性能が等価とは判断できません。

開始直後のQPSはプロビジョンド側が高く、最初の10秒に差がありました。プロビジョンド側では16 GiBのデータセットが共有バッファへ読み込まれていた一方、Aurora Serverlessは小さいキャッシュから開始したためです。Aurora Serverlessは約1分で差を閉じ、その後は試験終了まで同程度のQPSを示しました。

つまり、容量が1秒で増えることと、アプリケーションがピーク性能へ1秒で到達することは同義ではありません。エージェント型AIは利用例として挙げられていますが、公開された試験は実際のAIエージェントではなくSysbenchです。クエリ分布やワーキングセットが異なれば、キャッシュの温まり方も変わります。

platform version 3/4を特定してから容量設定を見直す

12 ACUの即時追加はplatform version 3と4で既定有効になり、設定変更は不要です。まず、対象クラスターがどちらで動いているかをRDSコンソールのインスタンス設定、またはServerlessV2PlatformVersionで特定します。利用できるACU範囲はDBエンジンとplatform versionの両方で決まるため、エンジンだけを見て256 ACU対応と判断しない方が安全です。

AWS CLIなら、platform versionと容量範囲を一度に確認できます。読み取り専用のコマンドです。

aws rds describe-db-clusters \
  --db-cluster-identifier "my-cluster" \
  --query "DBClusters[0].{PlatformVersion:ServerlessV2PlatformVersion,Scaling:ServerlessV2ScalingConfiguration}"

新規クラスター、復元、クローンには、そのリージョンで利用可能な最新platform versionが割り当てられます。既存クラスターは自動的に同じ状態とは限らないため、今回の改善を前提にSLOを見直す前に実値を押さえておきたいところです。

最小ACUと最大ACUは高速化後も設計値として残る

最大ACUは依然として性能の天井です。ACUUtilizationやCPU使用率が100%近くに張り付くなら、即時追加が働いてもそれ以上には増えません。AWSの容量設計ガイドも、最大値をピークへ届く大きさにし、最小値にはスケール速度とワーキングセットを保持できるメモリ量を考慮するよう案内しています。

最小ACUを下げるほどアイドル時のコンピュートは小さくできますが、キャッシュからデータが追い出されやすくなります。予測できる大きなバーストには、事前に最小ACUを上げて基準容量を確保する運用も、現在の管理ドキュメントに残っています。12 ACUを超える瞬間的な増分が必要なら、この選択肢はまだ有効です。

Aurora Serverlessのコンピュートは実際に使用したACUを秒単位で課金します。最小値を高く保てば応答の土台を作れる一方、低負荷時にもその容量を下回れません。また、0 ACUへの自動停止は対応するエンジンで最小値を0にした場合の機能です。「アイドルなら必ずゼロ課金」と一律には扱えません。

CloudWatchとアプリ側レイテンシを同じバーストで測る

高速化を評価するときは、ServerlessDatabaseCapacityだけで成功としない方がよいです。Aurora Serverless向けのCloudWatch指標では、現在ACUを示すServerlessDatabaseCapacityと、現在ACUを最大ACUで割ったACUUtilizationを確認できます。容量関連の指標は毎秒計算されます。

同じ時間軸へDatabaseConnections、DMLThroughput、CPU、空きメモリを並べ、アプリケーション側のp95/p99レイテンシ、タイムアウト、再試行も重ねます。これで「容量は増えたがキャッシュ待ち」「最大ACUへ到達」「接続急増が先に詰まった」といった原因を分けられます。

本番に近いワーキングセットとクエリ比率で、最低容量から想定ピークを流す試験が判断材料になります。一次ソースのQPS比較は有用ですが、単一の書き込みベンチマークから、すべてのエンジンや負荷でプロビジョンドと同等になるとは言えません。

12 ACUの初速をSLOに照らして構成を選ぶ

今回の更新により、platform version 3/4では、短いバーストのためだけに高い最小ACUを維持する必要性は下がりました。現在容量に12 ACUを足した地点で必要な処理量へ届き、キャッシュの再構築もSLO内なら、Aurora Serverlessへ任せられる範囲は広がります。

一方、最初の1秒から12 ACUを超える増分が必要な負荷、大きなワーキングセットを常にメモリへ置きたい負荷、一定の高負荷が続く構成では、最小ACUを上げるか、プロビジョンドとの性能・料金比較を続ける余地があります。比較はベンダーの単一ベンチマークではなく、自分のACU-hoursとレイテンシで行うのが実務的です。

冒頭の問いへの答えは、「スケーリング設定が不要になった」ではなく、「初動の容量不足という制約が小さくなった」です。platform version、容量の天井、キャッシュが温まる時間を同じ負荷試験で測れば、この12 ACUが構成を変える更新かどうかを判断できます。

出典

• Title: Faster scaling for Aurora serverless to support agentic AI and other spiky workloads
• URL: https://aws.amazon.com/blogs/database/faster-scaling-for-aurora-serverless-to-support-agentic-ai-and-other-spiky-workloads/