Cloud Tasks vous permet de créer des systèmes asynchrones résilients lorsque vous concevez des comportements d'exécution de file d'attente et des limites de service spécifiques. Vous pouvez éviter les goulots d'étranglement et les retards inattendus en tenant compte de la distribution "au moins une fois", de la limitation du système et de la capacité des ressources cibles.
Ordre d'exécution
À l'exception des tâches planifiées pour une exécution ultérieure, les files d'attente de tâches sont totalement indépendantes de la plate-forme en ce qui concerne l'ordre d'exécution. Aucune garantie ni tentative d'effort n'est faite pour exécuter les tâches dans un ordre particulier. Plus précisément, rien ne garantit que les anciennes tâches seront exécutées, sauf si une file d'attente est complètement vidée. Il existe un certain nombre de cas courants où les tâches les plus récentes sont exécutées plus tôt que les tâches plus anciennes, et les modèles qui entourent ce phénomène peuvent changer sans préavis.
Délai d'exécution
Les exécutions Cloud Tasks peuvent parfois subir des retards mineurs, qui durent généralement quelques minutes, en raison de redémarrages du système interne. Les tâches sont retardées, mais aucune n'est perdue. Il s'agit d'événements au niveau du système pour lesquels il n'existe aucune solution de contournement. Ces événements ne sont pas consignés et leur occurrence n'a pas de calendrier défini.
Exécution en double
Cloud Tasks vise une sémantique stricte de type "exécution exactement une fois". Toutefois, dans les situations où un compromis de conception doit être fait entre l'exécution garantie et l'exécution en double, le service privilégie l'exécution garantie. Ainsi, un nombre d'exécutions en double supérieur à zéro se produit. Assurez-vous que votre application gère correctement les exécutions en double afin qu'elles ne provoquent pas d'échecs inattendus. En production, plus de 99,999 % des tâches ne sont exécutées qu'une seule fois.
Limites des ressources
La source la plus courante de mise en attente de tâches dans les files d'attente de traitement immédiat est l'épuisement des ressources sur les instances cibles. Si vous tentez d'exécuter 100 tâches par seconde sur des instances frontend qui ne peuvent traiter que 10 requêtes par seconde, un backlog se crée. Cela se manifeste généralement de deux manières, qui peuvent toutes deux être résolues en augmentant le nombre d'instances traitant les requêtes.
Erreurs liées à l'intervalle entre les tentatives et taux appliqués
Les serveurs surchargés peuvent commencer à renvoyer des erreurs de backoff : HTTP 503 (pour les cibles App Engine), ou HTTP 429 ou 5xx (pour les cibles externes).
Cloud Tasks réagit à ces erreurs en ralentissant l'exécution jusqu'à ce que les erreurs cessent. Cette limitation du système empêche le worker d'être surchargé. Vos paramètres ne sont pas modifiés.
La limitation du système se produit dans les cas suivants :
Cloud Tasks effectue un intervalle exponentiel entre les tentatives pour toutes les erreurs. Normalement, Cloud Tasks utilise le délai d'intervalle entre les tentatives spécifié dans
retry_config. Toutefois, si le nœud de calcul renvoie des réponses d'erreur HTTP429 Too Many Requests,503 Service Unavailableou5xx, ou si le taux d'erreur est élevé, Cloud Tasks applique un taux de distribution inférieur et prend en compte le délai avant nouvelle tentative spécifié dans l'en-tête de réponse HTTPRetry-After. Une fois que les erreurs cessent et que les gestionnaires cibles renvoient des réponses HTTP2xx, la file d'attente augmente progressivement son taux de distribution appliqué.Pour éviter les pics de trafic et lisser les augmentations soudaines de charge, Cloud Tasks augmente progressivement les envois lorsqu'une file d'attente vient d'être créée, qu'elle reprend après avoir été suspendue ou qu'elle est inactive après quelques minutes sans envoi actif. Cette augmentation se produit également lorsqu'un grand nombre de tâches devient soudainement disponible pour la distribution, par exemple lors de pics de création de tâches ou lorsque de nombreuses tâches sont planifiées en même temps. À partir d'un état froid ou inactif, Cloud Tasks commence à distribuer les tâches à un taux de référence faible, puis augmente progressivement le taux de distribution appliqué à des intervalles d'évaluation périodiques. Le débit continue d'augmenter jusqu'au débit
max_dispatches_per_secondconfiguré tant que la demande de file d'attente reste saturée et que les gestionnaires cibles renvoient des réponses HTTP2xx. Pour en savoir plus sur l'activation progressive à froid ou inactive et sur la gestion des files d'attente réactivées, consultez Activation progressive initiale de la file d'attente et Surcharge de la cible.
Pics de latence et nombre maximal de tâches simultanées
Les serveurs surchargés peuvent également réagir en augmentant fortement la latence.
Dans cette situation, les requêtes restent ouvertes plus longtemps. Étant donné que les files d'attente s'exécutent avec un nombre maximal de tâches simultanées, elles peuvent ne pas être en mesure d'exécuter les tâches au débit prévu. Augmenter la valeur max_concurrent_dispatches pour les files d'attente concernées peut être utile lorsque la valeur a été définie trop bas, ce qui introduit une limite de débit artificielle. Toutefois, l'augmentation de max_concurrent_dispatches ne soulagera probablement pas la pression sur les ressources sous-jacentes.
Problèmes de montée en puissance avec les tâches de longue durée
Les files d'attente Cloud Tasks augmentent leur débit en partie en fonction du nombre de tâches précédemment distribuées avec succès. Si le gestionnaire de tâches prend un certain temps (de l'ordre de quelques minutes) pour effectuer une tâche et renvoyer une réponse de réussite, il peut y avoir un décalage dans le taux de montée en puissance de la file d'attente.
Affichage de plus de 5 000 tâches
Si vous avez plus de 5 000 tâches, certaines ne sont pas visibles dans la consoleGoogle Cloud . Utilisez la gcloud CLI pour afficher toutes les tâches.
Métrique de profondeur maximale de la file d'attente signalée
La métrique de profondeur maximale de la file d'attente signalée par Cloud Tasks est limitée à 1 000 000 de tâches. Cela permet d'améliorer les performances des nœuds de calcul de tâches sous-jacents et n'a aucune incidence sur le nombre de tâches pouvant être envoyées à votre file d'attente ou traitées par celle-ci. Les tâches envoyées à la file d'attente au-delà de la limite de profondeur de la file d'attente continuent de s'exécuter comme prévu.
Pour récupérer la profondeur de file d'attente actuelle au-delà de 1 000 000 de tâches, vous pouvez utiliser la méthode queues.tasks.list.
Cette méthode renvoie toutes les tâches avec pagination, ce qui vous permet d'agréger les données et d'effectuer une opération de comptage. Toutefois, selon la taille de la profondeur de la file d'attente, la méthode peut rencontrer des restrictions de quota.
Recréer une file d'attente portant le même nom
La suppression d'une file d'attente supprime définitivement et de manière irréversible toutes les tâches de la file d'attente, y compris les tâches planifiées et les tâches en attente d'exécution ou de nouvelle tentative. Ni vous, ni Cloud Customer Care ne pouvez récupérer des files d'attente ou des tâches supprimées.
Après avoir supprimé une file d'attente, vous devez attendre trois jours avant de la recréer avec le même nom. Ce délai d'attente évite tout comportement inattendu dans les tâches en cours d'exécution au moment de la suppression, ainsi que les échecs de processus internes pendant le cycle de suppression et de recréation. Le délai d'attente s'applique aux files d'attente supprimées via n'importe quelle interface, y compris la console Google Cloud , la gcloud CLI, l'API REST ou RPC, ou Terraform.
Pendant cette période de suppression définitive (jusqu'à trois jours), une requête de création de file d'attente peut sembler aboutir sans recréer la file d'attente, et l'importation d'un fichier queue.yaml incluant le nom de la file d'attente supprimée peut échouer. Pour vérifier qu'une file d'attente portant le même nom a été recréée, récupérez-la à l'aide de la commande gcloud tasks queues describe ou de la méthode projects.locations.queues.get. Une réponse positive (200 OK) confirme que la file d'attente a été recréée.
Pour effacer des tâches ou modifier une file d'attente sans la perdre ni déclencher le délai d'attente de 3 jours, supprimez définitivement toutes les tâches de la file d'attente, mettez à jour la file d'attente en place ou mettez en pause la file d'attente au lieu de la supprimer et de la recréer. Si vous gérez des files d'attente avec Terraform, définissez prevent_destroy = true dans le bloc lifecycle pour éviter toute suppression accidentelle de file d'attente.
Cible non compatible lors de l'utilisation d'un périmètre sécurisé
Si vous avez configuré un périmètre sécurisé à l'aide de VPC Service Controls, les requêtes HTTP provenant d'une exécution Cloud Tasks sont bloquées pour les cibles non compatibles et échouent avec un code d'erreur TARGET_TYPE_NOT_PERMITTED_FOR_VPC. Pour en savoir plus, consultez Configurer un périmètre de service à l'aide de VPC Service Controls.
Contraintes liées aux emplacements des ressources
Cloud Tasks permet de restreindre les emplacements des ressources. Toutefois, des limites s'appliquent aux régions suivantes :
us-central1us-central2(région Google Cloud privée)
Si vous spécifiez l'une ou l'autre de ces régions dans votre règle d'administration, vous devez inclure à la fois us-central1 et us-central2, même si vous ne créez pas de ressources Cloud Tasks dans les deux régions. Vous pouvez inclure la région us-central2 dans votre règle d'administration même si votre organisation n'utilise pas de régions privées.