服务
关于
CloudProse博客
聚光灯

法尔盖特vs Lambda

比较AWS'关于成本,性能和易用性的无服务器计算选项
 杰夫·卡特·崔克10
杰夫·卡特 | 2020年2月11日

最新的re:invent宣布对Lambda和Fargate进行了许多改进。尽管这些改进可能释放了附加功能,但它们在融合这两项服务方面也做了很多工作,消除了许多技术和财务障碍,这些障碍以前可能是决定在新项目中使用哪种技术的决定因素。在这篇文章中,我将介绍几种不同的类别,并对Lambda和Fargate进行比较,以给出新添加的功能,说明每种方法的剩余优点和缺点。

成本

让我们从一个有趣的开始吧-Lambda和Fargate在成本方面如何比较?这很复杂-很大程度上取决于您的用例。由于已经有很多关于此主题的文章,因此,我将重点关注最新的re:Invent公告如何影响事物。

首先,AWS宣布 HTTP API 用于API网关。此功能保证了更高的性能和更低的价格。如果您可以不使用REST API的某些功能,则可以支付较低的费用-每百万个请求$ 1.00,而不是每百万个请求$ 3.50。考虑到lambda执行成本,构建一个简单的api端点(可在100ms内处理并使用128 MB内存),每百万个请求大约需要1.408美元。

Lambda的另一个功能 预配置并发,这有点复杂。有一些 混合反应 之所以要使用此功能,是因为它使lambda可以按时间计费,而不仅仅是按使用量计费。对于充分利用的lambda,这可以节省16%的成本,但要以预测使用量为代价。

与Fargate等效,它在应用程序负载平衡器(ALB)后面扩展了一个256 CPU单元(1/4 vCPU)512 MB容器,价格有所不同-按(部分)小时,而不是按要求。此设置的费用约为每小时0.035美元。如果您能够使用 Fargate Spot ,这是re:Invent宣布的另一个新功能,该价格甚至进一步降低-每小时$ 0.0262。这是一个快速图表,以各种速率估算每百万条消息的成本:

尽管HTTP API的价格有所降低,但除非您的流量非常尖锐,否则Fargate在API方面无疑是赢家。重要的是要指出,API网关不仅可以提供ALB的功能,而且还提供速率限制(尽管目前还没有HTTP API)和授权。根据您的需要,这些需要在Fargate中实现,但它们是大多数语言的最流行Web框架的常见功能。

在处理来自队列的消息时,我也想做一个快速比较,因为这将更加公平。在前面的示例中,lambda的大部分支出来自API网关,以及lambda本身的调用成本。由于Lambda可以批量处理队列中的消息(SQS每批最多处理10条消息,Kinesis最多10,000 msgs或6 MB),因此调用成本要低得多。假设每个消息的处理时间为50毫秒,SQS的批量大小为10,Kinesis的批量大小为100,SQS的定价为每百万0.124美元,Kinesis的定价为每百万0.106美元。

对于Fargate,这是另一个图表,显示了以不同速率处理一百万条消息的成本:

即使使用现货定价,这种情况也使Lambda更具竞争力,这通常是异步处理任务的可行选择。对于尖峰负载和低至中等流量,Lambda在这里仍然表现不错。

最后一项涉及成本的新功能是 RDS代理 。传统上,使用Lambda的开发人员必须依靠变通办法,例如在全局范围内存储数据库连接,以防止出现某些连接问题,但这与理想的解决方案相距甚远,因为在Lambda被杀死时无法清理连接,并且除非您在Lambda上设置保留并发,否则您仍然可以耗尽与数据库的可用连接。 RDS代理通过在Lambda和数据库之间添加一项按小时付费的新服务来解决此问题,并为您管理连接池。尽管这是一个了不起的功能,但与可以处理连接池本身的Fargate相比,根据时间和数据库中vCPU的数量增加固定成本可以使该价格迅速过高。

设置与维护

在创建新应用程序时,SAM使基于Lambda的体系结构的处理变得异常简单。通过为所需的基础结构组件(例如API网关和角色)提供默认值,您可以仅专注于代码,然后根据应用程序的需要逐渐替换默认资源。它还提供了基于各种事件触发Lambda的简单机制。尽管有些 循环依赖 问题,整个过程相对容易进行。

另一方面,Fargate需要进行大量工作。现有的ECS CLI工具有助于稍微简化一下弹性容器服务(ECS)部分,但其余架构(存储,缓存等)则需要单独管理。新发布的工具 ECS CLI版本2 在这方面显示出一些希望,但还处于发展初期。

