Google Workflows | Outil d’orchestration serverless de Google Cloud Platform

Google Workflow : un outil d’orchestration serverless ?

‍

L’ordonnancement des tâches et la gestion de leurs dépendances est aujourd’hui une brique essentielle de la Modern Data Stack. Cette fonction est généralement remplie par un outil d’orchestration qui lance les différentes tâches dans un ordre défini, permet ou non la parallélisation, et gère les dépendances entre ces dernières.

Le choix d’un service d’orchestration dépend de nombreux critères, comme la performance de l’outil, sa scalabilité, sa sécurité ou encore son coût.

Parmi les outils d’orchestration les plus connus figurent Airflow, ou Dagster, deux outils open-source puissants et scalables mais nécessitant de déployer une infrastructure adaptée et une maintenance régulière.

Il existe une gamme spécifique d'orchestrateurs permettant de mettre en place une orchestration sans avoir besoin de déployer et gérer une infrastructure dédiée : les orchestrateurs serverless. Google Workflows est l’un de ces outils. Nous allons, au fur et à mesure de cet article, dérouler les avantages et inconvénients d’un orchestrateur serverless par rapport à un orchestrateur classique.

‍

Qu’est-ce que Google Workflows ?

‍

Google Workflows est un service d’orchestration serverless disponible sur GCP. Il permet d’agencer différentes étapes faisant appel à des services Google Cloud tels que Cloud Functions, Pub/Sub ou Cloud Run, mais aussi à des API tierces.

Un workflow se décline en un fichier YAML directement éditable dans la console Google Cloud, ou via Terraform et un outil de versionning comme Git. Dans ce fichier YAML sont décrites des étapes, qui seront exécutées dans un ordre et suivant les conditions précisées.

‍

‍

‍

Les fonctionnalités de base de Google Workflows

Structure

Un workflow basique ressemble à ceci :

main:
  params: [input]
  steps:
	- checkSearchTermInInput:
    	switch:
      		- condition: '${"searchTerm" in input}'
        		   assign:
          			- searchTerm: '${input.searchTerm}'
        		   next: readWikipedia
	- getLocation:
    	call: sys.get_env
    	args:
      		name: GOOGLE_CLOUD_LOCATION
    	result: location
	- setFromCallResult:
    	assign:
      		- searchTerm: '${text.split(location, "-")[0]}'
	- readWikipedia:
    	call: http.get
    	args:
      		url: '<https://en.wikipedia.org/w/api.php>'
      		query:
        			action: opensearch
        			search: '${searchTerm}'
    	result: wikiResult
	- returnOutput:
    	return: '${wikiResult.body[1]}'

‍

Le bloc “main” est toujours le point d’entrée, et c’est la première étape de la liste “steps” qui sera d’abord exécutée. On observe qu'un workflow peut recevoir des paramètres en entrée, ici "input".

Un même workflow peut être exécuté des dizaines de fois en parallèle avec des paramètres identiques ou différents, et chaque exécution est totalement indépendante des autres.

Exécution des étapes

La liste d’étapes d’un workflow est par défaut exécutée séquentiellement. Google Workflows va toujours attendre la fin de l'exécution d'une étape donnée pour exécuter la suivante. Nous verrons par la suite qu'il est possible de s'affranchir de cette règle et de contraindre Google Workflows à exécuter certaines étapes de manière parallèle.

Structure d'une étape

Une étape donnée est définie par son nom, par exemple "getLocation". Celui-ci doit être unique pour servir d’identifiant et pouvoir être identifié de manière précise par Google Workflows.

À l'intérieur d’une étape se trouvent des mots-clés correspondant à des actions à réaliser. Ces actions peuvent être :

• ‍call : L'exécution d'une fonction de la bibliothèque standard Google Workflows‍
• assign : L'assignation d'une valeur à une variable‍
• switch : La mise en place d'une condition‍
• return : Le retour d'une valeur, signant généralement la fin du workflow ou du sub-workflow en cours

‍

Ainsi, l’étape ci-dessous consiste à utiliser la fonction sys.get_env de la bibliothèque standard de Workflows. Un appel de fonction via un bloc call est généralement suivi d’un bloc args permettant de passer des arguments à la fonction appelée. En l'occurrence, on souhaite ici passer le nom de la variable d’environnement que l’on veut récupérer. Le résultat de cet appel est ensuite stocké dans la variable location qui est utilisée dans la suite du workflow via la syntaxe $location , le symbole “$” permettant d’accéder au contenu de la variable qu’il précède.

‍

- getLocation:
	call: sys.get_env
		args:
  		name: GOOGLE_CLOUD_LOCATION
	result: location

‍

La liste des fonctions de la bibliothèque standard de Google Workflows est donnée ici.

La gestion des blocs conditionnels

Comme tout orchestrateur, Google Workflows offre la possibilité de créer des blocs conditionnels.

