Cloud Tasks vous permet de gérer l'exécution des tâches en définissant le routage, les limites de débit d'envoi et le comportement des nouvelles tentatives au niveau de la file d'attente. Vous pouvez configurer ces paramètres lors de la création d'une file d'attente ou de la mise à jour d'une file d'attente existante.
gcloud tasks queues create et gcloud tasks queues update utilisent les mêmes options pour définir les paramètres de file d'attente, tandis que gcloud tasks queues update accepte également les options --clear-* pour rétablir les paramètres par défaut.
La configuration de l'authentification au niveau de la file d'attente remplace l'authentification au niveau de la tâche. Pour en savoir plus, consultez Utiliser des tâches HTTP Target avec des jetons d'authentification.
Configurer le routage au niveau de la file d'attente
La configuration du routage au niveau de la file d'attente remplace le routage défini au niveau de la tâche. Cela est utile si vous souhaitez utiliser Cloud Tasks comme tampon devant votre service cible ou si vous devez modifier le routage de toutes les tâches d'une file d'attente.
Le routage au niveau de la file d'attente s'applique aux éléments suivants :
- Tâches dans la file d'attente
- Tâches ajoutées à la file d'attente après la configuration du routage au niveau de la file d'attente
Limites
Le routage au niveau de la file d'attente n'est pas compatible avec les clés de chiffrement gérées par le client (CMEK) de Cloud Key Management Service (Cloud KMS). Si CMEK est activé, vous ne pouvez pas effectuer les opérations suivantes :
- Créer des tâches dans une file d'attente avec routage au niveau de la file d'attente
- Appliquer le routage au niveau de la file d'attente
Configurer le routage au niveau de la file d'attente pour les tâches HTTP
Vous pouvez configurer une file d'attente pour remplacer le routage au niveau de la tâche lors de la création ou de la mise à jour de la file d'attente. Pour configurer le routage au niveau de la file d'attente, définissez le paramètre uriOverride de la file d'attente sur la route de votre choix. Par défaut (uriOverrideEnforceMode défini sur ALWAYS), le routage au niveau de la file d'attente remplace le routage au niveau de la tâche. Vous pouvez également définir uriOverrideEnforceMode sur IF_NOT_EXISTS afin que le routage au niveau de la file d'attente ne s'applique que lorsqu'une tâche ne spécifie pas ses propres composants d'URI.
Si vous appliquez le routage au niveau de la file d'attente en tant que mise à jour d'une file d'attente existante, suspendez la file d'attente avant d'appliquer les modifications et attendez une minute après avoir appliqué les modifications pour reprendre la file d'attente.
Mettez la file d'attente en pause en exécutant la commande suivante :
gcloud tasks queues pause QUEUE_ID \ --location=LOCATION
Remplacez les éléments suivants :
QUEUE_ID: ID de votre file d'attente.LOCATION: emplacement de votre file d'attente.
Mettre à jour ou supprimer le routage au niveau de la file d'attente.
Pour mettre à jour le routage au niveau de la file d'attente, définissez le paramètre
uriOverridesur votre route mise à jour (ou transmettez l'option--http-uri-overrideàgcloud tasks queues update).Pour supprimer le routage au niveau de la file d'attente :
- Google Cloud CLI : exécutez
gcloud tasks queues updateavec l'option--clear-http-uri-override:
gcloud tasks queues update QUEUE_ID \ --location=LOCATION \ --clear-http-uri-override
API REST : envoyez une requête
patchpour la file d'attente avec un objet JSON vide ({}) et le paramètre de requêteupdateMaskdéfini surhttpTarget.uriOverride(ouhttpTargetpour effacer tous les paramètres de cible HTTP au niveau de la file d'attente).API RPC : envoyez une requête
UpdateQueueRequestpourQueueavecqueue.namespécifié,http_target.uri_overridenon défini et le paramètreupdate_maskdéfini surhttp_target.uri_override(ouhttp_targetpour effacer tous les paramètres de cible HTTP au niveau de la file d'attente).
- Google Cloud CLI : exécutez
L'exemple suivant utilise l'API REST pour mettre à jour l'hôte vers lequel les tâches sont acheminées :
curl -X PATCH -d @- -i \ -H "Authorization: Bearer ACCESS_TOKEN" \ -H "Content-Type: application/json" \ "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID?updateMask=httpTarget.uriOverride" << EOF { "httpTarget": {"uriOverride":{"host":"NEW_HOST"}} } EOFRemplacez les éléments suivants :
ACCESS_TOKEN: votre jeton d'accès. Pour l'obtenir, exécutez la commande suivante dans votre terminal :gcloud auth application-default login gcloud auth application-default print-access-token
PROJECT_ID: ID de votre projet Google Cloud . Pour l'obtenir, exécutez la commande suivante dans votre terminal :gcloud config get-value project
LOCATION: emplacement de votre file d'attente.NEW_HOST: nouvel hôte vers lequel vous souhaitez que votre file d'attente soit acheminée.
Patientez une minute.
L'application de la nouvelle configuration peut prendre jusqu'à une minute. Attendre avant de reprendre la file d'attente permet d'éviter que les tâches ne soient distribuées avec l'ancienne configuration.
Réactivez la file d'attente en exécutant la commande suivante :
gcloud tasks queues resume QUEUE_ID \ --location=LOCATION
Vérifiez que votre file d'attente a bien été configurée en exécutant la commande suivante :
gcloud tasks queues describe QUEUE_ID \ --location=LOCATION
Le résultat doit contenir le remplacement de routage
httpTargetque vous avez défini.
Configurer le routage au niveau de la file d'attente pour les tâches App Engine
Pour configurer le routage au niveau de la file d'attente pour les tâches App Engine, définissez le paramètre appEngineRoutingOverride de la file d'attente sur le service et la version App Engine de votre choix.
Configurez le routage au niveau de la file d'attente et remplacez tout routage au niveau de la tâche :
gcloud tasks queues update QUEUE_ID \ --location=LOCATION \ --routing-override=service:SERVICE,version:VERSION
Remplacez les éléments suivants :
QUEUE_ID: ID de la file d'attente (son nom court).LOCATION: emplacement de la file d'attente.SERVICE: service de nœud de calcul App Engine responsable de la gestion des tâches.VERSION: version de l'application.
Par exemple, si vous configurez un service de nœud de calcul pour gérer toutes les tâches d'une file d'attente, vous pouvez acheminer le trafic vers ce service et la version par défaut :
gcloud tasks queues update QUEUE_ID \ --location=LOCATION \ --routing-override=service:SERVICE
Vérifiez que votre file d'attente a bien été configurée en exécutant la commande suivante :
gcloud tasks queues describe QUEUE_ID \ --location=LOCATION
La sortie devrait ressembler à ce qui suit :
appEngineRoutingOverride: host: SERVICE.PROJECT_ID.appspot.com service: SERVICE name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID rateLimits: maxBurstSize: 100 maxConcurrentDispatches: 1000 maxDispatchesPerSecond: 500.0 retryConfig: maxAttempts: 100 maxBackoff: 3600s maxDoublings: 16 minBackoff: 0.100s state: RUNNING
Pour supprimer le routage au niveau de la file d'attente, exécutez la commande suivante :
gcloud tasks queues update QUEUE_ID \ --location=LOCATION \ --clear-routing-override
Lorsque le routage au niveau de la file d'attente est supprimé, le routage au niveau de la tâche est appliqué aux tâches de la file d'attente et aux tâches ajoutées à la file d'attente à l'avenir.
Définir des limites de débit
La limite de débit détermine le débit maximal en régime permanent auquel les tâches peuvent être distribuées par une file d'attente active, qu'il s'agisse d'une première tentative ou d'un nouvel essai.
Définissez le taux maximal et le nombre de tâches simultanées pouvant être distribuées par une file d'attente en exécutant la commande suivante :
gcloud tasks queues update QUEUE_ID \ --location=LOCATION \ --max-dispatches-per-second=DISPATCH_RATE \ --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
Remplacez les éléments suivants :
QUEUE_ID: ID de la file d'attente (son nom court).LOCATION: emplacement de la file d'attente.DISPATCH_RATE: taux de distribution. Il s'agit de la fréquence à laquelle les jetons du bucket sont actualisés. Dans des conditions où le flux de tâches est relativement stable, cela équivaut au taux d'envoi des tâches.MAX_CONCURRENT_DISPATCHES: nombre maximal de tâches de la file d'attente pouvant être exécutées simultanément.
Par exemple, si vous avez créé une file d'attente sans définir de paramètres, vous pouvez mettre à jour le nombre maximal de tâches simultanées en exécutant la commande suivante :
gcloud tasks queues update QUEUE_ID \ --location=LOCATION \ --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
Vérifiez que votre file d'attente a bien été configurée en exécutant la commande suivante :
gcloud tasks queues describe QUEUE_ID \ --location=LOCATION
La sortie devrait ressembler à ce qui suit :
name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID rateLimits: maxBurstSize: 100 maxConcurrentDispatches: MAX_CONCURRENT_DISPATCHES maxDispatchesPerSecond: DISPATCH_RATE retryConfig: maxAttempts: 100 maxBackoff: 3600s maxDoublings: 16 minBackoff: 0.100s state: RUNNING
Méthodes pour définir les taux de traitement des files d'attente
Vous pouvez définir les taux de traitement des files d'attente à l'aide de l'API Cloud Tasks ou en important un fichier queue.yaml. Les deux méthodes génèrent des files d'attente qui utilisent le même mécanisme sous-jacent.
Dans les deux cas, la file d'attente utilise l'algorithme token bucket pour contrôler le taux d'exécution des tâches. Chaque file d'attente nommée possède un bucket qui contient ses jetons.
Chaque fois que l'application exécute une tâche, un jeton est supprimé du bucket.
La file d'attente continue de traiter les tâches jusqu'à ce que son bucket n'ait plus de jetons. Le système remplit le bucket de nouveaux jetons de manière continue en fonction du taux max_dispatches_per_second que vous spécifiez pour la file d'attente. Si la file d'attente contient des tâches à traiter et que son bucket contient des jetons, le système traite simultanément autant de tâches qu'il y a de jetons, jusqu'à la valeur max_concurrent_dispatches que vous avez définie.
Sur une file d'attente active déjà préchauffée, une charge inégale peut entraîner une augmentation significative du nombre de jetons dans le bucket, ce qui peut entraîner des pics de traitement lorsqu'un pic de requêtes se produit. Dans ce cas, une file d'attente active peut connaître un taux de distribution réel qui dépasse temporairement votre taux max_dispatches_per_second, ce qui consomme des ressources système et concurrence les requêtes servant les utilisateurs. Si vous utilisez des files d'attente pour gérer les taux de distribution en fonction de contrats de niveau de service relativement lents pour les services en aval, ces pics peuvent entraîner des erreurs telles que HTTP 429 (Too Many Requests) ou HTTP 503 (Service Unavailable). Toutefois, si une file d'attente est nouvellement créée, récemment reprise ou inactive pendant plusieurs minutes, elle passe à l'état froid ou inactif et augmente progressivement vers max_dispatches_per_second au lieu de monter en flèche immédiatement. Pour en savoir plus sur la montée en puissance d'une file d'attente froide ou inactive, consultez Montée en puissance initiale de la file d'attente.
Lorsque vous utilisez une méthode de l'API Cloud Tasks, vous disposez de deux champs pour définir le taux de distribution de la file d'attente :
max_dispatches_per_secondmax_concurrent_dispatches
Un troisième champ,
max_burst_size, est calculé par le système en fonction de la valeur que vous définissez pourmax_dispatches_per_second. Pour en savoir plus, consultez MessagesRateLimits.Lorsque vous utilisez la méthode
queue.yaml, vous pouvez définir les trois éléments :max_concurrent_requests, qui équivaut àmax_concurrent_dispatchesrate, qui équivaut àmax_dispatches_per_secondbucket_size, qui équivaut àmax_burst_size
Dans la plupart des cas, l'utilisation de la méthode de l'API Cloud Tasks et la définition de max_burst_size par le système permettent d'obtenir un débit très efficace pour gérer les pics de requêtes.
Toutefois, dans certains cas, en particulier lorsque le débit nécessaire est relativement faible, vous pouvez utiliser la méthode queue.yaml pour définir manuellement bucket_size sur une valeur faible, ou définir votre max_concurrent_dispatches sur une valeur faible à l'aide de l'API Cloud Tasks, ce qui peut vous donner plus de contrôle.
Définir les paramètres de nouvelle tentative
Si une tâche ne s'exécute pas correctement, Cloud Tasks la relance avec un intervalle exponentiel entre les tentatives, en fonction des paramètres que vous avez définis. Une fois qu'une tâche s'est exécutée correctement, elle est supprimée de la file d'attente. Dans tous les cas, la limite de conservation maximale des tâches s'applique également.
Vous pouvez éventuellement spécifier une configuration de nouvelle tentative au niveau de la tâche qui remplace la configuration de nouvelle tentative au niveau de la file d'attente pour la tâche. Pour en savoir plus, consultez Définir les paramètres de nouvelle tentative pour une tâche.
Spécifiez le nombre maximal de tentatives pour les tâches ayant échoué dans la file d'attente, définissez une limite de temps pour les nouvelles tentatives et contrôlez l'intervalle entre les tentatives en exécutant la commande suivante :
gcloud tasks queues update QUEUE_ID \ --location=LOCATION \ --max-attempts=MAX_ATTEMPTS \ --max-retry-duration=MAX_RETRY_DURATION \ --min-backoff=MIN_INTERVAL \ --max-backoff=MAX_INTERVAL \ --max-doublings=MAX_DOUBLINGS
Remplacez les éléments suivants :
QUEUE_ID: ID de la file d'attente (son nom court).LOCATION: emplacement de la file d'attente.MAX_ATTEMPTS: nombre maximal de tentatives pour une tâche, y compris la première. Pour autoriser un nombre illimité de nouvelles tentatives, définissez cette valeur sur-1.MAX_RETRY_DURATIONs'applique toujours même siMAX_ATTEMPTSest atteint ou défini sur-1.MAX_RETRY_DURATION: délai maximal d'une nouvelle tentative d'exécution d'une tâche ayant échoué, mesuré à partir de la première tentative d'exécution de la tâche. La valeur doit être une chaîne se terminant par "s", par exemple5s. Pour spécifier une durée illimitée, définissez cette valeur sur0s.MAX_ATTEMPTSs'applique toujours, même siMAX_RETRY_DURATIONest atteint ou défini sur0s.
MIN_INTERVAL: délai d'attente minimal entre les tentatives. La valeur doit être une chaîne se terminant par "s", par exemple5s.MAX_INTERVAL: délai maximal d'attente entre les tentatives. La valeur doit être une chaîne se terminant par "s", par exemple5s.MAX_DOUBLINGS: nombre maximal de fois où l'intervalle entre les tentatives d'exécution de tâches ayant échoué est doublé avant que l'augmentation ne devienne constante. L'intervalle entre les tentatives d'une tâche commence àMIN_INTERVAL, puis doubleMAX_DOUBLINGSfois, puis augmente de manière linéaire, et enfin, les tentatives sont effectuées à des intervalles deMAX_INTERVALjusqu'àMAX_ATTEMPTSfois.Par exemple, si
MIN_INTERVALest défini sur10s,MAX_INTERVALsur300setMAX_DOUBLINGSsur3, l'intervalle entre les tentatives est doublé3fois, augmente de manière linéaire de 2^3 * 10 s, puis les tentatives sont relancées à des intervalles deMAX_INTERVALjusqu'à ce que la tâche ait été tentéeMAX_ATTEMPTSfois : 10 s, 20 s, 40 s, 80 s, 160 s, 240 s, 300 s, 300 s, etc.
Pour en savoir plus sur les paramètres, consultez la documentation de référence sur la ressource RetryConfig.
Vérifiez que votre file d'attente a bien été configurée en exécutant la commande suivante :
gcloud tasks queues describe QUEUE_ID \ --location=LOCATION
La sortie doit contenir les paramètres
retryConfigque vous avez définis :retryConfig: maxAttempts: MAX_ATTEMPTS maxBackoff: MAX_INTERVAL maxDoublings: MAX_DOUBLINGS maxRetryDuration: MAX_RETRY_DURATION minBackoff: MIN_INTERVAL
Étapes suivantes
- Découvrez comment créer des tâches de cible HTTP.
- Découvrez comment créer des tâches App Engine.
- Pour en savoir plus sur la gestion des files d'attente, consultez la documentation de référence de l'API RPC.
- Pour en savoir plus sur la gestion des files d'attente, consultez la documentation de référence de l'API REST.