Question

我的应用程序在很大程度上依赖于AWS服务，我正在寻找基于它们的最佳解决方案。 Web应用程序触发预定作业（假设无限重复），这需要执行一定量的资源。单次运行任务通常最多需要1分钟。

目前的想法是通过SQS传递作业，并根据队列大小在EC2实例上生成工作程序。（这部分或多或少清晰）但我很难找到一个适当的解决方案来实际以一定的时间间隔触发工作。假设我们正在处理10000个工作。因此，对于一个调度程序运行10k cronjobs（工作本身很简单，只是通过SQS传递工作描述）似乎是一个疯狂的想法。那么实际的问题是，如何自动调度调度程序本身（考虑到重新启动调度程序时的情况，创建新实例等）？或者调度程序作为应用程序是多余的，依赖AWS Lambda函数（或其他提供调度的服务）更明智？使用Lambda函数的问题是一定的限制，单个函数提供的128mb的内存实际上太多了（20mb似乎绰绰有余）

或者，工作人员本身可以等待一段时间并通知调度程序它应该再次触发该作业。假设频率是1小时：

1. Scheduler sends job to worker 1
2. Worker 1 performs the job and after one hour sends it back to Scheduler
3. Scheduler sends the job again

然而，这里的问题是工人可能会被缩放。

底线我正在尝试实现一种轻量级的调度程序，它不需要自动调节并充当仅用于传输作业描述的集线器。当然不应该在服务重启时受到限制。

Answer 1

Lambda非常适合这种情况。你有很多短暂的运行过程（约1分钟）和Lambda用于短流程（现在直到五分钟）。知道CPU速度线性耦合到RAM是非常重要的。如果我没记错的话，1GB Lambda函数相当于t2.micro实例，1.5GB RAM意味着CPU速度提高1.5倍。这些功能的成本非常低，您只需执行此操作即可。 128MB RAM具有微实例的1/8 CPU速度，因此我不建议实际使用它们。

作为一种排队机制，你可以使用S3（是的，你读的是正确的）。创建一个存储桶，让Lambda工作程序在创建对象时触发。如果要安排作业，请将文件放入存储桶中。 Lambda立即启动并处理它。

现在你必须尊重一些限制。这样，您只能同时拥有100个工作者（活动Lambda实例的总数），但您可以要求AWS增加此工作量。

费用如下：

每1000个PUT请求0.005个，因此每百万个工作请求需要5美元（这比SQS更贵）。
Lambda运行时。假设正常的t2.micro CPU速度（1GB RAM），每个作业需要0.0001美元（60秒，首次300.000秒免费= 5000个工作）
Lambda请求。每百万触发0.20美元（第一百万免费）

此设置不需要您的任何服务器。这不会失败（只有AWS本身确实如此）。

（不要忘记在完成后删除S3中的作业）

使用AWS服务调度长时间运行的任务

1 个答案: