PolarDB ServerlessとAurora Serverless V2の性能対決: 9倍の結果！

# 1. 目的と前提条件
## 1.1 目的
業務でAlibaba CloudのPolarDBとAWSのAuroraの両方を使用しています。これらは似ている位置づけで、それぞれのクラウドプラットフォームで推奨されるクラウドネイティブデータベースです。
前回の比較では、Provisionedインスタンスの性能を見たところ、同一スペックで比較した場合、PolarDBがAuroraに比べて約3倍の性能を発揮しました。

https://qiita.com/dennis_wang/items/33707050e665794a3d7c

今回は、全く同じ条件でPolarDB ServerlessとAurora Serverless V2の性能を比較します。
より実践に近いシナリオで正確に比較するため、中規模のシナリオのテストを設計しました。

PolarDB Serverlessの基本に関する情報は、下記の記事を参考にしてください。

https://qiita.com/dennis_wang/items/31f564a76fbd10e9fa20


## 1.2 PolarDB serverlessとAurora Serverlessの違いについて
1. エンドポイントについて
    - PolarDBは、クエリの種類に応じて`master node`と`read-only node`(Auroraにおける`Read replica`)を自動的に分散させるエンドポイントを提供しており、`master node`と`read-only node`を含むクラスター全体の性能テストを容易に実施できます。
    - Auroraにはこのような機能を持つエンドポイントが存在していない。
    https://qiita.com/dennis_wang/items/ce0ffe4768dfd938baaf#polardb
1. スケーリングの軸について 
    - PolarDBは垂直スケーリングと水平スケーリングの両方をサポート
        - <font color="red">垂直スケーリング(scale up/down)</font>：一つのnodeのスペックが自動的に上がったり、下がったりする
        - <font color="red">スケールアウト(（scale out/in）)</font>：一つのnodeが対応しきれない場合は、新し`read-only node`が自動的に起動してくれる
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/64f7f078-05cd-2f5f-fb53-25125bc38efe.png)

    - Aurora Serverless v2は、垂直スケーリングには対応していますが、水平スケーリングは対応していません。Reader nodeを増やすには、手動で追加する必要があります。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/39b406c2-ec89-a3a9-6584-5e1cef6f4c68.png)

1. 既存のプロビジョニングされたインスタンスへの適用について
- Aurora Serverless V2:
    - 既存のプロビジョニングされたインスタンスを直接Aurora Serverless V2に変換することはできません(<font color="red">二択一</font>)
    - 新しくAurora Serverless V2クラスターを作成するか、既存のクラスターを一度プロビジョニング型に変換してからAurora Serverless V2に移行する必要があります

- PolarDB Serverless:
    - 既存のプロビジョニングされたクラスターでもServerless機能を有効化可能(<font color="red">ハイブリッド型</font>)。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/18b49c6f-f86f-e095-5ab2-7e05aa6968d3.png)
    - 既存のクラスターに`サーバーレス機能の有効化`というオプションがあり、初期のクラスター設定で設定されたリソースに加えて、サーバーレス機能の有効化後に実際に消費されたリソースに対して課金されます。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/5005d0be-bba0-3b2b-5f3a-5fa65ad8f321.png)

この違いは、PolarDB Serverlessがより柔軟な導入オプションを提供しています。既存の環境を大きく変更することなく、サーバーレス機能を追加できるため、ユーザーにとってはより導入しやすい設計になっていると言えます。

https://www.alibabacloud.com/help/en/polardb/polardb-for-mysql/user-guide/enable-the-serverless-function-for-fixed-specification-clusters


## 1.3 テスト条件
- table数：20
- tableごとの行数：1,000万
- データベースのスペック：
    - 固定：PolarDB 8 PCU VS Aurora 8 ACU
    - 変動：PolarDB 1 ~ 8 PCU VS Aurora  0.5 ~ 8 ACU
:::note info
- PolarDB:
  - 1 PCU = 1 core CPU + 2GB メモリ
  - 最小PCU： 1 PCU
  - 最大PCU： 32 PCU
- Aurora:
  - 1 ACU = 約2GiBのメモリと対応するCPU
  - 最小ACU： 0.5 ACU
  - 最大ACU： 128 ACU
:::

- データベースのnode数： 1 (一つの`master node`のみの構成)
    - Auroraにクエリの種類に応じて`master node`と`read-only node`(AuroraにおけるRead replica)を自動的に分散させるエンドポイントを提供していないため、本テストでは`read-only node`を使用しないシナリオに焦点を当て、write nodeのみを使用した場合の性能をPolarDBと比較します。

