使用AWS CloudWatch 调优Lambda函数 | 技术头条

戳蓝字“CSDN云计算”关注我们哦!

使用AWS CloudWatch 调优Lambda函数 | 技术头条

技术头条:干货、简洁、多维全面。更多云计算精华知识尽在眼前,get要点、solve难题,统统不在话下!

译者:风车牛马

整理:刘丹


Kyle Galbraith,高级软件工程师,AWS认证专业解决方案架构师。Kyle Galbraith开门见山的提到:“对于使用Serverless和AWS Lambda的新人来说,通常我们会为他们提供需要的功能。我们编码时会考虑服务会做什么,它会依赖什么。”

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


当涉及到提供新服务时,需要对一些性能做出预测。估计有多少内存来提供功能;大致了解了运行函数并退出所需的时间,无服务器架构允许我们快速部署。

 

如果我们预测和估计错误呢?内存不足或将时间限制设置的较低,就会出现大量错误。亚马逊网络服务不会出现这些问题,这是一种责任。同时AWS为我们提供了一些工具和方法,允许我们自己检查这些问题。

 

本文我们将研究如何使用AWS CloudWatch来更好地理解Lambda函数——实际使用了多少内存和执行时间。在此基础上,可以调整功能,以平衡成本问题,同时不降低性能。


AWS CloudWatch

 

早在去年11月,AWS就发布了CloudWatch。几乎所有的AWS服务都会创建某种类型的日志,这些日志通常包含许多关于服务器的有价值的信息。

 

该版本发布之前,需要几跳地址获取这些数据并将其可视化。虽然可以对日志组执行基本查询,但很多时候,必须将日志转存到能够查询的地方。

 

CloudWatch 避免了这样的负担,可以直接查询所感兴趣的数据点。例如,查询函数实际使用了多少内存,针对各种不同的AWS服务编写自己的定制查询。这对于生成特定服务器的报告和可视化非常有用。

 

我们下面来探索CloudWatch如何优化分配的内存,从而节省一点钱。注意,CloudWatch 中运行查询的价格是每GB扫描数据0.005美元,所以要注意查询的数据量。

 

举个例子——AWS Lambda函数

 

我们首先假设一个实际应用的场景,已经过分分配了Lambda函数的内存。

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


我编写了一个Lambda函数自动创建MailChimp活动。该函数通过查询一个谷歌列表来获取一周的文章,然后使用电子邮件模板创建MailChimp活动。

 

这个函数一周运行一次,所以不会耗尽资源。但我们假设这个函数每周被调用10,000次。想象一下,这样跟得上吗? 下面开始详细讨论。

 

首先看看为这个连续不断的函数准备了多少内存,可以通过serverless.yml文件来看到。

 

有趣的是,我们在这个YAML文件中没有看到任何有关内存的内容,为什么?这意味着使用了无服务器框架的默认内存值,为这个函数提供了1024 MB的内存。

 

对于读取列表并调用MailChimp API的函数,我们真的需要这些内存吗?也许吧,但实际上我们可以通过使用CloudWatch得到答案。

 

确定超配的内存

 

CloudWatch 附带了许多开箱即用的示例查询。您可以使用它们查看最近的CloudTrail事件、查询VPC流日志、查看Route53区域正在接收多少请求等等。

 

这里感兴趣的是超配给内存的查询。我们可以通过登录到AWS控制台,然后进入CloudWatch来查询结果。一旦进入CloudWatch服务,我们就可以选择日志下面的链接。

进入CloudWatch 页面后,我们可以选择Sample Queries下拉菜单,然后打开Lambda选项。在这里,我们看到“Determine the amount of overprovisioned memory sample query” (查询过量内存的数量),然后选择它。如下所示:

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


查询的结果有已分配的内存、最小使用量、平均使用量、最大使用量,并计算内存的过度分配情况。在选择的时间段内(默认为1小时)进行计算。

 

在查询编辑器中,我们还看到一个下拉菜单,它允许我们选择查询的AWS资源。

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


我们看到这个函数过去四周运行了四次。假设这个函数每周被调用10,000次,函数在过去4周内被调用了40000次。可以得出以下结果。

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


我们所分配的内存是976 MB,但是平均内存使用量只有95 MB,这意味着函数被超额分配了881 MB。只使用提供的内存的9%意味着什么呢?

 

最简单的答案是,我们在浪费资源,因此也在浪费金钱。让我们来看看价格细分。

 

Lambda函数提供1024 MB内存,每次调用大约需要7000毫秒执行。对于每周10,000次调用,我们的成本分解如下所示。

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


以每GB每秒0.00001667美元的速率,我们得到的总成本为:

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


在此计算中,还有几美分需要考虑到请求的成本,但是在这个场景中,这些成本非常小。

老实说,一个月运行4万次的函数每月5美元似乎不算太糟。实际上不太值得您花时间优化它,但是为了方便讨论,假设将内存更改为128mb,这将如何影响我们的成本?

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


以每GB每秒0.00001667美元的速率,我们得到的总成本为:

 

使用AWS CloudWatch 调优Lambda函数 | 技术头条


哇,现在比1024 MB内存时便宜88%。好吧,这有什么大不了的,每个月只能省下4美元,可能不会对你的AWS账单产生明显的影响。

 

但是请记住,当我们使用无服务器框架来提供Lambda函数时,1024 MB是提供给它的默认内存。那么4-5名开发人员组成的团队需要将该Lambda函数迁移到无服务器架构时,情况会怎样? 他们是否对实际需要的内存做了足够分析?也许会吧,也许不会。

 

进一步假设有300个Lambda函数,它们的性能和我们的例子相似。当我们的功能供大于求时,无服务器架构的成本将是每月4.66 x 300美元是1398.00美元。如果我们对内存进行调优,成本会显著降低,每月0.58 x 300美元是174美元。对于如此小的变化,差异是巨大的。

 

其他要点

 

对于上述示例,我们将内存从1024 MB减少到128 MB,并且函数的性能没有改变,函数仍然在7秒内完成了其功能。

 

然而情况并不总是这样。在某些运行情况下,将所分配的内存更改88%将会更改函数执行所需的时间。如果减少内存导致增加6倍的时间来完成,那么反而影响了性能和效率。

 

另一方面,增加内存分配可以更快的调用。对于上述示例函数,我们可以将内存从1024 MB更改为2048 MB,并将执行时间从7秒降低到3.5秒。这意味着我们可以将函数的执行时间缩短一半,而不需要比1024 MB时多花一分钱。

 

要记住的是,可以根据需要对内存分配进行微调。超过900 MB的过剩内存,明显说明您可以缩减内存。能否调整到128mb可能会根据具体情况而定。

 

结论

 

Serverless是一种非常强大的体系结构,可以带来很多好处。节省成本,让开发人员将精力放在业务驱动而不是服务器上。但是,如果没有正确地配置和调优函数,成本效益就会很快消失。

 

要对分配给函数的内存进行调优,CloudWatch 是一个很好的方法。正如在示例函数中看到的,我们可以将函数调优到它实际使用的值(节省88%)。内存是成本控制的一个杠杆。另外,它还能以同样的成本获得性能优势。


使用AWS CloudWatch 调优Lambda函数 | 技术头条


使用AWS CloudWatch 调优Lambda函数 | 技术头条


福利

扫描添加小编微信,备注“姓名+公司职位”,加入【云计算学习交流群】,和志同道合的朋友们共同打卡学习!


使用AWS CloudWatch 调优Lambda函数 | 技术头条


推荐阅读:


使用AWS CloudWatch 调优Lambda函数 | 技术头条真香,朕在看了!