Как мы развернули коммунальный Apache Airflow для 30+ команд и сотни разработчиков

[SLASH_CyberPunk]

Подскажите, как вы решаете проблемы доступов на "коммунальном" сервере, если, на сколько я помню, у airflow нет разграничения прав на "группы" дагов. Как следствие, любой человек с нужными правами может дергать любой даг...

[dlampsi]

В коде DAG можно указать атрибут access_control, в котором можно указать название Airflow роли и права на конкретный даг.

access_control={
	"dataplatform": {"can_dag_edit"},
}

Подробнее описано тут и тут.

По умолчанию у нас на кластерах все пользователи имеют только роль Viewer, чужие DAGи никто изменять не может. Соответственно разработчики указывают в коде DAG роль своей команды и мы её выдаём по запросам.

[sshikov]

А как влияют 100 пользователей? Даже если бы их было 1000 — мне кажется, эта циферка ни о чем не говорит (во всяком случае отдельно). Живой пользователь, как правило, не создает большую нагрузку — а если он и запускает что-то тяжелое, то тяжесть не зависит от числа людей. Нагрузку создают либо роботы по расписанию или по событиям, а даже один человек может запустить что-то такое, что потребит любые ресурсы.

Если что, у нас Oozie, и я никогда не слышал, чтобы масштабирование по числу разработчиков приносило какие-то проблемы. Скорее их приносит ACL, когда появляются сотни групп, умноженные на десятки прав доступа к объектам. Вот тут всякие Sentry активно тормозят, это да.

[dlampsi]

Конечно, на сам кластер влияет кол-во работающих процессов (DAG) в кластере, кол-во которых у нас растёт с приходом на кластер новых пользователей-разработчиков.

А кол-во пользователей сайта (UI) влияет только на Airflow Webserver (который можно масштабировать). Тут проблем нет.

[sshikov]

Ну так и я про это. 100 пользователей для веб сервера — это вообще не нагрузка, скорее всего. А для кластера нагрузка зависит скорее от сложности DAG, а не от их количества.

Ну впрочем, чтобы понимать масштабы команды — 100 человек вполне себе показатель.

[eigrad]

У вас административно запрещено использовать VirtualenvOperator и все зависимости зашиваются в docker-образ где запускается worker?

Как организовано распределение ресурсов и ответственных за аппрув обновлений версий зависимостей в различных очередях? Каждой команде по своей очереди?

И как происходит обновление на воркерах?

[dlampsi]

Все python (и не только) зависимости устанавливаются в pipeline при сборке Docker образа (я описал это в главе "Модули"). В одном репозитории находятся DAGи у которых общие не конфликтующие зависимости.

На сколько мне известно, у нас никто не использует PythonVirtualenvOperator. Из-за выбранного нами способа разделения DAG в этом, я думаю, просто нет необходимости.

Соответственно и за обновление зависимостей ответственны команды разработки, тут они сами внутри команды решают что и когда обновлять и ни с кем не конфликтуют.

И да - каждый репозиторий обычно это одна или более очереди Celery. Ресурсы мы ограничиваем вручную: или выделяя отдельный хост под worker, или через лимиты Docker контейнеров в рамках одного хоста. Динамического выделения ресурсов пока что нет (мечтаем о Kubernetes).

Обновление (DAG и зависимостей) на worker происходит через pipeline я постарался описать это в главе "Modules deploy pipeline".