1. 目的と前提条件

1.1 目的

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

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

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

1.2 PolarDB serverlessとAurora Serverlessの違いについて

エンドポイントについて
- PolarDBは、クエリの種類に応じてmaster nodeとread-only node(AuroraにおけるRead replica)を自動的に分散させるエンドポイントを提供しており、master nodeとread-only nodeを含むクラスター全体の性能テストを容易に実施できます。
- Auroraにはこのような機能を持つエンドポイントが存在していない。
  https://qiita.com/dennis_wang/items/ce0ffe4768dfd938baaf#polardb
スケーリングの軸について
- PolarDBは垂直スケーリングと水平スケーリングの両方をサポート
  - 垂直スケーリング(scale up/down)：一つのnodeのスペックが自動的に上がったり、下がったりする
  - スケールアウト(（scale out/in）)：一つのnodeが対応しきれない場合は、新しread-only nodeが自動的に起動してくれる
- Aurora Serverless v2は、垂直スケーリングには対応していますが、水平スケーリングは対応していません。Reader nodeを増やすには、手動で追加する必要があります。
既存のプロビジョニングされたインスタンスへの適用について

Aurora Serverless V2:
- 既存のプロビジョニングされたインスタンスを直接Aurora Serverless V2に変換することはできません(二択一)
- 新しくAurora Serverless V2クラスターを作成するか、既存のクラスターを一度プロビジョニング型に変換してからAurora Serverless V2に移行する必要があります
PolarDB Serverless:
- 既存のプロビジョニングされたクラスターでもServerless機能を有効化可能(ハイブリッド型)。
- 既存のクラスターにサーバーレス機能の有効化というオプションがあり、初期のクラスター設定で設定されたリソースに加えて、サーバーレス機能の有効化後に実際に消費されたリソースに対して課金されます。

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

1.3 テスト条件

table数：20
tableごとの行数：1,000万
データベースのスペック：
- 固定：PolarDB 8 PCU VS Aurora 8 ACU
- 変動：PolarDB 1 ~ 8 PCU VS Aurora 0.5 ~ 8 ACU

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）
  
  AWSのEC2には32core64GBのインスタンスタイプがないため、36core72GBのC5.9xlargeを選択しました。VMのスペックは十分に高いため、テスト結果に影響はないと考えられます。
region：VMとデータベースは同じリージョンに配置
zone：VMとデータベースは同じアベイラビリティーゾーン（AZ）に配置
VPC：VMとデータベースは同じVPC内に配置

2. 結果比較

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

指標	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秒	可能	垂直と水平	32*16 = 512
Aurora	7566.57	378.33	7366.92	368.35	約2分	約4分	不可能	垂直のみ	128
PolarDB/Aurora倍数	6.9	6.8	9.0	9.0	1/6	1/2	-	-	-

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

3. テスト環境構築

3.1 Alibaba Cloud

3.1.1 PolarDB

実際にテストする時にスペックを修正すればいいので、先にデフォルトの状態でインスタンスを作成しておきます。
databaseのaccount作成

3.1.2 ECS

手動で必要なlibraryをインストール

$ sudo apt update
$ sudo apt install mysql-client-core-8.0 -y
$ sudo apt install sysbench -y

環境変数に以下の変数を設定しておく

DBHOST=*
DBUSER=*
DBPASS=*

PolarDB接続endpointの確認方法：
primary nodeしか接続していないPrimary Endpointとすべてのnodeに自動的に分散してくれるCluster Endpointの二種類があります。今回は後者のCluster Endpointを使ってください。

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

データのprepare中に、CPUとメモリの使用量が急激に増加し、PCUも迅速にピークに達しました。
データベースの中身を確認(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も直ちに下がりました。

3.2 AWS

3.2.1 Aurora

データ準備の時間を短縮するためには、デフォルトの値のままでインスタンスを作成しておきます。実際にテストする時にはまたACUを変更します。
生成されたAurora

3.2.2 EC2

手動で必要なlibraryをインストール

$ sudo apt update
$ sudo apt install mysql-client-core-8.0 -y
$ sudo apt install sysbench -y

環境変数に以下の変数を設定しておく

DBHOST=*
DBUSER=*
DBPASS=*

Auroraの接続endpoint確認方法：

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に変更
- 変更前：
- 変更：
- 変更後：
テスト実行

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

実行途中の変化状況を確認
最終結果確認：
データクリア（runコマンドをcleanupに変え、他のパラメーターは変更せずに）：

複数回のテストを行う場合、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

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を変更
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

自動スケーリングのプロセスを確認
1 PCU→ 1.5 PCU: 1秒
1.5 PCU→ 2.5 PCU: 5秒
2.5 PCU → 4 PCU: 5秒
4 PCU → 6.5 PCU: 5秒
6.5 PCU → 8 PCU: 5秒
QPSが最大に達するまでには約35秒かかりました：
TPSが最大に達するまでには約35秒かかりました：
TPS, QPSの結果：
テスト終了後，PCUも徐々に減っています。
PCUが最大の8から最小の1まで減少するのに2分4秒かかりました。

4.1.3 完全停止から起動まで十数秒かかる

PolarDBでは、データベースの負荷がゼロになった後、一定時間が経過すると「完全停止」になります。完全停止期間中、コンピューティングリソース（CPU、メモリ）は無料になります。データベースへのアクセスがあれば、十数秒で完全停止状態から起動可能です。

完全停止できるように設定する方法：

方法１：インスタンス作成する時に、該当機能を有効にする
方法2：インスタンス作成した後で、変更
時間間隔の設定：デフォルトでは60分間アクセスがない場合に完全停止になります。5分から24時間まで、5分間隔で設定が可能です。

完全停止から起動までかかる時間をテスト

監視の間隔を5分に設定しておく
5分間にアクセスがない場合は、完全停止になります。
以下のコマンドを実行

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秒かかりました。

4.2 Aurora

4.2.1 固定スペック：8 ACU

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

ACUが最小の0.5から最大の8までは約2分程度かかりました
結果：
テスト終了後、CPU使用率は急速に下がりましたが、ACUは即時に下がらず、段階的に下がりました(最大の8から最小の0.5まではやく4分程度かかりました)

5. まとめ

指標	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秒	可能	垂直と水平	32*8 = 256
Aurora	7566.57	378.33	7366.92	368.35	約2分	約4分	不可能	垂直のみ	128
PolarDB/Aurora倍数	6.9	6.8	9.0	9.0	1/6	1/2	-	-	-

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