Le bloc ci-dessous comporte une condition, matérialisée par le mot-clé switch. Ce bloc attend une liste de conditions. Ici, on vérifie que le paramètre d’exécution du workflow input contient bien une clé “searchTerm”. Si c’est bien le cas, la valeur de ce paramètre est assignée à la variable searchTerm.

‍

- checkSearchTermInInput:
	switch:
  	- condition: '${"searchTerm" in input}'
    		assign:
      			- searchTerm: '${input.searchTerm}'
    		next: readWikipedia

‍

L’élément important à observer dans cet extrait de code est le mot-clé next : c’est lui qui permet, si la condition est valide, de sauter directement à l’étape voulue “readWikipedia”.

Une bonne combinaison de blocs switch et d’instructions next permet de créer des workflows complexes et modulaires. 

‍

‍

‍

Les fonctionnalités avancées de Google Workflow

En plus des blocs conditionnels switch décrits plus haut, il existe d'autres fonctionnalités permettant d'écrire des workflows plus avancés et modulaires.

Les subworkflows

Un subworkflow doit être défini à l'extérieur du workflow principal. C'est une suite d'étapes réutilisable qui prend des paramètres d'entrée et retourne une valeur de sortie. Ils s’apparentent à des fonctions en programmation.

Ils peuvent être appelés de la même façon que les fonctions de la bibliothèque standard Google Workflows, à l'aide du mot-clé call.

La gestion d'erreurs

Il est possible de gérer les erreurs dans un workflow via les mots-clés try, except et retry.

Les étapes du bloc try seront exécutées normalement tant que l'une d'elles ne lève pas une exception. Si une exception est levée, deux cas de figure se présentent :

• Si un bloc retry est présent, alors les étapes du bloc try sont à nouveau exécutées autant de fois que le permet la retry_policy.‍
• S'il n'y a pas de bloc retry ou si le nombre de tentatives maximales est atteint, les étapes du bloc except sont exécutées.

Il est possible de définir une retry policy précise qui indique les conditions selon lesquelles une nouvelle tentative doit être faite, la durée d'attente au bout de laquelle elle doit être lancée et le nombre maximum de nouvelles tentatives.

La pause d'un workflow

La fonction sys.sleep permet de mettre l'exécution d'un workflow en état de pause pendant un laps de temps donné, en secondes. L'exécution n'est pas stoppée, mais momentanément suspendue. La durée de suspension maximale pour un workflow est d’un an moins le temps d'exécution déjà écoulé. Cette limite découle naturellement du fait que la durée d’exécution limite pour un workflow dans son ensemble est d’un an.

Cette fonction est notamment utile dans le cas où l'on souhaite attendre la fin d'un processus dont la durée moyenne d'exécution est connue avant de continuer le workflow.

Les callbacks

Comme indiqué ci-dessus, le timeout d'un workflow est très long. Cependant, une étape spécifique ne peut rester en état d'exécution plus de 30 minutes, après quoi elle lèvera une exception de timeout qui mettra fin à l’exécution du workflow.

Dès lors, on est en droit de se demander comment construire un workflow nécessitant d'attendre la fin de l'exécution d'une étape potentiellement très longue, mais dont le temps d'exécution n'est pas connu, ou une action précise d'un service ou d'un utilisateur, pouvant survenir à n'importe quel moment

Workflows offre pour cela un service de callbacks fonctionnant en deux temps.

Tout d'abord, il consiste à mettre en place un callback endpoint, une URL propre à l’exécution du workflow en cours. La seconde étape consiste à placer le workflow dans un état d'écoute sur l'URL créée. Il attendra qu'un appel HTTP avec la bonne méthode soit effectuée sur l'URL d'écoute pour redémarrer. Cet état d'écoute n'est pas considéré comme une étape en cours d'exécution, le timeout d’exécution de 30 minutes ne s’applique donc pas et la seule restriction est le timeout d'un an du workflow.

De manière plus concrète, un callback dans un workflow permettrait par exemple d’attendre qu’un utilisateur valide un formulaire sur un site web avant de continuer l’exécution du workflow, que l’utilisateur mette 24h ou plusieurs semaines pour cela.

La parallélisation

Dans Google Workflows, il est possible de paralléliser certaines tâches. La création d’un bloc de parallélisation se fait via le mot-clé parallel et permet de déclarer explicitement certaines tâches comme devant s’exécuter parallèlement.

Une fois que chacune des tâches du bloc de parallélisation est terminée, l’exécution du workflow continue normalement.

‍

Google Workflows : avantages et inconvénients de l’outil

Les avantages de Google Workflows

Une architecture serverless : nous l’avons abordé au début de cet article, Google Workflows est un service d’orchestration 100% serverless. Ce statut implique une grande facilité d’utilisation du service puisqu’il n’est pas nécessaire de s’inquiéter de l’allocation des ressources, ni de sa scalabilité : Google se chargera d’allouer correctement les ressources nécessaires à leur bonne exécution.

