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 livraison 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 l'ordre d'exécution. Il n'existe aucune garantie ni tentative d'optimisation pour exécuter des tâches dans un ordre particulier. Plus précisément, rien ne garantit que les anciennes tâches soient exécutées à moins qu'une file d'attente ne soit complètement vidée. Dans un certain nombre de cas courants, les tâches plus récentes sont exécutées plus tôt que les tâches plus anciennes, et les modèles qui en découlent peuvent changer sans préavis.
Délai d'exécution
Les exécutions Cloud Tasks peuvent parfois subir des retards mineurs, généralement de quelques minutes, en raison de redémarrages internes du système. Les tâches sont retardées, mais aucune n'est perdue. Il s'agit d'événements au niveau du système pour lesquels aucune solution de contournement n'existe. Ces événements ne sont pas consignés et leur occurrence n'est pas définie dans le temps.
Exécution en double
Cloud Tasks vise une sémantique stricte de type "exécution exactement une fois". Toutefois, dans les cas où un compromis doit être trouvé entre une exécution garantie et une 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. Vous devez vous assurer que les exécutions en double sont gérées correctement et qu'elles n'entraînent pas d'échecs inattendus. Dans un environnement de 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 ne pouvant traiter que 10 requêtes par seconde, une mise en attente de tâches est 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 d'intervalle entre les tentatives : 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 la surcharge du nœud de calcul. Notez que vos paramètres ne sont pas modifiés.
La limitation du système se produit dans les cas suivants :
Cloud Tasks effectue une interruption pour toutes les erreurs. Normalement, l'interruption spécifiée dans
rate_limitsest utilisée. Toutefois, si le nœud de calcul renvoie HTTP429 Too Many Requests,503 Service Unavailableou si le taux d'erreurs est élevé, Cloud Tasks utilise un taux d'interruption plus élevé. La nouvelle tentative spécifiée dans l'en-tête de réponse HTTPRetry-Afterest prise en compte.Pour éviter les pics de trafic et lisser les augmentations soudaines du trafic, les envois augmentent lentement lorsque la file d'attente est nouvellement créée ou inactive, et si un grand nombre de tâches deviennent soudainement disponibles pour l'envoi (en raison de pics dans les taux de création de tâches, de la reprise de la file d'attente ou de nombreuses tâches planifiées en même temps).
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 le
max_concurrent_dispatches
pour les files d'attente affectées peut être utile dans les cas où la valeur définie initialement était trop
faible, ce qui entraîne une limite de débit artificielle. Cependant, l'augmentation de max_concurrent_dispatches ne soulagera probablement pas la pression des ressources sous-jacentes.
Augmenter les problèmes de tâches de longue durée
Les files d'attente Cloud Tasks augmentent en partie leur sortie en fonction du nombre de tâches envoyées précédemment. Si le gestionnaire de tâches prend beaucoup de temps (de l'ordre de quelques minutes) pour terminer une tâche et renvoyer une réponse positive, il peut y avoir un décalage dans le taux d'augmentation de la file d'attente.
Afficher plus de 5 000 tâches
Si vous avez plus de 5 000 tâches, certaines ne sont pas visibles dans la Google Cloud console. 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. Cette limite vise à 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 continueront de s'exécuter comme prévu.
Pour récupérer la profondeur actuelle de la file d'attente au-delà de 1 000 000 de tâches, vous pouvez utiliser la
queues.tasks.list méthode.
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, en fonction de 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
Si vous supprimez une file d'attente de la Google Cloud console, vous devez attendre trois jours avant de la recréer avec le même nom. Cette période d'attente permet d'éviter tout comportement inattendu dans les tâches en cours d'exécution au moment de la suppression ou en attente d'exécution. Elle permet également d'éviter les échecs de processus internes lors du cycle de suppression ou de recréation.
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 le 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 d'emplacement des ressources
Cloud Tasks permet de limiter les emplacements des ressources . Toutefois, des limites s'appliquent aux régions suivantes :
us-central1us-central2(privé Google Cloud région)
Si vous spécifiez l'une de ces régions dans la règle de votre organisation, vous devez inclure 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 la règle de votre organisation, même si votre organisation n'utilise pas de régions privées.