Serverless 现状研究报告

阅读数:2 2020 年 3 月 24 日 09:00

Serverless现状研究报告

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

现在“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 函数得到了广泛的应用。

Serverless现状研究报告

Lambda 在大型环境中更为普遍

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

Serverless现状研究报告

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

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

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 的紧密集成。

Serverless现状研究报告

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 年新增的。

Serverless现状研究报告

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

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

Serverless现状研究报告

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

Serverless现状研究报告

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

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

Serverless现状研究报告

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

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

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

Serverless现状研究报告

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

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

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

Serverless现状研究报告

方法论

样本

在本报告中,我们收集了 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/

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布