在Elastic Beanstalk上自动调整批处理作业

Question

我正在尝试使用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分钟。仍然不能接受。

攻击这个问题的最佳方法是什么，它可以获得最快的结果并且同时具有价格效率？

我能想到的解决方案：

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

2. 放弃工作人员的beanstalk，实现我自己对微型计算机上运行的SQS队列的监视器，当队列中有足够的待处理消息时，让它启动更大的机器（或更大的机器组），我们检测到队列空闲时终止它们。这似乎是很多工作，除非有一个解决方案准备就绪。在任何情况下，我都失去了通过git，管理环境等部署代码的beanstalk的好处。

我不喜欢这两种解决方案中的任何一种 我还缺少其他不错的方法吗？

由于

Answer 1

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

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

毋庸置疑，如果你能为更大的基线机器预算，一切都会跑得更快。