Aurora Serverless のキャパシティ変更を試してみた

インサイトウォッチ

はじめに

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」まで実施しました。

利用スクリプト

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
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アドレスは保持されていました。

変更前

1
2
3
4
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

変更後

1
2
3
4
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アドレスが変化します。
1
2
3
4
5
6
7
$ 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)
1
2
3
4
5
"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.
  • 計測結果
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    +---------------------+-----+--------+
    | 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 |

2回目

  • ACU:4→8
  • 開始時刻 (CloudTrail)

1
2
3
4
5
"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.
  • 計測結果
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    +---------------------+-----+--------+
    | 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 |

3回目

  • ACU:8→16
  • 開始時刻 (CloudTrail)

1
2
3
4
5
"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.
  • 計測結果
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    +---------------------+-----+--------+
    | 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 |

まとめ

今回の測定では、Aurora Serverless のキャパシティ変更に伴うTPSの低下は数秒以下。 DB接続の失敗や、トランザクションエラーの発生も認められませんでした。

またキャパシティ変更後、DBのUptimeがクリアされている事より、異なるスペックの DBノードへのフェイルオーバが発生していると推測されますが、 Aurora ServerlessのクラスタエンドポイントがNLB相当のリバースプロキシとして機能する事で、 高速なフェイルオーバが実現されている模様です。

How Aurora Serverless Worksより

従来のAurora(Provisioned)と比較して、機能制限などの制約はありますが、 オンラインでの性能変更が可能なRDBMSとして、Aurora Serverlessを利用できる可能性が確認できたと思われます。

CPU負荷などをトリガーに利用できるAurora Serverlessのオートスケールの効果や、コストパフォーマンスについても追って検証、紹介させて頂きたいと思います。

毎週開催サーバーレス相談会