Сельдерей, использующий SQS в Amazon Elastic Beanstalk, часто останавливается на длительные периоды, пока есть сообщения

Question

В настоящее время я работаю над переносом существующего веб-проекта на основе Django на один сервер в Amazon Elastic Beanstalk. До сих пор я успешно настроил проект для использования RDS, Elastic Search, Simple Email Service и S3 без особых проблем. Я использую Code Deploy для создания контейнера Docker для проекта Django и развертывания в среде Elastic Beanstalk. Все это прекрасно работает, но я сталкиваюсь с проблемой, пытаясь заставить рабочую среду Elastic Beanstalk хорошо работать с этой настройкой.

Я развертываю тот же контейнер Docker в моей рабочей среде, но с другой точкой запуска для запуска celery -A project worker -l INFO вместо gunicorn config.wsgi --bind 0.0.0.0:5000 --chdir=/app --workers 3. Это похоже на работу; работник принимает сообщения и обрабатывает их очень хорошо, но часто кажется, что работа прекращается на несколько минут, даже если в очереди ожидают сообщения, ожидающие в очереди.

Во время моего тестирования я пытаюсь запустить процедуру генерации счетов, которая ставит в очередь сообщение для счета каждой учетной записи, используя Celery group в chain, чтобы он обрабатывал счета, а затем отправлял мне электронное сообщение " завершено "уведомление. Всего у меня в очереди около 250 сообщений. За журналами сельдерея для контейнера Docker я вижу группы из 8-12 сообщений, которые собираются, затем обрабатываются в течение одной или двух секунд, но затем рабочий бездействует несколько минут за раз. Обычно около 4 минут.

Я не вижу нигде ошибок, которые я мог бы посмотреть.

Я также экспериментировал с масштабированием рабочей среды, чтобы она работала с несколькими рабочими узлами, но это просто распространило проблему на несколько узлов. т. е. вместо того, чтобы один работник собирал 8–12 сообщений, два работника собирали между 4–6 сообщениями, обрабатывали их, а затем бездействовали.

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

Есть ли что-то, чего мне не хватает в этой настройке, или по какой-то причине, что рабочая среда Celery ведет себя таким образом?

Answer 1

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

При 4-минутном тайм-ауте он кажется очень близким к задержке повторения по умолчанию, присутствующей в Task.default_retry_delay у Celery, которая составляет 3 минуты. Это также может быть связано с Task.rate_limit, параметром конфигурации , который будет регулировать общее количество задач, выполняемых работниками сельдерея в данную единицу времени.

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