Amazon web services 弹性Beanstalk上的自动缩放批处理作业

我正在尝试使用beanstalk设置一个可伸缩的背景图像处理。 我的设置如下所示：

• 应用服务器（运行在Elastic Beanstalk上）接收一个文件，将其放在S3上，并发送一个请求，通过SQS对其进行处理
• Worker server（也在Elastic Beanstalk上运行）轮询SQS队列，获取请求，从S3加载原始映像，处理它，生成10个不同的变体，并将它们存储回S3
• 这些上传事件的发生率约为每天1-2批，每批20-40张，时间不可预测

问题: 我目前正在为worker使用一个微实例。生成图片的一个变体可能需要3秒到25-30秒（看起来第一个是在3秒内完成的，但是微实例的速度会减慢，我认为这是由于它的2秒突发性工作负载设计）。不管怎样，当我上传30张照片时，这意味着这项工作需要：30张照片*10个变种每个*30秒=2.5小时来处理

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

解决这一问题的最佳方法是什么，它将获得最快的结果，同时又具有价格效益

我能想到的解决办法是：

依靠beanstalk自动缩放。我尝试过，根据CPU利用率设置自动缩放。这似乎反应非常缓慢，而且不可靠。我已经尝试将测量时间设置为1分钟，违约持续时间设置为1分钟，阈值为70%上升，30%下降，增量为1。系统需要一段时间才能放大，然后再缩小，我可能可以对它进行微调，但它仍然感觉很奇怪。理想情况下，我希望得到一台比micro（小型、中型？）更快的机器来完成这些尖峰工作，但对于beanstalk，这意味着我需要始终至少运行一台，因为大部分时间系统处于空闲状态，这在价格方面没有任何意义

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

这两种解决方案我都不喜欢 我还缺少其他好方法吗

---

多亏了

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

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

---

不用说，如果你能为一台更大的基线机器做预算，一切都会运行得更快。

嗨，Dmitry，你最终是怎么解决这个问题的？我有一个类似的问题，想知道你发现什么是最好的解决方案。谢谢从未找到好的解决方案，一直坚持解决方案1。如果我必须重做的话，我可能会调查AWS Lambda，这可能会消除所有的头痛