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

先日東京リージョンで利用可能になったAurora Serverless。 オンラインでキャパシティ変更を実施、接続中のDBクライアントへの影響を含めた確認を行ってみました。
2018.08.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWSチームのすずきです。

東京リージョンで利用可能になったAurora Serverless。

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接続にコネクションプールなどを利用するシステムでも、少ない副作用で利用できる事が期待出来ると思われます。

How Aurora Serverless Worksより

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

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