Événements de nouvelle tentative

Un événement peut être rejeté pour plusieurs raisons. Par exemple, le service de réception d'événements peut être temporairement indisponible en raison d'une panne, une erreur peut être rencontrée par le service lors du traitement d'un événement ou les ressources du service peuvent être épuisées. Les erreurs temporaires de ce type peuvent être relancées.

Un événement peut également ne pas être distribué au récepteur d'événements. Par exemple, l'événement peut ne pas correspondre au schéma attendu configuré, ou la médiation de l'événement peut échouer avant que le message d'événement puisse être acheminé vers sa destination finale. Dans ce cas, des erreurs persistantes se produisent.

Erreurs temporaires

Eventarc Advanced vous permet de gérer les erreurs temporaires. Ces erreurs temporaires peuvent être relancées et incluent celles avec les codes d'erreur suivants :

  • HTTP 408 Request Timeout
  • HTTP 409 Conflict
  • HTTP 429 Too Many Requests
  • HTTP 500 Internal Server Error
  • HTTP 502 Bad Gateway
  • HTTP 503 Service Unavailable
  • HTTP 504 Gateway Time-out

Erreurs persistantes

Contrairement aux erreurs temporaires, les erreurs persistantes incluent les éléments suivants :

  • Erreurs qui se produisent lorsque le nombre de nouvelles tentatives configuré est épuisé
  • Erreurs qui se produisent lorsqu'un événement échoue avant de pouvoir être acheminé vers sa destination
  • Erreurs qui entraînent un code d'erreur considéré comme non relançable, par exemple, des codes d'erreur autres que ceux listés pour les erreurs temporaires

Vous pouvez identifier manuellement les erreurs persistantes et les gérer de manière appropriée.

Relancer les erreurs temporaires

Eventarc Advanced utilise un intervalle exponentiel entre les tentatives pour gérer les erreurs pouvant faire l'objet d'une nouvelle tentative. La règle de nouvelle tentative par défaut commence par un délai d'une seconde, qui est doublé après chaque tentative infructueuse (jusqu'à un maximum de 60 secondes et cinq tentatives).

Vous pouvez modifier la règle de nouvelle tentative par défaut à l'aide de la Google Cloud console ou de la gcloud eventarc pipelines update commande.

Notez que le facteur d'intervalle par défaut de 2 ne peut pas être modifié.

Console

  1. Dans la Google Cloud console, accédez à la page Eventarc > Pipelines.

    Accéder à la page Pipelines

  2. Cliquez sur le nom du pipeline.

  3. Sur la page Détails du pipeline, cliquez sur Modifier.

  4. Sur la page Modifier le pipeline, dans la section Règle de nouvelle tentative, modifiez les champs suivants :

    • Nombre maximal de tentatives : nombre de tentatives de distribution. La valeur par défaut est de 5 tentatives. Peut être n'importe quel entier positif. Si la valeur est définie sur 1, aucune règle de nouvelle tentative n'est appliquée et une seule tentative est effectuée pour distribuer un message.
    • Délai minimal (en secondes) : délai initial en secondes. La valeur par défaut est de 1 seconde. Doit être compris entre 1 et 600.
    • Délai maximal (en secondes) : délai maximal en secondes. La valeur par défaut est de 60 secondes. Doit être compris entre 1 et 600.

    Vous pouvez configurer un intervalle linéaire entre les tentatives en définissant les délais minimal et maximal sur la même valeur.

  5. Cliquez sur Enregistrer.

gcloud 

gcloud eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

Remplacez les éléments suivants :

  • PIPELINE_NAME: ID ou identifiant complet du pipeline.
  • MIN_DELAY: délai initial en secondes. La valeur par défaut est de 1 seconde. Doit être compris entre 1 et 600.
  • MAX_DELAY: délai maximal en secondes. La valeur par défaut est de 60 secondes. Doit être compris entre 1 et 600.
  • MAX_ATTEMPTS: nombre de tentatives de distribution. La valeur par défaut est de 5 tentatives. Peut être n'importe quel entier positif. Si la valeur est définie sur 1, aucune règle de nouvelle tentative n'est appliquée et une seule tentative est effectuée pour distribuer un message.

L'exemple suivant configure un intervalle linéaire entre les tentatives en définissant les délais minimal et maximal sur la même valeur :

gcloud eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

