宝石/服务用于自动缩放Heroku的工具和工作人员 [英] Gems/Services for autoscaling Heroku's dynos and workers
问题描述
我想知道在生产环境中是否有任何针对Heroku上的自动缩放工具和工作人员的良好解决方案（对于每个人来说可能是不同的解决方案，因为它们非常不相关）。你有什么/公司在使用这个吗？
我发现了很多选择，但是它们都没有在生产环境中真正成熟。
有Heroscale，它似乎引入了一些延迟，因为它不能在本地运行，而且我也听说过一些停机。有一些delayed_jobs的修改，这些修改很久没有更新过，并且当前捆绑器存在一些问题。还有一些与reque有关的替代方案，这些替代方案看起来并不能很好地处理某些HTTP异常，这会导致应用程序崩溃，而其他人似乎需要一个始终运行的工作人员来安排其他工作人员，并且还可能遭受一些HTTP异常问题。
好吧。到底。什么是现在正在使用Rails3在生产环境中自动缩放Heroku的工具和工作人员？
预先感谢。
前段时间我们遇到了这个问题，我花了很多时间来解决这个问题，我感到非常沮丧。我会尽力坚持突出点。乍一看，有几款Heroku自动缩放解决方案看起来不错。
这个例子已经被 heroku-autoscaler 实际上是用于自动缩放dynos，并且几乎是唯一声称可以做到这一点的解决方案（而且它确实做得不好）。大多数人只会为你自称为自动缩放工作人员。所以，我们先关注一下。您要为工作人员看的自动压缩机取决于您实际使用的背景工人的内容，例如 delayed_job ， resque 。这些是人们使用的最常见的后台处理库，所以自动缩放器将尝试将其绑定到其中一个库中。您可以使用以下内容：
其中一些工作在Cedar堆栈上可能需要一些调整。所有这些问题都是因为它试图通过自己的头发将自己从沼泽中拉出来。以Hirefire为例（这可能是最好的一个）。它修改delayed_job，以便工人自己可以查看队列并在必要时启动更多工人，如果队列中没有更多工作，工人将全部关闭。有几个问题：
- 如果您想将作业放在将来要执行的队列中，而不是现在，那么您运气不好。当工作进入队列时，工人启动，但由于工作将来会被执行，工人将关闭，除非另一个工作进入队列（这是唯一提示工人启动的工作），否则不会启动
- 您失去重试失败作业的能力，这在delay_job中可能是默认情况下的，但是如果失败的作业重试失败，需要一段时间才能重试失败的作业（并且逐渐变长）时间，但工人会在这段延迟期间关闭，并且没有任何事情可以促使他们再次启动（本质上，这与第一种情况下的问题相同）。
解决这个问题的方法是让一个工作人员连续运行，因此可以定期监视队列，并在必要时执行作业，甚至可以启动更多工作人员。但是如果你这样做了，那么你没有节省任何资金（你有一个工作人员连续24/7连续运行并且必须为此付费），这就是在heroku上的自动缩放器背后的全部前提。实质上，如果您只有偶尔的后台处理工作，或者您的后台作业很可能会失败，但会成功重试，或者您有后台作业不需要立即执行，那么就没有可以自动扩展的库使用它可以为你工作。
以下是一个选择。编写Hirefire的人稍后将其转换成一个web应用程序（ Hirefire应用程序），其实质是外部监控您的Heroku工作人员/指挥官，并根据需要启动/关闭工作人员dynos。这是免费的测试版，但它现在花钱，比你为24/7全天候运行的员工花费的钱要少，但如果你偶尔需要一些后台工作，那么它仍然不是微不足道的。无论哪种方式，这是唯一可行的方法，以确保您的后台作业基础设施做你想做的（以及滚动你自己的解决方案，这意味着有一台机器就像一个EC2实例，你可以把一些脚本，将ping你的英雄应用程序和旋转根据需要启动/关闭工作人员 - 不费力气）。
现在，Hirefire应用程序确实可以为您自动调整您的dynos，它会根据您的heroku请求队列的延迟情况执行此操作。然而，我发现这样做效果不好，也许如果你靠近你的heroku应用程序实际存在的亚马逊数据中心（我们不是），那么你可能会有不同的体验。但是，对我们来说，无论我调整了多少设置，它都会不必要地分散了大量的dynos，并且永远不会让它们失效。你可以把它归结为它是一个测试版，它可能自那时起有所改进，但那是我的经验。
长话短说，如果你想自动调整你的工作人员，使用Hirefire应用程序，你会比你想象的节省很多钱，但它仍然是最便宜的选择。如果你想自动调整dynos，你基本上运气不好。这只是为了像Heroku这样的平台提供方便而与之共存的其中一个限制。
I want to know if there are any good solutions for autoscaling dynos AND workers on Heroku in a production environment (probably a different solution for each of those, as they are pretty unrelated). What are you/companies using, regarding this?
I found lots of options, but none of them seem really mature for a production environment. There is Heroscale, which seem to introduce some latency as it does not run locally, and I also heard of some downtime. There are modifications of delayed_jobs, which have not been updated for a long time, and there are some issues with current bundlers. There is also some alternatives related to reque, which seem not to handle very well some HTTP exceptions, which results in app crashing, and others which seem to need an always-running worker to schedule other workers, and may also suffer from some HTTP exceptions problems.
Well. In the end. What is being used, nowadays, for autoscaling Heroku's dynos and workers on a production environment with Rails3?
Thanks in advance.
We ran into this a while ago and I spent quite a bit of time on this to my great frustration. I'll try to stick to the salient point. There are several Heroku autoscaling solution that seem decent at first glance.
The example that has already been given heroku-autoscaler is actually for autoscaling dynos and is pretty much the only solution out there that claims to do this (and it certainly doesn't do it well). Most others will only claim to autoscale workers for you. So, let's focus on that first. The autoscalers you'll look at for workers depend on what you're actually using for you background workers e.g. delayed_job, resque. Those are the most common background processing libs that people use, so the autoscalers will try to hook into one of them. You can use things like:
Some of these work on the Cedar stack some might need a bit of tweaking. The problem with all of them is that it's like trying to pull yourself out of the swamp by your own hair. Let's take hirefire as an example (it's probably the best one of the lot). It modifies delayed_job so that the workers themselves can look at the queue and spin up more workers if necessary, if there are no more jobs in the queue, the workers will all shut each other down. There are several problems:
- if you want to put a job on the queue to be executed in the future as opposed to right now, you're out of luck. A worker starts up when jobs enter the queue, but since the job is to be executed in the future the worker will shut down and will not start up unless another job enters the queue (that's the only thing that prompts workers to start up)
- you loose the ability to retry failed jobs, this is possible by default in delayed_job, but it takes a little while before a failed job is to be retried (and progressively longer) if it fail multiple times, but the workers will shut down during this time delay and there is nothing to prompt them to start up again (in essence this is the same issue as in the first scenario)
The thing that solves this problem is to have one worker running continuously it can therefore monitor the queue periodically and can execute jobs when necessary or even spin up more workers. But if you do that, you're not saving any money (you have a worker running continuously 24/7 and have to pay for that) and that's the whole premise behind autoscalers on heroku. In essence, if you only have occasional background processing to do, or you have background jobs that are likely to fail but succeed on retry, or you have background jobs that don't need to be executed instantly, there is no autoscaling library you can use that will work for you.
Here is one alternative. The guy who wrote Hirefire, later spun it off into a webapp (Hirefire app), the essence of which is to externally monitor your Heroku workers/dynos for you and spin up/shut down workers dynos as necessary. This was free in beta but it now costs money, less than what you'd pay to run a worker 24/7 but still not insignificant if you only need a few background jobs once in a while. Either way this is the only viable way to make sure your background job infrastructure does what you want (well that and rolling your own solution which means having a machine like an EC2 instance where you can put some scripts which will ping your heroku app and spin up/shut down workers as needed - a non-trivial amount of effort).
Now Hirefire app does offer to autoscale your dynos for you as well, it does this based on hooking in to the latency of your heroku request queue. However I found that this didn't work well, perhaps if you're close to the Amazon datacenter where your heroku app actually lives (we weren't), you might have a different experience. But, for us it unnecessarily spun up a whole bunch of dynos and would never spin them down no matter how much I tweaked the settings. You can put it down to the fact that it was a beta it may have improved since then, but that's the experience that I had.
Long story short, if you want to autoscale your workers, use Hirefire app, you'll be saving a lot less money than you thought, but it is still the cheapest option. If you want to autoscale dynos you're basically out of luck. This is just one of those limitations you live with for having the convenience of a platform like Heroku.
这篇关于宝石/服务用于自动缩放Heroku的工具和工作人员的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
