Aurora Serveless的红与黑

Original 飞总飞总聊IT 2017-12-08 22:43 Posted on

收录于合集 #互联网和企业分析 216个

本文仅代表个人立场，于本人的公司无关。

前两周亚马逊AWS在赌城热热闹闹的，给全世界发布了很多新的服务。我朋友圈里一度铺天盖地的有关这场AWS年度盛典的报道。我一度战战兢兢不敢多写，一直到我公司和我确认了我在媒体上发表自己的观点和立场，并不代表公司的态度，也不会破坏我公司和亚马逊亲密无间的合作关系。

提到Serveless，我们都不免要提到亚马逊的Lambda。无可否认这是一项非常伟大的发明。有个八卦是当时做C#的一组人在微软内部先有了这个想法。但是在微软内实现这个却困难重重。于是跳槽去了亚马逊。然后就有了这个产品。当然八卦归八卦，不能否认这个产品很伟大，而且属于亚马逊。

当然，现在其他云厂商也开始提供类似的产品了。微软谷歌都纷纷的发布了自己对应的Lambda的copycat。国内的云厂商也在招兵买马的做类似的产品。

今天这篇文章的主角当然不是这个三年前同一个会议发布的Lambda，是一卷数据库产品Aurora的 Serveless版。

Aurora作为亚马逊RDS服务下面自己研发的数据库，有MySQL和ProstgreSQL两种版本的支持。有关这个数据库的实现，大家可以阅读Aurora团队在SIGMOD2017发表的论文。网上也有很多解读版。

我的简单评价是这个数据库的实现里面有很多让人耳目一新的地方。存储和计算的分离的体系架构，写操作只写log，减少了Write amplifier，存储层有计算能力可以独立合并Log到基准数据去，Cache成为只读Cache等等都是很有意思的实现。论文值得一读，产品很有特色。

Aurora的传统使用方式，和其他的托管数据库服务，乃至本地数据库其实差不多。用户需要设置一台或者若干台机器，然后再用。如果说Capacity不够用，用户也需要人工干预重新去配置。

而Aurora的Serveless版，简单的来说就是用户不需要选择数据库的大小，只需要先和一个前端的代理简历连接，设置最小最大的Capacity，然后系统就会自动根据需要来增加或者减少容量。不再需要用户干预了。

我的第一个直觉，这是一个好东西。一切可以让人省力的东西当然都是好东西。数据库的容量管理并不是一个容易的事情。如果用户的访问不固定，一会多一会少的，数据库要么有浪费掉的资源，要么就有资源不够用的时候。如何管理数据库对每个客户都是一个问题。

当然我们知道，MySQL用得好，对大用户来说，sharding很重要。Sharding这个事情在工业界的自动解决方案是谷歌的Spanner。开源社区的蟑螂数据库和钛数据库是Spanner的copycat。这种自动sharding的实现的代价是单机的性能往往没有单机MySQL好。

但是Aurora本身不具备自动sharing功能。因为很多在亚马逊AWS上的客户本身也不是大客户，不需要sharding。Aurora的serveless版需要解决的问题更像是一个MySQL集群的用户，其使用的容量随着时间的变化比较大，所以需要动态调整，才不会造成资源浪费，让用户付最小的钱。

直观上看，这当然是个好东西，用户能够省心省力，又省钱。但是我们也需要注意到，这个东西有一些潜在的坑。而亚马逊尚未公布很多的技术细节，所以这些坑到底有多严重，也是未知之数。

坑主要来源于两方面。第一个方面是收费模式的问题。为了能够做到serveless，多用少用资源是需要收费的。这个收费方式以Aurora Capacity Unit作为计量单位。按照亚马逊的定义，一个Aurora Capacity Unit大致等价于2GB内存和它对应的CPU和网络带宽。

我以前在Cosmos工作的时候，面临过类似的收费问题。Cosmos是一个共享的数据中心，每年微软所有用Cosmos的队伍都需要做一个预算。预算的核心是这个队伍要用多少资源，花多少钱。

怎么收费一直以来都是一个很难解决的问题。Cosmos的做法是引入token的概念，token数乘以使用时间就是钱。一个token的定义是4GB内存加两个Core的CPU加网络带宽。

事情复杂性在于，你不知道为什么是4GB搭上2Core组个局。多少的内存加多少CPU对于不同的workload的表现是不一样的。你甚至都不知道，两个2GB的内存加一个core的实例和一个4GB的内存加两个core的实例，在实际计算能力上是不是等价的。

怎么收费才公平公正，让用户真正的付出了他们应该付出的是一个非常难的问题。在Cosmos里简单使用token的概念，导致的结果就是用户实际用的和用户付出的并不等价。这个问题一直都没有很好的解决。

今天我看Aurora serveless的收费模式，看到了这个Aurora Capacity Unit的计量单位。无疑是和当年Cosmos用的token的概念很有类似的地方。那么我也不知道为什么2GB的内存搭上对应的CPU就是一个普适的收费标准。我只知道这是一个相对偷懒和简单的收费模式。

至于用户在这个收费模式下付出的是不是合理，肯定有人会占便宜有人会吃亏。所以到最后用了serveless，付了不应该付的钱，那只能哭了。如何对数据库的serveless服务收费，我非常期待亚马逊公布一下内部为什么决定这样收费，为什么这种收费是合理的解释。

第二个问题更多的是技术实现本身的问题了。系统自动增加和减Capacity来应对变化的流量，本身是一个很有难度的事情。因为系统的侦测到采取行动本身就有延迟效应。

举个简单的例子吧。如果系统发现traffic多了才开始增加Capacity。等Capacity上来的时候，traffic已经减少了。系统发现不需要这些capacity了。这些capacity刚下架，traffic又上来了。分分钟搞死系统。最后当然是用户买单。

另外一个方面，traffic来了capacity怎么加也是一个有学问的事情，到底是一下子加很多，还是慢慢一点一点的加。2GB和1core这样的加，还是起个4GB 和2core的instance呢？谁知道怎么做是好的。

而且有一点大家注意到，任何一个Aurora Capacity Unit的最低收费是1分钟。那么谁能保证会不会产生很多实际上用了1秒钟最后被收了1分钟的instance呢？

简单一点来说，Aurora这个产品很有特色。Aurora serveless如果做好了，也是方便很多人，解决很多实际问题的产品。但是从收费和技术的角度来看，我觉得使用Aurora serveless的人一定需要小心谨慎一些。

从目前公布出来的资料来看，和我自己以前的经历结合比较，我觉得这个收费模式本身可能需要近一步观察。而Aurora到底怎么样去自动增加和减少资源的系统实现，也需要使用者去认真关注。

我非常期待亚马逊可以公布更多的技术和实现细节，以及为何要这样收费的细节。另外如果能够有一些实验数据和比较告诉大家serveless在什么样的workload下好，什么样的workload下反而付出更多了，也是很重要的。这款产品到底是大红大紫，还是坑一堆，只有拭目以待了。

打赏专用二维码

Recommend