- VMのスペック：
  - ECS (Alibaba Cloud上のバーチャルマシン)：32core64GB（`ecs.c7.8xlarge`）
  - EC2：36core72GB（`C5.9xlarge`）

    :::note info
    AWSのEC2には32core64GBのインスタンスタイプがないため、36core72GBの`C5.9xlarge`を選択しました。VMのスペックは十分に高いため、テスト結果に影響はないと考えられます。
    :::

- region：VMとデータベースは同じリージョンに配置
- zone：VMとデータベースは同じアベイラビリティーゾーン（AZ）に配置
- VPC：VMとデータベースは同じVPC内に配置

# 2. 結果比較
先にテストした結果をまとめます。
詳細な手順については後ほど詳しく解説します。

<style>
.table-container {
  width: 100%;
  overflow-x: auto;
}
table {
  width: max-content;
}
</style>
<div class="table-container">

|指標 |QPS:8PCU固定| TPS:8PCU固定|QPS:1PCU~8PCU| TPS:1PCU~8PCU|scale up(1PCU→8PCU)時間|scale down(8PCU→1PCU)時間|完全停止|scale 方法|最大PCU|
|:-----------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|
| PolarDB | 52331.66 |  2554.69  | 66540.27 |   3327.01  | 21秒|  2分4秒  |<font color="red">可能</font>|<font color="red">垂直と水平</font>| 32*16 = 512| 
| Aurora     | 7566.57  |   378.33  | 7366.92|  368.35  | 約2分| 約4分| 不可能|垂直のみ|128|
| PolarDB/Aurora倍数 | 6.9 | 6.8 | <font color="red"> 9.0 </font> |  <font color="red">9.0</font> |<font color="red">1/6|<font color="red"> 1/2| - | - | - |
</div>

:::note info
- スケールアップ時間：データベースの負荷に応じて、最小のPCUから最大のPCUまで拡張するのに必要な時間です。この時間が短ければ短いほど、Elasticity（弾力性）が高いと言え、負荷が大きい、または負荷変動が激しい本番環境に適しているという指標になります。
- スケールダウン時間：データベースの負荷に応じて、最大のPCUから最小のPCUまで減少するのに必要な時間です。この時間が短ければ短いほど、より迅速にコスト削減が可能と言えます。
:::

# 3. テスト環境構築
## 3.1 Alibaba Cloud
### 3.1.1 PolarDB
- 実際にテストする時にスペックを修正すればいいので、先にデフォルトの状態でインスタンスを作成しておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/8d0eeca4-f6f8-7c51-ab14-c3bd0f9534f5.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/dd6f0fa4-eb30-0a58-1ced-af5f96c7f8f5.png)
- databaseのaccount作成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/8ec25449-8a8a-805d-568d-c6f6ea9ce461.png)

### 3.1.2 ECS
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/9af37c5a-1882-b76b-97da-d09152059e3c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/77e8536d-d22f-a951-941e-64124e20dec7.png)
- 手動で必要なlibraryをインストール
```
$ sudo apt update
$ sudo apt install mysql-client-core-8.0 -y
$ sudo apt install sysbench -y
```
- 環境変数に以下の変数を設定しておく
```
DBHOST=*
DBUSER=*
DBPASS=*
```

:::note info
PolarDB接続endpointの確認方法：
primary nodeしか接続していない`Primary Endpoint`とすべてのnodeに自動的に分散してくれる`Cluster Endpoint`の二種類があります。今回は後者の`Cluster Endpoint`を使ってください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/15e405ce-4d2d-b060-a182-465df80d4315.png)
:::

- sysbenchはデフォルトで`sbtest`というデータベースを利用するため、手動でデータベースを作成しておきます。
```
echo 'CREATE DATABASE sbtest' | mysql -h ${DBHOST} -P 3306 -u ${DBUSER} -p
```
- tableとデータを作成
```
time sysbench --db-driver=mysql \
    --mysql-host=${DBHOST}  \
    --mysql-user=${DBUSER} \
    --mysql-password=${DBPASS} \
    --tables=20 \
    --table_size=10000000 \
    --range_selects=on \
    --db-ps-mode=disable \
    --time=1800 \
    --threads=500 \
    --report-interval=1 \
    oltp_read_write \
    prepare
```

