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

Question

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

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

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

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

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

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

Answer 1

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

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