Архитектура web-приложения на Python с потоками: как быть?

[anatolym]

Привет. Требуется помощь знатоков.

Задача

Есть веб-приложение на Python (Flask), предоставляющее некую функциональность через API. Оно состоит из двух частей.

1. Web-сервер: приём запросов, валидация входящих данных, запуск обработчика, возвращение ответа.
2. Пул обработчиков: список неких юнит (инициализированный class), хранящий свой стейт в памяти. Нужен именно пул, так как есть некая логика выбора юнитов из пула, инвалидации юнитов.

Юнит принимает данные на входе, обрабатывает их продолжительное время (от 1 до 60 секунд) и отдаёт результат. Один юнит может обрабатывать только один запрос в единицу времени.

В данный момент воркфлоу выглядит так:

1. Запускается flask приложение. Формируется пул обработчиков (инициализация объектов, наполнение списка).
2. При поступление входящего HTTP-запроса в эндпоинт, принимаются данные из запроса, валидируются, из пула запрашивается свободный юнит, ему передаются входящие данные, запускается обработка.
   При этом HTTP-подключение не закрывается, и клиент продолжает ждать результата (это минус).
3. После завершения обработки юнит возвращает результат в веб-приложение, затем возвращается ответ клиенту.

Минусы

• Долгие открытые коннекты от клиентов.
• Количество одновременно обрабатываемых запросов от клиентов ограничено количеством юнитов в пуле.
• Невозможно запустить Flask приложение в мультипроцессовом режиме (только мультипоточный), так как у каждого процесса должен быть доступ к одному и тому же пулу обработчиков. Иначе пришлось бы делать пулы на каждый отдельный процесс (в данном случае это неудобно). Это ограничивает одновременно обрабатываемое количество HTTP-запросов.

Что хотелось бы

• Убрать минусы, описанные выше.

Вариант решения

• Выделить пул в отдельного демона, не связанного с web-приложением.
• Сменить воркфлоу обработки на:
  • Web-приложение получает запрос на обработку, фиксирует его в каком-то хранилище (БД, кэш), отдаёт клиенту id его запроса.
  • Затем web-приложение отправляет сообщение в очередь (zeromq, beanstalkd, например).
  • Демон пула слушает очередь.
  • При поступлении сообщения, демон пула выбирает доступный юнит, запускает его обработку в отдельном потоке (а-ля запустить коллбэк).
  • После завершения работы юнита, результат обработки сохраняется в хранилище (БД, кэш). Выделенный поток приложения умирает.
  • Параллельно этому клиент переодически опрашивает web-приложение, готов ли результат для ранее полученного id запроса.

Вопросы

1. Насколько бредово выглядит изначальный вариант?
2. Какие мысли по поводу переработанного воркфлоу?
3. Как обычно решаются подобные задачи?
4. Как правильно создавать/убивать потоки в python?
5. Как мониторить состояние пула?
   В данный момент в web-приложении есть страничка состояния пула, так как объект пула доступен из web-приложения. Если выделить пул в демона – как получить из него информацию о состоянии? Снова делать из него веб-приложение с методами для получения состояния?

PS: изначально планировалось это сделать простым микросервисом. Что-то уже вылезает из "микро".

[astynax]

1. Изначальный вариант выглядит не очень хорошо - основные проблемы уже обозначены.
2. По переработанному варианту:
   • Отдельный процесс с пулом воркеров - нормальное решение. Очередь можно для начала сделать на чём-то не требующем лишних сущностей, например, на snake-mq (нагрузка на очередь здесь микроскопическая, так что должно хватить чего-то подобного)
   • стоит подумать о замене Flask на тот же Tornado - это умеет websockets, что позволяет организовать нормальные push-уведомления об окончании выполнения задач, тем более что "синхронная часть работы" всё равно переместится в отдельный процесс, общение с которым будет осуществляться асинхроно посредством очереди.