- 並行実行しているconnections数を確認してみる('--threads'に500のthreadを指定しましたが、20個のテーブルしかないため、20個のconnectionしかありません。)
```
sudo netstat -antp | grep sysbenc
sudo netstat -antp | grep sysbench | wc -l
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/565fb6a3-2ad0-4931-4009-23b7bfc4fbc8.png)
- データの`prepare`中に、CPUとメモリの使用量が急激に増加し、PCUも迅速にピークに達しました。
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/a6035b24-4439-7e71-e8a5-3db4e1a2a68b.png)
- データベースの中身を確認(`sbtest1`~ `sbtest20`まで20個のテーブル、それぞれ1000万のレコードがあります)
```
$ mysql -h ${DBHOST} -P 3306 -u ${DBUSER} -p

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| __recycle_bin__    |
| sbtest      |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

mysql> use sbtest;

mysql> show tables;
+-------------------------+
| Tables_in_sbtest |
+-------------------------+
| sbtest1          |
| sbtest10         |
| sbtest11         |
| sbtest12         |
| sbtest13         |
| sbtest14         |
| sbtest15         |
| sbtest16         |
| sbtest17         |
| sbtest18         |
| sbtest19         |
| sbtest2          |
| sbtest20         |
| sbtest3         |
| sbtest4          |
| sbtest5          |
| sbtest6          |
| sbtest7          |
| sbtest8          |
| sbtest9          |
+------------------+

mysql> show create table sbtest1;
+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table   | Create Table                                                                                                                                                                                                                                                                         |
+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=10000001 DEFAULT CHARSET=utf8 |

mysql> select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
|    10000000 |
+----------+
```
- データの準備が完了すると、CPU使用率はすぐに減少し、PCUも直ちに下がりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/61fc28db-7578-13c7-8883-3c29265c5c87.png)


## 3.2 AWS
### 3.2.1 Aurora
- データ準備の時間を短縮するためには、デフォルトの値のままでインスタンスを作成しておきます。実際にテストする時にはまたACUを変更します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/df8ba33d-be36-8095-d428-77875b61227e.png)
- 生成されたAurora
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/1263b931-974d-92cf-6e12-4992c0f6e677.png)

### 3.2.2 EC2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/df2a9bb6-c57f-4515-2e9b-ee2e6498a65d.png)
- 手動で必要なlibraryをインストール
```
$ sudo apt update
$ sudo apt install mysql-client-core-8.0 -y
$ sudo apt install sysbench -y
```
- 環境変数に以下の変数を設定しておく
```
DBHOST=*
DBUSER=*
DBPASS=*
```
::: note info
Auroraの接続endpoint確認方法：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e961a77e-4fb7-87e6-8955-758700433b99.png)

:::
- sysbenchはデフォルトで`sbtest`というデータベースを利用するため、手動でデータベースを作成しておきます。
```
echo 'CREATE DATABASE sbtest' | mysql -h ${DBHOST} -P 3306 -u ${DBUSER} -p
```
- tableとデータを作成
```
time sysbench --db-driver=mysql \
    --mysql-host=${DBHOST}  \
    --mysql-user=${DBUSER} \
    --mysql-password=${DBPASS} \
    --tables=20 \
    --table_size=10000000 \
    --range_selects=on \
    --db-ps-mode=disable \
    --time=1800 \
    --threads=500 \
    --report-interval=1 \
    oltp_read_write \
    prepare
```
# 4. テスト実施
## 4.1 PolarDB
### 4.1.1 固定スペック：8 PCU
- PolarDBの準備：
  - 最大のnode数と最小のnode数を0に変更(read-only nodeを削除させるため)、最大PCUと最小PCUを8に変更
  - 変更前：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/6d82376d-b717-bbd9-d325-3bca4365a5a6.png)
  - 変更：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/ee930f9d-9236-f904-c71d-291489b8827b.png)
  - 変更後：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/0cce61db-6602-c72a-5fca-f7143611e91b.png)

- テスト実行
```
sysbench --db-driver=mysql \
      --mysql-host=${DBHOST}  \
      --mysql-user=${DBUSER} \
      --mysql-password=${DBPASS} \
      --tables=20 \
      --table_size=10000000 \
      --range_selects=on \
      --db-ps-mode=disable \
      --time=600 \
      --threads=100 \
      --report-interval=1 \
      oltp_read_write \
      run
