f10@t's blog

Cloud Programming Simplified:A Berkeley View on Serverless Computing

字数统计: 5.9k阅读时长: 21 min
2021/08/19

这篇论文深入探讨了Serverless Computing这个较新的云计算概念,并讨论了它的来源、想要解决的问题等等。最近也是接触了一些新的云技术的思想和技术,尤其是自接触了Kubernetes和Quarkus,触发了我对这个领域的好奇心。云计算领域之前也有写过文章微服务入门-5W和微服务思想 · float's blog,但是当时只是简单的看了一下供微服务应用底层使用的一些平台,比如IaaS、PaaS,FaaS等等,也只简单了解了Serverless的概念。故跟着学习一下。

摘要

文章摘要主要叙述了以下重点内容:

  • 说明Serverless cloud computing的特点和作用:
    • 让编程人员更容易的使用云资源
    • 提供了一种接口,极大的简化了云原生(cloud programming)编程以及代表了从汇编语言向高级编程语言转化的过程
  • 概述了云计算的历史,包括:
    • 回顾2009年UCB的云计算的文章:《Above the clouds: A Berkeley view of cloud computing. Technical report》
    • 阐述Serverless computing的动机
    • 概述能够解决当前serverless技术局限性的应用
    • 列出当前该技术的难题,以及探讨其背后学术研究的机会
  • 结语:

Just as the 2009 paper identified challenges for the cloud and predicted they would be addressed and that cloud use would accelerate, we predict these issues are solvable and that serverless computing will grow to dominate the future of cloud computing.

就如2009年的文章指出云计算的难点、预测他们会被解决并提出云技术会繁荣昌盛一样,我们预测当前serverless computing出现的问题也会被解决,并且会主导今后的云计算未来。

第一章 Serverless Computing介绍

在2009年伯克利的文章《Above the clouds: A Berkeley view of cloud computing. Technical report》中,文章叙述了六个云计算的潜在可被挖掘的优点:

  • 可以按需提供无限的计算资源
  • 消除对云用户的预先承诺the elimination of an up-front commitment by cloud users没看懂什么意思
  • 可以提供短期内交付所需计算资源的能力
  • 由于使用了很多、很大的数据中心,所以提供了显著降低了成本的规模经济Economies of scale
  • 通过资源虚拟化来简化操作流程并提高了资源利用率
  • 通过复用来自不通组织的工作负载来提高硬件利用率

但是2009年提出的这些优势,在这十年间(到2019年)上述的六个优势的最后两个没有实现,即:云用户的操作依旧很复杂、多个工作负载也没有从高效的多路复用中获取收益。这两个问题具体展开来说问题如下:

  • 云计算让用户避免了直接管理物理基础设施,但是用户仍需要去管理大量的虚拟资源
  • 多路复用在批类型的工作负载中(比如Hadoop的MapReduce或者高性能计算)表现的很好,这些类型都可以充分利用他们分配的实例。但是对于一些有状态的服务,比如数据库管理系统,移植到云上则会影响工作效果。(原因是因为数据库通常上需要长期保留实例,然而他们的工作负载可能是突发性的,这会导致较低的资源利用率)

2009年的时候,在云计算虚拟化领域主要有两个解决方案:

  • Amazon EC2
  • Google App Engine

前者(EC2)属于更偏底层的方案,实际上市场也选择了Amazon的EC2,但是缺点随之而来,那就是开发人员得自己管理虚拟机,基本包括就是作为系统管理员或者跟系统管理员一块设置开发环境,下面列出了在云上直接操作环境,你自己要考虑的事情:

  1. 你得保证可用性,避免一个机器宕机导致服务不可用
  2. 对副本进行地理隔离,避免灾害来了一锅端
  3. 为了合理利用资源,你需要考虑负载均衡以及路由
  4. 要能根据变化来自动伸缩(Autoscaling)系统
  5. 要有后台监控来保证服务一直运行
  6. 要有日志记录来为后期提供调试(debug)和性能调优
  7. 定期系统升级,包括安全补丁
  8. 如果有新的实例可用,要提供可以直接迁移的能力

所以,上述这些要求的步骤或者叫能力,所需要的时间精力相比于你正儿八经去实现业务功能要复杂,自然是划不来的了。

