AWS Lambda function 间接性超时

128 天前
 lvhuiyang
使用 Python + sqlalchemy 容器化部署在 AWS 一个 lambda 函数,来实现某些特殊存储业务的服务,用于提供给 Web Server 后端来调用。

背景:目前部署在测试环境,因为测试环境流量不大,考虑到在一段时间没有调用 lambda 的时候可能会导致 “休眠”,于是添加一个 Amazon EventBridge 的 schedule 来每分钟调用一次 lambda 函数,同时在业务中也实现了一个 celery 定时任务每分钟调用一次。

但是发现了一个奇怪的现象,在 lambda 函数没有做任何改动的前提下,调用会接歇性的超时。如果某段时间 100% 超时的话,我认为是 lambda 函数休眠了,需要冷启动花费时间。但是现状是每分钟都有请求保证其“不休眠”,而且并非请求 100% 超时,在某几分钟内有的请求超时,有的是正常的。统计图如下



有没有比较懂的老哥解答一下,十分感谢 ~
964 次点击
所在节点    Amazon Web Services
8 条回复
Mithril
128 天前
你看一下 log ,看看是不是冷启动了。Log 里面会有 Init Duration 。
不过就算你不停的 ping ,也不能保证它不会冷启动。如果那个可用区负载过高,你的 lambda 也可能被负载均衡搞出去,一样会冷启动。

如果你对这冷启动的时间很敏感,可以试试 Provisioned Concurrency 。或者干脆就用 EKS ,不要用 Lambda 。
Aygnh136
128 天前
就算你每秒都有请求,lambda 觉得自己需要扩容,或者超过最大持续时长了,都会开新的 lambda(需要冷起)
无论如何 15 分钟都会有一次冷启的
Aygnh136
128 天前
lambda 相当于执行你的代码之后,保留运行环境,并输出一个 handler(用于被调用),这个启动这个环境叫“冷启”。
当 lambda 被调起时,会分配一个 handler (没有可用的会新起一个)执行并返回结果。
它根据自己的设定(不同语言不同逻辑)来判断目前环境是否活跃,不活跃则释放。
lambda 保留的运行环境有最大时间限制(即使活跃也会被销毁),一般是 15 分钟。
我用的 node 至于 Python 的运行环境应该是同理。
lvhuiyang
128 天前
#1 @Mithril 非常感谢回复,看来我对 lambda 的冷启动理解有问题,查了下日志确实是大量 Init Duration

对冷启动时间倒是不是很敏感,敏感的是因为超时带来的请求错误。通过日志看冷启动时间不超过 1s ,业务处理逻辑应该在 200 ms 以内,因此设置了 5s 的超时时间应该是足够的。但是错误率确实和超时时间有关,我再定位一下吧,总之十分感谢提供的信息

日志查询 Init Duration:


错误率确实和允许时常有关 :
lvhuiyang
128 天前
#2 #3 @Aygnh136

明白了,我对 lambda 的理解确实有问题,我再去了解一下,十分感谢回复
BeautifulSoap
128 天前
lz 你的 Lambda 的负载难道只有 1rps ? 如果大于 1rps 你这做法当然会出现冷启动的问题

但再冷启动,11s 也太长了,Lambda 的冷启动时间撑死也就 2s~3s ,而 11s 的处理时间明显是程序内部哪里的问题,建议打 log 或者启用 xray 看看内部发生了什么
lvhuiyang
126 天前
#6 @BeautifulSoap 十分感谢回复,经过排查确实是我的程序内部逻辑问题:在 lambda 内部使用 sdk 调用 secretsmanager client 的 get_secret_value 时候默认未设置超时时间,导致有一定概率会卡住:

```python
session = boto3.session.Session()
client = session.client(
service_name="secretsmanager",
region_name=REGION_NAME,
config=aws_client_config,
)
response = client.get_secret_value(SecretId=db_secret_id)
```

虽然还不清楚在 lambda 内部使用 sdk 调用 secretsmanager client 会啥可能卡住,目前换了其他的方式来避免调用 secretsmanager client 之后,原来的问题解决了。
BeautifulSoap
126 天前
@lvhuiyang 原来如此。其实不光是 ssm ,aws 的其他服务比如 dynamodb 之类通过 https 提供服务的都会出现可能性的超时。之前生产环境每几小时报错,查到后来发现是和 dynamodb 的通信超时了。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1005121

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX