Aurora Serverless v2 の ゼロスケール の動作を確認してみた

本記事は Japan AWS Top Engineers Advent Calendar 2024 シリーズ2 10日目の記事になります。

はじめに

2024年11月20日に Aurora Serverless v2 において、キャパシティを ゼロ にすることができる(以下、ゼロスケール)アップデートが発表されました。

• Amazon Aurora Serverless v2 がゼロキャパシティへのスケーリングをサポート

少し歴史を紐解きますと、Aurora Serverless v2 が 2022年春に GA された時には、v1 ではサポートされていたゼロスケールがサポートされておらず、最低でも 0.5 ACU¹ で稼働させることが必要となり、停止できないのでコスト削減が思ったよりもできない、というような話が出ていました。

一方で、Aurora Serverless v1 が 2024年12月31日 で終了されること が発表されており、v1でゼロスケール含みのコストでの運用を考えていると(v2にすることで)コスト増になってしまう、というジレンマがありました。

Aurora Serverlss v2 ゼロスケールの制限

ゼロスケールを利用できるDBエンジンのバージョンやシステム構成に制限があります。

DBエンジンバージョン

ゼロスケールに対応しているのは次のバージョンになります。

• PostgreSQL: 13.15以上、14.12以上、15.7以上、16.3以上
• MySQL: 3.08.0 以上
  出典：Aurora Serverless v2 capacity

システム構成

次のようなシステム構成の場合には、自動的にゼロスケールが行われません。
基本的には常にアクティビティを処理する必要がある役割の場合には、ゼロスケールがされない動作となるようです。

• フェイルオーバ優先度：読み取りインスタンスのフェイルオーバ優先度が ０ もしくは １ の場合には書き込みインスタンスの動作に従う
• Auroraグローバルデータベース：セカンダリクラスタ内のインスタンス、プライマリクラスタ内のフェイルオーバ優先度が２以上の読み取りインスタンス
• ゼロETL統合：ゼロETL統合が関連付けられているインスタンス

Aurora Serverless v2 の作成

Auroraを作成する際に、対応するバージョンを選択したうえで、次図の通り「インスタンスの設定」にて「Serverless v2」を選択すると、「最小キャパシティ（ACU）」を 0 に設定することが可能です。
対応していないバージョンの場合、「最小キャパシティ（ACU）」は 0.5 までしか選択できません。
また、「非アクティブ時に一時停止」の項目で該当の時間非アクティブ状態が続くと、ゼロスケールが行われる形になります。5分 ～ 24時間 で選択することが可能です。

ここで「非アクティブ」として判断されるのは接続があった場合に判断される模様です。
つまり、繋がれていれば接続あり、として判断されて自動停止はされません。Connection Poolingなどを利用している場合には Pool 自体も一度切断する、といった形が必要になると想定されます。

停止時の動作

実際にpsqlを切断して 5分(今回の「非アクティブ時に一時停止」の設定値)経過すると、次図のようにキャパシティがゼロになり、インスタンス側の課金は停止されます (ストレージは継続課金)。

実際に停止しているかどうかは、イベントでも確認できます。

再開時の動作

psqlを切断するとアイドルとなり停止されるのとは逆に、ゼロスケール状態の Aurora Serverless v2 に新規接続されると再開されます。
ACUの値を変化させて確認してみましたが、 2ACU 以上の時はまず 2ACU で再開し、その後スケールアップするような状況が確認できました。2ACU 未満の時は設定値で再開します。

そのためか、2ACU以上の時は大体 10～15秒 程度で再開してましたが、2ACU未満の時は 15～20秒程度で再開していました。数回しか確認してませんので、誤差の範囲かもしれません。

こちらも、メトリクスやイベントで確認が可能です。

• イベント

• メトリクス

「deeper sleep」モードからの再開動作

Aurora Serverless v2では24時間以上 ゼロスケールが継続する場合、deeper sleepモードに移行され、再開に30秒以上の時間がかかる、と説明があります。

If an Aurora Serverless v2 instance remains paused more than 24 hours, Aurora can put the instance into a deeper sleep that takes longer to resume. In that case, the resume time can be 30 seconds or longer, roughly equivalent to doing a reboot of the instance. If your database has periods of inactivity that last longer than a day, we recommend setting connection timeouts to 30 seconds or more.

(出典：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html#auto-pause-resuming)

こちらも、同様に deeper sleep 状態のインスタンスに接続して再開時間を確認してみたところ、こちらはACUに関わらず 75秒 前後という結果になりました。

以下は一例ですが、何度か複数のインスタンスでも確認しましたが、大体同様の時間がかかっていました。

deeper sleep からの resume

$ date;psql -h pgtest.cluster-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -p 5432 -U postgres -d pgtest
Thu Dec  5 07:35:49 UTC 2024 ★再開開始時刻
select current_timestamp;

psql (13.7, server 16.4)
WARNING: psql major version 13, server major version 16.
         Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: AES128-SHA256, bits: 128, compression: off)
Type "help" for help.

pgtest=> select current_timestamp;
       current_timestamp
-------------------------------
 2024-12-05 07:37:03.399246+00 ★再開完了時刻
(1 row)

まとめ

Aurora Serverless v2 のゼロスケールの動作を停止時・再開時それぞれで確認してみました。
どちらもそれほど直感から外れた動作はしていないことが確認できます。
自動的に停止されないときは、自動停止の制限に合致していないか、もしくは接続がなされていないかを確認すると良いでしょう。

再開については必要時間は通常時と deeper sleep 時で差がありますが、それぞれ大きなブレはないと想定されますので、各々のアプリケーションの特性に応じて最適化すると良いと思います。

1. ACU（Aurora Serverless Unit）：インスタンスクラスとは関係なく割り当てられる容量、1ACU として 約2GiBメモリと対応する CPU・ネットワークが割り当てられる ↩