【要約】Aurora Serverless v2 のゼロスケール再開時間を Platform Version 4 で再計測してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
- ・Aurora Serverless v2 のゼロスケール運用における、コールドスタート時のレイテンシ。
- ・PV4 の性能向上（スケーリング速度向上等）が、0 ACU からの再開時間に寄与するかという不明点。
- ・再開待ちによるアプリケーション側の接続エラーや、適切なタイムアウト設計の判断基準の欠如。
// Approach
1.Aurora PostgreSQL 17.7 (db.serverless) を使用した検証環境を構築。
2.最大 ACU を 1, 2, 4, 8 と段階的に変更し、比較測定を実施。
3.「通常の一時停止（5分放置）」と「Deeper Sleep（24時間以上放置）」の 2 シナリオを設定。
4.クライアントの
date と DB 側の clock_timestamp() の差分を用いて再開時間を算出。5.前回（PV2 相当）の実測値との比較分析を実施。
// Result
- ・通常の一時停止（max=1）では再開時間が約 25〜30% 短縮（13.7秒）。
- ・最大 ACU 2 以上の構成では、再開時間は 12 秒前後で頭打ちとなり、前回と同水準。
- ・Deeper Sleep からの再開時間は約 73 秒で、前回（約 75 秒）から変化なし。
- ・PV4 の改善は稼働中のスケーリングに特化しており、コールドスタートへの波及は限定的。
Senior Engineer Insight
> PV4 の性能向上は「稼働中のスケーリング」に主眼があり、コールドスタートの改善を期待すべきではない。再開時間のボトルネックは、スケーリングアルゴリズムよりもストレージ再マウント等の低レイヤーにある。運用設計においては、再開時間を前提としたタイムアウト値の設定が不可欠。通常 pause 時は 20 秒以上、Deeper Sleep 時は 120 秒以上のタイムアウトを推奨する。Deeper Sleep 回避には、Lambda 等を用いた定期的なウォームアップ接続の検討が必要である。