```
- 実行途中の変化状況を確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/82f7a1ee-1dc5-d49e-56cb-0b1206171db6.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/17a9b881-7e12-3717-1214-550f271c55f3.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/5247c695-67a3-5afa-6cbd-1512516d38c3.png)
- 最終結果確認：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/4fca897f-c60b-c2c9-972a-87d90154e68c.png)
- データクリア（`run`コマンドを`cleanup`に変え、他のパラメーターは変更せずに）：
:::note info
複数回のテストを行う場合、`prepare`、`run`、`cleanup`の三つのコマンドを正確な順序で実行することが必須です。`cleanup`のステップを省略して何度も`run`を行うことは避けてください。その理由は、以前のテストから一時テーブルや接続といったリソースが残っている可能性があり、これらを事前にクリアしておかないと、新たなテストデータと衝突し、エラーが発生したりテストの精度に影響を及ぼす恐れがあるからです。
:::

```
sysbench --db-driver=mysql \
      --mysql-host=${DBHOST}  \
      --mysql-user=${DBUSER} \
      --mysql-password=${DBPASS} \
      --tables=20 \
      --table_size=10000000 \
      --range_selects=on \
      --db-ps-mode=disable \
      --time=600 \
      --threads=100 \
      --report-interval=1 \
      oltp_read_write \
      cleanup
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e5a8811d-8268-17dc-b600-f43a0f4a288a.png)
```
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| __recycle_bin__    |
| information_schema |
| mysql              |
| performance_schema |
| sbtest             |
| sys                |
+--------------------+

mysql> show tables from sbtest;
Empty set (0.00 sec)
```
### 4.1.2 変動スペック：1 ~ 8 PCU
- PolarDBのPCUを変更
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/925cc3de-1328-5ef6-b6a1-187fec1b7eba.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/b93d6ce2-d5c4-0b04-e552-2029a398da1f.png)
- PCUは1になった後で、以下のコマンドを実行
```
sysbench --db-driver=mysql \
    --mysql-host=${DBHOST}  \
    --mysql-user=${DBUSER} \
    --mysql-password=${DBPASS} \
    --tables=20 \
    --table_size=10000000 \
    --range_selects=on \
    --db-ps-mode=disable \
    --time=600 \
    --threads=100 \
    --report-interval=1 \
    oltp_read_write \
    run
```
- 自動スケーリングのプロセスを確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/3abf1db8-3b41-a98f-60d1-8a844842e313.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/0ed7a3e3-2078-1372-8a67-cff1a754fb8f.png)
- 1 PCU→ 1.5 PCU: 1秒
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/343e97ae-e367-0938-ee61-3ba8bb981eb8.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/a5c0d20c-397d-8a61-684e-b5031394cf9f.png)
- 1.5 PCU→ 2.5 PCU: 5秒
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/a8d7e1eb-ec96-b779-0bc4-658c54537617.png)
- 2.5 PCU → 4 PCU: 5秒
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/3ef8ee4b-8367-d51d-d25a-79a2c78cc546.png)
- 4 PCU → 6.5 PCU: 5秒
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/b2418c49-e1ca-d7cc-bceb-fa2f20650ef0.png)
- 6.5 PCU → 8 PCU: 5秒
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e586aa73-d22c-887e-a7b4-bf3bb7d99241.png)
- QPSが最大に達するまでには約35秒かかりました：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/0fa29583-cfe6-0421-475f-9b298e810b48.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e4a1106c-ea76-ca5e-de17-4977dab6877e.png)
- TPSが最大に達するまでには約35秒かかりました：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/170c8526-9080-8a54-5cd2-509339857ca6.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/5d28c482-7de4-8fa8-b76e-cfe76a99fcab.png)
- TPS, QPSの結果：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/167a1995-d06d-3a34-ed68-34c59ad48797.png)

- テスト終了後，PCUも徐々に減っています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/901a26f0-3bfa-fae0-1822-f821149cba15.png)
- PCUが最大の8から最小の1まで減少するのに2分4秒かかりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/afa75f89-b22f-5d6e-6ec1-b96b4405a55f.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e147b21b-f210-3842-16cb-bcf1c9ec5a5a.png)

### 4.1.3 完全停止から起動まで十数秒かかる
PolarDBでは、データベースの負荷がゼロになった後、一定時間が経過すると「完全停止」になります。完全停止期間中、コンピューティングリソース（CPU、メモリ）は無料になります。データベースへのアクセスがあれば、十数秒で完全停止状態から起動可能です。
1. 完全停止できるように設定する方法：
  - 方法１：インスタンス作成する時に、該当機能を有効にする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/0de482a0-5ca1-74d1-4363-a81db1f3f9a1.png)
  - 方法2：インスタンス作成した後で、変更
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e083582c-2b7a-6d96-44c9-28df38c7e8d2.png)
  - 時間間隔の設定：デフォルトでは60分間アクセスがない場合に完全停止になります。5分から24時間まで、5分間隔で設定が可能です。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/d04720a0-a0b7-cba0-5ba6-8d852fd50cdd.png)
