Comprendre Cloud Tasks

Cette page présente les tâches et les files d'attente de Cloud Tasks. Elle décrit également quand et comment les utiliser. Cloud Tasks vous permet de trier les opérations qui peuvent être effectuées indépendamment du flux principal de votre application et de les traiter de manière asynchrone à l'aide de gestionnaires que vous créez. Ces opérations indépendantes sont appelées tâches. Par exemple, vous devez mettre à jour une base de données dans le cadre du traitement d'une requête utilisateur, mais les mises à jour peuvent prendre beaucoup de temps. Le déchargement de cette action en tant que tâche vous permet de résoudre plus rapidement la requête.

Point clé : Le service Cloud Tasks est conçu pour les tâches asynchrones. Elle n'offre pas de garanties solides concernant la chronologie de livraison des tâches et n'est donc pas adaptée aux applications interactives dans lesquelles un utilisateur attend le résultat.

La tâche déchargée est ajoutée à une file d'attente, qui la conserve jusqu'à son exécution. En fonction de votre configuration initiale, la file d'attente peut également servir de contrôle du flux de distribution. Vous créez et configurez la file d'attente, qui est ensuite gérée par le service Cloud Tasks. Une fois les tâches ajoutées, la file d'attente les envoie et s'assure qu'elles sont traitées de manière fiable par vos nœuds de calcul. Les complexités associées à ce processus, telles que les coûts de la latence subie par l'utilisateur, les plantages du serveur, les limites de consommation des ressources et la gestion des nouvelles tentatives, sont gérées par le service.

Cloud Tasks est conçu pour fournir une distribution de type "au moins une fois", c'est-à-dire que si une tâche est ajoutée avec succès, la file d'attente la distribuera au moins une fois. Dans de rares cas, l'exécution de plusieurs tâches est possible. Votre code doit donc garantir l'absence d'effets secondaires néfastes d'une exécution répétée. Vos gestionnaires doivent être idempotents.

Les tâches elles-mêmes sont composées d'un nom unique et d'informations de configuration, et éventuellement de toutes les données de la requête initiale, appelées charge utile, nécessaires au traitement de la requête. Lorsque la charge utile est envoyée dans le corps de la requête, les tâches qui incluent des charges utiles doivent utiliser la méthode POST ou PUT.

Pour accéder au service Cloud Tasks à l'aide de l'API Cloud Tasks , vous devez disposer d'un projet Google Cloud.

Cas d'utilisation

Vous trouverez ci-dessous des cas d'utilisation types :

• Accélération des temps de réponse des utilisateurs en déléguant à un nœud de calcul des opérations en arrière-plan potentiellement lentes, telles que des mises à jour de base de données
• Préservation des requêtes dans le contexte d'incidents de production inattendus
• Atténuation des pics de trafic en supprimant les tâches non destinées aux utilisateurs du parcours utilisateur principal
• Gestion des taux d'appels d'API tierces

Files d'attente Cloud Tasks avec cibles HTTP

Dans le cas de cibles HTTP génériques, le service Cloud Tasks transfère la requête de tâche au nœud de calcul, situé à n'importe quel point de terminaison HTTP générique, en fonction de la configuration de la tâche. Selon la configuration de la tâche, ce point de terminaison peut se trouver sur Cloud Functions, Cloud Run, GKE, Compute Engine ou même un serveur Web sur site. Ces files d'attente distribuent les requêtes à un débit fiable et configurable. Elles garantissent une exécution sûre des tâches. Une fois celle-ci réussie, tous les nœuds de calcul doivent envoyer un code de réponse HTTP (200-299) au service Cloud Tasks avant l'expiration du délai par défaut de 10 minutes, avec une limite maximale de 30 minutes. Si une réponse différente est envoyée, ou si aucune réponse n'est transmise, la tâche est relancée.

La cible doit gérer les nœuds de calcul liés au trafic et les tâches de nettoyage une fois celles-ci terminées.

Si votre cible requiert une authentification, vous devez configurer deux comptes de service, un pour votre application (le client) et un pour la file d'attente elle-même. Les autorisations requises sont accordées aux deux comptes et un identifiant pour le compte de service client doit être inclus dans la requête de tâche. Pour en savoir plus, consultez la page Créer des tâches HTTP Target.

Files d'attente Cloud Tasks avec cibles App Engine

Cloud Tasks est compatible avec les environnements App Engine suivants:

• Environnements d'exécution de deuxième génération de l'environnement standard App Engine
• Environnement flexible App Engine

Les utilisateurs des environnements d'exécution de première génération App Engine qui utilisent actuellement l'API Task Queue peuvent migrer vers Cloud Tasks. Pour savoir comment procéder, consultez Migrer les anciens services groupés. Les utilisateurs d'environnements d'exécution de première génération App Engine qui n'utilisent pas le service de tâches intégré peuvent passer à des environnements d'exécution de deuxième génération pour utiliser Cloud Tasks.

Dans le cas des cibles App Engine, le service Cloud Tasks transfère également la requête de tâche au gestionnaire, mais ce nœud de calcul se trouve dans App Engine. Ainsi, toutes les files d'attente qui ciblent les gestionnaires App Engine doivent disposer d'une application App Engine. Les gestionnaires doivent s'exécuter dans la région d'exécution de l'application App Engine. Cette région sert également de paramètre LOCATION_ID pour vos requêtes Cloud Tasks.