基于上述这些问题,Amazon在2015年也退出了一个叫AWS Lambda service的服务,Lambda提供了cloud functions的功能,并引发了大家对于serverless computing的关注,这个技术带来了一大特性:用户只需要编写代码就可以了,剩下的服务器配置以及管理任务留给云提供商就可以了。所以就诞生了FaaS这种东西(Function as a Service),FaaS的概念我前面有总结。此外除了FaaS平台,云平台商业提供了一些定制化serverless框架,比如BaaS(Backend as a Service)。文章对Serverless Computing下的简单定义为:

serverless-computing = FaaS + BaaS

具体来说:一个服务如果是Serverless的,那么他必须可以在无显式配置的情况下可以实现autoscaling,并且根据使用情况来进行收费。

最后小结:本文会像之前2009年文章一样,对云计算领域进行讨论,列举出挑战以及学术研究价值。

While we are unsure which solutions will win, we believe all issues will all be addressed eventually, thereby enabling serverless computing to become the face of cloud computing.

文章预测serverless技术会成为云计算领域技术的代表(face啊)。

第二章 Serverless Computing技术的出现

在Serverless平台下,用户只需要用高级编程语言实现业务逻辑就可以了,其他的如实例选举、扩容、部署、容错、监控、日志记录、安全补丁等等操作都交由serverless系统平台自己处理。

下表表示传统方案和Serverless方案的区别,文章将传统方案称为serverful cloud computing(后续我也直接这么写,代表传统方案)。这两种方案代表基于函数的/以服务器为中心的计算平台的端点(endpoint),而如Kubernetes这样的容器编排框架则代表中间体。

image-20210819180804653

从上表我们可以看出,不仅整体的成本下来了,而且原本SysAdmin的工作也全都交由云提供商来完成了,我们只需要敲就完事了。

下图展示了serverless架构是如何简化了应用部署、让云资源变得更加好用的:

image-20210819181110837

作者接下来用一个小例子说明了云计算的过程,并指出了serverless的优点:

在云计算下,serverful computing是在一个使用如汇编语言等底层语言来进行实现的,而serverless computing则使用高级编程语言,比如Python。

举一个例子比如c = a +b,如果是汇编语言的话,首先需要选择多个可以使用的寄存器,然后保存a和b,然后进行数学运算,然后将结果c再另存到寄存器中。这个过程就映射了serverful cloud programming的过程。首先你要准备提供可用的资源或者指出可用的资源,然后将这些资源加载、进行运算、返回或储存这个结果,最后释放资源。

然而,对于serverless computing,它的目的和应用场景是带给云编程人员上类似述的过度到高级编程语言的一些优势,此外,高级编程语言和serverless computing也有相似之处。就好比自动化的内存管理使得程序员不必自己去管理内存资源一样,serverless computing也使得我们不必去管理服务器资源。

具体来讲,serverless computing和serverful computing有三大区别:

  1. 将计算和存储解耦(Decoupled)。存储和计算两部分是分开进行伸缩的,并且是分开提供和计费的。即储存服务是由一个单独云服务商提供的,并且计算服务是无状态的。
  2. 在无需管理资源分配的情况下执行代码。写好代码直接扔上去,云平台就会自动分配资源并执行代码。
  3. 在支付(Paying,也就是计费)的时候,不是按照资源分配量来支付而是按照资源使用量来支付(这一点前面也说过了)。平台是按照和运行相关的元素来进行计费的,比如运行的时间,而不是说按照分配好的资源量来计费的,比如给你分的虚拟机数目之类的。通俗点,一个包子一块,你买了3个吃了2个包子就掏2块,不是掏3块。

下面在上述这三个区别的基础上进行详细讨论

Serverless Computing的上下文(讨论定义、特征)

让serverless computing实现需要哪些技术呢?作者提及以前也有类似的技术,比如PaaS平台(如Heroku、Firebase等)、CGI技术(Perl,PHP)等等,但是作者认为serverless computing相对于这些传统模型,Serverless Comp带来了更大的创新。

哪些创新?serverless computing相比之前的这些模型带来了:更好的自动伸缩、较好的隔离机制、平台灵活性和服务生态支持。

文章举了AWS Lambda为例子,说明了Lambda在收缩机制上的进步,并且按照the time thire code was actually executing, not for the resources reserved to execute their program的标准来收取费用。

