Serverless现状研究报告

现在“Serverless”可能是一个流行术语,但是它并非空洞的存在。AWS Lambda推出还不到5年的时间,就已经被近一半使用AWS基础设施的公司所采用。在本报告中,我们分析了数千家公司的Serverless使用情况,以了解在现实中他们是如何使用Serverless(以及使用到了什么程度)。

Serverless消除了提供和管理基础设施组件(例如,服务器、数据库、队列,甚至容器)的必要性,能够允许团队专注于代码,同时最小化他们的运维开销。本报告将关注Serverless领域的一个子集,即所谓的“函数即服务”(functions-as-a-service, FaaS),它提供了与公共云相同的即付即用模型,但处于“函数”级别,而不是基础设施组件级别。函数只是简单的代码片段,在用户请求或其他事件调用时执行离散的业务逻辑。

对于本报告来说,我们会关注AWS Lambda,它在2020年初是我们的用户群中最成熟和被广泛采用的Serverless平台。在该报告的未来版本中,我们可能会研究来自其他提供商的Serverless产品,比如Google Cloud Platform和Microsoft Azure。

一半的AWS用户已经采用了Lambda

在2020年初,Lambda已经不再是小众的技术。使用Amazon Web Services的Datadog客户中有近一半已经采用了Lambda。(参见文末的方法论章节以了解我们是如何定义采用Lambda和使用AWS的。)这样的采用率,再结合下面章节所讨论的根据环境分解的Lambda使用情况,表明Lambda并不局限于云原生的早期采用者和小众使用场景。相反,在采用AWS基础设施的各种各样的公司中,serverless函数得到了广泛的应用。

Lambda在大型环境中更为普遍

令人意外的是,Lambda的广泛采用并不是由更新、更小的公司所驱动的。相反,我们看到Lambda的采用情况与公司基础设施环境的大小有着明显的相关性,无论环境指的是主服务器、容器,还是serverless函数均是如此。(参见文末的方法论章节以了解我们规模区分的详细信息。)在基础设施规模最大的那些公司中,超过四分之三的公司都采用了Lambda。

使用容器的用户已经大面积采用Lambda

在AWS中运行容器的公司特别中意于Lambda。截至2020年1月,在AWS运行容器的组织中有近80%都采用了Lambda。尽管serverless函数和容器是两个非常不同的环境,但是它们似乎基于类似的原因而被众人所接受,比如为了简化运维而抽象出基础设施的关注点。在一些使用场景中,Lambda和容器基础设施是直接连接的(例如,使用Lambda函数来触发Amazon Elastic Container Service的任务),但是更多的组织可能正在分别运行它们,以满足不同的需求。例如,某家公司可能在一个容器集群中运行其大部分的应用程序,同时将突发的、短期运行的任务(例如支付处理)转移到serverless的函数中。

Amazon SQS、DynamoDB与Lambda是绝配

在将函数连接至基础设施和应用程序组件时,Lambda用户有大量可选的技术。当函数被触发时,它通常会将自己所产生的数据发送给消息队列,而消息队列可以将数据路由至其他的Lambda函数、基于服务器的应用程序或者云服务。消息队列能够让组织采用“仅为真正使用的内容服务”的serverless模式。相对于调用其他的函数并一直等待响应(占用可计费的调用时间),serverless可以通过消息队列的方式进行异步调用。由于函数是临时的和无状态的,所以它们通常会对单独的持久化数据存储进行读写操作。

在与Lambda函数相同的请求中所调用或查询的服务里面,Amazon DynamoDB名列前茅。键值和文档存储非常适合Lambda函数,因为它是一个托管的、可自动伸缩的数据存储,可以保证低延迟。在使用Lambda的场景中,数据存储方面另一个最流行的选择是SQL数据库(无论是Amazon RDS实例还是自管理数据库)和Amazon S3。Amazon SQS(Simple Queue Service)是Lambda请求中消息队列的首选,其次是Amazon Kinesis和Amazon SNS(Simple Notification Service)。SQS在逻辑上非常适合serverless架构:它易于搭建和扩展,成本相对较低,并且提供与Lambda的紧密集成。

Lambda用户中,Node.js和Python占据了主导地位

在Lambda用户可用的语言和框架中,我们看到有两个明显占据了主导地位:Python和JavaScript(借助Node.js)。在当前所有已部署的Lambda中,有47%在运行Python,另外还有39%在运行Node.js应用。Python 3与Python 2的比例是2比1(Python 2在2020年1月正式结束了其生命)。

