Gems / Услуги по автомасштабированию динамов и рабочих Heroku - PullRequest
21 голосов
/ 06 июля 2011

Я хочу знать, есть ли какие-нибудь хорошие решения для автоматического масштабирования динамов и рабочих на Heroku в производственной среде (возможно, другое решение для каждого из них, поскольку они довольно не связаны).Что вы / компании используете по этому поводу?

Я нашел много вариантов, но ни один из них не кажется действительно зрелым для производственной среды.Есть Heroscale, которая, кажется, вводит некоторую задержку, поскольку она не работает локально, и я также слышал о некоторых простоях.Существуют модификации delayed_jobs, которые долгое время не обновлялись, и есть некоторые проблемы с текущими компоновщиками.Существуют также некоторые альтернативы, связанные с Reque, которые, кажется, не очень хорошо обрабатывают некоторые исключения HTTP, что приводит к сбою приложения, и другие, которые, кажется, нуждаются в постоянно работающем работнике для планирования других работников, а также могут страдать от некоторых исключений HTTPпроблемы.

Хорошо.В конце.Что в настоящее время используется для автоматического масштабирования динамов и рабочих Heroku в рабочей среде с Rails3?

Заранее спасибо.

Ответы [ 5 ]

35 голосов
/ 22 сентября 2011

Мы столкнулись с этим некоторое время назад, и я потратил немало времени на это, к моему большому разочарованию.Я постараюсь придерживаться основной точки.Существует несколько решений Heroku для автоматического масштабирования, которые на первый взгляд кажутся приличными.

Пример, который уже был приведен heroku-autoscaler , на самом деле предназначен для автоматического масштабирования динозавров и является практически единственным решением, которое утверждает, что делает это (и, конечно, оно этого не делает)Что ж).Большинство других претендуют только на то, что вы автоматически работаете за вас.Итак, давайте сосредоточимся на этом в первую очередь.Автоскалеры, которые вы увидите для работников, зависят от того, что вы на самом деле используете для фоновых работников, например delayed_job , resque .Это наиболее распространенные библиотеки фоновой обработки, которые используют люди, поэтому автоскалер попробует подключиться к одному из них.Вы можете использовать такие вещи, как:

Некоторые из этих работ со стеком Cedar могут потребовать небольшой доработки.Проблема со всеми из них в том, что это все равно что пытаться вытащить себя из болота своими собственными волосами.Давайте возьмем найм огня в качестве примера (это, вероятно, лучший из всех).Он изменяет delayed_job, чтобы сами работники могли просматривать очередь и, если необходимо, раскручивать большее количество работников. Если в очереди больше нет рабочих мест, все работники будут закрывать друг друга.Есть несколько проблем:

  • Если вы хотите поставить задачу в очередь для выполнения в будущем, а не прямо сейчас, вам не повезло.Рабочий запускается, когда задания входят в очередь, но, поскольку в будущем задание будет выполнено, работник выключится и не запустится, если в очередь не войдет другое задание (это единственное, что побуждает работников запускаться)
  • вы теряете возможность повторять неудачные задания, это возможно по умолчанию в delayed_job, но требуется некоторое время, прежде чем неудачное задание должно быть повторено (и постепенно дольше), если оно повторяется несколько раз, но рабочиебудет отключен во время этой задержки, и нет ничего, что заставляло бы их запускаться снова (по сути, это та же проблема, что и в первом сценарии)

Единственное, что решает эту проблему, это иметьпоэтому один рабочий, работающий непрерывно, может периодически отслеживать очередь и при необходимости выполнять задания или даже увеличивать количество рабочих.Но если вы делаете это, вы не экономите деньги (у вас есть работник, работающий непрерывно 24/7, и вы должны платить за это), и в этом вся посылка за автоскалером на героку.По сути, если у вас есть только периодическая фоновая обработка, или у вас есть фоновые задания, которые могут быть неудачными, но успешными при повторных попытках, или у вас есть фоновые задания, которые не нужно выполнять мгновенно, библиотеки для автоматического масштабирования вы не сможетеиспользуйте это будет работать для вас.

Вот одна альтернатива.Парень, который написал Hirefire, позже включил его в веб-приложение ( Hirefire app ), суть которого заключается в том, чтобы внешне контролировать ваших рабочих / динозавров Heroku и, при необходимости, раскручивать / выключать рабочих динамометров.Это было бесплатно в бета-версии, но теперь оно стоит денег, меньше, чем вы платите за работу 24 часа в сутки, но все же не так уж и незначительно, если вам нужно лишь несколько фоновых заданий время от времени.В любом случае, это единственный реальный способ убедиться, что инфраструктура фоновых заданий выполняет то, что вы хотите (хорошо, и это означает, что вы должны развернуть свое собственное решение, которое означает наличие машины, подобной экземпляру EC2, где вы можете поместить несколько сценариев, которые будут проверять ваше приложение heroku и вращатьсяпри необходимости поднимать / выключать работников - нетривиальные усилия).

