aws lambda
by Yan Cui
崔燕
恐怕您正在考虑AWS Lambda的冷启动完全错误 (I’m afraid you’re thinking about AWS Lambda cold starts all wrong)
When I discuss AWS Lambda cold starts with folks in the context of API Gateway, I often get responses along the line of:
当我在API Gateway的上下文中与其他人讨论AWS Lambda时,我经常会收到以下响应:
Meh, it’s only the first request right? So what if one request is slow, the next million requests would be fast.
嗯,这只是第一个请求吧? 因此,如果一个请求很慢,接下来的一百万个请求将很快。
Unfortunately, that is an oversimplification of what happens.
不幸的是,这太简单了。
Cold start happens once for each concurrent execution of your function.
冷启动发生一次为你的函数的每个并发执行 。
API Gateway reuses concurrent executions of your function if possible. Based on my observations, it might even queue up requests for a short time in the hope that one of the concurrent executions would finish and become reusable.
如果可能,API Gateway会重用函数的并发执行。 根据我的观察,它甚至 可能 在短时间内将请求排队,以希望并发执行之一可以完成并变得可重用 。
If user requests happen one after another, then you will only experience one cold start in the process. You can simulate this using Charles proxy by repeating a captured request with a concurrency setting of 1.
如果用户的请求接连发生,那么您在此过程中只会经历一次冷启动。 您可以通过使用并发设置为1重复捕获的请求来使用Charles代理进行模拟。
As you can see in the timeline below, only the first request experienced a cold start. The response for this request was much slower than the rest.
如您在下面的时间线中看到的,只有第一个请求经历了冷启动。 此请求的响应比其余请求慢得多。
1 out of 100 — that’s bearable. Hell, it won’t even show up in my 99 percentile latency metric.
每100个中有1个是可以接受的。 天哪,它甚至不会出现在我的99%延迟指标中。
What if the user requests came in droves instead? After all, user behaviours are unpredictable and unlikely to follow the nice sequential pattern we see above. So let’s simulate what happens when we receive 100 requests with a concurrency of 10.
如果用户请求成群结队怎么办? 毕竟,用户行为是不可预测的,不可能遵循我们上面看到的良好的顺序模式。 因此,让我们模拟一下当我们收到100个并发为10的请求时会发生什么。
Now things don’t look quite as rosy — the first 10 requests were all cold starts! This is problematic if your traffic pattern is bursty around specific times of the day or specific events, for example:
现在事情看起来并不那么乐观-前10个请求都是冷启动! 如果您的流量模式在一天中的特定时间或特定事件中突然爆发,则这是有问题的,例如:
- Food ordering services (like JustEat and Deliveroo) have bursts of traffic around meal times 餐饮订购服务(例如JustEat和Deliveroo)在用餐时间附近流量激增
- e-commence sites have highly concentrated bursts of traffic around popular shopping days of the year — like Cyber Monday and Black Friday 电子商务网站在一年中的热门购物日(例如“网络星期一”和“黑色星期五”)的交通流量非常集中
- Betting services have bursts of traffic around sporting events 博彩服务在体育赛事期间流量激增
- Social networks have bursts of traffic around notable events happening around the world 社交网络在世界各地发生的重大事件周围流量激增
For these services, the sudden bursts of traffic means API Gateway would add more concurrent executions of your Lambda function. That equates to bursts of cold starts, and that’s bad news for you.
对于这些服务,流量的突然爆发意味着API Gateway将添加更多Lambda函数的并发执行。 这相当于突然开始冷门,这对您来说是个坏消息。
These are also the most crucial periods for your business when you want your service to be on its best behavior.
当您希望服务保持最佳状态时,这些也是您业务最关键的时期。
If the spikes are predictable, then you can mitigate the effect of cold starts by pre-warming your API.
如果峰值是可预测的,则可以通过预热API来缓解冷启动的影响。
For example, in the case of a food ordering service, you know there will be a burst of traffic at noon. You can schedule a cron job using a CloudWatch scheduled event at 11:58am to trigger a Lambda function. This function would generate a burst of concurrent requests to force API Gateway to spawn the desired number of concurrent executions ahead of time.
例如,对于食品订购服务,您知道中午会有大量的交通。 您可以使用上午11:58的CloudWatch计划事件来计划cron作业,以触发Lambda函数。 此函数将生成大量并发请求,以强制API网关提前产生所需数量的并发执行。
You can use HTTP headers to tag these requests. The handling function can then distinguish them from normal user requests and short-circuit.
您可以使用HTTP标头标记这些请求。 然后,处理功能可以将它们与正常的用户请求和短路区分开。
Does it not betray the ethos of serverless computing that you shouldn’t have to worry about scaling?
它是否背叛了您无需担心扩展的无服务器计算的精神?
Yes, it does, but making users happy trumps everything else. Your users are not happy to wait for your function to cold start so they can order their food. The cost of switching to a competitor is so low nowadays, what’s stopping them from leaving you?
是的,的确如此,但是让用户满意比其他一切都重要 。 用户不愿意等待您的功能冷启动,以便他们点菜。 如今,转换竞争对手的成本如此之低,是什么阻止他们离开您呢?
You could also consider reducing the impact of cold starts instead, by reducing the duration of cold starts:
您还可以考虑通过减少冷启动的持续时间来减少冷启动的影响:
Author your Lambda functions in a language that doesn’t incur a high cold start time — that is, Node.js, Python, or Go
使用不会产生高启动时间的语言(即 Node.js,Python或Go)编写Lambda函数
- Use higher memory setting for functions on the critical path, including intermediate APIs 对关键路径上的功能(包括中间API)使用更高的内存设置
- Optimize your function’s dependencies and package size 优化函数的依赖性和包大小
Stay as far away from VPCs as you can! Lambda creates ENIs (elastic network interface) to the target VPC, which can add up to 10s (yeah, you’re reading it right) to your cold start
尽可能远离VPC! Lambda为目标VPC创建ENI(弹性网络接口),这可以使冷启动最多增加10秒(是的,您没看错)
There are also two other factors to consider:
还需要考虑其他两个因素:
Executions that are idle for a while would be garbage collected
- Executions that have been active for a while (somewhere between 4 and 7 hours) would be garbage collected, too 处于活动状态一段时间(在4到7小时之间)的执行也会被垃圾回收
What about APIs that are seldom used? In that case, every invocation might be a cold start if too much time passes between invocations. To your users, these APIs are always slow, so they’re used less, and it becomes a vicious cycle.
很少使用的API呢? 在这种情况下,如果两次调用之间的时间间隔过长,则每次调用可能都是冷启动。 对于您的用户而言,这些API总是很慢,因此使用较少,这将成为一个恶性循环。
For these, you can use a cron job (as in, a CloudWatch scheduled event with a Lambda function as target) to keep them warm. The cron job would run every 5–10 mins and ping the API with a special request. By keeping these APIs warm, your users would not have to endure cold starts.
对于这些,您可以使用cron作业(例如,以Lambda函数为目标的CloudWatch计划事件)使它们保持温暖。 cron作业每5-10分钟运行一次,并通过特殊请求ping API。 通过使这些API保持温暖,您的用户将不必忍受冷启动。
This approach is less effective for busy functions with lots of concurrent executions. The ping message would only reach one of the concurrent executions, and there is no way to direct it to specific executions. In fact, there is no reliable way to know the exact number of concurrent executions for a function at all.
这种方法对于具有大量并发执行的繁忙功能不太有效。 ping消息将仅到达并发执行之一,并且无法将其定向到特定执行。 实际上,根本没有可靠的方法可以知道某个函数并发执行的确切次数。
Also, if the number of concurrent user requests drops, then it’s in your best interest to let idle executions be garbage collected. After all, you wouldn’t want to pay for unnecessary resources you don’t need.
另外,如果并发用户请求的数量减少,那么最好让空闲的执行被垃圾回收。 毕竟,您不需要支付不必要的不必要资源。
This post is not intended to be your one-stop guide to AWS Lambda cold starts. It’s intended to illustrate that talking about cold starts is a more nuanced discussion than “the first request.”
这篇文章并不是要成为AWS Lambda冷启动的一站式指南。 旨在说明,与“ 第一个请求 ”相比,谈论冷启动是一个更为细微的讨论。 ”
Cold starts are a characteristic of the platform that we have to live with. And we love the AWS Lambda platform and want to use it, as it delivers on so many fronts. Nonetheless, it’s important to not let our own preference blind us from what’s important. Keeping our users happy and building a product that they love is always the most important goal.
冷启动是我们必须使用的平台的特征。 我们喜欢AWS Lambda平台,并希望使用它,因为它在很多方面都可以提供。 尽管如此,重要的是不要让我们自己的偏好使我们看不到重要的东西。 让我们的用户满意并开发自己喜欢的产品始终是最重要的目标。
To that end, you do need to know the platform you’re building on. With the cost of experimentation being so low, there’s no reason not to experiment with AWS Lambda yourself. Try to learn more about how it behaves and how you can make the most of it.
为此,您确实需要了解所构建的平台。 由于实验成本如此之低,因此没有理由不亲自试用AWS Lambda。 尝试了解有关它的行为以及如何充分利用它的更多信息。
aws lambda