Где я должен запускать запланированные фоновые задания?

Question

Здесь, в моей компании, у нас есть регулярное приложение в aws ebs с некоторыми фоновыми заданиями. Проблема в том, что эти рабочие места начинают становиться тяжелее, и мы думали, что они отделяют их от приложения. Вопрос в том, где мы должны это делать?

Мы думали сделать это в aws лямбда, но тогда нам пришлось бы перенести наш код рельсов на python, node или java, что, похоже, очень много. Какие другие варианты для этого? Должны ли мы просто создать еще одну среду ec2 для работы? Заранее спасибо.

Редактировать: Я использую драгоценный камень shoryuken: http://github.com/phstc/shoryuken интегрирован с SQS. Но в настоящее время с некоторой утечкой памяти, и мое приложение иногда падает, я не знаю, является ли утечка памяти причиной жесткой. Мы уже отделили приложение между частью API в EBS и интерфейсной частью в S3.

Answer 1

Как правило, только один экземпляр EC2 с копией приложения Rails, где вместо rails s для запуска веб-сервера вы запускаете rake resque:work или независимо от того, какая команда запуска вашего бегуна. Оба будут использовать один и тот же экземпляр Redis и базу данных, чтобы ваш веб-сервер записывал задания в очередь, а рабочий собирал их и запускал.

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

Answer 2

У нас было аналогичное требование, для нас это были рабочие задания sidekiq, они стали очень тяжелыми, поэтому мы разделили его на отдельный стек opsworks с простым рецептом для создания зависимостей между машинами (ruby, mysql, и т. д.), и поскольку нам не нужно беспокоиться о балансировщиках нагрузки и времени ожидания запросов, все равно, что все машины будут развернуты одновременно.

Кроме того, вы можете использовать в opsworks использование плановых машин (если задание требуется в определенное время в течение дня), если машина предоставляется за несколько минут до момента выполнения задачи, а затем после выполнения задачи вы могли бы автоматически отключить его, что снизит ваши затраты.

EB также имеет приложение другого типа, которое является рабочим приложением, вы также можете проверить это, но, честно говоря, я не изучил его, поэтому не могу сказать вам, какие плюсы и минусы этого ,

Answer 3

Вы можете подумать о том, чтобы отправить свою задачу в службы AWS SQS, тогда вы можете использовать рабочую среду elasticbeantaslk для обработки вашей задней задачи.

Elasticbeanstalk поддерживает железнодорожные приложения: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Ruby_rails.html

Answer 4

В зависимости от того, какой работы выполняют эти фоновые задания, вы можете думать о том, может быть, извлекая эти функции в microservices, если вы работаете задания на экземпляре разницы в любом случае.

Here является хорошим сообщением в блоге о том, как подойти к этому.

Для простого почтового типа это определенно чувствует себя немного тяжело, но если функциональность более сложна, например. общее уведомление разных клиентов, это может стоить накладных расходов.

Answer 5

Мы недавно прошли по этому маршруту. Я докционировал наше приложение для рельсов и написал пользовательскую точку входа в этот контейнер докеров.Таким образом, команда entrypoint анализирует команды после запуска. docker run IMAGE_NAME

Например: если вы запустите: docker run IMAGE_NAME sb rake do-something-magical точка входа понимает, что она будет запускать rake-задание с конфигурацией среды песочницы. если вы только запускаете: docker run IMAGE_NAME будет rails s -b 0.0.0.0

PS: Я написал пользовательскую точку входа, потому что у нас есть 3 разных среды, эта точка входа загружает конфигурацию среды, специфичную для s3.

И я настроил кластер ECS, написал задание с заданиями на Лямбде, эта функция лямбда расписала задачу на кластере ecs, и мы запускаем эту лямбду из CloudWatch Events. Вы можете отправлять пользовательские полезные данные в lambda при использовании CloudWatch Events.

Звучит сложно, но реализация на самом деле проста.