1. 完全停止から起動までかかる時間をテスト
  - 監視の間隔を5分に設定しておく
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/f0d33ff1-1b99-b178-590e-4a5cfb5fe62c.png)
  - 5分間にアクセスがない場合は、完全停止になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/7aa90066-cef3-2f65-1914-d852be174a4e.png)
  - 以下のコマンドを実行
```
sysbench --db-driver=mysql \
    --mysql-host=${DBHOST}  \
    --mysql-user=${DBUSER} \
    --mysql-password=${DBPASS} \
    --tables=20 \
    --table_size=10000000 \
    --range_selects=on \
    --db-ps-mode=disable \
    --time=600 \
    --threads=100 \
    --report-interval=1 \
    oltp_read_write \
    run
```
- 完全停止からクエリ処理し始まるまでは約18秒かかりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/923f3fda-8ea9-3d17-f4c7-411ad3a4baf6.png)


## 4.2 Aurora
### 4.2.1 固定スペック：8 ACU
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/ceb0acbe-01f8-d376-ff8f-cfed5d28e946.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/600eaace-fa4c-f15a-28f5-f598d8904d6d.png)

### 4.2.2 変動スペック：0.5 ~ 8 ACU

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/ba786689-f679-54e5-dd42-337ac398fc10.png)
- ACUが最小の0.5から最大の8までは約2分程度かかりました
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/905553d5-4bc7-fdb0-8faf-eb602f3d9762.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/16db5100-ec6a-8f06-84b4-e6b7237d33a8.png)
- 結果：
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/b01a7593-f9e9-1d57-32aa-7df733f3d37f.png)
- テスト終了後、CPU使用率は急速に下がりましたが、ACUは即時に下がらず、段階的に下がりました(最大の8から最小の0.5まではやく4分程度かかりました)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/fb4ce65b-56be-4883-12ee-37f404689aca.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/76a0b979-6d7f-3095-ea6c-9b829986029e.png)

# 5. まとめ
<style>
.table-container {
  width: 100%;
  overflow-x: auto;
}
table {
  width: max-content;
}
</style>
<div class="table-container">

|指標 |QPS:8PCU固定| TPS:8PCU固定|QPS:1PCU~8PCU| TPS:1PCU~8PCU|scale up(1PCU→8PCU)時間|scale down(8PCU→1PCU)時間|完全停止|scale 方法|最大PCU|
|:-----------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|:------------:|
| PolarDB | 52331.66 |  2554.69  | 66540.27 |   3327.01  | 21秒|  2分4秒  |<font color="red">可能</font>|<font color="red">垂直と水平</font>| 32*8 = 256| 
| Aurora     | 7566.57  |   378.33  | 7366.92|  368.35  | 約2分| 約4分| 不可能|垂直のみ|128|
| PolarDB/Aurora倍数 | 6.9 | 6.8 | <font color="red"> 9.0 </font> |  <font color="red">9.0</font> |<font color="red">1/6|<font color="red"> 1/2| - | - | - |
</div>


- Serverlessは変動するワークロードに適しているため、PCUを固定する必要はないと考えられます。PCUを固定する場合は、Serverlessではなく、Provisionedインスタンスの利用が適切でしょう。
- こちらでPCUを固定したシナリオをテストしたのは、固定した場合のPolarDBとAuroraの性能を比較するためです。
- 1~8PCUが変動するシナリオでは、PolarDBはAuroraに比べて約`9倍`の性能を発揮しました。これは最も重要な数字です。
- スケールアップ時間およびスケールダウン時間においても、PolarDBはAuroraよりも明らかに速く、より高いElasticity（弾力性）を持っていると言えます。これは、PolarDBのほうが負荷の大きい、または負荷変動が激しい本番環境に適しているといえるかもしれません。
- PolarDBでは、データベースの負荷がゼロになった後、一定時間が経過すると「完全停止」になります。完全停止期間中、コンピューティングリソース（CPU、メモリ）は無料になります。データベースへのアクセスがあれば、十数秒で完全停止状態から起動可能なため、昼間は使用されているが夜間はほとんど使用されないようなシーンでは、PolarDBの方が大幅にコストを節約できるしょう。