Les tâches sont acheminées en fonction de la configuration de la tâche (ou, plus rarement, de la file d'attente elle-même). Les files d'attente envoient les requêtes à un débit fiable et configurable. Ils garantissent une exécution fiable des tâches : en cas de réussite, tous les nœuds de calcul doivent envoyer un code de réponse HTTP (200-299) au service Cloud Tasks, dans cette instance avant un délai basé sur le type de scaling de l'instance du service : 10 minutes pour le scaling automatique ou jusqu'à 24 heures pour le scaling manuel. Si une réponse différente est envoyée, ou qu'aucune réponse n'est envoyée, la tâche est relancée.

Étant donné que les gestionnaires font partie d'App Engine, le service Cloud Tasks assure en grande partie la gestion des processus de la tâche, en effectuant un scaling des nœuds de calcul à la hausse ou à la baisse par rapport au trafic et la suppression des tâches une fois qu'elles sont terminées.

Remarque :Deux emplacements App Engine, appelés europe-west et us-central dans les commandes App Engine, sont appelés respectivement europe-west1 et us-central1 dans les commandes Cloud Tasks.

Régions acceptées par cible

Si votre cible est un point de terminaison HTTP/S, Cloud Tasks est disponible dans toutes les régions Google Cloud compatibles avec Cloud Tasks.

Si votre cible est une application App Engine située dans votre projet actuel:

• Une tâche ciblant App Engine ne peut être créée que dans la région App Engine du projet.

• Un projet Google Cloud ne peut contenir qu'une seule application App Engine, et la région dans laquelle elle se trouve ne peut plus être modifiée une fois l'application créée.

• App Engine est régional, ce qui signifie que l'infrastructure qui exécute votre application est située dans une région spécifique. Si vous souhaitez répartir le calcul et les files d'attente sur plusieurs régions, ciblez plutôt un point de terminaison HTTP/S.

• Si vous n'utilisez pas App Engine en tant que cible, vous n'avez pas besoin de déployer une application App Engine et vous pouvez désactiver toute application App Engine existante.

Workflows

Voici le workflow général :

1. Vous créez un nœud de calcul pour traiter les tâches.
2. Vous créez une file d'attente.
3. Vous créez des tâches par programmation et les ajoutez à la file d'attente.
4. Le service Cloud Tasks renvoie un code d'état "OK" à l'application d'origine. Cela indique que la tâche a bien été écrite dans l'espace de stockage Cloud Tasks. La requête de création de tâche devient ainsi hautement disponible et durable.
5. Les tâches sont transmises au nœud de calcul.
6. Le nœud de calcul traite la tâche.
7. Pour terminer la séquence, le nœud de calcul renvoie un code d'état de réussite 2xx au service Cloud Tasks.

Une fois la tâche transférée à la file d'attente, aucune donnée n'est mise à la disposition de la requête initiale.

Remarque : L'API Cloud Tasks fournit une interface vers le service de file d'attente de tâches App Engine, indépendante d'App Engine. Les files d'attente accessibles à l'aide du SDK App Engine sont également accessibles à partir de l'API Cloud Tasks, et inversement.

Fonctionnalités

Cloud Tasks vous permet d'envoyer des éléments de travail asynchrones avec les contrôles suivants :

• Planifier des délais de distribution spécifiques
• Gérer les rythmes de distribution
• Configurer le comportement des nouvelles tentatives
• Accéder à des tâches individuelles et les gérer dans une file d'attente
• Activer la déduplication des tâches

Conditions d'utilisation

Le tableau suivant répertorie les termes clés décrivant certains aspects du comportement de Cloud Tasks.

Terme	Définition
File d'attente	Ensemble de tâches ayant le même type de cible, géré par une configuration unique.
Type de cible	Où et comment une tâche est traitée.
Nœud de calcul	Service qui traite des tâches.
Tentative	Tentative d'exécution d'une tâche.
Tentative d'envoi	Moment où Cloud Tasks a envoyé la tâche à sa cible.
Tentative de réponse	Réponse d'un nœud de calcul qui indique que le travail associé à la tâche a abouti ou a échoué.
réessayer	Tentatives multiples d'exécution d'une tâche. Le nombre de tentatives est défini via l'élément RetryConfig.
Limites de débit	Limites de débit pour une file d'attente.

Métriques

Les métriques Google Tasks prédéfinies suivantes sont disponibles à l'aide de Cloud Monitoring.

Type de métrique Nom à afficher Genre, type, unité	Description Libellés
api/request_count Requêtes API DELTA, INT64, 1	Nombre d'appels d'API Cloud Tasks. api_method : méthode API appelée (par exemple, "CreateTask"). response_code : code de réponse canonique sous forme de chaîne (par exemple, "ok").
queue/depth Profondeur de la file d'attente (BÊTA) GAUGE, INT64, 1	Nombre de tâches dans la file d'attente. Échantillonné toutes les 60 secondes. Après échantillonnage, les données ne sont pas visibles pendant un délai pouvant atteindre 120 secondes.
queue/task_attempt_count Nombre de tentatives de la tâche DELTA, INT64, 1	Nombre de tâches que la file d'attente a tenté de distribuer, réparties par code de réponse de tâche. response_code : code de réponse canonique sous forme de chaîne (par exemple, "ok").
queue/task_attempt_delays La tentative de tâche retarde DELTA, DISTRIBUTION, ms	Délai entre chaque heure de tentative planifiée et l'heure de tentative réelle.