Serverless 数据库服务

Serverless 最适合计算型任务，计算资源可以随时部署、伸缩，免去了繁琐的运维管理。 这也是为什么 Berkeley 的报告“Cloud Programming Simplified: A Berkeley View on Serverless Computing”1中重点预测 Serverless 在云计算中的应 用将会得到广泛的支持。

在数据库服务中，最合适做 Serverless 支持的也是计算节点，典型的是计算和存储分离架 构中的计算节点。随着 Amazon 推出 Serverless 的数据库服务2，GCP 也有类 似的 Serverless 服务，只不过是 NoSQL3，Azure 也推出了 Serverless 的 SQL Server 服务。

Serverless 数据库服务的价值

Serverless 数据库服务是一种云计算的解决方案。从用户角度可以看到的价值在于：

  1. 自动扩展性：计算资源按需使用，秒级计费。

    以单个计算节点看，可以使用的资源可以在零和机器（或 VM）最大资源之间伸缩。也就是 垂直扩展，Scale up 或 Scale down。既然资源是按需使用的，也就需要按需计费。云 计算目前典型的计费粒度是秒，这也是主流厂商都支持的粒度。

  2. 简化运维管理：实例启停、资源容量自动伸缩。

    之前的数据库服务都需要用户自己做运维，包括什么时候启停，什么时候去做扩容或缩 容。但是有很多的业务场景下用户自己很难去按照系统负载动态的调整资源规格，而且 资源规格的调整还不一定可以立即生效。

  3. 更好的性价比：这也是按需使用和付费带来的潜在好处。

    用户选择数据库服务规格，然后购买和部署，即使资源没有用到，也会付出对应的费用。 Serverless 可以做到按需分配资源，并且按量计费。对于很多不是一整天都持续有访问 高峰的业务，开发中的测试性业务，或新开发的还搞不清楚业务访问模式的业务， Serverless 服务都省去了很多运维管理和购买资源的费用支出。

从上述的价值分析中可以发现，Serverless 适合的可能是对 SLA 要求不是特别严格的中长 尾的业务，也就是公有云中实例数量最多的业务。

Serverless 数据库服务的技术要求

既然 Serverless 数据库服务是一种云计算的解决方案，它的技术挑战更多的是在整体 架构、伸缩和计费等方面。而从数据库内核的角度看，更多的是复用了已经存在的技术。下 面将以 MySQL 为例子来阐述具体的技术要求。

整个产品的架构必须要支持 Serverless 的部署

部署在物理机上并且采用了本地存储的 MySQL 就不容易做到 Serverless。即使我们通过 VM 或容器或 MySQL 内核本身做到资源的弹性伸缩了，并且在物理机上部署了多个 MySQL 实例。在其中的某些 MySQL 实例缩容导致计算资源有富余时，也很难快速调度新的 MySQL 实例进来，因为实例的调度需要迁移数据。类似的，在某些 MySQL 扩容导致机器资源不足 时，也很难快速将部分 MySQL 实例调度走。

采用计算和存储分离的架构设计的数据库产品，将更容易的做到 Serverless。例如将 MySQL 部署在 VM 或容器中，而把数据存储在分布式共享存储上，VM 类似于一个计算节点， 相对比较容易演进为 Serverless 服务。类似的，Amazon Aurora 等则是更新颖的计算和存 储分离产品，它们的计算节点也适合做成 Serverless 形式。

整个产品的计费必须全面支持细粒度（秒级）

因为资源是按需使用，就需要切分清楚哪些资源是可伸缩并计费的，哪些是不可伸缩并计费 的。所有可以伸缩的部分都要按使用量、使用时长进行细粒度计费。例如用户产生的通讯流 量、数据库计算节点的计算资源（vCPU 和内存等）。如果数据库计算节点还有其他的副本 或者备机，它们的计算资源也要统一按量计费。

对于存储资源，即使系统不提供服务了，它也还是被用户实例占用了，所以它的收费时长不 存在 SHUTDOWN 导致的中断。从厂商的角度看，用户实际购买的资源和实际占用的资源其实 是两码事，按照实际占用的空间付费也是更友好的选择。实际占用的存储量显然也是动态变 化的，也应该按照秒级计费。

数据库内核以及相关联的产品都要支持动态伸缩

Serverless 的关键在于资源的可伸缩性。对于数据库计算节点而言，就是节点中的 Scale up 和 Scale down，也就是垂直可伸缩。这个是单机数据库很擅长并且已经解决了的问题， 不过对于具体的产品，还是会有一些具体的功能需要去实现或改进。例如：

  1. 需要能够识别计算节点的压力是否变化了（一定时间内没有连接或没有活动连接）。
  2. 需要能够动态调整计算节点需要的 vCPU 个数。
  3. 需要能够动态调整计算节点需要的内存数量（尤其是 BUFFER POOL）。
  4. 需要能够在识别出节点没有负载后 SHUTDOWN 或休眠。
  5. 也需要在识别出有负载后（例如有新的连接进来）尽快启动或取消休眠。

计算资源的动态伸缩带来的资源利用率挑战

提高资源利用率是多租户支持的必然需求，也是云计算规模化效益的保证。它并不是 Serverless 新带来的挑战。只不过 Serverless 强化了这方面的需求。会云厂商肯定不希 望数据库计算实例动态缩容后节省出来的资源空闲，而是希望尽快调度给别的业务去使用。 而且，在数据库计算实例动态扩容后，有可能导致本机的物理资源不够，而需要调度走一些 实例。数据库服务的计算层要能够在用户无感知的情况下跨机器调度。与此同时，系统针对 数据库实例的调度需要减少对 SLA 的影响，或者说 Serverless 类服务对 SLA 不能太敏感。

References

1 https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf

2 https://aws.amazon.com/rds/aurora/serverless/

3 https://cloud.google.com/products/databases/

[ Serverless , DBMS ]
Written on May 12, 2019