Lambda Cron有多可靠？

安迪·沃宗（Andy Warzon） | 2017年1月6日

2017年1月6日，星期五

它的名称较为正式，但不太吸引人 具有计划事件源和Lambda目标的Cloudwatch事件…但是我们认为“ Lambda Cron”只是稍微好一点了。

Cloudwatch 大事记是一项服务，可让您从AWS环境中的各种事件中自动执行操作并触发一些不同的操作，其中包括任意的Lambda函数。 “事件源”之一只是速率表达式或时间表，表示为 cron语法。因此，将这两件事放在一起，就可以按计划调用Lambda函数了……也就是Lambda Cron。

我们对Lambda Cron可靠性进行了为期四个月的测试，并获得了一些有趣的数据。但是首先有一点背景。

什么是Lambda Cron？

此功能于2015年秋季发布，最低分辨率为5分钟，然后在几个月前悄悄更新为1分钟分辨率。在Trek10上，我们发现，特别是在1分钟的分辨率下，“ Lambda Cron”是许多无服务器架构的关键构建块。一些用途：

实际上可以在Lambda内部运行的小型定期后台任务。
启动更大的管道或任务执行的触发器，例如通过ECS运行任务执行的Docker容器任务。这样，Lambda Cron就是共享的，高度可用的主cron。
一分钟的分辨率和59秒的超时时间，这是一个无服务器的长轮询工作程序。

这是一个非常令人信服的主意……非常可靠的cron，而无需弄乱crontab或让实际上闲置的服务器停滞不前，只是为了运行一些定期过程。而且比尝试构建一些高度可用的cron解决方案要容易得多。这也是Lambda入门的简单方法&无服务器的，用于迁移系统中的某些后台进程，这些后台进程更容易与旧版应用程序分离。

在Trek10上，我们着迷于构建高度可靠的系统，并且想知道Lambda Cron如何堆叠。因此，我们进行了一个小实验，以收集有关服务一致性和可靠性的一些数据。

本实验

为了测试可靠性，我们设置了计划的Lambda，使其每分钟在五个不同的AWS区域中运行，并将结果记录到DynamoDB表中，并使其运行四个月以上。因此，我们记录了近一百万次执行。

我们正在记录两个不同的数据点：

When Cloudwatch 大事记 triggers Lambda, it passes some JSON with the “event time”. Think of this as AWS telling you when it was supposed to be running. When you set up one minute cron with the cron expression 0/1 * * * ? *, this value is the 0th second, on the minute, every time.
然后，我们的Lambda函数记录了系统时间。由于Lambda函数只需执行毫秒，因此我们可以将这段时间视为cron实际触发的时间。

我们得到了一些有趣的结果……

Lambda Cron非常可靠

在五个区域中的每个区域，近20万次执行中，我们只有2到15个间隔，而没有记录执行情况。而且我们不能肯定地说Cloudwatch 大事记无法触发……这可能是Lambda函数或Dynamo错误。因此，可以肯定地说，Lambda Cron至少具有99.99％的可靠性，并且至少在四个月内可能达到100.％的可靠性，甚至高达99.999％。很扎实！

但是它不能完全在“零秒”内运行您的函数

…实际上，运行时间可能会相差很大

尽管文档中有些埋藏，但AWS实际上说这非常清楚：

由于CloudWatch 大事记和目标服务的分布式性质，在触发调度的规则的时间与目标服务兑现目标资源的执行时间之间的延迟可能是几秒钟。您的排定规则会在该分钟之内触发，但不会在精确的第0秒触发。

也就是说，当他们说“几秒钟”时，AWS有点乐观。我们的数据显示了一个不同的故事。以下是将近一百万次执行的统计信息：“事件时间”（应该触发执行的时间）与我们的函数记录的实际系统时间之间的差（以秒为单位）。

Lambda Cron的执行时间延迟（秒）

	百分位数
地区	1st	25th	50th	75th	95th	99th	99.9th	99.99th
维吉尼亚州 us-east-1	39	40	40	40	41	43	585	2537
俄勒冈州 us-west-2	29	29	30	30	31	31	60	852
爱尔兰 eu-west-1	11	12	12	12	13	14	23	1963
德国 eucentral-1	35	36	36	36	37	37	38	45
东京 ap-northeast-1	1	2	2	2	3	3	5	44

在过去的4个月中，每个地区执行了近20万次执行，第99.99个百分位将发生大约20次，或大约每周一次。

从这些数据中可以得出一些非常有趣的发现：

虽然执行永远不会在第0秒发生，但99％的执行确实在非常一致的1-3秒窗口中发生。
地区之间存在相当大的系统差异。 ap-northeast-1（东京）的延迟为1-3秒，而us-east-1的延迟为40秒。在这些区域中，Cloudwatch Event计划的运行方式肯定存在一些非常可靠的差异。
更大的区域=更大的可变性。最大的地区，弗吉尼亚，分布的变化最大，而最小的地区，东京&德国，最少。这并不奇怪：分布式系统越大，可变性就越大。
长尾很长：5个区域中的3个区域的14分钟超过99.99％。

结论：记住要建立弹性并期待失败

因此，最重要的是，Lambda Cron是一个出色的系统，您可以依靠它以非常低的精力为您提供非常可靠的cron执行。只是不要依赖它在第0秒执行。就像任何好的系统设计，尤其是AWS上任何好的分布式系统设计一样，请务必记住Lambda Cron并非完全一致。对于那一千分之一或一万分之一的情况，您应该期望Lambda Cron会有严重的滞后，并构建系统来对这些故障做出优雅的响应。