截至2020年初,Lambda仍然很容易用于旋转新架构。当涉及到新的部署和持续的维护时,事情甚至会变得更多。两者的新部署都包括更新CloudFormation模板和部署。对于Lambda和Fargate,AWS都管理底层服务器,这意味着开发人员不必担心安全补丁,而只需关注应用程序代码本身。开发人员将需要更新依赖关系并修复两个平台上的错误,但是对于Fargate,开发人员还需要维护基础映像。这可以是肯定的或否定的-这是一个附加步骤,但确实可以进行更多控制。简单的方法是使Fargate容器基于Amazon Linux 2,而后者由AWS管理,并且始终是Lambda运行时的基础。对于更高级的,您可以使用精简的容器,例如 坚决的 或构建仅包含没有操作系统的已编译二进制文件的映像,从而进一步减小了攻击面。 AWS最近还宣布了 扫描ECR图像 为了自动扫描已知漏洞。

可扩展性

Lambda特别在两个方面发光-缩放到零和快速缩放。对于流量较低的工作负载和开发环境,您无需为空闲的应用程序付费是非常有用的。快速从0-1000扩展的能力对于尖峰,不可预测的流量非常重要。

由于AWS管理底层服务器,因此Fargate可以比在托管EC2实例之上运行的传统ECS更快地扩展。 ECS上的容器扩展事件可能不得不等待基础群集的大小调整,而Fargate可以立即添加任务。但是,由于容量是以阶梯方式添加的,因此它的能力比Lambda差一点。添加新容器可将处理能力提高到每秒数百条消息,这意味着您通常要为不必要的计算支付更多费用。 Fargate的另一个缺点是无法自然扩展到0,尽管可以很容易地按计划或手动关闭Fargate任务,以便在不需要在工作时间以外运行的开发环境中节省资金。

性能

由于Fargate使用更多专用资源运行,因此性能会比Lambda更好也就不足为奇了。问题是,有多少更好,甚至有关系吗?为了测试这一点,我在Fargate和Lambda中都创建了HTTP端点,以进行一些轻量数据操作,并将结果保存到DynamoDB或从DynamoDB检索结果。两项服务均部署在us-east-1中,我从印第安纳州中部的工作站访问了端点。当以50条消息/秒的速度发送10 KB有效负载时,我记录了不同百分位数的以下延迟(以毫秒为单位):

尽管Fargate最终确实更快,但我认为此处更重要的质量是响应时间的一致性。但是这些数字的含义完全取决于用例。在许多使用案例中,增加延迟和不一致并不是问题,尤其是在API所做的工作足以使额外的100毫秒开销不那么明显的情况下。对于更具时间敏感性或关键性的API,例如作为付费服务提供的API,提供快速且一致的体验更为重要。

对于异步的,消耗大量队列的任务,性能并不是问题。在边缘情况之外,任何一个平台都可以出色地完成这项工作。

展望未来

Re:Invent 2019宣布了许多有助于模糊Lambda和Fargate之间界限的功能。 Lambda添加了一些功能来帮助应对冷启动和使用关系数据库,并且Fargate在Fargate Spot中引入了较低的定价选项。尽管它是在re:Invent之前宣布的,但是节省计划是客户可以在可预测的Fargate工作负载上节省金钱的另一种方法。

尽管最近有所改进,但由于技术限制,Lambda和Fargate仍然在某些领域无法竞争。 Lambda无法执行长时间运行的任务或后台处理之类的事情。 Fargate无法直接处理某些事件源,例如DynamoDB流。展望2020年及以后,我相信随着Lambda和Fargate继续融合功能集,这些技术限制的数量将继续减少。新的ECS CLI在将SAM样式的易于部署功能引入Fargate方面已显示出很大的希望。此外,Lambda具有不断增加的限制并支持新的运行时的历史。有趣的是,这些服务将继续发展。

结论

那么,哪种工具最适合您的组织?这取决于!没有灵丹妙药,我不希望经历所有可能的情况。我可以说的是,对于许多应用程序,您都可以使用任一平台构建经济高效,高性能,可靠的体系结构。利用最新的功能和节省成本的选择,正确的体系结构可能不再取决于成本或技术问题,而是取决于人员。根据您团队的专业知识和经验,再培训人员的成本可能远远超过使用其他平台所能节省的成本。或者,可能值得一处使用效率较低的解决方案,以便使用与组织其余部分相同的工具。

无论如何,AWS上无服务器计算的未来是光明的,我们在Trek10拥有一批知识丰富的架构师和工程师,随时准备帮助您在AWS上构建高效,有效的云原生解决方案!

作者