Python和Node.js的Lambda运行时的流行程度反映了最近应用程序开发的趋势以及Lambda服务本身的发展。AWS在2014年首次发布Lambda预览版,其中Node.js就是第一个得到支持的运行时,2015年又增加了对Java和Python支持。对C#(借助.NET Core)、Go和Ruby的支持则是在2018年新增的。

Lambda函数运行时间的中位数是800毫秒

Lambda函数运行时间的中位数约是800毫秒,这是在所有调用中取平均值得到的,但是延迟分布曲线的尾部很长。四分之一的Lambda函数平均执行时间超过3秒,12%的函数执行时间超过10秒。一些Lambda函数的持续时间很长,这是值得注意的,因为serverless的延迟不仅影响应用程序的性能,还会影响云计算的成本。Lambda定价是基于计算时间的“GB-seconds”:分配给函数的内存(详细信息如下图所示),并乘以其调用的持续时间。

我们将函数持续时间的分布放大一下可以发现,将近五分之一的函数在100毫秒内执行完成,大约三分之一在400毫秒内执行完成。

一半的Lambda函数具有最小的内存分配

如前所述,Lambda调用的成本是根据持续时间和函数内存的乘积计算出来的。因此,鼓励运行Lambda的公司限制其函数的内存分配(这是一个可配置的设置,因此比函数的持续时间更容易控制)。实际上,47%的函数被配置为使用最小的内存运行,即128 MB,而只有14%的函数的内存分配大于512 MB,用户可以为每个函数最多分配3,008 MB。

三分之二的超时时间定义都在1分钟以下

每个Lambda函数都有一个可配置的超时设置,时间从1秒到15分钟不等,这是Lambda调用所允许的最长持续时间。大多数函数都使用了较短的超时:三分之二的超时时间配置为60秒或更少。(创建函数时的默认超时时间为3秒。)

通常来讲,建议的做法是使用较短的超时时间,因为挂起函数会增加云成本,而且Lambda应用程序架构经常需要快速响应。Amazon API Gateway通常用于在Lambda函数前提供REST接口,它的最大超时设置为29秒。因此,API网关后面的任何Lambda函数如果响应时间超过29秒的话,都将会导致一个错误,即使Lambda最终成功地完成了它的工作也是如此。尽管有这些考虑因素,但是依然有许多函数都配置为所允许超时的最大设置:当前的900秒限制以及之前的300秒限制(有效期到2018年10月)。

仅有4%的函数定义了并发限制

默认情况下,在每个region中,Lambda客户的所有函数会有1000个并发执行的限制。用户可以设置每个函数的并发限制,这样的话,就能够为特定函数在总并发池中预留一部分。如果函数超过了它的并发限制,就会进行节流。

如今,在所有的函数中,尽管大多数组织都知道有这个可选限制,但是只有4.2%的函数配置了并发性限制。实际上,88.6%运行Lambda的公司在其环境中至少为一个函数使用了并发限制。定义了并发限制的函数更有可能被限流。在5天的评估窗口中,具有并发限制的函数中有8.3%至少被限制一次,而只有0.3%的函数仅受到region的限制,而不是每个函数本身的限制。

方法论

样本

在本报告中,我们收集了Datadog客户群中数千家公司的使用数据。虽然Datadog的客户涵盖了各个公司规模和行业范围,但他们确实有一些共同的特点。首先,他们往往对软件基础设施和应用程序的性能非常重视。他们比一般的人群更倾向于采用云平台和服务。本文中的所有结果都存在偏见,因为数据来自我们的客户群,这是一个庞大但不完美的全球市场样本。

Lambda的采用情况

在这个报告中,我们认为如果某家公司一个月里至少运行五个不同的Lambda函数,那么我们就认为他们采用了Lambda。Datadog Forwarder函数会将S3和CloudWatch日志等数据发送到Datadog,该函数不包含在计数中。

关于对AWS的使用

如果一个公司在一个月内至少运行5个不同的Lambda函数或5个不同的EC2实例,那么我们就认为该公司在使用AWS。通过这种方式,我们可以捕获AWS用户的基本信息,从而将它们分为专门运行EC2实例的公司、专门运行serverless 函数的公司或同时运行这两种功能的公司。

环境的规模

为了评估公司基础设施环境的相对规模,我们检查了公司的serverless函数、容器、物理服务器、云实例和其他基础设施服务的使用情况。虽然类别(如“中型”和“大型”)之间的界限必然是人为定义的,但类别之间的趋势是明显的。

原文链接:

https://www.datadoghq.com/state-of-serverless/

本文最初发表于Datadog站点,授权InfoQ中文站翻译分享。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/KcLMwB6OXaDhE4676QmM
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券