Amazon Aurora Serverlessの容量スケーリングと選び方
Aurora ServerlessのACU、自動スケーリング、v1とv2の仕組み、停止と再開、Data APIを整理し、可変ワークロードに適した構成を学びます。
Amazon Aurora Serverlessの容量スケーリングと選び方
Amazon Aurora Serverlessは、Auroraの計算容量をワークロードに合わせて自動調整する構成です。固定サイズのDBインスタンスをあらかじめ選ぶ方式と異なり、利用者は容量の下限と上限を設定し、その範囲内でサービスにスケーリングを任せます。アクセス数や処理量が時間帯・季節・イベントによって変わるシステムや、負荷を事前に予測しにくいシステムで候補になります。
ただし、「サーバーレス」はデータベースの運用や料金がなくなるという意味ではありません。データベースエンジン、ストレージ、バックアップなどは引き続き存在し、計算容量にも料金が発生します。負荷がほぼ一定で高いシステムでは、プロビジョンド構成の方が料金や性能を見積もりやすい場合があります。
固定インスタンスサイズの代わりにACUを設定する
プロビジョンドAuroraでは、DBインスタンスのインスタンスクラスを選び、CPUやメモリなどの計算資源を決めます。Aurora ServerlessではDBインスタンスの固定サイズを指定する代わりに、Aurora Capacity Unit（ACU） の最小値と最大値を指定します。Auroraは処理負荷に応じて、その範囲の中で計算容量を増減させます。
ACUは ECUではありません。1 ACUはおよそ2 GiBのメモリと、それに対応するCPU・ネットワーク能力を表す容量単位です。メモリだけを別々に増やすのではなく、データベースを処理するための資源全体が連動して変化します。Aurora Serverless v2では、通常0.5 ACU刻みで容量を調整できます。設定可能な上下限や刻み幅はエンジン、バージョン、リージョンなどの条件を確認してください。
ACUの範囲は、自動スケーリングの振る舞いと料金の両方に関わります。最大値が低すぎると、負荷の上昇時に必要な容量まで増えられません。一方、上限を大きく設定しても、利用した分だけ無条件に性能が保証されるわけではなく、対応するDBエンジンやデータベース側の処理能力も関係します。最小値が高いほど負荷急増への余裕を持ちやすい反面、アイドル中も計算容量の料金が発生しやすくなります。
Serverless v1とv2の違い
Aurora Serverless v1は2018年に一般提供され、v2は2022年に一般提供されました。世代ごとに容量の調整方法や可用性の考え方が異なります。さらに、v1は2025年3月31日にサポート終了しており、現在は新しいシステムの選択肢として扱わず、既存環境の移行対象として理解します。
| 比較点 | Aurora Serverless v1 | Aurora Serverless v2 |
|---|---|---|
| 容量の考え方 | 設定範囲内で容量を調整 | 設定範囲内でより細かく容量を調整 |
| アイドル時 | 条件を満たすとクラスターを一時停止できる | 最小ACUを保って稼働する。対応するエンジンでは0 ACUへの自動一時停止も可能 |
| 再開・スケール時 | 停止後の再開に時間がかかり、急な負荷変動への応答に待ち時間が生じる場合がある | 停止していない容量範囲内では、稼働を続けながら段階的にスケールする |
| 可用性・構成 | v2より対応構成に制約がある | リーダーを含むクラスター構成など、より広い構成をサポートする |
| 現在の位置づけ | 2025年3月31日にサポート終了 | 新規設計で検討する現行世代 |
v1：アイドル時に停止し、接続要求で再開する
Aurora Serverless v1は、一定時間データベースへのアクセスがない場合にクラスターを一時停止する設定ができました。停止中は計算容量を使わないため、その間の計算料金を抑えられます。ストレージやバックアップなど、計算容量以外の料金までなくなるわけではありません。
停止中のクラスターへ要求が届くと、処理を受け付ける前に再開が必要です。起動・接続復旧に待ち時間が発生するため、利用者がいつでも即時応答を期待するアプリケーションには合わないことがあります。定期的なアクセスがあり常時稼働が必要なシステムでは、停止を無効にするか、別の構成を検討する必要があります。
v1とv2の一般提供開始年は世代を識別する目安ですが、試験や設計では古い機能の特徴だけでなく、サポート状況も確認します。v1はすでにサポート終了しているため、既存クラスターを運用する場合には、移行計画と利用可能なAuroraエンジンの条件を調べてください。
v2：稼働を続けながら容量を細かく変える
Aurora Serverless v2では、AuroraクラスターにサーバーレスDBインスタンスを配置し、指定したACUの範囲で負荷に応じて容量を調整します。プロビジョンドのDBインスタンスとサーバーレスのDBインスタンスを同じクラスター内で組み合わせられる構成もあります。これにより、一定の容量を維持するライターと、需要に合わせて伸縮させる読み取り側を組み合わせるなど、ワークロードに応じた構成を取りやすくなります。実際に利用できる構成はエンジンやバージョンの対応状況に従います。
最小容量を0.5 ACU以上に設定する標準的な構成では、データベースを停止させずに最低限の計算容量を保てます。v1のように停止状態から全体を立ち上げる待ち時間を避けやすく、継続的に要求があるアプリケーションや、可用性とスケーリングの両方が必要な構成に向きます。その一方、最低容量を維持するため、負荷がない時間にも計算料金が発生します。
一部のAuroraエンジン・バージョンでは、v2の最小容量を0 ACUにして、利用者の接続がない状態が設定時間続いた後に自動一時停止させられます。AWSの現行ガイドでは、たとえばAurora MySQL 3.08.0以降やAurora PostgreSQL 16.3、15.7、14.12、13.15以降が最低条件として示されています。対応リージョンや新しいエンジン系列を含む全条件は更新されるため、利用前に対応表を確認します。また、バージョンが条件を満たしていても、併用する一部の機能や設定によっては自動停止しない場合があります。再開を伴うため応答までの待ち時間が発生する点は、一時停止を使わない最小0.5 ACU以上の構成と異なります。
ワークロードに合わせた選択
Aurora Serverlessが特に検討しやすいのは、平常時とピーク時の差が大きい場合、バッチ処理やキャンペーンによって負荷が断続的に高まる場合、または利用者数を事前に予測しにくい場合です。地域の文化施設が運営する予約サイトで、普段の閲覧は少ない一方、催しの受付開始時にアクセスが集中する、といったワークロードでは、計算容量を需要に合わせる利点があります。
反対に、常に一定以上の負荷が続く場合、最小容量を高く保つ必要がある場合、または性能を固定して厳密に評価する必要がある場合は、プロビジョンド構成との比較が重要です。Serverlessという名称だけで安価と判断せず、典型日、ピーク日、アイドル時間、最大容量到達時の性能を測定して、必要なACU範囲を決めます。
設計時には、次の観点を合わせて確認します。
- 平常時とピーク時の容量差、およびピークが継続する時間
- スケールアップ前の短時間に、処理遅延や接続待ちが許容されるか
- 停止・再開を使う場合、再開時の待ち時間を利用者が許容できるか
- 最大ACUに到達した際も、アプリケーションが期待する応答性能を維持できるか
- クラスターのストレージ、バックアップ、I/O、データ転送を含めた総料金
- Auroraエンジン、バージョン、リージョンで必要な機能が利用できるか
コンソールからSQLを実行する
AWS Management ConsoleのRDS Query Editorを使うと、対応するAuroraクラスターに対してコンソールからSQLを実行できます。アプリケーションコードにDBドライバーや接続プールを組み込む方式と異なり、ブラウザーからの操作をAWS側のAPI経由でデータベースへ届けられます。運用時の状態確認や学習目的のクエリ実行に便利です。
Query EditorはAurora Serverlessだけの機能でも、ACUスケーリングの一部でもありません。内部の接続経路にData APIを利用する構成では、データベースエンジンとバージョンがData APIに対応していること、Data APIを有効にすること、IAM権限とデータベース認証情報を設定することなどが必要です。コンソールがSQLを実行できるからといって、任意のネットワーク・認証条件でアプリケーションから直接接続できるとは限りません。
アプリケーションからHTTPベースのData APIを使う場合も、通常のデータベース接続とは接続管理やAPI制約が異なります。SQLを実行する窓口と計算容量を自動調整する仕組みは別の機能として捉え、必要な方を選びます。
料金を比較する
Aurora Serverlessでは、設定した最小容量や処理時に消費する容量に応じて計算料金が発生します。v2はACUの利用量を時間単位の料金に換算し、通常は秒単位で計測します。対応構成で自動一時停止を利用すれば停止中の計算料金を抑えられますが、ストレージ、バックアップ、I/O、データ転送などの料金は別に確認します。
v1の停止機能やv2の容量スケーリングは、アイドル時間が長いシステムでは費用を削減できる可能性があります。一方で、最低容量を高くする設定や、継続的に大きな負荷を処理する用途では、プロビジョンドより費用が低いとは限りません。世代ごとの料金単価も変わるため、固定額や「v2は常にv1より高い」といった決めつけではなく、現行の料金表と実際の使用パターンで比較します。
試験での見分け方
- インスタンスサイズを事前に選ばず、負荷に応じて計算容量を伸縮させたいという要件では、ACUの範囲を設定するAurora Serverlessを考えます。
- アクセスがなくなったら計算料金を抑えたいが、再開時に待ち時間を許容できるという要件は、v1の一時停止機能を示す旧来の特徴です。v1はすでにサポート終了しています。
- 停止・再開の待ち時間を抑えながら、容量を細かく変えたいという要件では、v2を検討します。最小ACUを0.5以上に保つ構成と、対応エンジンで0 ACUまで自動一時停止する構成の違いも読み取ります。
- 突発的に利用が増える、負荷を予測しにくい場合は、Serverlessの自動スケーリングが候補になります。ただし最大ACU、エンジン対応、料金を確認します。
- コンソールからSQLを実行したいという要件では、RDS Query EditorやData APIを検討します。これはACUのスケーリングとは別の機能です。
- 一定の高負荷を継続して処理する場合は、Serverlessが常に最安とは限りません。プロビジョンドと総料金・性能を比較します。
公式ドキュメント
重要ポイント
- ▸Aurora Serverlessは固定のDBインスタンスサイズを選ぶ代わりに、ACUの範囲を設定して計算容量を自動調整する
- ▸ACUはECUではなくAurora Capacity Unit。v2では一般に0.5 ACU単位で容量が変化し、メモリ・CPU・ネットワークが連動する
- ▸v1はアイドル時にクラスターを一時停止でき、再開時には待ち時間が発生する。v1は2025年3月31日にサポート終了した
- ▸v2はインスタンスを継続稼働させたまま細かくスケールでき、対応エンジンでは0 ACUへの自動一時停止も選べる
- ▸最小容量を0.5 ACU以上にすれば停止からの再開待ちを避けやすいが、最小容量分の計算料金が継続して発生する
- ▸RDS Query EditorやData APIは接続方法に関する機能であり、サーバーレス容量の自動調整とは別の論点
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
AWSデータベースサービス に関連するトピックを続けて確認できます。