1. 目的と前提条件
1.1 目的
業務でAlibaba CloudのPolarDBとAWSのAuroraの両方を使用しています。これらは似ている位置づけで、それぞれのクラウドプラットフォームで推奨されるクラウドネイティブデータベースです。
前回の比較では、Provisionedインスタンスの性能を見たところ、同一スペックで比較した場合、PolarDBがAuroraに比べて約3倍の性能を発揮しました。
今回は、全く同じ条件でPolarDB ServerlessとAurora Serverless V2の性能を比較します。
より実践に近いシナリオで正確に比較するため、中規模のシナリオのテストを設計しました。
PolarDB Serverlessの基本に関する情報は、下記の記事を参考にしてください。
1.2 条件
- 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のみの構成)
- PolarDBは、クエリの種類に応じてmaster nodeとread-only node(Auroraにおける
Read replica)を自動的に分散させるエンドポイントを提供しており、master nodeとread-only nodeを含むクラスター全体の性能テストを容易に実施できます。一方、Auroraにはこのような機能を持つエンドポイントが存在しないため、本テストではread-only nodeを使用しないシナリオに焦点を当て、write nodeのみを使用した場合の性能をPolarDBと比較します。 - PolarDBは垂直スケーリング(一つのnodeのスペックが自動的に上がったり、下がったりする)と水平スケーリング(スケールアウト：一つのnodeが対応しきれない場合は、新しいread-only nodeが自動的に起動してくれる)の両方が対応できる。
一方、Aurora Serverless v2は、垂直スケーリングには対応していますが、水平スケーリング（scale out/in）は対応していません。Reader nodeを増やすには、手動で追加する必要があります。
- VMのスペック：
- ECS (Alibaba Cloud上のバーチャルマシン)：32core64GB（
ecs.c7.8xlarge） - EC2：36core72GB（
C5.9xlarge）
- ECS (Alibaba Cloud上のバーチャルマシン)：32core64GB（
AWSのEC2には32core64GBのインスタンスタイプがないため、36core72GBのC5.9xlargeを選択しました。VMのスペックは十分に高いため、テスト結果に影響はないと考えられます。
- region：VMとデータベースは同じリージョンに配置
- zone：VMとデータベースは同じアベイラビリティーゾーン（AZ）に配置
- VPC：VMとデータベースは同じVPC内に配置
2. 結果比較
先にテストした結果をまとめます。
詳細な手順については後ほど詳しく解説します。
| 指標 | QPS: 8PCU | TPS: 8PCU | QPS: 1~8PCU | TPS:1~8PCU | scale up(1→8)時間 | scale down(8→1)時間 | 完全停止 | scale 方法 | 最大PCU |
|---|---|---|---|---|---|---|---|---|---|
| PolarDB | 52331.66 | 2554.69 | 66540.27 | 3327.01 | 21秒 | 2分4秒 | 可能 | 垂直 and 水平 | 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 | - | - | - |
- スケールアップ時間：データベースの負荷に応じて、最小の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> 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: 1~8PCU | TPS:1~8PCU | scale up(1→8)時間 | scale down(8→1)時間 | 完全停止 | scale 方法 | 最大PCU |
|---|---|---|---|---|---|---|---|---|---|
| PolarDB | 52331.66 | 2554.69 | 66540.27 | 3327.01 | 21秒 | 2分4秒 | 可能 | 垂直 and 水平 | 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の方が大幅にコストを節約できるでしょう。