Ce document explique comment configurer les nouvelles tentatives pour les fonctions Cloud Run basées sur des événements.
Comme décrit dans la section Événements de nouvelle tentative, lorsqu'une destination de message Pub/Sub ne peut pas accuser réception d'un message, la réponse Pub/Sub par défaut consiste à renvoyer le message avec un délai d'intervalle exponentiel entre les tentatives. Un intervalle exponentiel entre les tentatives vous permet d'ajouter des délais progressivement plus longs entre les nouvelles tentatives. Toutefois, ce comportement peut ne pas être celui que vous souhaitez pour votre implémentation particulière.
La propriété retries n'est pas implémentée sur la fonction elle-même, mais sur le déclencheur Eventarc qui l'appelle, ce qui offre plus de flexibilité. Cela signifie que pour les destinations Cloud Run (y compris les fonctions Cloud Run créées avec l'API Cloud Run Admin ou l'API Cloud Functions V2), vous pouvez configurer une seule tentative de livraison sans nouvelle tentative. Il s'agit de la configuration par défaut lorsque vous créez un déclencheur Eventarc dans la Google Cloud console à partir de la page Cloud Run. Pour en savoir plus, consultez Créer des déclencheurs avec Eventarc.
Pourquoi les fonctions basées sur des événements échouent-elles ?
Une fonction basée sur des événements peut échouer en raison d'erreurs générées dans le code même de la fonction. Voici quelques raisons possibles :
- La fonction contient un bug et l’environnement d'exécution renvoie une exception.
- La fonction ne peut pas atteindre de point de terminaison de service, ou bien elle dépasse le délai en essayant d'y parvenir.
- La fonction renvoie intentionnellement une exception (par exemple, lorsqu'un paramètre échoue à la validation).
- Une fonction Node.js renvoie une promesse refusée ou transmet à un rappel une valeur qui n'est pas
null. - Il peut arriver qu'une fonction se ferme prématurément en raison d'une erreur interne. Par défaut, cette fonction peut être relancée automatiquement ou non.
Dans tous les cas, la fonction cesse d'être exécutée et renvoie une erreur. Les déclencheurs d'événements qui génèrent les messages disposent de stratégies de nouvelle tentative que vous pouvez personnaliser pour répondre aux besoins de votre fonction.
Configurer la stratégie de nouvelle tentative
En fonction des besoins de votre fonction Cloud Run, vous pouvez configurer la stratégie de nouvelle tentative via la stratégie de nouvelle tentative d'abonnement Pub/Sub associée à votre déclencheur Eventarc. Cela vous permet de configurer n'importe quelle combinaison des éléments suivants :
- Réduire la fenêtre de nouvelle tentative de sept jours une durée qui peut aller jusqu'à 10 minutes seulement.
- Modifier le temps d'intervalle minimal et maximal pour la stratégie de nouvelle tentative avec intervalle exponentiel entre les tentatives.
- Modifier la stratégie de nouvelle tentative pour réessayer immédiatement.
- Configurer une file d'attente de lettres mortes.
- Définir un nombre maximal et minimal de tentatives de livraison.
Pour configurer la stratégie de nouvelle tentative, procédez comme suit :
- Écrivez une fonction HTTP.
- Utilisez l'API Pub/Sub pour créer un abonnement Pub/Sub, en spécifiant l'URL de la fonction en tant que cible.
Consultez la documentation Eventarc sur les nouvelles tentatives d'événements pour découvrir d'autres bonnes pratiques, par exemple comment rendre idempotentes les fonctions basées sur des événements qui peuvent être réessayées.
Consultez la documentation Pub/Sub sur la gestion des échecs pour en savoir plus sur la configuration directe de Pub/Sub.
Bonnes pratiques
Cette section décrit les bonnes pratiques relatives à l'utilisation de la répétition des tentatives.
Utiliser la répétition pour faire face aux erreurs temporaires
Votre fonction est relancée en continu tant que son exécution n'est pas réussie. Vous devez donc éliminer de votre code les erreurs permanentes telles que les bugs par le biais de tests. Ce n'est qu'après cette étape que vous pourrez activer la répétition des tentatives. La répétition des tentatives est particulièrement utile pour gérer les échecs intermittents/temporaires qui présentent une probabilité élevée de résolution à mesure des nouvelles tentatives, par exemple lorsqu'un point de terminaison de service ou un délai d’inactivité est instable.
Définir une condition de fin pour éviter les boucles infinies de répétition de tentatives
Il est recommandé de protéger votre fonction contre les boucles continues lors de l'utilisation de la répétition des tentatives. Pour ce faire, incluez une condition de fin bien définie avant le début du traitement de la fonction. Notez que cette technique ne fonctionne que si votre fonction démarre correctement et qu'elle est en mesure d'évaluer la condition de fin.
Une approche efficace consiste à ignorer les événements dont l'horodatage est antérieur à une certaine période. Cela permet d'éviter des exécutions excessives lorsque les échecs sont persistants ou plus longs que prévu.
Par exemple, l'extrait de code suivant supprime tous les événements de plus de dix secondes :
Node.js
Python
Go
Java
C#
Ruby
PHP
Distinguer les fonctions pouvant être réessayées des erreurs fatales
Si la répétition de tentatives est activée pour votre fonction, toute erreur non gérée déclenche une nouvelle tentative. Assurez-vous que votre code capture toutes les erreurs qui ne doivent pas entraîner de nouvelle tentative.
Node.js
Python
Go
Java
C#
Ruby
PHP
Étapes suivantes
- Déployer une fonction Cloud Run
- Créer des déclencheurs à partir d'événements Pub/Sub
- Créer des déclencheurs à partir d'événements Cloud Storage
- Déclencher des fonctions depuis Pub/Sub à l'aide d'Eventarc
- Déclencher des fonctions depuis Cloud Storage à l'aide d'Eventarc