Serverless Computing依赖于强大的性能和安全的隔离机制来让多用户同享硬件,目前的标准是使用类似VM虚拟机的隔离机制,当然VM虚拟机的创建肯跟会花费一定时间,所以serverless的提供商们在尽力用技术来加速开发环境的创建。文章举的还是Lambda的例子,Lambda中有两个缓冲池,一个叫做warm pool,由一些VM实例组成,可以理解为预热池,直接按需分配给用户而无需再去创建;还有一些VM实例组成了active pool,这些实例正在运行且被一直维护来供未来使用。所以,使用资源生命周期管理以及多用户打包来实现高利用率,对serverless computing来说是重要的技术点,文章指出近期一些厂商在通过容器技术、unikernel、library OSes,或者language VMs来降低多用户隔离的开销,比如Google的gVisor,已被App EngingCloud Functions、Cloud ML Engine采用;Amazon的Firecracker虚拟机已被AWS LambdaFargate采用;CloudFlare Workers的serverless平台则采用了Web浏览器沙盒技术,在一些使用JavaScript实现的云功能之间进行用户隔离。

serverless computing还有一些其他的优势:

  • 允许用户使用自己的库(libraries),所以较PaaS平台支持更广应用面的应用程序。而PaaS服务则和具体的应用捆绑在一起
  • FaaS使得serverless流行的原因还有一点:背后的BaaS提供了其他的基础性功能,而这些基础性功能从公有云出现的时候(比如AWS S3)就存在了。所以BaaS的存在也是一个优势。

这里作者也澄清了一个概念,FaaS和Serverless computing不是一个东西,前文如果你有和我一样的疑惑,这里就解开了

Cloud functions(i.e., FaaS) represent serverless computing in a more generel form.

即FaaS它知识Serverless Computing的一个更为具体的形式,即规范和实现这种关系。下表对比了一些serverless computing服务在编程接口和消费模型上的区别,我们可以看到不同应用他的接口以及模型都是消费方式都是不一样的,个人认为这旨在说明了Serverless Computing服务的应用领域的多样性。

image-20210819201741247

要注意一点就是,这些应用的存储费用是要单独来收取的,比如Google Cloud Storage、AWS S3等。

接下来作者围绕一些新兴技术结合着进行了讨论,包括Kubernetes技术、边缘计算技术。

首先是关于Kubernetes的,要讨论一个问题:

how it relates to Kubernetes?

这和Kubernetes有啥关系吗?

首先是什么是Kubernets的定义?

a "container orchestration" technology for deploying microservices

一个用来部署微服务的容器编排技术

所以结论是,不同于Serverless ComputingKubernetes它是一个可以简化serverful Computing的技术。下面是他们的相似点与不同点:

  • Kubernetes也可以提供短期(short-lived)的运行环境,但在硬件资源、运行时间和网络通信这些方面上限制小得多。
  • Kubernetes可以直接将你自己本地开发的应用程序直接部署到公有云上,并且几乎没啥修改。而Serverless Computing则引入了一种范式转变(paradigm shift),将操作责任完全交给了提供者,并让细颗粒度的多用户多路复用成为可能。Google Kubernetes Engine(GKE)以及AWS Elastic Kubernetes Service(EKS)都提供了一个中庸的选择:既减轻了Kuberenetes的运行管理,也给予了开发者能够配置任意容器的灵活性
  • KubernetesServerless Computing的收费方式也不一样,前者是按照拥有的资源来收费,而后者是按照每个功能的运行时间来收费

作者接下来也阐述了一个预测,Kubernetes不仅可以本地运行应用,它也同样使用于混合型的应用程序,比如一部分运行在本地,另一部分运行在云上。作者认为这种混合型的应用对于逐步迁移到云这一过程是有意义的。但是长远来看,作者认为云计算规模的逐渐扩大、更快速的网络、不断增加的云服务、通过Serverless Computing技术而逐渐简化的云资源管理,这样的混合型应用的存在感会慢慢减小。

紧接着作者讨论了边缘计算方面。

Edge computing is the partner of cloud computing in the PostPC Era.

边缘计算是后PC时代、云计算的合作伙伴

这里作者主要讨论Serverless Computing将如何改变数据中心内的变成,这对边缘计算也有有趣的潜在影响。一些内容交付网络(CDN)运营商提供了在靠近用户在基础设施中执行一个Serverless函数的功能,甚至AWS IoT Greengrass还可以吧这些函数嵌入到边缘设备中。

Serverless Computing的优势

