Несколько экземпляров сельдерея для автоматического масштабирования приложения django на эластичном стебле

Question

Я пытаюсь найти лучший способ структурировать приложение Django, которое использует Celery для обработки асинхронных и запланированных задач в автоматическом масштабировании среды AWS ElasticBeanstalk.

До сих пор я использовал только один экземпляр среды Elastic Beanstalk с Celery + Celerybeat, и это работало идеально. Тем не менее, я хочу, чтобы в моей среде работало несколько экземпляров, потому что время от времени происходит сбой экземпляра, и требуется много времени, пока экземпляр не будет восстановлен, но я не могу масштабировать свою текущую архитектуру до нескольких экземпляров, потому что Предполагается, что Celerybeat запускается только один раз во всех экземплярах, так как в противном случае каждое задание, запланированное Celerybeat, будет отправлено несколько раз (один раз для каждого экземпляра EC2 в среде).

Я читал о нескольких решениях, но все они, похоже, имеют проблемы, которые не помогают мне:

• Использование django cache + lock: этот подход больше напоминает быстрое исправление, чем реальное решение. Это не может быть решением, если у вас много запланированных задач, и вам нужно добавить код для проверки кэша для каждой задачи. Также задачи по-прежнему отправляются несколько раз, этот подход только гарантирует, что выполнение дубликатов останавливается.
• Использование параметра leader_only с ebextensions: изначально отлично работает, но если экземпляр EC2 в среде выходит из строя или заменяется, это может привести к ситуации, когда Celerybeat вообще не работает, поскольку лидер определяется только один раз при создании среды.,
• Создание нового приложения Django только для асинхронных задач на рабочем уровне Elastic Beanstalk: Хорошо, потому что веб-серверы и рабочие могут масштабироваться независимо, а производительность веб-сервера не зависит от огромных асинхронных рабочих нагрузок, выполняемых работниками. Однако этот подход не работает с Celery, поскольку демон SQS рабочего уровня удаляет сообщения и публикует тела сообщений по заранее определенным URL-адресам. Кроме того, мне не нравится идея иметь полное дополнительное приложение Django, которое нуждается в импорте моделей из основного приложения и нуждается в отдельном обновлении и развертывании, если задачи изменены в основном приложении.

Как использовать Celery с запланированными задачами в распределенной среде Elastic Beanstalk без дублирования задач? Например, как я могу убедиться, что ровно один экземпляр работает во всех экземплярах все время в среде Elastic Beanstalk (даже если происходит сбой текущего экземпляра с Celerybeat)?

Есть ли другие способы добиться этого? Как лучше всего использовать рабочую среду Elastic Beanstalk с Django?

Answer 1

Я думаю, вы могли бы выделить бит сельдерея для другой группы.

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

У вас должен быть другой набор (или только один) экземпляра для удара сельдерея

Answer 2

На случай, если у кого-то возникнут аналогичные проблемы: я переключился на другую среду очередей / задач для django. Он называется django-q и был создан и работает менее чем за час. Он обладает всеми необходимыми мне функциями, а также лучшей интеграцией с Django, чем с Celery (поскольку djcelery больше не активен).

Django-q очень прост в использовании, а также легче, чем огромный каркас из сельдерея. Я могу только рекомендовать это!