‍

Modularité des workflows déployés : bien que la syntaxe en YAML et la méthode d’écriture des workflows puissent paraître restrictives, Workflows permet en réalité de déployer des flux de tâches très flexibles et modulaires. Cette flexibilité est permise par les blocs conditionnels et les instructions de saut à une étape précise que nous avons vues plus haut. De plus, l’écriture de sub workflows apporte une réelle modularité en permettant la factorisation et la réutilisation de blocs d’étapes répétitives.

‍

Grande permissivité dans la gestion d’erreurs : Workflows permet de paramétrer précisément les options de nouvelles tentatives d’une étape, ainsi que la gestion de ses exceptions. Cette finesse permet de gérer à peu près tout type d’erreurs, et de mettre en place un alerting différent selon le type d’erreur rencontré.

‍

Intégration dans GCP : une large bibliothèque de fonctions est disponible pour interagir avec les autres services GCP. Google Workflows est donc parfaitement adapté pour l’orchestration de services GCP entre eux.

‍

Possibilité de versionning avec Terraform : comme la plupart des ressources GCP, il est possible de créer un workflow directement via Terraform, permettant une reproductibilité plus simple pour un workflow donné, ainsi que la collaboration sur la définition d’un workflow.

Les inconvénients de Google Workflows

Syntaxe YAML obligatoire : l’utilisation du YAML pour définir des workflows complets et bien construits peut parfois nécessiter un temps d’adaptation. De plus, les erreurs éventuelles dans le fichier YAML écrit pour exécuter le workflow ne sont pas toujours bien explicitées par la console, et peuvent être compliquées à déboguer.

‍

Dépendance à GCP : bien que Google Workflows soit parfaitement en mesure de faire appel à des API externes, il est optimisé pour fonctionner au mieux avec les autres services GCP. Ainsi, Workflows n’est pas l’orchestrateur le plus adapté pour orchestrer des services dans un environnement multi-cloud.

‍

Limitations et quotas : Google Workflows impose certaines limitations quant à l’utilisation de son service. Nous l’avons évoqué plus haut, la durée d’exécution globale d’un workflow ne peut pas excéder un an et celle d’une étape individuelle ne peut excéder 30 minutes, ce qui est plus restrictif et peut parfois poser des problèmes pratiques.

Tarification du service

Comme beaucoup de services GCP, Google Workflows fonctionne sur un modèle “pay-as-you-go”, uniquement à l’usage des ressources.

Cela se traduit par le fait que l’utilisateur est facturé au nombre d’étapes exécutées chaque mois. Une distinction est faite cependant entre les étapes dites “internes” (celles faisant appel à un autre service GCP) et les étapes dites “externes” (celles faisant appel à un service non-intégré à GCP).

Voici le détail de la facturation pour les étapes internes:

• 0$ pour les 5000 premières étapes du mois
• 0,01$ toutes les 1000 étapes, entre 5000 et 100M d’étapes

Et pour les étapes externes:

• 0$ pour les 2000 premières étapes du mois
• 0,025$ toutes les 1000 étapes, entre 2000 et 100M d’étapes

‍

Dans les deux cas, pour un besoin allant au-delà de 100M d’étapes par mois, il est nécessaire de contacter le service commercial de GCP pour mettre en place une tarification spéciale.

Attention: la facturation de Workflows est uniquement dépendante du nombre d'étapes exécutées, et pas de la longueur de celles-ci. Ainsi, la facturation d’une étape de 5 secondes et de 30 minutes sera identique. Cependant, si une étape d'un workflow implique, par exemple, l'appel d'un service Cloud Run durant un laps de temps important, cela entraînera bien une facturation en conséquence, mais seulement relative à l'utilisation de Cloud Run sur la plage de temps donnée.

Workflows est donc une solution très avantageuse d’un point de vue financier, permettant l’exécution d’un nombre important d’étapes pour des coûts relativement faibles.

Google Workflow : un outil puissant de la Modern Data Stack

Google Workflows est un puissant outil d’orchestration serverless qui s’intègre parfaitement dans l’écosystème GCP. En outre, il permet des appels à des APIs externes pour un spectre d’action encore plus étendu, le tout pour des tarifs avantageux.

Il est aussi adapté à l’utilisation au sein d’une organisation grâce à la possibilité de versionner les workflows, via l’utilisation conjointe de Terraform et Git.

Il est cependant important de prendre en compte ses limitations, ainsi que sa courbe d’apprentissage initiale pour un développeur n’étant pas habitué à définir des flux en YAML.

Comme toujours, il est essentiel d’étudier le besoin spécifique de l’entreprise avant de mettre en place une orchestration complète au sein de votre Modern Data Platform utilisant ce service.

Si vous souhaitez découvrir un cas d’usage concret de Google Workflows par Modeo, je vous conseille ce webinaire et pour en savoir plus sur nos offres et notre approche, contactez-nous !