本章主要说明了一些Serverless Computing的优势,带来的好处,并陈述了一些表明Serverless Computing在不断增长的数据报告,这块我就不写具体数据了。

  • 对于云提供商来说Serverless COmputing技术可以促进业务增长,因为这使得云资源更容易吸引新的用户以及让旧用户发现更多可探索的功能。

  • 由于Serverless Computing运行时间短、内存占用小、无状态的特性,云提供商可以用一些未使用的资源来运行这些任务,比如一些没那么流行的、普通的计算机资源,这些资源可能对于传统Serverful的用户来说没啥用,但是可以投入到Serverless使用中去。

  • 对于客户来说,Serverless允许使用高级编程语言,提高了客户的生产效率,并且还可以节省成本。

  • Serverless也让云部署的级别从x86机器码提升到了高级编程语言,带来了架构的创新。比如,如果ARM或者RISC-V能带来比x86更高的效率的话,Serverless平台可以轻松地切换指令集。

  • 对新手非常友好。即使是菜鸡也能在不了解云基础设施的情况下轻松地部署函数功能,大神们也可以节省开发时间来专注于业务本身。

  • 研究人员被Serverless Computing所吸引,因为它有望成为云计算的未来,有更多的机会来提升当前的性能并客服当前的局限性。

第三章 Serverless Computing平台当前的局限性

本节作者举了五个研究项目的例子来讨论阻碍了Serverless Computing技术的一些难题。包括:

  • ExCamera: Video encoding in real-time
  • MapReduce
  • Numpywren: Linear algebra
  • Cirrus: Machine learning training
  • Serverless SQLite: Databases

下面是这五个项目的总结,包括功能性描述、挑战、工作环境、表现。接下来会对表里出现的问题进行讨论。

细颗粒度操作的储存不够

serverless平台天生就是无状态的,所以这导致很难去支持一些需求是细颗粒度状态共享的应用。而这最大的原因,就是因为现存的、云服务商提供的存储服务的局限性。

哪些局限性?下表进行了说明:

上表中绿色就是好,橙色就是罢了,红色就是不大行。最后一列是我们想要的--Ideal

包括了Block Storage类型、对象型数据库(AWS S3、Azure Blob Storage、Google Cloud Storage)、文件系统、键值型数据库(AWS DynamoDB、Google Cloud Datastore、Azure Cosmos DB)。但是上述这些应用都有各自的优缺点。

学术研究价值:由于不同的应用程序需要不同的持久性和可用性保证,所以作者认为这需要我们去开发一些临时的和持久的Serverless存储方案,第四章会详细讨论。

缺乏精细的协同(coordination)

为了扩展Serverless Computing的能力来支持状态化的应用(stateful applications),serverless框架需要提供一种可以用来协同的方式。好比task A用了task B的输出,那么A必须要有一种方式能知道B是否产生了输出,即使这俩不在一个节点上。许多旨在确保数据一致性(data consistency)的协议也需要类似的协同

这里作者想说的协同我个人理解就是通信的方式,目前没有一个云存储服务提供了通知功能(notification capabilities)。虽然云提供商业提供了独立的通知服务,比如SNS、SQS,但是它们都带来了较大的延迟,有时候甚至几百毫秒。而且对于细颗粒度的协同来说花费太大 。

虽然也有一些论文提出了新的系统比如Pocket -- Pocket: Elastic ephemeral storage for serverless analytics. In 13th USENIX Systemposium on Operating Systems Design and Implementation(OSDI 18), pages 472-444, 2018,但是该方案也尚未被云提供商锁才去。

所以,对于开发者来说,他们的程序就么得选择了,就只能要么用虚拟机来提供比如ElastiCache或者SAND这样的通知服务,或者他们自己实现一套通信机制。

学术研究价值:新的Serverless Computing还值得被挖掘和探索,比如对函数实例进行命名,以实现直接寻址访问其内部状态(比如Actors as a Server, 来自:Johnn Schleier-Smith. Serverless foundations for elastic database systems. CIDR, 2019)。

标准通信模式下性能较差

broadcast-广播aggregation-聚合shuffle-重新分发数据这些都是常见的分布式系统的通信原语,一把都是由应用来执行,比如说在机器学习训练过程中或者大数据分析过程中。下标展示了基于VM虚拟机或者基于函数的方案使用这些原语所构成的通信方式:

从图中可以看到a中的VM通信方式所需的远程消息数目明显少于b,这是因为VM实例支持在发送数据之前或者之后,可以夸人物在本地进行共享、聚合、组合。

对于VM方案,所有在同一个实例上运行的任务都可以获取被广播的数据的副本,或者在给其他实例发送数据前先进行本地的聚合。所以对于VM方案,广播和聚合的通信复杂度是O(N),N代表系统中VM的实例数目。

