炙手可热的serverless架构,或者称为无服务器架构,是最近几年新冒出来的一种技术架构趋势。
那么,被誉为云计算未来的serverless,有何优势?
在过去不久的全球分布式云大会上,腾讯云数据库专家工程师李志阳分享了【分布式数据库serverless化:深入解读无服务器架构下的数据库】的主题演讲,给出了自己的答案。
Part1 serverless数据库特点
随着业务专注度的提升,服务的抽象程度也在提高。
李志阳举了一个汽车服务的例子,以前为了出行只能购买汽车,现在可以使用打车服务,只需知道目的地即可,不再关注开车和保养,核心诉求得到了更好的满足。
计算服务的演进也是类似,从前自建机房,需要维护机房设备;后来可以在云上直接购买虚拟机,部署业务,负责服务的扩缩容;现在的函数计算,从CI/CD到服务部署,扩缩容,全部自动完成,客户可以更专注于业务代码。
狭义的serverless分为FaaS和BaaS,基本特点是无需运维、以API方式提供服务、按实际使用计费、无使用无费用等。举个例子,用户浏览网页,可能涉及CDN资源。如果是静态内容,从对象存储下载照片、视频;如果是动态内容,则触发一个函数计算,云函数将从云数据库获取相应的资源,生成用户所需的动态内容。其中,云函数为FaaS,对象存储和云数据库则为BaaS。
传统的云数据库会提供多种内存/CPU规格给用户购买。即使无法时刻用满负载,用户也需要为选中的规格付费。如果要将数据库serverless化,需要满足以下三大特性:
第一、自动扩缩容。访问量上来时自动扩容,降低时自动缩容,用户不需要关注规格。
第二、按照实际使用的资源付费。
第三、不使用不计费。如果没有访问,不应该收费。
Part2 serverless数据库选型
在讲述serverless数据库选型之前,李志阳先介绍了云数据库架构的演进。
图左侧是目前的主流架构—单体冗余架构(一主多从),是现在大部分客户使用的架构。这类架构存在扩展性问题,实例的升降级和读扩展,都通过数据搬迁实现,随着数据量的增长,迁移耗时越来越长。
为了解决这个问题,业界趋势是采用存算分离架构,衍生出两类,一类是ShareNothing架构,计算和存储均支持水平扩展,扩展能力非常强。不过,也存在一些缺点,其中最大的问题是SQL兼容性,解决之道在于持续构建和完善自己的生态,让用户更好的接受提供的用法。
另一类则是ShareStorage架构,共享存储架构并没有改变查询引擎和ACI这些基础特性,可以做到100%的兼容性。当然它也有缺点,目前计算节点没有提供写扩展能力,这个也是未来演进的方向。
随后,李志阳又关注到了Serverless数据库的用户群,主要面向中长尾用户,他们对扩展性的诉求并不强,更多关注使用的便利性,兼容性是最重要一点。
因此,腾讯云优先选择了基于共享存储架构的数据库产品TDSQL-C提供Serverless服务。
李志阳对TDSQL-C的总体架构进行了介绍:TDSQL-C是腾讯云基于共享存储架构的云原生数据库,始于2017年。由于ToB业务对稳定性的要求很高,在设计之初就定下了一个基本原则,即复用云上的成熟组件。
在计算层使用了腾讯维护的MySQL内核分支-TXSQL,复用它的bugfix和新特性;存储侧则选择了在腾讯内部有十几年历史的云硬盘CBS,把CBS的核心存储和硬盘逻辑进行剖离,打造了统一存储平台-HiSTOR。
作为存储底座,已适配了云硬盘CBS、云分布式文件系统CFS和数据库TDSQL-C等多款产品,提供副本同步、故障自动迁移、数据校验等一系列完善的数据安全保障能力,这正是TDSQL-C产品能够稳定运行数年的重要基石。
另外,它还提供丰富的特性:备份/回档速度,支持以MB为粒度并发,速度达到GB/s;除了高性能的SSD,还有混存和EC版本,应对归档类的业务,提供更低成本的存储。
除了上述两个关键组件,我们还在计算侧实现了物理复制,将innodb的redo日志准实时同步到备机,主从延时非常低(小于1毫秒);相比传统数据库先写日志后异步刷脏,TDSQL-C只写日志到存储,存储侧通过dbstore模块将日志转化数据。日志下沉的优点很多,这里不做赘述。
由于腾讯云是国内首家提供Serverless数据库的厂家,李志阳主要对比了国外AWS的同类产品Aurora Serverless,并分析如何实现serverless数据库的三大特性。
一、自动扩缩容:
上图右侧有一个共享的虚拟机池,规格不尽相同。Aurora Serverless的扩容策略是从1核2G到4核8G逐步递增规格。例如需要从1核2G扩大到2核4G,则从池子里面找到2核4G的虚拟机,将对应的数据盘挂载到虚拟机,并将访问切到该虚拟机,即可完成自动扩容。有2个问题:1、假设用户访问本身需要4核8G,Aurora Serverless仍需要从1核2G开始逐步增加到4核8G,扩容耗时偏长;2、由于选择新的虚拟机扩容,会导致BP失效,访问将经历一次冷启动过程。
二、按使用量计费
实现比较简单,秒级粒度统计正在使用的规格,按照该规格计费。
三、不使用不计费:
如果实例超过一段时间没有访问,则关闭计算节点。由于有数据库代理节点作为接入层,如果用户再有访问请求,会先到达数据库代理节点。此时,代理节点按照上面提到的方法,从共享池里面找到对应的虚拟机提供服务。对用户而言,原有连接不受到影响,只是感觉到一次卡顿。缺点是引入了代理节点,用户需要为此付费;另外,恢复时长需要30秒,耗时也比较长。
(扩容时BP失效导致的问题)
Part3 TDSQL-C serverless
了解完业界情况,李志阳开始介绍TDSQL-C Serverless。
上图为总体架构,核心模块为中控节点(svls scheduler)。
中控节点接收计算层采集的内存/CPU/访问情况等监控数据,根据策略决定是否扩缩容,启停实例,以及按照计费规则上报云控制台计费。
相对Aurora Serverless的区别在于暂停的应对,TDSQL-C Serverless有faker模块,暂停计算节点时会把四层的vip:vport绑定到faker端口,用户请求过来后,识别为有效的MySQL协议,则通知中控模块将实例重新拉起。其优点在于用户不需要为代理节点付费。
随后,李志阳详细解释了TDSQL-C Serverless如何满足serverless数据库的三大特性。
一、TDSQL-C Serverless的自动扩缩容:
目标是做到秒级的扩缩容,并且期间对用户是平滑的,无感知的。
以上图为例子,用户在购买时选择最小规格为1核2G,最大规格为2核4G。
左边为Aurora Serverless,矩形的纵坐标是CPU,横坐标为内存。初始为1核2G,当业务访问过来,把CPU用满了,持续一段时间才扩容到2核4G。
而右侧的TDSQL-C Serverless,初始就给用户提供最大CPU规格,内存则从最小规格开始。假设用户使用的CPU超过1核,并持续一段时间,将把内存从2G扩到4G。
可以看出,TDSQL-C Serverless的CPU资源不会受限,可以在设置的最大规格内任意使用。优点是用户性能不受限,引入的缺点是可能整机出现满负载。
由于TDSQL-C采用存算分离架构,一旦监控到整机资源超过阈值,就进行快速迁移。迁移其实就是在另外一台相对空闲的机器重新拉起实例,秒级完成。在资源负载上可以精准控制。
另外,现在云数据库整机利用率偏低。基于这两点,TDSQL-C Serverless可以很好应对。
二、TDSQL-C Serverless的按使用量计费:
我们定义了一个算力单元CCU(TDSQL-C Compute Unit)=max{CPU,MEM/2,最小规格}。
其中,MEM/2的含义是,由于我们定义的规格CPU/内存比都是1/2,内存除以2相当于把内存换算成CPU。整体还是以CPU决定整个算力。我们通过计算每个小时CCU平均值给用户计费。
举例说,假设用户选择最小最大规格为0.25核-4核,从图中可以看到,业务高峰过来,一开始就能用到3核,右侧CCU也会按照3核计费,能够很好的应对业务负载。
三、TDSQL-C Serverless的不使用无计费:
自动启停的逻辑比较简单,只要10分钟(用户可配)内监测到没有访问就回收掉计算节点,访问回来就把节点重新拉起。
这里最核心的点是怎么做到快速恢复,之前提过TDSQL-C是日志下沉的,存储侧接收到日志之后会源源不断的回放,数据库计算节点在启动的过程中,不需要像传统数据库那样加载到日志然后重放,所以启动相对比较简单和快速。
具体来说,VDL表示已经持久化的日志点。在运行阶段会不断异步持久化VDL(last-vdl)。Recovery阶段,首先获取last-vdl(checkpoint点),然后广播所有相关的小表获取大于等于last-vdl的所有日志段,最后通过败者树找到最后连续的日志点作为VDL。
整个过程都是并行化的,而且没有数据重放,耗时小于100毫秒。另外,我们还对MySQL启动过程做了多处并行化处理,因此目前可以2秒内恢复实例。
Part4 展望
李志阳表示,TDSQL-C Serverless还在持续优化,不久的将来会把冷启动从2秒缩短到百毫秒级别,更贴近云函数的启动时间。
同时,为了进一步降低用户的存储成本,如果很长时间没有访问,将数据转存到对象存储COS,届时用户只需要付COS的费用即可。
最后,点击「阅读原文」,即可体验19.9一年的TDSQL-C,欢迎大家使用~
- End -
更多精彩
大奖花落谁家,TDSQL他来了
国产数据库,中标哪家强?
↓↓一年19.9特惠TDSQL-C点这儿~