[AWS]Aurora Serverless 概要

## 1. 概要

- Amazon Aurora のオンデマンド型自動スケーリング機能を備えたバージョン。  
- 従来のプロビジョニング方式では、予め決められたインスタンスサイズで常時稼働させる必要があったが、Serverless ではワークロードに応じて「Aurora Capacity Unit (ACU)」という単位でコンピューティングリソースが自動的に増減する。  
- 0.5 ACU 単位での細かいスケーリングが可能で、迅速な拡大・縮小を実現し、利用中のクエリに影響を与えずに動的なリソース調整が可能。  
	- これにより、利用状況に合わせた従量課金が行われ、アイドル時のコスト削減や、急激なアクセス増加時の自動拡張が期待できる。  

## 2. 主な用途

以下のようなユースケースに適している
- **可変ワークロード・断続的な利用の場合**  
    利用頻度が低かったり、特定の時間帯だけアクセスが集中する開発環境、テスト環境、またはキャンペーンサイトなどで、必要なときだけスケールアップすることでコスト効率を向上させる。
    
- **予測困難なアクセスパターン**  
    突発的なトラフィック増加（例：ニュースサイト、交通情報サイトなど）に対して、シームレスにスケールアップできるため、性能低下を防ぐことができる。
    
- **SaaS アプリケーション**  
    顧客ごとに異なるデータベースクラスターをプロビジョニングする必要がなく、使用時のみリソースを消費するため、効率的な運用が可能。
    
## 3. 通常の Aurora（プロビジョンド）との違い

プロビジョンド版は安定性と一貫したパフォーマンスが求められるシナリオに適しており、Serverless v2 は利用パターンが断続的・変動的な場合にコストや運用効率でメリットが出やすい。
### プロビジョンド方式との比較

- **リソース管理方法**  
    従来のプロビジョンド Aurora は、固定サイズの DB インスタンスを事前にプロビジョニングし、常時稼働させる。一方、Aurora Serverless は、アプリケーションの需要に応じて ACU 単位で自動スケーリングを行うため、アイドル時はリソースが抑えることができる。
- **スケーリングの柔軟性**  
    Serverless v2 は、0.5 ACU 単位でスケールできるため、必要な容量だけを細かく調整できる。対して、従来のプロビジョンド方式はインスタンスのサイズ変更に手動の介入が必要であり、柔軟性が低い。    
- **運用管理負荷**  
    Serverless では、インスタンスの起動・停止、スケールアップ・ダウンを自動で行うため、管理工数が大幅に削減される。

| 項目                  | プロビジョンド版                                 | Aurora Serverless v2                                                       | 備考                                                       |
| ------------------- | ---------------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------- |
| **品質 (Quality)**    | ・固定リソースにより一貫した安定性能・事前にサイズを選定するため高負荷時も安定  | ・自動スケーリングにより需要に応じたリソース供給・最新機能（マルチAZ、リードレプリカ対応）により柔軟性あり・連続高負荷の場合、若干の遅延の可能性も | シナリオによってはServerlessでも十分な品質を発揮。利用パターン次第で使い分けが必要           |
| **コスト (Cost)**      | ・常時稼働するため、低負荷時も料金が発生・リザーブドインスタンスで大幅割引が可能 | ・従量課金制で、利用が断続的・変動的な場合はコスト削減効果あり・ただし、常時高負荷の場合は累積単価が高くなる可能性                  | ワークロードの利用状況により、Serverless v2が有利になるケースとプロビジョンド版が有利なケースがある |
| **運用効率 (Delivery)** | ・手動でスケール調整が必要・急激な需要変動時の対応に時間がかかる可能性      | ・自動スケーリングにより需要の変動に即時対応・管理作業が大幅に簡略化され、運用効率が向上                               | 迅速なキャパシティ供給が可能なため、変動するアクセスに対して柔軟に対応できる                   |

## 4. メリット・デメリット
### メリット
- **コスト効率**  
    アイドル時はリソースが減少するため、従量課金で実際に使用した分のみ料金が発生する。
- **自動スケーリング**  
    突発的なアクセス増加にも即座に対応可能で、シームレスにキャパシティが調整されるため、パフォーマンス維持が期待できる。
- **運用負荷の低減**  
    サーバー管理やインスタンスの調整が不要なため、開発者はアプリケーションロジックに専念できる。
### デメリット
- **スケーリング時の一時的なレイテンシ**  
    急激なスケールアップ時に、若干のコールドスタートや遅延が発生する可能性がある。
- **一定のワークロードではプロビジョンドの方が性能安定性が高い場合がある**  
    常に高負荷がかかる環境では、固定リソースで安定したパフォーマンスを発揮するプロビジョンド方式の方が適していることがある。

## 5. 利用方法

### コンソールからの利用方法
1. **AWS マネジメントコンソールにログイン**  
    AWS のコンソールから「RDS」サービスにアクセスする。
2. **Aurora クラスターの作成**  
    「DB クラスターの作成」画面で、Aurora のエンジン（MySQL 互換または PostgreSQL 互換）を選択し、起動オプションで「Serverless」を指定する。
3. **接続情報の確認**  
    作成後、エンドポイントが発行されるので、アプリケーションから接続設定を行う。
### CLI（AWS CLI）からの利用方法
1. **Aurora クラスター作成**  
    
    ```bash
    aws rds create-db-cluster \
      --db-cluster-identifier my-serverless-cluster \
      --engine aurora-postgresql \
      --engine-version 13.6 \
      --database-name mydb \
      --master-username myuser \
      --master-user-password mypassword \
      --engine-mode provisioned \
      --serverlessv2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
    ```
2. **DB インスタンスの作成**  
    クラスター作成後、同様に `aws rds create-db-instance` コマンドを使用して、インスタンスを作成する。  
    インスタンスクラスとして `db.serverless` を指定することで、サーバーレスモードでの起動が行われる。
    
## 6. 参考文献
- [Amazon Aurora Serverless](https://aws.amazon.com/jp/rds/aurora/serverless/)
- [Aurora Serverless v2 の仕組み](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html)
- [Amazon Aurora Serverless をグラレコで解説](https://aws.amazon.com/jp/builders-flash/202402/awsgeek-amazon-aurora-serverless/)