Step 5 of 8

Luigid

Вот мы и добрались до, пожалуй, сердца всего фреймворка Luigi — Luigid.

Luigid — это веб-сервис с простым симпатичным интерфейсом. Он реализован на веб-фреймворке Tornado, который наружу предоставляет интерфейс по типу RPC (Remote Procedure Call). Здесь и далее я буду называть его диспетчером задач.

Основные функции демона:

• Предоставлять инженеру всю информацию о текущем статусе задач (на исполнении, в ожидании, ошибки), показывать граф зависимостей между задачами
• Разруливать ситуации, когда одна и та же задача может быть выполнена двумя разными воркерами.

Последний пункт наиболее важный. Начинающие пользователи luigi думают, что luigid не несёт в себе никакой пользы кроме графического дэшборда. Но это глубокое заблуждение.

Бесспорно, код задачи исполняется воркером, но перед его исполнением воркеру необходимо проделать подготовительную работу, а именно:

• проверить что Task и его зависимости ранее не были выполнены (для этого он вызывает метод complete, который в свою очередь проверяет Target на существование (через обязательный для реализации метод exists у всех классов-наследников Target)
• Отрапортовать результат сбора информации диспетчеру Luigid со всеми статусами
• Обратиться к диспетчеру за задачами на исполнение

Здесь очень важно понимать, что воркер, ВНИМАНИЕ, не начинает работу над исполнением задачи без ведома диспетчера. Именно последний говорит ему что необходимо выполнить прямо сейчас (исходя из зависимостей между задачами и их статусами). В продакшен среде, где одновременно могут исполняться сотни задач, необходим механизм, контролирующий исполнителей и предотвращающий появление ситуаций, когда одно и то же задание может быть выполнено дважды и более раз.

Ниже представлена упрощенная схема взаимодействия между пользователем, воркером и диспетчером Luigid:

В luigi существует два типа диспетчеров:

• LocalScheduler
• RemoteScheduler

LocalScheduler представляет из себя объект, который создаётся в момент инициализации воркера (когда пользователь запускает команду выполнения задачи). Он в первую очередь предназначен для локальной разработки и отладки пайплайнов. Соответственно не рекомендуется использовать его в продакшен среде, т.к. у каждого запуска задачи будет свой собственный диспетчер и ни о каком контроле выполнения задач между разными воркерами речи быть не может. Для его инициализации в командной строке достаточно указать параметр --local-scheduler.

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

Из плюсов:

• Простота самого инструмента, нет необходимости дополнительно беспокоиться о синхронизации доступа к объекту в памяти
• Минимальное количество зависимостей, вам не нужно поднимать дополнительные сервисы вроде базы данных, кэшей и т.д.

Из минусов:

• Диспетчер является "бутылочным горлышком", разработчики luigi утверждают, что luigid способен обрабатывать тысячи задач, но проблемы могут начаться, когда их количество перешагнет за десяток тысяч.
• Если диспетчер внезапно упадёт, то информация о задачах (стейт) тоже исчезнет, что вынуждает разработчика дополнительно реализовывать механизм отказоустойчивости.