ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Orchestration avec Cloud Workflows

GCP Cloud Workflows comme couche d'orchestration intermédiaire entre Cloud Scheduler et Cloud Composer — serverless, économique, et suffisamment capable pour des pipelines multi-étapes.

Planté
gcpdata engineeringautomation

Entre “utiliser simplement Cloud Scheduler” et “déployer Cloud Composer” se trouve Cloud Workflows : une orchestration serverless à 0,01 $ pour 1 000 étapes. Il comble le vide pour les équipes qui ont besoin d’une coordination de pipeline multi-étapes sans le coût fixe de Composer de 300 à 400 $/mois.

Ce que fait Cloud Workflows

Workflows fournit les primitives de flux de contrôle qui manquent à Cloud Scheduler :

  • Logique conditionnelle. Branchez selon le résultat d’une étape précédente. Exécutez dbt uniquement si l’extraction a réussi. Envoyez des notifications différentes selon le succès ou l’échec.
  • Exécution parallèle. Exécutez des étapes indépendantes en simultané. Extrayez de trois sources en parallèle, puis exécutez dbt lorsque les trois sont terminées.
  • Gestion des erreurs. Sémantique try/catch/retry. Définissez ce qui se passe quand une étape échoue — réessayez avec un backoff, passez à un fallback, ou arrêtez le workflow.
  • Politiques de retry. Configurez les retry par étape avec backoff exponentiel et nombre maximum de tentatives.

Vous pouvez appeler Cloud Run Jobs, Cloud Functions, des endpoints HTTP et diverses API GCP. La syntaxe YAML exprime les dépendances et les branchements :

main:
steps:
- run_extraction:
call: http.post
args:
url: https://extraction-job-url/
result: extraction_result
- check_extraction:
switch:
- condition: ${extraction_result.body.status == "success"}
next: run_dbt
- condition: true
raise: "Extraction failed"
- run_dbt:
call: http.post
args:
url: https://dbt-job-url/
result: dbt_result
- notify:
call: http.post
args:
url: https://slack-webhook/
body:
text: "Pipeline completed"

Cet exemple illustre un pattern courant : extraire des données, valider le résultat, exécuter des transformations dbt, puis notifier l’équipe. Quatre étapes, branchement conditionnel et gestion des échecs — le tout pour quelques fractions de centime par exécution.

Le pattern hybride : Workflows et Cloud Run Jobs

L’architecture la plus pratique pour les pipelines de données multi-étapes sur GCP associe Cloud Workflows à Cloud Run Jobs :

  1. Cloud Scheduler déclenche le workflow selon un planning cron
  2. Cloud Workflows orchestre la séquence d’étapes
  3. Cloud Run Jobs exécutent chaque tâche intensive (extraction, dbt, validation)
  4. Eventarc déclenche optionnellement des workflows supplémentaires selon des événements

Chaque composant fait ce pour quoi il est conçu. Scheduler gère la planification. Workflows gère le séquençage et le flux de contrôle. Cloud Run Jobs gèrent l’exécution intensive en calcul. Le coût total reste négligeable comparé à Composer — typiquement moins de 10 $/mois pour des pipelines multi-étapes quotidiens.

Ce que vous sacrifiez

Les compromis par rapport à Composer sont spécifiques et méritent d’être compris avant de s’engager :

Pas de commande backfill. La commande backfill d’Airflow vous permet de réexécuter des pipelines pour des plages de dates arbitraires avec résolution des dépendances. Workflows n’a pas d’équivalent. Si vous devez retraiter trois mois de données après un changement de schéma, vous écrivez un script pour invoquer le workflow avec des dates paramétrées — gérable, mais manuel.

Pas d’interface opérationnelle. Workflows dispose d’un journal d’exécution dans la Console GCP, mais c’est une liste d’exécutions avec statut et durée. Pas de graphiques de Gantt, pas de graphes de dépendances, pas de drill-down au niveau des tâches. Pour le débogage, vous analysez Cloud Logging. Pour la visibilité opérationnelle de l’équipe, vous construisez un tableau de bord personnalisé ou vous vous appuyez sur des notifications Slack.

Pas d’écosystème d’opérateurs. Airflow dispose de centaines d’opérateurs pour interagir avec différents systèmes — S3, Snowflake, dbt Cloud, Slack, PagerDuty. Workflows interagit avec les services via des appels HTTP et des connecteurs API GCP. Ce qu’Airflow fait via un opérateur dédié, Workflows le fait via un appel HTTP brut. C’est acceptable pour des intégrations simples, mais devient laborieux lorsque vous devez interagir avec de nombreux systèmes externes.

Gestion d’état limitée. Workflows peut passer des données entre étapes via des variables, mais il n’y a pas d’équivalent à l’XCom d’Airflow pour partager des données volumineuses ou complexes entre tâches. Les sorties d’étapes sont limitées en taille, donc vous utiliserez Cloud Storage ou une base de données pour les résultats intermédiaires plutôt que de les faire transiter par le workflow.

Quand Workflows est le bon choix

Cette option intermédiaire convient aux équipes qui répondent à ces critères :

  • Besoin d’une orchestration multi-étapes. Votre pipeline a plus d’un job qui doit s’exécuter en séquence avec gestion des erreurs. Cloud Scheduler seul ne peut pas exprimer “exécuter B uniquement si A a réussi.”
  • Les besoins de backfill sont minimes. Vous devez rarement retraiter des données historiques, ou vous pouvez le gérer manuellement lorsque cela se présente.
  • La sensibilité aux coûts exclut Composer. Le minimum de 300 à 400 $/mois n’est pas justifiable pour votre charge de travail.
  • La complexité du pipeline est modérée. Moins de dix étapes. Si vous construisez des DAG avec des dizaines de tâches et des arbres de dépendances complexes, le modèle Airflow vous servira mieux.
  • Vous êtes à l’aise sans l’interface Airflow. Votre équipe peut déboguer à partir des logs et n’a pas besoin d’une surveillance visuelle du pipeline.

Pour les pipelines qui séquencent deux à cinq Cloud Run Jobs avec une logique conditionnelle et une gestion des erreurs, Workflows atteint un point optimal : suffisamment expressif pour gérer de véritables besoins d’orchestration, suffisamment économique pour que le coût n’entre jamais en ligne de compte, et suffisamment simple pour que la définition YAML soit l’intégralité du système — sans infrastructure à gérer, sans environnement à maintenir.

Le framework de décision d’orchestration dbt pour GCP positionne Workflows par rapport aux autres options. En heuristique : si Cloud Scheduler ne suffit pas et que Composer est trop coûteux pour la charge de travail, Workflows est l’option intermédiaire naturelle.