Categories
程式開發

调查了数千家企业,我们发现Lambda更受大型企业欢迎


最近一段时间,“无服务器”可以说是风头正劲。但更重要的是,这个概念并非空有炒作——自诞生以来不到五年,AWS Lambda已经得到近半数AWS云服务用户的接纳。在本份统计报告中,我们跟进数千家企业的无服务器技术使用情况,旨在总结无服务器计算在现实世界中的普及水平(以及整体使用量)。

无服务器计算,强调的是一种前所未有的资源使用方式:它同样采用公有云最鲜明的按需计费模式,但交付的却是“函数”资源,而非传统的基础设施组件。顺带一提,函数是指部分特定代码段,负责根据用户请求或者其他事件的调用执行离散的业务逻辑单元。

在本份报告中,我们将主要着眼于AWS Lambda——截至目前,它仍是现有及未来潜在用户群体当中成熟度最大、使用范围最广的无服务器平台。当然,在本报告的后续迭代中,我们也会根据情况关注其他服务供应商(例如Google Cloud Platform以及微软Azure)的无服务器产品。

半数AWS用户对Lambda青眼有加

2020年初,Lambda早已不是什么小众技术。目前,我们调查的近半数AWS云服务客户都在使用Lambda。从服务采用率以及按所在行业背景划分的Lambda使用率角度来看,我们发现Lambda已经全面突破了早期云原生应用以及其他小众用例。事实上,无服务器功能目前已经在采用AWS服务的各类企业客户当中得到广泛普及。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 1

Lambda在大型业务中的普及度较高

可能令大家意想不到的是,Lambda广泛普及的背后,依靠的并不是那些规模较小的新兴企业。相反,我们发现Lambda采用率与企业基础设施环境规模之间存在着显著的关联性。无论这类环境以传统服务器、容器还是无服务器为主导,在基础设施规模最大的企业群体当中,有超过四分之三的公司已经开始使用Lambda。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 2

容器用户对Lambda表现出高涨的热情

事实证明,Lambda在那些立足AWS环境运行容器的企业客户中极受欢迎。截至2020年1月,在AWS上运行容器的企业中,近八成已经开始使用Lambda。尽管无服务器函数与容器属于两种截然不同的环境,但出于类似的业务改进诉求,企业对二者表现出了类似的热情——例如通过对基础设施的抽象化,简化日常运营流程。在某些用例当中,用户会将Lambda与容器直接连通(例如使用Lambda函数触发Amazon Elastic Container Service任务);则大多数企业则以各自独立运行的方式满足不同业务需求。例如,一家企业可能将大部分应用程序运行在其容器集群当中,同时将那些突发性、仅需要短期运行的任务(例如付款处理)交由无服务器函数打理。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 3

Amazon SQS 与DynamoDB:Lambda的好伙伴

Lambda用户可以通过多种技术选项,将各类函数与基础设施乃至应用程序组件进行对接。在被触发之后,函数往往会将产生的数据发送至消息队列,再由消息队列进一步将数据路由至其他Lambda函数、基于服务器的应用程序或者云服务处。消息队列能够帮助组织获取无服务器服务提供的“按需计费”模式。各类无服务器函数可通过消息队列进行异步调用,这就打破了只能由一项函数调用另一项函数、并在等待响应的过程中长期闲置(这会显著增加计费时长)的困境。另外,由于函数具有临时性与无状态等特征,因此通常可以面向独立的持久数据存储执行读取或写入。

在包含Lambda函数的请求当中,Amazon DynamoDB成为调用或查询比例最高的配套服务选项。很明显,这是一套云托管型自动规模伸缩数据存储方案,较低的延迟水平配合键值/文档存储机制天然适合与Lambda函数的协同需求。在Lambda用例当中,SQL数据库(包括Amazon RDS实例以及其他企业自主管理的数据库)与Amazon S3则成为第二及第三大高人气数据存储选项。Amazon SQS(简单队列服务)则成为Lambda请求中的首选消息队列方案,紧随其后的是Amazon Kinesis与Amazon SNS(简单通知服务)。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 4

