はじめに
- Auroraを構成するにあたり、ProvisionedとServerlessを比較検討したのでその内容を記事にしています。
- 記載している制約やサポートバージョンは2023/10/23時点の公式ページを元にしています。
Auroraの種類
AuroraにはMySQL互換／PostgreSQL互換のそれぞれに対し3種類の稼働方式が存在します。
- 従来からあるサーバーを常時稼働させる「Provisioned」
- アプリからのニーズに応じてサーバーの起動停止／スケールアップダウンが自動化できる「Serverless v1」
- Serverless v1の性能課題を解決し、より使いやすくなったものの新たな制約も発生した「Serverless v2」
仕様比較表
| 比較項目 | Provisioned | Serverless v1 | Serverless v2 |
|---|---|---|---|
| サポートバージョン | MySQL 5.7/8.0 PostgreSQL 11～15 |
MySQL 5.7 PostgreSQL 11/13 |
MySQL 8.0 PostgreSQL 13/14/15 |
| 接続ポート | MySQL/PostgreSQLと互換性のあるポート | MySQL/PostgreSQLのデフォルトポートのみ | Provisionedと同一 |
| パブリックIPアドレス可否 | 可能 | 不可 | 可能 |
| パフォーマンスインサイト | 利用可 | 不可 |
利用可 ※ACU2以上推奨 |
| 性能 | インスタンスタイプにより固定db.t4g.medium=vCPU:2,メモリ4GB |
ACUにより可変 最小0～最大384（1.0単位） ※停止していない場合 MySQL：最低1ACU PostgreSQL：最低2ACU ※1ACU=vCPU:非公開,メモリ2GB |
ACUにより可変 最小0.5～最大128（0.5単位） ※1ACU=vCPU:非公開,メモリ2GB |
| クラスターの停止 | 手動のみ | 手動/自動 （未使用時は自動停止=0ACU） ※起動には時間を要する |
手動のみ （未使用時は自動で0.5ACU稼働） |
| CPU不足による自動拡張 | 無し | あり | あり |
| メモリ不足による自動拡張 | 無し | 無し | あり |
| ストレージ不足による自動拡張 | あり | あり | あり |
| 対AZ障害 （コンピューティング） |
リードレプリカをクラスタリングすることでマルチAZ構成が可能 | 単一AZでシングル稼働だがAZ障害時には別AZへインスタンスを再作成 | リードレプリカをクラスタリングすることでマルチAZ構成が可能※ |
| 対AZ障害 （ストレージ） |
3つのAZに各2つの計6つを冗長保存 | Provisionedと同一 | Provisionedと同一 |
| 料金(USD/時間) | インスタンスタイプにより固定 db.t4g.mediumの場合：0.113 |
1ACU：0.1 | 1ACU：0.2 |
※Serverless v2のシングル構成ではAZ障害時に別AZへ再作成されません
公式ページに下記の記述がありますがv1の記述であり、v2には適用されません（2022/12/15時点、AWSサポート確認済）
DB インスタンスか AZ が使用不能になった時でも、Aurora Serverless を使用していてれば、別の AZ 内に Aurora が DB インスタンスを自動的に再作成します。
↓公式ページが修正されていました（2023/7/4確認）
DB インスタンスまたは AZ が使用不能になった時でも、Aurora Serverless v1 を実行していれば、別の AZ 内に Aurora が DB インスタンスを自動的に再作成します。Aurora Serverless v2 は、フェイルオーバーや他の高可用性機能のためにプロビジョニングされたように機能します。
Serverless制限機能
＜v1で利用できない機能＞
- Aurora Global Database
- Aurora レプリカ
- AWS Identity and Access Management (IAM) データベース認証
- Aurora でのバックトラック
- データベースアクティビティストリーミング
- Kerberos 認証
- Performance Insights
- RDS Proxy
- AWS Management Console でログを表示する
＜v2で利用できない機能＞
- データベースアクティビティストリーム (DAS)
- Aurora PostgreSQL のクラスターキャッシュ管理
最小構成での性能比較
可用性を担保したうえでAuroraをなるべく安く利用したい場合どうなるかを比較しました。
- 比較条件
- データベースはMySQL
- 東京リージョンを利用
- RLO：AZ障害でも片系で継続稼働
- RTO：15分以内
- RPO：1日前
- 常時稼働状態
| 比較項目 | Provisioned | Serverless v1 | Serverless v2 |
|---|---|---|---|
| バージョン | MySQL 8.0 | MySQL 5.7 | MySQL 8.0 |
| 最小性能 | db.t4g.medium | 1.0ACU(最低=最大) | 最低0.5最大1.0ACU |
| vCPU | 2 | 1?（推測） | 0.5～1.0?（推測） |
| メモリ | 4GB | 2GB | 1～2GB |
| 必要インスタンス (マルチAZ構成) |
2 ライター＋レプリカ |
1 障害時に別AZへ自動再作成 |
2 ライター＋レプリカ |
| 料金単価 | 通常時：0.113USD/時間 バースト時：0.203USD/時間 |
0.1USD/時間 | 0.1～0.2USD/時間 |
| 料金合計 (単価×インスタンス数) |
通常時：0.226USD/時間 バースト時：0.406USD/時間 |
0.1USD/時間 | 0.2～0.4USD/時間 |
| 料金合計 (為替1$=150円) |
通常時：25,222円/月 バースト時：45,310円/月 |
11,160円/月 | 22,320～44,640円/月 |
最低スペックにおいてはServerless v1の障害時別AZ自動再作成はインスタンス１つで済むためとてもよい機能でした。
v2ではその機能が廃止された代わりに、Provisionedと混在してクラスタ構成が取れるようになっています。
※ストレージ料や通信料は除外しています
所感
- Serverless v1はMySQLを前提とした場合、最新バージョンに対応していないため用途が限られます（MySQL5.7のサポート期限が2024年10月31日）
- Serverless v2は単純に単価が高く、パフォーマンスインサイトを有効にするためには2.0ACU以上推奨であることを考慮すると一定以上の性能が要求され、且つスパイクがある場合に有効であると考えられます。
- 実際にv2のパフォーマンスインサイト無効で最低の0.5ACUで構築してみたところアクセスが無くてもCPU使用率が常時50%程度利用されていました。
- Provisionedはリザーブドインスタンスという割引手段（最大55%引き）もあるため、db.t4g.mediumで性能が満たされる限りはServerlessよりも従来通りのProvisionedが有効であると感じました。
単体性能測定
比較の続きとして、負荷テストの実測結果を投稿しました↓
参考情報
- Amazon Aurora の料金
https://aws.amazon.com/jp/rds/aurora/pricing/ - Aurora Serverless v2 と Aurora Serverless v1 の要件の比較
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html#Serverless.v1-v2-requirements