Nous avons cherché à ajouter au sein de l’infrastructure d’Affluences une solution qui nous permettrait de gérer plus facilement nos différents processus, notamment de script, ou de tâche planifiée. La solution qui a été retenue est Airflow, et c’est une vraie réussite pour le besoin que nous avions.
Airflow, c’est quoi ?
Apache Airflow est une plateforme de planification de flux de travail open-source, utilisée par un grand nombre d’entreprises pour ce qui touche à l’ingénierie des données.
La solution est très complexe, mais aussi complète, et bien documentée. La mise en place de l’outil est globalement complexe, mais l’écriture de job depuis la 2.0 est faite avec des annotations et les tests sont assez simples à mettre en place.
Airflow utilise des DAG (Directed Acyclic Graph) qui peuvent être individuellement paramétrés et que l’on peut apparenter à des CRON, pour celles et ceux qui sont plus familiers avec. Sans aller trop profond dans les détails, Airflow se compose d’un minimum de 3 programmes :
- Airflow Webserver: Page web qui permet la gestion des dag
- Airflow Scheduler: Message broker en charge de la distribution des dags à des workers
- Airflow Worker: Programme qui écoute le scheduler et exécute le dag dès lors que l’ordre lui est donné. Il est préférable d’avoir plus d’un worker afin de pouvoir paralléliser les exécutions.
Les avantages d’Airflow
Airflow nous permet de centraliser les différentes tâches planifiées, CRON, script, et autres petits programmes, en un seul endroit. Écris en Python, nos dag sont assez simples à faire, et le maintien du code est, lui aussi, simplifié.
L’interface est facilement accessible autant pour les développeurs, que pour des personnes en dehors de la tech qui n’aurait sans ça pas pu déclencher eux-même des exécutions au besoin. L’audit est aussi important pour Affluences, il est d’autant plus simple maintenant que nous avons une interface sur ces projets !
D’autres fonctionnalités tel que le OAuth Google, les gestions de droits, les exécutions avec configuration, etc… font de cet outil un membre à part entière de la stack Affluences.
Les problèmes d’Airflow
Évidemment une telle solution contient quelques contreparties qui dans notre cas ont été soit acceptées, soit contournées, soit en train d’être résolues.
Par exemple, la mise en place initiale nous a posé des contraintes techniques au regard des librairies disponibles sur les dag (embarqués, ou venv si besoin), ainsi que l’alimentation asynchrone des dag eux-même (depuis Gitlab). Notre solution ? intégrer un CRON (git-sync) au sein de Scheduler et Worker, qui alimente les dag depuis le repository.
Vous pourrez trouver sur la doc de Airflow un guide afin de monter la solution dans un environnement Kubernetes, mais nous utilisons Swarm 🤷 donc nous avons dû créer notre propre stack.
Un autre gros problème que nous avons rencontré, lié au point précédent, est l’absence de paradigme fort sur l’écriture des dag. Nous avons décidé d’une architecture plus rigide, d’un format et de concepts afin de linéariser nos dag. Cette solution se verra évoluer vers un environnement où les dag seront uniquement des Pod (conteneur docker) et pourront être écrits dans n’importe quel langage, avec n’importe quelle librairie embarquée !
L’implémentation chez Affluences
Parmi de nombreux outils (Dkron, Activeeon, RunDeck…) qui proposaient une solution similaire, Airflow a été adopté courant 2022. Peu à peu le premier choix lorsqu’un nouveau projet qui s’y prête doit être créé, ou qu’un projet existant doit être mis à jour.
Initialement, nous avons étudier les différentes possibilités qui s’offraient à nous sur plusieurs points:
Comment formater nos dag ?
Cette partie était difficile car il nous a fallu étudier les différentes façon existantes de créer et utiliser un dag, et d’en sélectionner une qui répond à notre besoin!
Nous avons opté pour l’utilisation des décorateurs, présents depuis Airflow 2.0, afin d’alléger notre code, et d’embarquer des librairies Affluences dans l’image.
Ce choix d’embarquer des librairies dans l’image nous a permis de diviser le temps de traitement d’un dag par 10, car autrement, nous devions définir un venv pour chaque dag qui requiert une lib externe, et Airflow régénère ce venv à chaque exécution.
À l’avenir, nous comptons faire évoluer les dag afin que ceux-ci soient des conteneurs docker, ce qui nous permettrait une plus grande liberté sur les langages, librairies, et implémentation d’Airflow.
Quelle architecture pour Airflow ?
Nous avons commencé par tout regrouper derrière supevisord, qui nous permettait de lancer plusieurs processus au sein d’une même image. Problème ? Impossible de scale les workers uniquement. Cette structure a été gardée pour pouvoir lancer la solution en local lors du développement, mais n’est plus utilisée dans le swarm.
Après avoir repenser au besoin et aux contraintes, nous sommes arrivés à la solution suivante, qui comprend 3 services distincts et que l’on a connecté à nos services de base de données / message broker existant.
Cette dernière solution est toujours d’actualité et répond à nos besoins sans soucis. Des services comme Grafana sont aussi venus s’intégrer autour de Airflow.
Pour résumer
Airflow fût un choix de solution très convainquant et s’intègre parfaitement au sein de la stack d’Affluences. Malgré les difficultés de mise en place et de gestion, nous sommes parvenus à avoir un outil stable, pérenne, et qui résout notre problématique initiale, comment regrouper et mieux gérer nos tâches planifiées et scripts temporaires.
Nous continuerons d’évoluer avec Airflow et de migrer nos projets vers des dag jusqu’à ce qu’aucun projet qui puisse être un dag n’en soit pas un.J’espère que cet article vous a appris les bases de airflow et donné l’envie d’en savoir plus !
En lisant ce texte, j’ai pu prendre connaissance de la nouvelle infrastructure que Airflow propose à ses utilisateurs. Il m’a alors permis d’être à la page et surtout de faire avancer mon entreprise de manière optimale. La gestion du flux de travail est donc actuellement optimisée au sein de ma boite. Que du positif !