学术价值:然而,对于基于函数的方案,这个复杂度是O(N x K),其中K代表每一个VM的函数的数目。对于Shuffle操作来说这个差别更大了,假如说同样数目的发送这和接受者产生了N^2个消息数目,对于b方案来说,就需要发送(N x K)^2个数目的消息,K通常上范围是[10, 100]。这都是理想的状态,由于应用程序不能控制云功能的位置,有可能一个Serverless Computing应用就得发送比这个多2到个数量级的数据。

不可预测的表现

尽管云函数比传统的基于VM虚拟机的实例启动延迟要小的多,但是对于一些应用,云函数的方式可能会导致他的启动延迟变大。有三个影响这个冷启动延迟的因素:

  • 启动云函数的时间
  • 初始化这个函数所需要软件环境的时间,比如加载Python库
  • 具体应用中用户代码的初始化时间

虽然说可能一个云函数启动花费时间小于一秒,但是如果云函数的数目多了,这个时间就会变成几十秒。这是一个值得研究的学术问题。

此外另一个值得研究的问题就是,由于云提供商提供选择的底层服务器种类多样,所以导致很难去预测硬件资源的性能,比如不同世代的CPU,这种不确定性暴露了云提供商希望最大限度利用他们的资源的愿望 和 可预测性之间的取舍问题。

第四章 Serverless Computing的未来

这一章作者主要说研究人员已经开始着手解决上一章节提到的问题了,包括伯克利的人也在寻找以数据为中心的分布式系统、机器学习和编程模型的挑战以及Serverless Computing的机遇。下面小结将以一个广泛的视角来讨论一些能够良好结合Serverless Computing的应用和硬件的例子,并指明学术界的挑战,主要包括五个方面:抽象、系统、网络、安全性、架构

抽象挑战

资源需求

数据依赖

系统挑战

高性能的、经济实惠、透明工作的存储服务

Ephemeral Storage(临时性存储)

Durable Storage(永久性存储)

协同/信号机制(signaling)服务

最小化启动时间

网络挑战

安全挑战

调度随机化和物理隔离

细颗粒度的安全上下文管理

Oblivious(遗忘的) Serverless Computing

计算机架构挑战

硬件异构性、定价和管理便利性

参考学习

Jonas E , Schleier-Smith J , Sreekanti V , et al. Cloud Programming Simplified: A Berkeley View on Serverless Computing[J]. 2019.

(72条消息) 论文阅读笔记(五):Cloud Programming Simplified: A Berkeley View on Serverless Computing_wufeifan_learner的博客-CSDN博客

(72条消息) Cloud Programming Simplifie : A Berkeley View on Serverless Computing_Master-TJ的个人博客-CSDN博客

阿里毕玄:《A Berkeley View on Serverless Computing》读后感-阿里云开发者社区 (aliyun.com)

CATALOG
  1. 1. 摘要
  2. 2. 第一章 Serverless Computing介绍
  3. 3. 第二章 Serverless Computing技术的出现
    1. 3.1. Serverless Computing的上下文(讨论定义、特征)
    2. 3.2. Serverless Computing的优势
  4. 4. 第三章 Serverless Computing平台当前的局限性
    1. 4.1. 细颗粒度操作的储存不够
    2. 4.2. 缺乏精细的协同(coordination)
    3. 4.3. 标准通信模式下性能较差
    4. 4.4. 不可预测的表现
  5. 5. 第四章 Serverless Computing的未来
    1. 5.1. 抽象挑战
      1. 5.1.1. 资源需求
      2. 5.1.2. 数据依赖
    2. 5.2. 系统挑战
      1. 5.2.1. 高性能的、经济实惠、透明工作的存储服务
        1. 5.2.1.1. Ephemeral Storage(临时性存储)
        2. 5.2.1.2. Durable Storage(永久性存储)
      2. 5.2.2. 协同/信号机制(signaling)服务
      3. 5.2.3. 最小化启动时间
    3. 5.3. 网络挑战
    4. 5.4. 安全挑战
      1. 5.4.1. 调度随机化和物理隔离
      2. 5.4.2. 细颗粒度的安全上下文管理
      3. 5.4.3. Oblivious(遗忘的) Serverless Computing
    5. 5.5. 计算机架构挑战
      1. 5.5.1. 硬件异构性、定价和管理便利性
    6. 5.6. 参考学习