Node.js与Python在Lambda用户中占据主导地位

在Lambda用户群体之内,我们还在编程语言与框架方向上找到两大领先方案选项:Python与JavaScript(通过Node.js)。在目前已经部署的全部Lambda服务当中,有47%运行有Python代码,另有39%运行着Node.js应用程序。其中Python 3的普及度又比Python 2(已经于2020年1月停止支持)高一倍。

Python与Node.js Lambda运行时的广泛普及,反映出应用程序开发领域的最新趋势以及Lambda服务自身的前进方向。AWS于2014年首次发布Lambda预览版本,而Node.js则成为首个受到支持的运行时。在接下来的2015年中,Java与Python支持也陆续上线。在2018年的最新一轮迭代中,Lambda又迎来对C#(通过.NET Core)、Go以及Ruby的支持。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 5

函数的中位数运行时长为800毫秒

在全部调用当中,Lambda函数的中位数运行时长为800毫秒,但持续时长也呈现出明显的长尾分布倾向。有四分之一的Lambda函数平均执行时间超过3秒,12%的函数甚至拥有10秒甚至更长的时间周期。我们之所以高度关注某些特定Lambda函数的长时间运行情况,是因为这不仅会直接影响到应用程序的性能表现,同时也决定着云资源使用成本。Lambda的定价基于“GB-秒”这一计算单位,即分配给特定函数的内存乘以调用所持续的时长。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 6

进一步关注函数持续时长分布,可以发现近五分之一的函数会在100毫秒之内执行完毕,而且约三分之一的函数会在400毫秒内结束。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 7

半数Lambda函数仅具有最低内存容量

如上所述,Lambda函数的调用成本由函数持续时长与内存占用量相乘而计算得出。因此,采用Lambda服务的企业当然会尽可能限制内存分配量(这是一项可配置选项,且控制难度远低于函数持续时长)。实际上,有47%的函数以128 MB最低内存容量方式运行。更重要的是,虽然AWS允许用户为每项函数分配最高3008 MB内存,但只有14%的函数拥有超过512 MB的内存分配量。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 8

三分之二的预定义超时低于1分钟

每项Lambda函数都拥有一条可配置的超时定义,范围在1秒到15分钟之间,其上限代表着Lambda调用所允许的最长持续时间。大部分函数匹配的超时都非常短暂——根据本次调查,三分之二的超时配置不超过60秒(创建函数时的默认超时为3秒)。

之所以建议使用较短的超时配置,是因为函数闲置既会显著增加云服务成本,也不符合Lambda应用架构所通常强调的快速响应理念。用户通常会选择Amazon API Gateway在Lambda函数之前提供REST接口,其最大超时设置为29秒。因此,即使Lambda成功完成了任务,API网关后的一切Lambda函数也需要经过29秒才会被判定为出现响应超时错误。虽然这一保障措施已经相当安全,但大部分用户会为函数设置最大允许超时量——以往上限为300秒(截至2018年10月),目前的最新上限已经提升至900秒。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 9

只有4%的函数具有预定义并发限制

在默认情况下,Lambda客户只能在特定区域内为全部函数保留1000条并发执行空间。用户可以为每项函数设置并发限制,相当于为其指定总并发池中的一定并发资源比例。如果该项函数超出并发限制量,将无法进一步占用并发资源。

目前,虽然大多数客户都很清楚并发限制选项,但只有4.2%的函数实际使用到这项限制功能。但在另一方面,有88.6%的Lambda客户在业务环境中至少对一项函数做出了并发限制。事实证明,具有并发限制的函数确实极有可能发生并发量激增情况。在为期5天的评估窗口当中,有8.3%的并发限制函数至少触发过一次限制功能;相比之下,按区域限制(而非按函数限制)的函数中仅有0.3%触发过并发限制功能。

调查了数千家企业,我们发现Lambda更受大型企业欢迎 10

原文链接:

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