Réessayer les requêtes ayant échoué

Cette page décrit les bonnes pratiques concernant la relance des requêtes échouées à l'API IAM (Identity and Access Management).

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 IAM peut réussir ou échouer. Si votre application relance des requêtes ayant échoué sans attendre, elle peut envoyer un grand nombre de tentatives à IAM dans un court laps de temps. Par conséquent, vous risquez de dépasser les quotas et limites qui s'appliquent à chaque ressource IAM de votre projet Google Cloud.

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 de gestion standard 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 à IAM.
  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 IAM 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 IAM qui renvoient le code d'erreur 404. Les lectures IAM sont cohérentes à terme. Par conséquent, il est possible que les ressources ne soient pas visibles immédiatement après leur création, ce qui peut entraîner des erreurs 404.

En outre, utilisez une version modifiée de cette stratégie de nouvelle tentative pour toutes les requêtes adressées à l'API Cloud IAM qui renvoient le code d'erreur 409 et l'état ABORTED. Ce type d'erreur indique un problème de simultanéité. Par exemple, vous essayez peut-être de mettre à jour une stratégie d'autorisation qu'un autre client a déjà écrasée. Pour ce type d'erreur, vous devez toujours relancer la série complète de requêtes lecture-modification-écriture, en appliquant un intervalle exponentiel entre les tentatives tronqué avec gigue introduite. Si vous n'effectuez qu'une seule opération d'écriture, la requête échouera.

Étape suivante