【RDS】Aurora Serverless v2について調べてみた

はじめに

業務で特定のピーク期間にのみ、トラフィックが急増するアプリケーションを検討する中で、Aurora Serverlessについて、調べる機会があったのでまとめてみました。
2023年10月時点での情報となっていますので、変更情報など最新情報も含めてご参照ください。

RDS Auroraの仕組み

ProvisionedとServerlessの2種類の管理方法があります。
Provisionedとは、リリース設定をユーザーが手動で行う必要があるため、必要な性能に応じて変更することができます。
一方Serverlessとは、データベースのトラフィックに基づいて自動的にスケーリングされます。また、インスタンスの数やサイズを指定する必要がなく、AWSが管理するため、ユーザーはリソース管理が不要です。

Serverless v1とv2の違い

管理方法

Serverless v1とv2でも、上記の管理方法が異なります。
具体的には、v1はクラスターがserverlessで管理され、v2はクラスターがProvisioned, インスタンスがServerlessで管理されています。

つまり、v1ではクラスターとしてServelessを選択するため、インスタンスを管理する領域でなく、v2ではクラスターはProvisionedで、インスタンスがServerlessとして選択できます。
そのため、v2ではクラスター内にProvisioned型のインスタンスとServerless型のインスタンスを作成することが可能です。

スケーリング

v１では、クラスターがしきい値に達した場合、16から32, 32から64のように2倍にスケーリングされます。
v2では、容量を半分追加することができるようになり、より段階的にスケーリングができます。

また、v1ではクエリ処理されていないスケーリングポイントで、vCPU、メモリの増減を変更する必要があるのに対し、v2ではトランザクションやDBコネクションに影響を与えずにvCPU、メモリを増減することが可能となりました。

v1はクラスター単位、v2はインスタンス単位で増減されることを考えると、v2の方がより細かに変更できることがわかります。

可用性

v2からは、マルチAZ機能に対応されました。3つのAZにわたる最大15のAurora Serverless v2リーダーを追加できます。

バッファプール

v2では、インスタンスのスペック変更に追従し、DBに割り当てられるメモリサイズが動的に変更されるようになりました。また、ストレージから読み取られた直後は、バッファプール内にはアクセス頻度が中程度として格納されるため、即座にバッファを廃棄対象となることを回避されるようになっています。
スケールダウン時は、利用頻度の低いバッファプールから切り詰められるようになっています。

Aurora Serverless v2の容量単位

Aurora Capacity Unit(ACU) として、パフォーマンスを評価するための単位として導入されています。
各ACUでは、約2GiBのメモリと、対応するCPU、ネットワークが組み合わされています。
ServerlessDatabaseCapacityとACUUtilizationメトリクスに基づいて、実際に利用されている容量を測定します。

定義可能な最小ACUは0.5ACUで、最大は128ACUです。

料金

ACUの時間で測定されます。
Auroraの料金例に基づき、米国東部（バージニア北部）で5ACUの状態で30分間稼働した場合を計算すると、以下になります。

5ACU × ACU時間あたり0.12USD × 0.5h = 0.30USD

インスタンスクラスのおおよそのメモリを基に、どの程度のACUを設定すべきかを検討します。

インスタンスクラス	メモリ(GiB)	ACU
db.t3.small	2	1
db.t3.medium	4	2
db.t3.large	8	4
db.r3.large	16	8
db.r3.xlarge	32	16
db.r6g.4xlarge	128	64

ユースケース

• マルチテナントなアプリケーション
• 数百以上のアプリケーションから参照され、性能管理が難しいワークロード
• シャーディング、水平方向に負荷分散したデータベース
• 無停止でライターインスタンスのスケーリングが必要なワークロード
• リードレプリカ縮退時の影響により、リーダーインスタンスのスケールアップ、ダウンが望まれるワークロード

おわりに

Serverless v1とv2では、そもそもの管理方法が異なることや、性能面で実際に運用環境として導入できるようなアップデートもあることがわかりました。
実際に導入を検討する場合、具体的な料金算出やスケールアップ/ダウンの要件も考慮する必要があるため、一概に導入できるとは言えず、コスト観点でのプロビジョンドとの比較が重要な要因となりそうです。