实测Aurora Serverless MySQL

2018-08-15  |  23:15分类:Database,云计算  |  

前几天Aurora Serverless正式GA, 第一时间体验了一下,看看到底怎样。

概述

Lambda的无服务技术是AWS在云产品形态上的一次重大创新,它把云计算最重要的“弹性”能力再向前推了一步。Aurora Serverless MySQL是Serverless技术在数据库上的应用。Aurora Serverless理念非常好,长远来看,对于用户来说,可以根据实际系统压力进行结算,比一次性购买预留实例更加实惠。这是云计算,对于“弹性”概念的又一次升级。

对于云厂商来说,当云的规模足够大时,相比使用预留实例的方式,通过这种系统控制的自动弹性能力,可以极大提高整体的系统利用率。一个简单、极端但是可以说明效果的例子是这样的:如果有两套系统,一套是服务东半球的用户,一套是服务西半球的用户,那么相比给两套系统都预留最大要求容量的资源,这种全自动的弹性可能只需要使用75%或者更少的资源(最低是50%),就可以服务好这两套系统业务。当你服务的业务的高低峰错峰越明显,资源体量越大,那么这种自动弹性的能力带来的效益可能就越大。

那么,我们来看看实际使用中,会带来哪些好处,又或者可能会有哪些“坑”需要小心。

购买

Aurora Serverless MySQL目前只支持MySQL5.6版本,购买过程中配置选项很少,主要需要用户配置,允许弹性的范围,包括如下三部分

  • 实例最大可以扩容(scaling-up)到多少
  • 实例最小可以缩容(scaling-down)到多少
  • 另外,是否允许实例完全没有压力时,暂停实例(scaling to zero)

如果候选了Pause选项,默认实例在连续五分钟没有任何压力时,实例自动被暂停,下一次请求过来后,实例再自动恢复。

控制台

控制台包含了如下信息:
(1) 实例详情,包括主要配置、endpoint、备份计划等信息。
(2) 监控指标,这里提供了共29个监控指标,粒度为1分钟。包括Database Capacity、CPU Utilization、DB Connections等。
(3) 弹性扩缩容的记录,这里记录每次弹性出发的时间点,以及何时完成弹性扩缩容。

实测

这里购买了一个最小为2 capacity units,最大为8 capacity units的实例,内存分别对应为4GB和16GB。

新建数据库表:

CREATE TABLE `a` ( `id` int(11) NOT NULL DEFAULT '0', `num` int(11) DEFAULT NULL, `bid` int(11) DEFAULT NULL, KEY `IND_NUM` (`num`) ) ENGINE=InnoDB

初始化数据(多个如下命令并行):

for i in `seq 0 30000`;do mysql -uzhou -p -hzhou-aurora-1.cluster-cjzowaj9vqpd.ap-northeast-1.rds.amazonaws.com -poraHz#nhTv%8 -v supu -e " insert into a values (rand()*100000,rand()*10000,rand()*10000)"; done

重复运行简单查询:

#!/bin/bash for i in `seq 1 500000` ;do sleep 0.5 && TZ=Asia/Shanghai date +%H:%M:%S.%N && time mysql -uzhou -p -hzhou-aurora-1.cluster-cjzowaj9vqpd.ap-northeast-1.rds.amazonaws.com -poraHz#nhTv%8 supu -e "select * from a where num=4484 limit 1" -q > 1.log 2>2.log ;done

运行大压力SQL(并行几个就可以把系统压力加上去):

select * from a,a as b where a.bid = b.id;

scaling-up测试

在给系统增加多个select * from a,a as b where a.bid = b.id;并行运行以后,系统压力很快就上去了。

系统压力在19:38分CPU利用超过70%,17:43开始出发scaling-up。即五分钟后开始触发scaling-up。

Snip20180814_86

Snip20180816_123

这是一个,关于执行query响应时间稳定性的趋势图,可以看到,在完成scaling-up之后,系统响应会更加稳定:

42255130020_b49f5b0917_z
(点击查看大图)

另外,这里发现一个问题,在系统压力加上去后,scaling-up动作一致没有成功完成。原因在于,Aurora Serverless在出发scaling-up之后,会选取一个scaling point开始去支持scaling的动作,执行这个动作必须避开如下情况: long running query或者long running transaction。

在上面的案例中,系统中有多个long running query,所以一直没有scaling-up成功,直到我登上数据库,把long running的query全部kill,Aurora才成功完成scaling-up。

这是一个非常严重的问题,在系统压力很大的时候,很可能存在长时间运行的query或者transaction,这些query可能是系统压力大的“因”,也有可能是“果”,但,这是非常常见的。这可能导致,scaling-up在很多情况下都无法成功,也就达不到当系统压力较大时,自动scaling-up这个目的。

scaling-down测试

scaling-down的触发条件是CPU利用率小于30%,并且,连接数低于40%。当系统压力下降时,会触发scaling-down:

Snip20180816_126

scaling to zero / paused测试

特别是对于个人测试环境来说,这是一个非常好的特性。当我,晚上不再使用这个实例的时候,实例相当于会自动停掉,是非常节约成本的。

看下图日志,可以看到:18:24分我去食堂吃饭了,系统很快进入了paused状态。19:13我回来继续测试,系统开始重新恢复,这里显示,系统恢复时间约为17秒。但是在实际测试过程中,从paused状态再入恢复到可用,实际感受约25秒。

Snip20180816_124

但是,这里也发现了另一个问题。scaling to zero的触发条件必须是系统没有任何query,且系统没有任何连接。很多时候,系统没有任何连接是比较难的,比如在实测时就出现了这个情况,由于某个终端下建立的MySQL连接,但是该终端由于某个原因异常断开了,但是,这时这个MySQL连接在Server端很可能会一直保持,这会导致,Aurora无法scaling to zero。这种断掉的连接,在服务端可能要经历非常长的“超时”设置才会被断开。

没有正确断开的连接,也会导致Aurora无法scaling to zero,而没有正确断开的连接,在实际管理操作中这是比较常见的。

其他概念

cooldown

scaling-up的操作有3分钟的cooldown,只有在上次scaling操作之后至少3分钟才会触发。Scaling-down的cooldown为15分钟。

1.5分钟和5分钟

触发scaling-up需要系统达到触发条件,并持续1.5分钟,才会触发。Scaling-down则需要达到触发条件5分钟才会开始触发。

scaling point

scaling-up操作过程中,如果没有满足条件的scaling point,那么在尝试五次scaling操作之后,系统将会放弃。

Snip20180816_125

总结

如果系统压力是缓慢增长,Aurora Serverless那么这种scaling策略可能非常有效。

但是,在实测中也发现一些问题,比如,scaling-up操作需要寻找到没有long running query和transaction的scaling point,实际情况中这个要求是很高的,系统压力较大时,尤其是系统压力突然增大时,很可能会由于找不到scaling point而导致scaling-up失败。再比如,如果希望scaling to zero,那么系统不仅没有query,而且不能有任何的连接,而这在实际情况中也是比较难控制的。

Aurora Serverless MySQL给用户带来的实惠是,真正的按使用量付费,数据库压力大的时候,系统自动进行升级,用户需要支付更大实例的费用,数据库压力小的时候,系统自动降级,则只需支付较少的费用,当完全没有压力的时候,则无需支付任何计算(包括内存)费用,只需支付存储费用。听起来比较美好,但是要在生产中比较好的使用,还需要一定的“磨合”。

--EOF--

喜欢本文,那就收藏到:

发表您的评论