Stratégie de nouvelle tentative

Cette page décrit les bonnes pratiques concernant la relance des requêtes échouées à l'API Model Armor.

Pour les requêtes pouvant être réessayées en toute sécurité, nous vous recommandons d'utiliser un intervalle exponentiel tronqué entre les tentatives avec une gigue introduite.

Présentation de l'intervalle exponentiel tronqué entre les tentatives

Chaque requête adressée à l'API Model Armor peut réussir ou échouer. Si votre application relance les requêtes échouées sans attendre, elle peut envoyer un grand nombre de tentatives à Model Armor sur une courte période. Par conséquent, vous risquez de dépasser les quotas et limites qui s'appliquent à chaque ressource Model Armor de votre Google Cloud projet.

Pour éviter de déclencher ce problème, nous vous recommandons vivement d'utiliser un intervalle exponentiel tronqué entre les tentatives avec l'introduction de gigue, qui est une stratégie standard de gestion des erreurs des applications réseau. Dans cette approche, un client relance régulièrement une requête ayant échoué en observant des délais croissants entre les tentatives. Un petit délai aléatoire, appelé "gigue", est également ajouté entre les tentatives. Ce délai aléatoire permet d'éviter une vague synchronisée de nouvelles tentatives de plusieurs clients, également appelée problème de tonnage.

Algorithme de l'intervalle exponentiel entre les tentatives

L'algorithme suivant met en œuvre un intervalle exponentiel tronqué entre les tentatives avec gigue :

  1. Envoyez une requête à Model Armor.
  2. Si la requête échoue, attendez 1 + random-fraction secondes, puis effectuez une nouvelle tentative.
  3. Si la requête échoue, attendez 2 + random-fraction secondes, puis effectuez une nouvelle tentative.
  4. Si la requête échoue, attendez 4 + random-fraction secondes, puis effectuez une nouvelle tentative.
  5. Continuez ce modèle en attendant 2n + random-fraction secondes après chaque nouvelle tentative, jusqu'à maximum-backoff fois.
  6. Après deadline secondes, arrêtez de relancer la requête.

Lorsque vous appliquez l'algorithme, utilisez les valeurs suivantes :

  • Avant chaque nouvelle tentative, le temps d'attente est défini sur min((2n + random-fraction), maximum-backoff), avec n commençant à 0 et incrémenté de 1 pour chaque nouvelle tentative.
  • Remplacez random-fraction par une valeur fractionnelle aléatoire inférieure ou égale à 1. Utilisez une valeur différente pour chaque nouvelle tentative. L'ajout de cette valeur aléatoire empêche les clients d'être synchronisés et d'envoyer un grand nombre de tentatives en même temps.
  • Remplacez maximum-backoff par le délai d'attente maximal, en secondes, entre les nouvelles tentatives. Les valeurs habituelles sont de 32 ou 64 (25 ou 26) secondes. Choisissez la valeur qui convient le mieux à votre cas d'utilisation.
  • Remplacez deadline par le nombre maximal de secondes pendant lequel vous souhaitez continuer à envoyer des tentatives. Choisissez une valeur qui reflète votre cas d'utilisation. Par exemple, dans un pipeline d'intégration continue/de déploiement continu (CI/CD) qui n'est pas hautement sensible, vous pouvez définir deadline sur 300 secondes (5 minutes).

Types d'erreurs à réessayer

Utilisez cette stratégie de nouvelle tentative pour toutes les requêtes adressées à l'API Model Armor qui renvoient les codes d'erreur 500, 502, 503 ou 504.

Vous pouvez éventuellement utiliser cette stratégie de nouvelle tentative pour les requêtes adressées à l'API Model Armor qui renvoient le code d'erreur 429.