背景
Aurora Serverless v2を実際に運用して分かった知見を書いていきます。
スケーリングについて
スケールアップ･スケールダウンが自動。手動でもめっちゃ楽
Aurora Serverless v2はsmall、mediumといったインスタンスクラスはなく、ACU(Aurora Capacity Unit)というデータベース容量を指定します。最小ACUと最大ACUを指定しておくと、自動でスケールアップ･スケールダウンしてくれます。
EventBridge+Lambdaを組み合わせることで、スケジュールしてスケーリングすることもできます。(書こうと思ったら一緒に働いている方に先を越されていましたw)
スケールアップ･スケールダウンが無停止
プロビジョンドAuroraでスケールアップしたい場合は、
- WriterとReaderの2台のインスタンスを用意
- Readerをスケールアップ
- フェールオーバーでWriterとReaderを入れ替え
- Writerもスケールアップ
といった流れで実施することが多いのかなと思います。ただしフェールオーバーする際に30秒〜1分程度DB接続がエラーになってしまいます。Aurora Serverless v2の場合は、なんとACUを変更する際に停止はほぼ発生しません(気づいてないだけで数秒くらい接続不可時間があるかもしれませんが,DB接続しているアプリケーションでエラーが発生しているのはぼぼ見かけません)。
ちなみに、Aurora Serverless v2でフェールオーバーする際はプロビジョンドAuroraと同じく30秒〜1分程度のDB接続エラーは発生します。
スケールアップ･スケールダウンが高速
最低ACUを1→32にしたとき、約10分ほどで32に変更できました。実際の運用でここまで大きな変更をすることは少ないかもしれませんが、かなり速いのかなと思います。
v1と違い、テーブルロック中などでもスケーリング可能
Aurora Serverless v1ではクエリ実行中、テーブルロックがかかっている、SQLトランザクション処理中にスケーリングができなかったようです。
When it does need to perform a scaling operation, Aurora Serverless v1 first tries to identify a scaling point, a moment when no queries are being processed. Aurora Serverless v1 might not be able to find a scaling point for the following reasons:
- Long-running queries
- In-progress transactions
- Temporary tables or table locks
なんとv2ではテーブルロックがかかっている場合などでもスケーリングをしてくれるようです(どうなってんの)。
Serverless v2 scaling can happen while database connections are open, while SQL transactions are in process, while tables are locked, and while temporary tables are in use. Aurora Serverless v2 doesn't wait for a quiet point to begin scaling. Scaling doesn't disrupt any database operations that are underway.
コストについて
プロビジョンドAuroraのインスタンスクラスとACUの比較
For example, suppose that you use the db.r6g.4xlarge DB instance class when your cluster has a high workload. That DB instance class has 128 GiB of memory. Thus, you can specify a maximum ACU setting of 64 to set up an Aurora Serverless v2 DB instance that can scale up to approximately that same capacity. That's because each ACU corresponds to approximately 2 GiB of memory. You might specify a somewhat higher value to let the DB instance scale up farther in case your db.r6g.4xlarge DB instance sometimes doesn't have enough capacity to handle the workload effectively.
とのことなので、おおむね1ACU=2GiBで計算することができます。
を見ながら照らし合わせると以下のようになります。
| インスタンスクラス | メモリ (GiB) | ACU |
|---|---|---|
| db.t3.small | 2 | 1 |
| db.t3.medium | 4 | 2 |
| db.t3.large | 8 | 4 |
| db.r5.large | 16 | 8 |
| db.r6g.4xlarge | 128 | 64 |
料金
料金はACUで確定します。2022/11/25時点の東京リージョンだと0.20USD/ACU 時間です。
1ACUで146USD/月(1ドル140円換算で20,440円/月)です。
8ACUだと1,168USD/月(1ドル140円換算で163,520円/月)です。
だいたい同じスペックのdb.r5.largeで255.5USD/月(1ドル140円換算で35,770円/月)です。
Aurora Serverless v2高っ!普通に高いです！
オハイオリージョンなどは0.12USD/ACU 時間なので、東京リージョンも今後安くなるのに期待です。
変動する負荷に対して有効
上記で書いたとおり、Aurora Serverless v2は結構高めです。そのためリクエストなどが時間に依らず、安定しているサービスについてはt系やr系のプロビジョンドAuroraを使った方が安く済みます。頻繁にアクセスしない開発環境などは、Aurora Serverless v2で営業時間だけ起動するようにするか、db.t3.smallなどでも十分でしょう。
逆に1日のうち夜はしょぼいスペックで、昼間は高スペックにする必要があるといった場合にAurora Serverless v2を使うと、昼間だけACUを追加してするので、安く済む場合があります。
正確な費用を予測しにくい
Maxでかかる費用に関しては、最大ACUから金額を算出することができます。ただ良くも悪くもACUを自動で変更してくれるので、非常に正確な費用は算出しにくい印象があります。
最大ACUを高めに設定していて、謎にACUを追加されて高額になってしまわないかという不安はあります。。。
設定について
デフォルトでmax_connectionsは動的に変動する
デフォルト設定だと、ACUによってmax_connectionsが変動します。低いACUのときにスパイクが発生すると、高速でスケールアップはしますが、connectionの上限値にぶち当たってエラーになるので、パラメータグループからmax_connectionsをデフォルトから3000とかに変更したりで対処できます。
Aurora Serverless v2とプロビジョンドAuroraを併用できる
serverworksさんの記事でやっているのを見て知りました。ホンマにできんの?と思いやってみたら普通にできちゃいました。ただ併用すると保守が難しくなるんじゃないかなと懸念しています。
所感
AWSの場合サポートに泣きつくこともできますが、GAになったのが2022年の4月で新しいサービスになるので、情報はやや少なめです。周囲でもあまり使っているのを見かけずだったので、困らないか不安もありましたが、今の所問題なしです。
費用がややお高めなので、プロビジョン済みAuroraより安くなるか、という点の判断が難しいかなと思います。スケーリングもサクッとできるので、結構楽です。
Discussion