AWS Aurora Serverless v2 導入を考える（2024年後半 直近のアップデートも添えて）
概要
こんにちは🙌
AuroraServerless v2を導入するにあたって検討したことと、導入後の運用について収穫がありましたので、ここで整理しておこうと思います。
特に書き分けの説明が無い場合、Aurora PostgreSQLでの事例となりますが、ほとんどMySQLにも言える内容となっているはずです。
Aurora Serverlessを導入するか悩んでいる方々の参考になれば幸いです。
多くの記事引用をさせていただいております。先人達に感謝です。
ゴール
- 導入、運用時の検討事項が整理されていること
Aurora Serverlessの理解、コスト、性能 あたりの内容がメインとなります。
TL;DR
- ACU（Aurora Capacity Unit）が分かればServerlessについてちょっと分かる。
- コストが安くなるパターンは限定的だが、一考の余地あり。
- MAX ACUを多く設定してもプロビジョニングよりもパフォーマンス（Latencyを指します）が落ちる可能性がある。
導入にあたって
導入を検討した理由
これまでAuroraは利用し続けていましたが、インスタンスサイズを設定するプロビジョニングインスタンスを使ってきました。これまでに何度か事業成長とともにインスタンスサイズを変更してきたという歴史もあります。
また、円安の影響によってコスト削減に取り組むことが急務になっていました。
そこでシステムで利用されているAWSサービスを見た時に、コストの割合が大きいAuroraを最適化することが出来ないか検討を進めました。
そもそもAmazon Aurora Serverless v2とは？
Aurora Serverlessとは、ワークロードに応じてスケールアップやスケールインするオートスケーリング設定となります。
スケールする容量単位のことを ACU(Aurora Capacity Unit) といいます。ACUは、約 2 ギビバイト (GiB) のメモリと、対応する CPU、ネットワークが組み合わせられています。
つまり、4ACUの場合、8GiBのメモリを持つプロビジョニングインスタンスと大体同程度の性能となっていると考えることが出来ます。
Aurora Serverless v2という名前からも分かるように、v1もあります。
今から導入を考える場合は、v2一択になるかと思われます。
簡易的な比較表を載せておきます。
AWS公式ドキュメントより抜粋（2024/12時点）
| 機能 | Aurora Serverless v2 | Aurora Serverless v1 |
|---|---|---|
| DBエンジン | Aurora MySQL、Aurora PostgreSQL | Aurora MySQL、Aurora PostgreSQL |
| 最小Aurora 容量ユニット(Aurora MySQL) | 0.5 | クラスターが実行中の場合は 1、クラスターが一時停止しているときは 0。 |
| 最小Aurora 容量ユニット(Aurora PostgreSQL) | 0.5 | クラスターが実行中の場合は 1、クラスターが一時停止しているときは 0。 |
| 最大 ACU (Aurora MySQL) | 256 | 256 |
| 最大 ACU (Aurora PostgreSQL) | 256 | 384 |
| DB インスタンスのスケーリング | 0.5 ACU の最小増分でスケールアップおよびスケールダウン | ACU を倍増または半分にすることでスケールアップとスケールダウン |
| SQL ステートメントの実行中にスケーリングが発生する可能性がありますか。 | はい。Aurora Serverless v2 はクワイエットポイントを待つ必要はありません。 | いいえ。例えば、スケーリングは、長時間実行されるトランザクション、一時テーブル、およびテーブルロックの完了を待ちます。 |
| マルチ AZ 機能 | はい、プロビジョニングされた場合と同じです。 | Aurora Serverless v1 クラスターは、すべてのコンピューティングを 1 つの AZ で実行します。 |
| Aurora Global Database | 可能 | 不可 |
| IAM ロールの関連付け | 可能 | 不可 |
| Data API が利用可能 | はい (現在は Aurora PostgreSQL のみ) | 可能 |
| クエリエディタが使用可能 | はい (現在は Aurora PostgreSQL のみ) | 可能 |
| Performance Insights | 可能 | 不可 |
| Amazon RDS Proxy が使用可能 | 可能 | 不可 |
抜粋していくつか挙げてみましたが、つまりはAurora Serverless v1を理由はほぼほぼないと思います。
これまでは、Serverless v2では、0ACU(アイドル状態が続くと自動的に完全停止する)が設定出来なかったですが、2024/11/20のアップデートで設定が出来るようにもなっています。 ドキュメント見ていただけると分かりますが、Aurora Serverless v1 は2025年3月31日でサービス終了となります。もし使っているシステムがある場合、移行が必須となります。
検討事項1 コスト
コストに関しては、DeNA TechCon2023のセッション資料の内容が数値的な検証も含めて最も分かりやすく、めちゃめちゃ参考にさせていただきました。
コストに関して、Serverlessにするとメリットが生まれないという記事も多いですが、個人的には以下の観点も考慮してもいいかと思います。
環境が複数ある場合
例えば、開発環境で、常に使われている環境ではない場合、Serverlessに変更することで、必要な時に必要なリソースを提供できてコストメリットが生まれる可能性があります。
クラスターにおけるライターとリーダーの使用率
Serverless v2は、インスタンスごとにACU増減をすることが可能です。例えば、ライターは負荷が高くスケールをしたとしても、リーダーの使用率が低ければ、ACUは変わらずの状態です。
プロビジョニングでもライターとリーダーでインスタンスサイズを変えることは可能ですが、フェイルオーバーの関係上、推奨されない構成です。Serverlessだと自動でスケールするので、それぞれが違うACUとなっていてもスケーリングさせることが可能なので、万が一フェイルオーバーした場合も勝手に必要なキャパシティ分のスケールが行われます。
今後費用が下がる可能性があること
2024年11月に25%値下げの価格改定が実際にありました。
検討事項2 性能
またDeNAさんのブログ記事となりますが、導入時はこちら参考にしています。
ただし、2年前の記事なので、この時よりも性能は上がっているように思われます。
スケーリングの速度
公式ドキュメントにもあるように、瞬時にスケーリングします。
スケーリングに関しては、バッファプールの減少を考慮して段階的にスケールダウンをするような保守的なアプローチとなっています。
実際に導入後、メトリクスは細かく上下していることを確認しています。
Serverless v1では、スケールアウトまでが遅いと言われることも多々ありましたが、v2になって文字通りの瞬時のスケールが可能となっています。
プロビジョニングに劣る可能性
瞬時のスケーリングが可能になったので、必要なリソースを十分に提供出来るようになったと思っていたのですが、実際に運用してみて気付きました。
プロビジョニングに性能が劣っていることに。
ReadLatencyとWriteLatencyが明らかに変わることになります。
利用可能な物理メモリが減って、データベースのインスタンスのメモリにデータが乗らなくなったことによる オーバーヘッドが一定程度発生していることに起因するのではないかと推察しています。
アソビューさんのブログを参考にさせていただきました。
デフォルト最大接続数の考え方
性能と言っていいのかという気はしますが、気を付けるべきポイントとして、最大接続数の考え方があります。
プロビジョニングでは、インスタンスサイズに応じて最大接続数が決まるようになっていました。
Aurora Serveless v2でも基本的には、同じように最大ACUによってデフォルトの最大接続数が変わります。
| 最大 ACU | Aurora MySQL のデフォルトの最大接続値 | Aurora PostgreSQL のデフォルトの最大接続値 |
|---|---|---|
| 1 | 90 | 189 |
| 4 | 135 | 823 |
| 8 | 1,000 | 1,669 |
| 16 | 2,000 | 3,360 |
| 32 | 3,000 | 5,000 |
| 64 | 4,000 | 5,000 |
| 128 | 5,000 | 5,000 |
| 192 | 6,000 | 5,000 |
| 256 | 6,000 | 5,000 |
1点だけ注意があります！
ただし、PostgreSQL 互換 DB インスタンスで 0.5 ACU の最小容量を指定すると、max_connections の最大値は 2,000 に制限されます。
そのため、いくら最大ACUを上げたとしても、最小ACUが0.5の場合は、最大接続数は2,000に制限されるので、ご注意ください！
Serverless特有のメトリクス
プロビジョニングで運用を既にしている前提でServerlessv2に変更した時にどのように変わるかという内容で書きます。
Auroraを既に使っている場合、基本的に既存のメトリクス監視をそのまま使っていただける監視も多いです。
公式ドキュメントを参考にしながら、Serverlessを使う場合のメトリクスをいくつか紹介します。
- ServerlessDatabaseCapacity
- 現在のDBインスタンスのキャパシティ（ACU単位）を示します
- クラスターレベルでは、全Aurora Serverless v2 DBインスタンスの平均値となります。
- ACUUtilization
- ServerlessDatabaseCapacityをクラスターの最大ACU値で割った割合です。
- 100%に近づく場合は以下の対応を検討：
- 最大ACU設定の増加
- リーダーインスタンスの追加（読み取りワークロードの場合）
- CPUUtilization
- 現在使用中のCPUを最大ACU値で利用可能なCPU容量で割った割合です。
- 100%に近づく場合は以下の対応を検討：
- クラスターの最大ACU設定の増加を検討
- リーダーインスタンスの場合は追加インスタンスの検討
- FreeableMemory
- 最大容量時に利用可能な未使用メモリ量となります。
- 現在の容量が最大容量より低いACUごとに約2GiB増加します。
- 0に近づく場合：
- 最大ACU設定の増加
- リーダーインスタンスの追加を検討
監視対象とするかは、状況にもよりますが、見るべきメトリクスとして、ネットワークのメトリクス(NetworkReceiveThroughput、NetworkTransmitThroughput等)もあります。
これは、スケーリングの要因としてCPU、メモリ、ネットワーク等のリソースが考えられるためです。
Aurora では、各 Aurora Serverless v2 ライターやリーダーの CPU、メモリ、ネットワークなどのリソースの使用率を継続的に追跡しています。
-
DatabaseConnections
性能の箇所で述べた通りですが、プロビジョニングとは異なる考え方をする場合(最小ACU 0.5)がありますので、ご注意ください！
プロビジョニングインスタンスからの変更方法
まずは、Aurora Serverless v2の要件と制限についてです。
利用可能なリージョンとDBエンジンバージョン
随時更新されるため、公式ドキュメントをご参照ください。
東京、大阪ともに利用可能なので、国内利用の場合は問題なく導入に踏み切ることが出来そうです。
Terraformサンプルコード
簡易的ですが、どれくらい簡単で、プロビジョニングから変更が少ないか、サンプルコードを書いてみます。
ちなみに、このコードのままTerraformをApplyしても再起動待ちの変更保留状態になるので、すぐに変更を適用したい場合は、apply_immediatelyオプション等を検討してください。
プロビジョニングとの違いは、2点だけで、aws_rds_cluster.example.serverlessv2_scaling_configurationで、ACU設定をしていること。
aws_rds_cluster_instance.example.instance_classで、"db.serverless"を設定しています。(db.serverlessがv2となります。)
resource "aws_rds_cluster" "example" {
cluster_identifier = "example"
engine = "aurora-postgresql"
engine_mode = "provisioned"
engine_version = "13.6"
database_name = "test"
master_username = "test"
master_password = "must_be_eight_characters"
storage_encrypted = true
serverlessv2_scaling_configuration {
max_capacity = 1.0
min_capacity = 0.0
seconds_until_auto_pause = 3600
}
}
resource "aws_rds_cluster_instance" "example" {
cluster_identifier = aws_rds_cluster.example.id
instance_class = "db.serverless"
engine = aws_rds_cluster.example.engine
engine_version = aws_rds_cluster.example.engine_version
}
もちろん変更を適用させるためには、再起動が必要となりますが、これだけで変更が可能なので、作業的な難しさは一切ないかと思います。
おわりに
Aurora Serverless v2を導入するまでに検討したこと、実際に運用して得られた知見を整理してみました。
導入時には性能面での検討事項は残りますが、マネージドサービスとしてのメリットや、オートスケーリングによる運用負荷の軽減を考えると、非常に魅力的なサービスだと考えています。
ぜひ皆様も導入を前向きに検討してみてください！
Discussion