Теперь приложение Hirefire также предлагает автоматическое масштабирование ваших динамов, оно делает это, основываясь на задержке вашей очереди запросов heroku.Однако я обнаружил, что это не сработало, возможно, если вы находитесь близко к центру обработки данных Amazon, где на самом деле живет ваше приложение heroku (у нас это не так), у вас может быть другой опыт.Но для нас это излишне раскручивало целую кучу динамометров и никогда не раскрутило бы их, независимо от того, насколько я изменил настройки.Вы можете объяснить это тем фактом, что это была бета-версия, которая с тех пор могла быть улучшена, но это мой опыт.

Короче говоря, если вы хотите автоматически масштабировать своих работников, используйте приложение Hirefire,вы будете экономить гораздо меньше денег, чем вы думали, но это все еще самый дешевый вариант.Если вы хотите автоматически масштабировать динамометры, вам в основном не повезло.Это лишь одно из тех ограничений, с которыми вы живете для удобства использования платформы, подобной Heroku.

10 голосов
/ 29 декабря 2012

Heroku предлагает новую надстройку под названием AdeptScale, которая только что вышла из бета-версии.

Вот страница дополнения для AdeptScale

Вот более подробная документация для AdeptScale

Вот форма для подписки на бета-программу Heroku

Надеемся, что это будет надежное решение для автоматического масштабирования Heroku Dynos, поскольку меня все еще не устраивают текущие параметры.

Обновление (4/4/13): я подписался на бета-программу Heroku, чтобы опробовать это дополнение, и оно отлично сработало для меня.Время от времени увеличивая трафик, но в основном сидя на минимальном количестве дин, которое я установил 2. Это значительно уменьшило мой счет и избавило от беспокойства, что я могу быть медленным во время пиковых нагрузок.

Обновление (3/ 6/13): добавлена ​​ссылка на страницу регистрации Heroku для их бета-программы.

Обновление (14.04.13): похоже, что автоматическое масштабирование вышло из бета-версии.Это все еще работает очень хорошо для меня.

3 голосов
/ 25 июля 2013

HireFire.io (Служба, а не проект с открытым исходным кодом) теперь позволяет вам использовать метрики New Relic для автоматического масштабирования веб-динамо. New Relic - это инструмент для мониторинга производительности, предоставляемый в качестве дополнения через Heroku. У них есть бесплатный уровень, и его достаточно использовать с HireFire.

Вы можете автоматически масштабировать на основе:

  • Время отклика
    • Это время отклика, которое вы найдете на панели инструментов новой реликвии. Это сочетание различных факторов, в том числе очереди запросов, производительности базы данных, уровня приложений, маршрутизатора и т. Д.
  • Оценка Apdex
    • Это позволяет вам масштабироваться в зависимости от вашей оценки New Relic Apdex, позволяя вам масштабировать в зависимости от опыта / удовлетворенности пользователя, который определяется этим результатом.

Помимо этого, мы стали независимыми от языка / структуры. Для рабочих dynos все, что вам нужно сделать, чтобы получить автоматическое масштабирование - это настроить конечную точку JSON по определенному пути в вашем приложении, которая возвращает очень простую строку JSON, содержащую размер очереди (мы предоставляем удобные, но не обязательные макросы для языка Ruby и некоторой встроенной поддержки приложений Django, но, как я уже сказал, он работает для любого языка / фреймворка, вручную настраивая конечную точку JSON - это очень просто). Для веб-dynos вы можете использовать источник метрик HireFire практически с любым языком / каркасом и вышеупомянутый источник метрики New Relic для языков / каркасов, которые поддерживаются New Relic (это распространенные языки, такие как Ruby, Python, Java и т. Д.). ).

Отказ от ответственности: я построил HireFire.

2 голосов
/ 09 июля 2011

Я тоже пытаюсь найти хороший способ автоматического масштабирования динамометра.

https://github.com/ddollar/heroku-autoscale делает это, но имеет оговорку о его незрелости.

1 голос
/ 15 сентября 2014

Я недавно написал систему автоматического масштабирования heroku под названием Heroku Vector:

https://github.com/wpeterson/heroku-vector

Позволяет масштабировать несколько типов динамограмм на основе разных источников трафика. В настоящее время он поддерживает NewRelic во всех и Sidekiq количество занятых потоков. По мере того, как трафик идет вверх или вниз, он будет увеличивать или уменьшать количество динамов. Это процесс-демон, который можно запустить в своем собственном динамо на Heroku или где-либо еще.

...