Aurora Serverless のキャパシティ変更を試してみた
先日東京リージョンで利用可能になったAurora Serverless。 オンラインでキャパシティ変更を実施、接続中のDBクライアントへの影響を含めた確認を行ってみました。
はじめに
AWSチームのすずきです。
東京リージョンで利用可能になったAurora Serverless。
以下のスペックをオンライン状態で切り替え、オートスケールで利用する事が可能です。
- Aurora Serverless キャパシティ一覧
ACU(Aurora Capacity Unit) メモリ(Gb) 2 4 4 8 8 16 16 32 32 64 64 122 128 244 256 488
今回、Aurora Serverless キャパシティ変更の所要時間の確認と、DBクライアントへの影響を確認する機会がありましたので、 紹介させていただきます。
検証環境
Aurora
- AWS東京リージョン、
- デフォルトVPCに「Aurora Serverless」のクラスタを設置しました
DBクライアント(EC2)
- AWS東京リージョン
- 利用AMI :Amazon Linux 2 AMI (HVM), SSD Volume Type - ami-e99f4896
- インスタンスタイプ : c5.2xlarge (vCPU:8)
- DBクライアント : mariadb-5.5.56-2.amzn2.x86_64
検証方法
- DBクライアントからmysqlコマンドを利用して4並列でDB更新をループで実行
- AWSコンソールから 「Aurora Serverless」のキャパシティ変更を「2」「4」「8」「16」まで実施しました。
利用スクリプト
sudo yum install mysql -y
echo '[client]
password=<xxxxxx>' > ~/.my.cnf
chmod 600 ~/.my.cnf
DBENDPOINT='db.cluster-<xxxxxx>.ap-northeast-1.rds.amazonaws.com'
DBUSER='xxxxxx'
DBNAME='xxx'
mysql -h ${DBENDPOINT} -P 3306 -u ${DBUSER}
echo "CREATE DATABASE ${DBNAME};" | mysql -h ${DBENDPOINT} -P 3306 -u ${DBUSER}
echo "CREATE TABLE t8 (up_time INT , cur_time TIMESTAMP);" | mysql -h ${DBENDPOINT} -P 3306 -u ${DBUSER} ${DBNAME}
function db_put () {
DBTABLE="$1"
SQL="begin; insert into ${DBTABLE} select VARIABLE_VALUE , now() from information_schema.GLOBAL_STATUS where VARIABLE_NAME='Uptime'; commit;"
for i in {0..50000};
do
echo "$SQL;" | mysql -h ${DBENDPOINT} -P 3306 -u ${DBUSER} ${DBNAME}
done;
}
host ${DBENDPOINT}
for i in {1..8} ; do
db_put t8 &
done
host ${DBENDPOINT}
echo "select cur_time as Processingtime, count(1) as TPS, min(up_time) as Uptime from t4 group by cur_time order by cur_time;" | mysql -h ${DBENDPOINT} -P 3306 -u ${DBUSER} ${DBNAME}
結果
エンドポイントIP
- キャパシティ変更前後、IPアドレスは変化がありませんでした
- Aurora Serverlessの停止中(キャパシティ:0)も、クラスターエンドポイントの正引で戻されるIPアドレスは保持されていました。
変更前
host ${DBENDPOINT}
db.cluster-<xxx>.ap-northeast-1.rds.amazonaws.com is an alias for vpce-<xxx>-mltam7k3.vpce-svc-<xxx>.ap-northeast-1.vpce.amazonaws.com.
vpce-<xxx>-mltam7k3.vpce-svc-<xxx>.ap-northeast-1.vpce.amazonaws.com has address 172.31.27.111
vpce-<xxx>-mltam7k3.vpce-svc-<xxx>.ap-northeast-1.vpce.amazonaws.com has address 172.31.3.82
変更後
host ${DBENDPOINT}
db.cluster-<xxx>.ap-northeast-1.rds.amazonaws.com is an alias for vpce-<xxx>-mltam7k3.vpce-svc-<xxx>.ap-northeast-1.vpce.amazonaws.com.
vpce-<xxx>-mltam7k3.vpce-svc-<xxx>.ap-northeast-1.vpce.amazonaws.com has address 172.31.27.111
vpce-<xxx>-mltam7k3.vpce-svc-<xxx>.ap-northeast-1.vpce.amazonaws.com has address 172.31.3.82
参考(Provisioned)
- 従来のAurora(Provisioned)クラスターでは、フェイルオーバーの実施によりクラスターエンドポイントのIPアドレスが変化します。
$ host db-1.cluster-<xxx>.ap-northeast-1.rds.amazonaws.com db-1.cluster-<xxx>.ap-northeast-1.rds.amazonaws.com is an alias for a1.<xxx>.ap-northeast-1.rds.amazonaws.com. a1.<xxx>.ap-northeast-1.rds.amazonaws.com has address 172.31.15.175 $ host db-1.cluster-<xxx>.ap-northeast-1.rds.amazonaws.com db-1.cluster-<xxx>.ap-northeast-1.rds.amazonaws.com is an alias for a1-ap-northeast-1c.<xxx>.ap-northeast-1.rds.amazonaws.com. a1-ap-northeast-1c.<xxx>.ap-northeast-1.rds.amazonaws.com has address 172.31.27.73
変更所要時間と影響測定
1回目
- ACU:2→4
- 開始時刻 (CloudTrail)
"eventTime": "2018-08-10T13:03:25Z",
"eventName": "ModifyDBCluster",
"requestParameters": {
"capacity": 4,
},
- RDSイベント
- Fri Aug 10 22:04:16 GMT+900 2018
- Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: The customer initiated scaling.
- Fri Aug 10 22:04:23 GMT+900 2018
- The DB cluster has scaled from 2 capacity units to 4 capacity units.
-
計測結果
+---------------------+-----+--------+ | Processingtime | TPS | Uptime | +---------------------+-----+--------+ | 2018-08-10 13:03:25 | 233 | 336 | | 2018-08-10 13:03:26 | 227 | 337 | | 2018-08-10 13:03:27 | 224 | 338 | (略) | 2018-08-10 13:04:10 | 222 | 381 | | 2018-08-10 13:04:11 | 208 | 382 | | 2018-08-10 13:04:12 | 217 | 383 | | 2018-08-10 13:04:13 | 12 | 384 | | 2018-08-10 13:04:14 | 159 | 3 | | 2018-08-10 13:04:15 | 172 | 4 | | 2018-08-10 13:04:16 | 176 | 5 | | 2018-08-10 13:04:17 | 177 | 6 | | 2018-08-10 13:04:18 | 180 | 7 | | 2018-08-10 13:04:19 | 179 | 8 | | 2018-08-10 13:04:20 | 168 | 9 | | 2018-08-10 13:04:21 | 178 | 10 | | 2018-08-10 13:04:22 | 190 | 11 | | 2018-08-10 13:04:23 | 179 | 12 | | 2018-08-10 13:04:24 | 213 | 13 | | 2018-08-10 13:04:25 | 229 | 14 |
- 所要時間(ModifyDBCluster→cluster has scaled): 58s
2回目
- ACU:4→8
- 開始時刻 (CloudTrail)
"eventTime": "2018-08-10T13:07:47Z",
"eventName": "ModifyDBCluster",
"requestParameters": {
"capacity": 8,
},
- RDSイベント
- Fri Aug 10 22:08:35 GMT+900 2018
- Scaling DB cluster from 4 capacity units to 8 capacity units for this reason: The customer initiated scaling.
- Fri Aug 10 22:08:48 GMT+900 2018
- The DB cluster has scaled from 4 capacity units to 8 capacity units.
計測結果
+---------------------+-----+--------+ | Processingtime | TPS | Uptime | +---------------------+-----+--------+ | 2018-08-10 13:07:47 | 225 | 216 | | 2018-08-10 13:07:48 | 226 | 217 | | 2018-08-10 13:07:49 | 227 | 218 | (略) | 2018-08-10 13:08:34 | 213 | 263 | | 2018-08-10 13:08:35 | 197 | 264 | | 2018-08-10 13:08:36 | 215 | 265 | | 2018-08-10 13:08:37 | 8 | 8 | | 2018-08-10 13:08:38 | 170 | 9 | | 2018-08-10 13:08:39 | 140 | 10 | | 2018-08-10 13:08:40 | 168 | 11 | | 2018-08-10 13:08:41 | 179 | 12 | | 2018-08-10 13:08:42 | 151 | 13 | | 2018-08-10 13:08:43 | 138 | 14 | | 2018-08-10 13:08:44 | 178 | 15 | | 2018-08-10 13:08:45 | 177 | 16 | | 2018-08-10 13:08:46 | 184 | 17 | | 2018-08-10 13:08:47 | 170 | 18 | | 2018-08-10 13:08:48 | 192 | 19 | | 2018-08-10 13:08:49 | 202 | 20 |
- 所要時間: 59s
3回目
- ACU:8→16
- 開始時刻 (CloudTrail)
"eventTime": "2018-08-10T13:11:32Z",
"eventName": "ModifyDBCluster",
"requestParameters": {
"capacity": 16,
},
- RDSイベント
- Fri Aug 10 22:12:18 GMT+900 2018
- Scaling DB cluster from 8 capacity units to 16 capacity units for this reason: The customer initiated scaling.
- Fri Aug 10 22:12:23 GMT+900 2018
- The DB cluster has scaled from 8 capacity units to 16 capacity units.
計測結果
+---------------------+-----+--------+ | Processingtime | TPS | Uptime | +---------------------+-----+--------+ | 2018-08-10 13:11:32 | 231 | 183 | | 2018-08-10 13:11:33 | 216 | 184 | | 2018-08-10 13:11:34 | 222 | 185 | (略) | 2018-08-10 13:12:12 | 211 | 223 | | 2018-08-10 13:12:13 | 139 | 224 | | 2018-08-10 13:12:14 | 71 | 2 | | 2018-08-10 13:12:15 | 175 | 3 | | 2018-08-10 13:12:16 | 182 | 4 | | 2018-08-10 13:12:17 | 165 | 5 | | 2018-08-10 13:12:18 | 181 | 6 | | 2018-08-10 13:12:19 | 175 | 7 | | 2018-08-10 13:12:20 | 183 | 8 | | 2018-08-10 13:12:21 | 189 | 9 | | 2018-08-10 13:12:22 | 196 | 10 | | 2018-08-10 13:12:23 | 188 | 11 | | 2018-08-10 13:12:24 | 199 | 12 | | 2018-08-10 13:12:25 | 229 | 13 |
- 所要時間: 51s
まとめ
今回の測定では、Aurora Serverless のキャパシティ変更、長時間のロックやトランザクションなどの阻害用意がなければ1分以下で完了する事を確認できました。 変更中のDBクライアントへの影響もTPSの低下は数秒以下。DB接続の失敗や、トランザクションエラーの発生も認められませんでした。
キャパシティ変更後、DBのUptime情報がクリアされている事より、 異なるスペックのDBノードへのフェイルオーバが発生していると推測されますが、 エンドポイントのIPアドレスは変化しない事が確認できました。
公式ドキュメントの資料などからも、Aurora ServerlessのクラスタエンドポイントはNLB相当のリバースプロキシとして機能していると推測され、DB接続にコネクションプールなどを利用するシステムでも、少ない副作用で利用できる事が期待出来ると思われます。
従来のAurora(Provisioned)と比較し、機能制限、制約などもありますが、 オンラインでの性能変更が可能なRDBMSとして、Aurora Serverlessを利用できる可能性が確認できたと思われます。
CPU負荷などをトリガーに利用できるAurora Serverlessのオートスケールの動作や、コストパフォーマンスなどの効果についても追って検証、紹介させて頂きたいと思います。
