Elastic Beanstalk 上的 Auto Scaling 批处理作业

Posted 2023-03-04

【中文标题】Elastic Beanstalk 上的 Auto Scaling 批处理作业

【英文标题】：Auto scaling batch jobs on Elastic Beanstalk

【发布时间】：2014-04-05 17:20:03

【问题描述】：

我正在尝试使用 beanstalk 设置可扩展的背景图像处理。 我的设置如下：

应用程序服务器（在 Elastic Beanstalk 上运行）接收文件，将其放在 S3 上并发送请求以通过 SQS 对其进行处理。 工作服务器（也在 Elastic Beanstalk 上运行）轮询 SQS 队列、接受请求、从 S3 加载原始图像、处理它产生 10 个不同的变体并将它们存储回 S3。 这些上传事件以每天大约 1-2 批的速度发生，每批 20-40 张图片，时间不可预测。

问题： 我目前正在为工人使用一个微实例。生成图片的一个变体可能需要 3 秒到 25-30 秒（似乎第一个是在 3 秒内完成的，但随后微实例变慢了，我认为这是因为它的 2 秒突发工作负载设计）。无论如何，当我上传 30 张照片时，这意味着这项工作需要：30 张照片 * 每张 10 个变体 * 30 秒 = 2.5 小时来处理？？！？！

显然这是不可接受的，我尝试使用“小”实例，那里的性能是一致的，但每个变体大约需要 5 秒，所以仍然是每批 30*10*5 = 26 分钟。仍然不能接受。

解决这个问题的最佳方法是什么，既能获得最快的结果，又能节省成本？

我能想到的解决方案：

依靠 beanstalk 自动缩放。我已经尝试过了，根据 CPU 利用率设置自动缩放。这似乎反应非常缓慢且不可靠。我尝试将测量时间设置为 1 分钟，并将突破持续时间设置为 1 分钟，阈值为 70% 上升，30% 下降，增量为 1。系统需要一段时间才能扩大规模，然后需要一段时间才能缩小规模，我可能可以对其进行微调，但仍然感觉很奇怪。理想情况下，我希望获得一台比微型（小型，中型？）更快的机器来处理这些工作高峰，但是使用 beanstalk 这意味着我需要一直运行至少一个，因为大多数时候系统是空闲的这在价格方面没有任何意义。

为 worker 放弃 beanstalk，实现我自己的对在 micro 上运行的 SQS 队列的监控，并在队列中有足够的待处理消息时让它启动更大的机器（或一组更大的机器），当我们检测到队列空闲时终止它们。这似乎需要做很多工作，除非有现成的解决方案。无论如何，我失去了 beanstalk 通过 git 部署代码、管理环境等的好处。

我不喜欢这两种解决方案中的任何一种 还有其他我想念的好方法吗？

谢谢

【问题讨论】：

嗨，Dmitry - 你最后是怎么解决这个问题的？我有一个类似的问题，想知道你发现什么是最好的解决方案。谢谢！

从未找到好的解决方案，一直使用解决方案#1。如果我必须重做，我可能会研究 AWS Lambda，它可能会消除所有头痛

【参考方案1】：

在这种情况下，微型实例上的 CPU 利用率可能不是用于自动缩放的最佳指标。

SQS 队列的长度可能是更好的指标，也是最自然的指标。

不用说，如果您可以预算购买更大的基准机器，那么一切都会运行得更快。