3. Подобные задачи решаются либо самостоятельно - примерно так, как и описано во "флоу №2", либо используется Celery - готовое решение для запуска задач на пуле с управлением посредством очереди. Крайне рекомендую посмотреть на этот вариант, т.к. Celery - проверенная временем рабочая лошадка. Только не нужно сразу ставить RabbitMQ в качестве брокера - пока нет распределения нескольких инстансов Celery по кластеру, Rabbit - overkill.
4. Правильно и безопасно убивать потоки не очень просто, но возможно. Например, силами инструментария из модуля threading. Если же использовать Celery, то у неё есть свои средства управления исполнением задач (это тоже очевидный плюс готового решения).
5. Мониторить состояние пула можно с помощью отправки из каждого воркера heartbeat-сообщений в очередь. Такие сообщения позволяют быстро понять, что процесс "завис" - по пропаданию "пульса". С помощью сообщений же можно отдавать информацию о прогрессе выполнения.

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

[emakashov]

Привет!

Как уже отметил @astynax, распространенное и проверенное решение - веб-сервер в связке с Celery. Могу привести в пример, как у нас в проекте сделано (на джанге, но суть та же). Веб-сервер создает запись в базе и запускает асинхронно celery таску, клиенту возвращает id таски. Когда celery выполняет задачу, то переводит статус в базе, записывает результат и пр. Клиент периодически опрашивает состояние задачи, когда она выполнена, веб-сервер возвращает ее результат и удаляет из базы.

Если веб-сервер простой, то есть смысл переписать на торнадо/aiohttp, тогда не придется отдельно менеджить сервисы celery и бэкенда (redis/etc)

[anatolym]

Спасибо за подробный ответ и за ссылки на snake-mq и Celery!

Про WebSocket'ы подумаю, может, с ними будет и проще.

threading буду смотреть. Так как этот проект частично является пет-проджектом, то время на самообучение есть. Хочется уже потрогать мультипоточность.

Мониторить состояние пула можно с помощью отправки из каждого воркера heartbeat-сообщений в очередь.

В моём случае, если я хочу отображать статус (и статистику) пула, получателем таких heartbeat-сообщений от воркеров будет пул. А как доставить аггрегированную статистику пула в web-приложение? Тоже через очередь?

[anatolym]

Как уже отметил @astynax, распространенное и проверенное решение - веб-сервер в связке с Celery. Могу привести в пример, как у нас в проекте сделано (на джанге, но суть та же). Веб-сервер создает запись в базе и запускает асинхронно celery таску, клиенту возвращает id таски. Когда celery выполняет задачу, то переводит статус в базе, записывает результат и пр. Клиент периодически опрашивает состояние задачи, когда она выполнена, веб-сервер возвращает ее результат и удаляет из базы.

Звучит проще, чем у меня сейчас. Хех, хотел обойтись малым рефакторингом, похоже, не получится =)

[astynax]

Пул не должен общаться с вокрерами через очередь. Через очередь он общается с web-сервером. Воркеров пул просто запускает через тот же multiprocessing и heartbeat от подпроцессов в пул будет приходить через pipe. А дальше пул может транслировать состояние воркеров web-серверу через очередь. Сажать ещё и воркеров на очередь нет особого смысла

[emakashov]

PS: изначально планировалось это сделать простым микросервисом.

Если размер проекта небольшой, то наверное проще будет переписать на aiohttp, хотя без подробностей сложно сказать

threading буду смотреть. Так как этот проект частично является пет-проджектом, то время на самообучение есть. Хочется уже потрогать мультипоточность.

Да кому нужна эта многопоточность на питоне. Асинхронный подход и проще, и интересней, имхо

[anatolym]

В общем, промучившись с реализацией на питоне, которая была крайне нестабильна, я забил и переписал всё на go.
Да, я не умею готовить код на питоне, и кто-то бы сделал это лучше меня. Но я решал свою проблему, и теперь не парюсь из-за сервиса, который работает и есть не просит.