Introduction
Cela faisait pas mal de temps que je n’avais plus créé d’articles techniques, et pour cause j’étais très occupé. Et justement, pour répondre à un besoin précis d’intégration de données, j’ai découvert un outil open-source puissant : Airbyte.
Sur le papier, le concept de cet ETL / ELT est simple : un flux entrant (la source) et un flux sortant (la destination) gérés et distribués de manière centralisée.
Imaginez le gain de temps : automatiser un pipeline de données depuis Stripe avec un dispatch direct vers un Google Sheets. C’est parfait pour rendre une équipe marketing autonome, sans polluer le temps d’une équipe de dev avec la maintenance des API. Rentrons dans le vif du sujet.
À qui s’adresse Airbyte ? (Profils Tech et DevOps)
Je dirais qu’en premier lieu, ce produit s’adresse à une équipe de développeurs ou de Data Engineers qui veulent garantir un fonctionnement sans frictions en cross-app (entre différentes applications).
Imaginez le cauchemar de gérer à la main un multi-flux depuis une base de données, avec la maintenance constante des API que cela implique. Et surtout, imaginez devoir coder vous-même la conversion des données pour qu’elles soient lisibles par un utilisateur métier (type commercial ou marketing). Airbyte automatise tout cela.
Attention cependant : il faut que l’équipe ait aussi une forte appétence DevOps (ou DataOps). Dans sa version open-source (auto-hébergée), Airbyte est un outil relativement lourd et complexe à mettre en place. Il vous faudra maîtriser des environnements comme Docker ou Kubernetes pour le faire tourner en production. (À noter que pour contourner cela, l’éditeur propose aussi une version Airbyte Cloud entièrement managée).
Cas concret : Le cauchemar du downtime (et comment l’éviter)
Imaginez le scénario : vous gérez une architecture BaaS (Backend as a Service), et pour des raisons opérationnelles, le client exige une visibilité constante. Même si le cloud principal tombe en panne, pas question d’avoir un downtime sur ses données vitales : il veut recevoir un e-mail avec les ventes des 5 dernières minutes en cas de crash.
Évidemment, le client résume ça très simplement : « Si le cloud est HS, on reçoit un mail ». On connaît tous la qualité des clients pour formuler ce genre de requêtes…
Techniquement, le besoin est complexe. Il faut faire un export automatique et très régulier depuis notre base PostgreSQL, stocker les données de manière sécurisée, écouter un heartbeat (le statut de santé du serveur) et, le cas échéant, isoler le dernier fichier pour l’envoyer par e-mail.
Une belle usine à gaz sur le papier, mais nous allons voir comment Airbyte nous fait gagner un temps considérable pour mettre cela en place, tout en s’affranchissant des soucis de conversions de données.
L’erreur classique : Demander à PostgreSQL de générer des fichiers
Je vous voyais venir : on va demander à PostgreSQL de générer du JSON et hop, on le push sur un S3 via un simple cron job.
Énorme erreur, et surtout extrêmement lourd en IOPS pour les performances de votre base de données !
À la place, on va laisser Airbyte opérer. Et le plus beau, c’est que tout se configure directement depuis sa Web UI (oui, vous avez bien lu, une interface graphique claire et intuitive).
Plutôt que de bricoler des triggers ou des vues SQL lourdes à maintenir et à purger manuellement, on connecte le connecteur natif d’Airbyte à notre base PostgreSQL en activant le CDC (Change Data Capture) via la réplication logique (WAL). Le principe ? Airbyte écoute les changements sur vos tables critiques en temps réel de manière sécurisée, sans écrire la moindre ligne d’API et sans impacter les performances de la base.
Ensuite, on configure une destination Amazon S3 dans Airbyte. On teste la connexion, puis on définit notre schéma de synchronisation avec notre fameuse fréquence de 5 minutes.
Résultat : à chaque changement détecté (CDC), Airbyte publie automatiquement un fichier CSV parfaitement formaté sur le S3.
Bien entendu, on fait les choses dans les règles de l’art : le bucket S3 est chiffré et configuré en WORM (Write Once, Read Many) pour empêcher toute altération. Et pour éviter la surcharge de stockage, une simple règle de cycle de vie purge les fichiers CSV toutes les semaines. Seul le strict nécessaire reste présent.
Airbyte est-il toujours LA solution ? (Les limites de l’outil)
Jusqu’à présent, vous avez peut-être l’impression qu’Airbyte est le meilleur outil possible pour la synchronisation cross-app. Et c’est vrai, il est redoutable. Mais est-ce pour autant une solution obligatoire ? Non, pas du tout.
Tout dépend de votre contexte. Par défaut, une base de données aussi évoluée que PostgreSQL possède déjà ses propres mécanismes internes (sauvegardes en batch, réplication native, etc.).
Alors, pour un besoin strictement métier comme le nôtre, qu’est-ce qui nous empêche de dire « Airbyte et c’est tout » ? Il y a trois limites majeures à prendre en compte :
- Le coût d’infrastructure : Airbyte est une grosse usine à héberger (self-hosted). Si vous partez sur un déploiement Kubernetes, la consommation de ressources fera vite grimper la facture cloud.
- La charge de maintenance : Maintenir l’outil à jour, surveiller les workers et l’infrastructure demande un vrai temps de cerveau DevOps.
- Le risque de SPOF (Single Point of Failure) : En cas de panne d’Airbyte lui-même, que se passe-t-il ? Vos flux de données s’arrêtent net.
À mon sens, c’est un outil clé en main fantastique pour gagner du temps et offrir un Plan de Continuité d’Activité (PCA)robuste face à un besoin métier précis. Mais en aucun cas cela n’est la solution universelle absolue si votre équipe n’a pas les reins solides pour le maintenir.
L’installation en local : Monter notre stack de test
Quand on se rend sur le site d’Airbyte, il y a plusieurs options de déploiement : le Cloud (SaaS), Kubernetes (K8s), ou l’installation locale (historiquement via Docker Compose, aujourd’hui via leur outil abctl).
Laissons Kubernetes et Minikube de côté pour des besoins de production très spécifiques. Ici, notre but est de tester notre pipeline en local.
Pour cela, nous allons d’abord monter notre stack applicative avec un fichier docker-compose.yml. Et pour faire tourner notre application de test, nous allons utiliser FrankenPHP. Eh oui, ce blog est Symfony friendly, et c’est mon outil de cœur pour créer toutes sortes de projets ultra-performants !
Pour simuler notre cas d’usage complet (de la base de données jusqu’au bucket S3 de secours), voici le docker-compose.ymlde base que je vous propose :
version: '3.8'
services:
# Notre application Symfony propulsée par FrankenPHP
php:
image: dunglas/frankenphp
environment:
- SERVER_NAME=localhost
ports:
- "80:80"
- "443:443"
volumes:
- .:/app
depends_on:
- database
# Notre base de données source (PostgreSQL) configurée pour Airbyte (CDC)
database:
image: postgres:15-alpine
environment:
POSTGRES_USER: app_user
POSTGRES_PASSWORD: app_password
POSTGRES_DB: app_database
ports:
- "5432:5432"
command: ["postgres", "-c", "wal_level=logical"] # Indispensable pour le CDC Airbyte !
# Notre destination S3 locale (MinIO)
minio:
image: minio/minio
environment:
MINIO_ROOT_USER: admin
MINIO_ROOT_PASSWORD: password123
ports:
- "9000:9000"
- "9001:9001"
command: server /data --console-address ":9001"Avec ce simple fichier, vous avez votre application Symfony, votre base PostgreSQL prête à envoyer ses logs transactionnels (grâce au paramètre wal_level=logical), et un bucket MinIO pour faire office d’Amazon S3 gratuit en local.
Il ne reste plus qu’à lancer Airbyte à côté (via abctl local install) et à connecter tout ce beau monde via l’interface graphique !
abctl, késako ? (La magie du déploiement local)
Pour simplifier le déploiement local sans devoir se complexifier l’installation, il faut comprendre une chose : Airbyte fonctionne sur une architecture complexe en microservices.
Imaginez devoir tout installer pod par pod (le serveur API, l’interface web, les workers, le planificateur de tâches, la base de données interne…) et devoir configurer le réseau pour les connecter manuellement entre eux. Un véritable enfer pour un simple test de faisabilité !
L’équipe interne d’Airbyte a justement pensé à ça. Ils ont créé abctl, un outil en ligne de commande dédié. Sous le capot, cet outil monte un mini-cluster Kubernetes directement dans votre Docker de manière totalement transparente. Il s’occupe de lancer et de lier tous les pods nécessaires en une seule commande. Vous profitez de la robustesse de leur architecture microservices, sans la migraine opérationnelle.
Cet article t’a plu ?
Je suis Jean-Sébastien Christophe et je partage sur mon blog mon univers geek, mais aussi mes retours d’expérience sur les outils que j’utilise au quotidien, et sur Symfony, mon outil numéro 1.
Laisser un commentaire