Archiver les messages pour gérer les erreurs persistantes

Vous pouvez écrire des messages dans une table BigQuery à mesure qu'ils sont reçus. Cela vous permet d'identifier manuellement les erreurs persistantes et de les gérer de manière appropriée.

Vous trouverez ci-dessous une présentation des étapes nécessaires pour archiver vos messages d'événement, identifier les erreurs persistantes et relancer les événements concernés.

  1. Créez un bus. Configurez le bus de manière appropriée, par exemple pour publier des événements provenant de sources Google.
  2. Créez un sujet Pub/Sub. Ce sujet Pub/Sub sera la destination cible de votre pipeline.
  3. Créez un abonnement BigQuery pour le sujet Pub/Sub. Un abonnement BigQuery est un type d'abonnement d'exportation qui écrit les messages dans une table BigQuery existante à mesure qu'ils sont reçus. Vous pouvez également créer la table lorsque vous créez l'abonnement BigQuery.

  4. Créez un pipeline et une inscription qui acheminent tous les messages reçus par le bus (à l'aide de --cel-match="true") vers le sujet Pub/Sub. Configurez une règle de nouvelle tentative pour le pipeline.

    Par exemple, les commandes suivantes créent un pipeline et une inscription :

    gcloud eventarc pipelines create my-archive-pipeline \
    --destinations=pubsub_topic='my-archive-topic' \
    --min-retry-delay=1 \
    --max-retry-delay=20 \
    --max-retry-attempts=6 \
    --location=us-central1

    gcloud eventarc enrollments create my-archive-enrollment \
    --cel-match="true" \
    --destination-pipeline=my-archive-pipeline \
    --message-bus=my-message-bus \
    --message-bus-project=my-google-cloud-project \
    --location=us-central1

  5. Acheminez les journaux de votre pipeline vers un autre ensemble de données BigQuery.

    Vous devriez maintenant disposer de deux ensembles de données BigQuery distincts : l'un stocke tous les messages reçus par votre bus Eventarc Advanced et l'autre stocke les journaux de votre pipeline.

  6. Pour identifier les messages qui ont échoué, utilisez une instruction de requête pour joindre les deux ensembles de données BigQuery sur le message_uid champ.

  7. Après avoir identifié les messages ayant échoué, vous pouvez les publier à nouveau sur votre bus à l'aide de l'API de publication Eventarc. Par exemple, vous pouvez déployer un service ou un job Cloud Run pour lire les messages depuis BigQuery et les publier directement sur le bus Eventarc Advanced.

Rendre les gestionnaires d'événements idempotents

Les gestionnaires d'événements qui peuvent être relancés doivent être idempotents, en suivant les consignes générales suivantes :

  • De nombreuses API externes vous permettent de fournir une clé d'idempotence en tant que paramètre. Si vous utilisez une telle API, vous devez utiliser la source et l'ID de l'événement comme clé d'idempotence. (Les producteurs doivent s'assurer que la source + l'ID est unique pour chaque événement distinct.)
  • Vous pouvez également utiliser un attribut CloudEvents, xgooglemessageuid, pour assurer l'idempotence. La valeur de cet attribut est identique au champ message_uid dans les messages Eventarc Advanced. Il identifie de manière unique l'action de publication d'un événement. Par exemple, si le même événement est publié deux fois sur un bus, chaque événement aura une valeur xgooglemessageuid différente lorsqu'il sera envoyé à un gestionnaire d'événements.
  • L'idempotence fonctionne bien avec une livraison de type "au moins une fois", car elle permet de répéter la tentative en toute sécurité. Une bonne pratique pour écrire du code fiable consiste donc à combiner l'idempotence à la répétition des tentatives.
  • Assurez-vous que votre code est idempotent en interne. Exemple :
    • Assurez-vous que les mutations peuvent se produire plus d'une fois sans en changer le résultat.
    • Interrogez l'état de la base de données dans une transaction avant de muter l'état.
    • Assurez-vous que tous les effets secondaires sont eux-mêmes idempotents.
  • Imposez un contrôle transactionnel en dehors de votre service, indépendamment du code. Par exemple, conservez l'état quelque part en notant qu'un ID d'événement donné a déjà été traité.
  • Gérez les appels de doublons hors bande. Par exemple, mettez en place un processus de nettoyage distinct qui se lance après les appels de doublons.

Étape suivante