我应该在哪里运行预定的后台作业？

Question

在我的公司，我们在 aws ebs 中定期应用一些后台工作。问题是，这些工作开始变得越来越重，我们正在考虑将它们与应用程序分开。问题是：我们应该在哪里做？

我们曾考虑在 aws lambda 中执行此操作，但随后我们必须将我们的 rails 代码移植到 python、node 或 java，这似乎需要大量工作。对此还有哪些其他选择？我们是否应该为作业创建另一个 ec2 环境？提前致谢。

编辑：我正在使用 shoryuken gem：http://github.com/phstc/shoryuken 与 SQS 集成。但它目前有一些内存泄漏，我的应用程序有时会出现故障，我不知道内存泄漏是否是导致棘手的原因。我们已经在 EBS 中的 API 部分和 S3 中的前端部分之间分离了应用程序。

Answer 1

通常，只是另一个带有您的 Rails 应用程序副本的 EC2 实例，您可以运行 rake resque:work 或您的作业运行器启动命令，而不是 rails s 来启动 Web 服务器。两者都将共享相同的 Redis 实例和数据库，以便您的 Web 服务器将作业写入队列，然后工作人员将它们拾取并运行它们。

如果您需要更多工作人员，只需添加更多指向同一个 Redis 实例的 EC2 实例。我建议按队列名称分隔您的工作，以便一名工作人员可以处理快速的东西，例如电子邮件发送，其他人可以做长时间运行或缓慢的工作。

Answer 2

我们有类似的需求，对我们来说是 sidekiq 后台作业，它们开始变得非常繁重，因此我们将其拆分为单独的 opsworks 堆栈，并使用简单的配方来构建机器依赖项（ruby、mysql 等)，并且由于我们不必担心负载均衡器和请求超时，因此所有机器同时部署是可以的。

您可以在 opsworks 中使用的另一件事是使用计划的机器（如果在一天中的特定时间需要作业），在任务开始前几分钟配置机器，然后在任务完成后你可以让它自动关机，这样可以降低你的成本。

EB 也有不同类型的应用程序，即工作程序应用程序，您也可以查看它，但老实说，我没有研究过它，所以我无法告诉您它的优点和缺点。

Answer 3

我们最近通过了那条路线。我将我们的 Rails 应用程序 docker 化，并为该 docker 容器编写了一个自定义入口点。总之，入口点在您运行 docker run IMAGE_NAME 后解析命令

例如：如果您运行：docker run IMAGE_NAME sb rake do-something-magical 入口点知道它将使用沙箱环境配置运行 rake 作业。如果你只运行：docker run IMAGE_NAME 它会运行rails s -b 0.0.0.0

PS：我编写了自定义入口点，因为我们有 3 个不同的环境，入口点从 s3 下载特定于环境的配置。

我设置了一个 ECS 集群，在 Lambda 上编写了一个任务运行程序作业，这个 lambda 函数在 ecs 集群上安排了一个任务，我们从 CloudWatch Events 触发了那个 lambda。使用 CloudWatch Events 时，您可以将自定义负载发送到 lambda。

听起来很复杂，但实现起来非常简单。

Answer 4

您可以考虑将您的任务提交给 AWS SQS 服务，然后您可以使用 elasticbeantaslk 工作环境来处理您的后生任务。

Elasticbeanstalk 支持铁路应用： http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Ruby_rails.html

Answer 5

根据这些后台作业执行的工作类型，如果您在不同的实例上运行作业，您可能需要考虑将这些功能提取到微服务中。

Here 是一篇很好的代码管理博客文章，介绍了如何解决这个问题。

对于简单的邮件类型的东西，这肯定感觉有点笨拙，但如果功能更复杂，例如不同客户的一般通知，这可能是值得的开销。