Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comportement de nouvelle tentative

Lorsqu'une demande à un Service AWS échoue en raison d'une erreur transitoire ou d'une limitation, le SDK peut automatiquement réessayer la demande. Cette page explique comment configurer les nouvelles tentatives et comment elles fonctionnent en interne.

Configuration des nouvelles tentatives

Vous contrôlez la stratégie de nouvelle tentative utilisée par le SDK et le nombre de nouvelles tentatives.

Choisir un mode de nouvelle tentative

Le mode nouvelle tentative détermine le comportement du SDK en cas d'échec d'une demande. Trois modes sont disponibles : standard , adaptatif et ancien.

Mode standard (par défaut)

Le mode standard réessaie les demandes qui ont échoué en utilisant un retard exponentiel avec gigue. Il utilise des délais plus courts pour les erreurs transitoires (telles que les délais d'expiration du réseau) et des délais plus longs pour les erreurs de limitation (telles que). ThrottlingException

Le mode standard inclut un quota de nouvelles tentatives, un compartiment de jetons qui déduit des jetons pour chaque nouvelle tentative et réapprovisionne les jetons lorsque les demandes aboutissent. Lorsque les jetons disponibles sont épuisés, le SDK renvoie l'erreur sans réessayer. Votre application échoue donc rapidement au lieu d'attendre de nouvelles tentatives qui ont peu de chances de réussir. Cela permet également de résoudre plus rapidement les interruptions de service en réduisant le nombre de nouvelles tentatives. En fonctionnement normal, le quota reste plein et n'a aucun effet. Le quota de nouvelles tentatives ne retarde ni ne bloque la demande initiale. Seules les nouvelles tentatives sont concernées. Pour en savoir plus, consultez Quota de nouvelles tentatives (compartiment de jetons).

Utilisez le mode standard, sauf si vous avez une raison précise de choisir un autre mode.

Mode adaptatif

Le mode adaptatif inclut toutes les fonctionnalités du mode standard, ainsi qu'un limiteur de débit côté client. Le limiteur de débit suit les réponses en cas de ralentissement et ajuste la vitesse à laquelle le SDK envoie les demandes. Contrairement au mode standard, le mode adaptatif peut retarder ou bloquer la demande initiale, et pas simplement les nouvelles tentatives, lorsqu'une limitation est détectée.

Le limiteur de débit fonctionne par instance cliente du SDK. Toutes les demandes d'un client partagent la même limite de débit, quelle que soit l'opération d'API ou la ressource qu'elles ciblent.

Quand utiliser le mode adaptatif :

Quand ne pas utiliser le mode adaptatif :

Le mode adaptatif n'est généralement pas recommandé par défaut.

Mode Legacy

Le mode Legacy est le comportement de nouvelle tentative utilisé par chaque SDK avant l'introduction du mode standard. Il n'inclut pas de quota standardisé de nouvelles tentatives. Certains SDK (tels que Java) avaient leurs propres implémentations de quotas de nouvelles tentatives en mode hérité, mais le comportement n'est pas cohérent entre les SDK. Sans quota standardisé, un client continue de réessayer à plein régime pendant les interruptions de service. Cela bloque les threads et les connexions sur les demandes qui ont peu de chances d'aboutir, tout en ajoutant de la charge qui peut retarder la reprise du service.

Le mode Legacy varie d'un SDK à l'autre. Le nombre de tentatives, le délai d'attente, les ensembles d'erreurs réessayables et le comportement de limitation varient d'une langue à l'autre. Le code qui dépend du comportement de nouvelle tentative existant peut se comporter différemment lorsqu'il est déplacé d'un SDK à l'autre.

Disponible en : Java, Python, Ruby, PHP, C++, CLI

Non disponible dans : .NET, Go, Kotlin, Rust, Swift, JavaScript

Le mode Legacy existe pour des raisons de rétrocompatibilité. Si vous utilisez actuellement le mode Legacy, passez en mode standard.

Réessayez les paramètres

Les paramètres suivants contrôlent le comportement des nouvelles tentatives. Vous pouvez les définir via des variables d'environnement, le fichier de configuration partagé (~/.aws/config) ou la configuration du client dans le code.

Une valeur maximale de tentatives 3 signifie que le SDK effectue une demande initiale et jusqu'à deux nouvelles tentatives. Définissez le nombre maximum de tentatives 1 pour désactiver complètement les nouvelles tentatives.

Ordre de priorité de configuration

Lorsque vous spécifiez le même paramètre à plusieurs endroits, le SDK résout la valeur en utilisant la priorité suivante, de la plus élevée à la plus faible :

Cela correspond à la priorité de configuration standard du AWS SDK. Une valeur définie à un niveau supérieur remplace toujours une valeur définie à un niveau inférieur. Par exemple, si vous définissez AWS_RETRY_MODE=adaptive comme variable d'environnement et que vous l'retry_mode=standardactivez~/.aws/config, le SDK utilise le mode adaptatif.

Language-specific configuration

Les paramètres inter-SDK décrits sur cette page (retry_modeetmax_attempts) fonctionnent dans tous les SDK. Cependant, l'API permettant de configurer les nouvelles tentatives dans le code varie en fonction de la langue. Consultez le guide du développeur de votre SDK pour les options de configuration spécifiques à la langue, telles que les stratégies d'annulation personnalisées, les erreurs supplémentaires pouvant être réessayées et le réglage des quotas de nouvelles tentatives.

Comment fonctionnent les nouvelles tentatives

Cette section décrit la manière dont AWS les kits de développement logiciel gèrent les demandes échouées : quelles erreurs déclenchent les nouvelles tentatives, combien de temps le SDK attend entre les tentatives et quand il arrête les nouvelles tentatives.

Que se passe-t-il lorsqu'une demande échoue

Lorsque vous effectuez un appel d'API via un AWS SDK, celui-ci suit la séquence suivante :

Le SDK répète cette boucle jusqu'à ce que la demande aboutisse, que le nombre maximum de tentatives soit atteint, que le quota de nouvelles tentatives soit épuisé ou qu'une erreur non réessayable se produise. L'ensemble du processus est automatique. Votre application reçoit soit une réponse positive, soit une erreur finale.

Quelles erreurs sont réessayées

Le SDK classe chaque demande ayant échoué dans l'une des trois catégories suivantes : temporaire, limitée ou non réessayable. Cette classification détermine si le SDK réessaie la demande et combien de temps il doit attendre avant de réessayer.

La classification est basée sur le code d'erreur et le code d'état HTTP contenus dans la réponse du service. Par exemple, un HTTP 400 avec le code d'erreur RequestTimeout est classé comme transitoire et réessayé. Un HTTP 400 avec ValidationException est classé comme non réessayable et renvoyé immédiatement.

Classification des erreurs

Les erreurs transitoires sont réessayées avec un court délai de base (50 ms) :

Les erreurs de limitation sont réessayées avec un délai de base plus long (1 000 ms) :

Non-retryable les erreurs (telles queAccessDeniedException,ValidationException,ResourceNotFoundException) sont immédiatement renvoyées à votre code.

Les erreurs de limitation signifient que le service a activement rejeté votre demande en raison de limites de débit. Le SDK attend donc plus longtemps avant de réessayer pour donner au service le temps de récupérer de la capacité. Consultez Combien de temps attend le SDK les délais spécifiques.

Combien de temps attend le SDK

Le SDK utilise un backoff exponentiel avec une gigue complète. En moyenne, chaque nouvelle tentative attend plus longtemps que la précédente, avec une sélection aléatoire pour répartir les demandes provenant de plusieurs clients.

Délais de base par type d'erreur

Le délai de base varie selon que l'erreur est transitoire ou temporaire :

Formule de rétrogradation

Le SDK calcule le délai de chaque nouvelle tentative à l'aide de la formule suivante :

delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)

Où :

La durée maximale de latence est de 20 secondes. Aucun délai individuel ne dépasse 20 secondes, quel que soit le nombre de tentatives.

Exemples pratiques

Exemple 1 : erreur transitoire, 3 tentatives maximum

La latence totale ajoutée est en moyenne d'environ 75 ms pour les deux tentatives.

Exemple 2 : erreur d'étranglement, 3 tentatives maximum

La latence totale ajoutée est en moyenne d'environ 1 500 ms pour les deux tentatives.

Exemple 3 : erreur transitoire, atteinte de la limite de réduction

Avec un délai de base de 50 ms, le délai calculé avant le plafonnement serait :

La limite entre en vigueur à la 10e tentative (11e tentative) pour les erreurs transitoires. Pour les erreurs d'étranglement avec une base de 1 000 ms, le plafond prend effet à la 6e tentative.

Pourquoi la nervosité est importante

Le multiplicateur aléatoire est appelé gigue totale. Sans cela, tous les clients qui rencontraient une erreur en même temps réessaieraient en même temps, ce qui créerait une rafale de trafic (le problème du « troupeau tonitruant »). Full Jitter répartit les nouvelles tentatives de manière uniforme sur l'ensemble de la fenêtre d'attente, de sorte que le service reçoit un flux constant de demandes au lieu de pics synchronisés.

Par exemple, supposons que 1 000 clients reçoivent tous un 503 au même moment. Full Jitter distribue ses premières tentatives de manière uniforme sur une fenêtre de 50 ms au lieu d'avoir les 1 000 tentatives à exactement 50 ms.

Server-directed calendrier des nouvelles tentatives

Certains Services AWS incluent un x-amz-retry-after en-tête dans les réponses aux erreurs. La valeur de l'en-tête est un délai en millisecondes. Lorsque cet en-tête est présent, le SDK utilise le délai spécifié par le serveur, limité au minimum au délai d'attente calculé et au maximum au délai d'attente calculé plus 5 000 ms. Étant donné que le délai d'attente calculé est lui-même plafonné à 20 secondes, le délai maximum effectif dirigé par le serveur est de 25 secondes. Le SDK n'applique pas de gigue à cette valeur, car le service est censé la modifier. Cela permet au service de communiquer exactement quand il s'attend à ce que la capacité soit disponible.

Quota de nouvelles tentatives (compartiment de jetons)

Le SDK gère un budget de jetons interne qui permet de suivre le ratio entre les demandes réussies et les échecs. Lorsque les échecs sont nombreux, le budget s'épuise et le SDK renvoie directement les erreurs. Votre demande échoue rapidement au lieu d'attendre de nouvelles tentatives qui ont peu de chances d'aboutir. Cela réduit également le nombre de nouvelles tentatives, ce qui permet de résoudre plus rapidement les interruptions de service.

Comment fonctionne le quota de nouvelles tentatives

Le budget symbolique commence à être plein. Chaque nouvelle tentative déduit des jetons. Lorsqu'une nouvelle tentative aboutit, le SDK restaure les jetons consommés par cette nouvelle tentative. Lorsqu'une demande aboutit au premier essai (aucune nouvelle tentative n'est nécessaire), le SDK restaure 1 jeton. Lorsque le budget atteint zéro, le SDK arrête de réessayer et renvoie les erreurs directement dans votre code.

Le coût plus élevé des nouvelles tentatives transitoires reflète leur schéma d'échec différent. Les erreurs transitoires telles que les erreurs 500 et les pannes de connexion indiquent souvent un problème à l'échelle du service. Dans ces situations, il est peu probable qu'une nouvelle tentative soit couronnée de succès. Cela ajoute de la latence à vos appels, sollicite les ressources des clients et peut retarder la reprise pour tout le monde. Les erreurs de limitation indiquent que le service a besoin de plus de temps avant que la demande ne puisse aboutir. Le SDK attend plus longtemps entre les nouvelles tentatives afin d'améliorer les chances de succès.

Quand recommence le blocage des quotas ?

Le quota de nouvelles tentatives permet de suivre les jetons à tout moment, mais ne bloque les nouvelles tentatives que lorsque le budget est épuisé. En fonctionnement normal, presque toutes les demandes aboutissent et le budget reste complet. Le quota n'a aucun effet observable sur les nouvelles tentatives.

Une nouvelle tentative rétablit uniquement le coût de son propre jeton (14 ou 5 jetons), et non le coût des tentatives échouées précédentes dans la même demande. Par exemple, si la première tentative échoue et que la seconde réussit, le budget perd 14 jetons nets. Le budget s'épuise le plus rapidement lorsque les nouvelles tentatives épuisent toutes les tentatives sans succès, mais il s'épuise également progressivement lorsque les demandes nécessitent plusieurs tentatives avant de réussir.

Avec la valeur par défaut de 3 tentatives maximum, le quota commence à s'épuiser lorsque plus d'environ 22 % des demandes entraînent des échecs transitoires prolongés, ou plus d'environ 32 % pour des erreurs de limitation. En dessous de ces taux, les demandes abouties réapprovisionnent le budget plus rapidement que les nouvelles tentatives échouées ne l'épuisent.

Le solde de départ de 500 jetons du budget fournit une réserve qui absorbe les courtes rafales d'échecs. Un bref pic d'erreurs, même grave, ne bloque pas les nouvelles tentatives à moins qu'il ne persiste assez longtemps pour vider la mémoire tampon.

Implications pratiques

Service-specific comportement

DynamoDB

Les clients DynamoDB utilisent des paramètres par défaut optimisés pour le profil de faible latence de DynamoDB :

Ces valeurs par défaut s'appliquent à la fois à Amazon DynamoDB et à DynamoDB Streams.

Long-polling opérations

Certaines AWS opérations utilisent de longues interrogations. Ils peuvent maintenir une connexion ouverte en attendant l'arrivée du travail. Ces opérations bénéficient d'un traitement spécial lors des nouvelles tentatives :

Comportement particulier : lorsque le quota de nouvelles tentatives est épuisé et que les nouvelles tentatives sont bloquées (étape 7 deQue se passe-t-il lorsqu'une demande échoue), le SDK applique toujours un délai d'attente avant de renvoyer l'erreur à votre code.

Cela est important car les opérations de sondage de longue durée sont généralement organisées en boucle serrée. Votre code appelleReceiveMessage, traite tous les messages, puis ReceiveMessage rappelle immédiatement. Sans l'annulation forcée, un budget de jetons épuisé entraînerait le renvoi d'erreurs par le SDK sans délai. Votre boucle d'interrogation enverrait alors immédiatement la requête suivante, augmentant ainsi l'utilisation du processeur du client et générant du trafic supplémentaire. Le délai d'annulation forcée interrompt ce cycle, permettant ainsi de gérer l'utilisation des ressources du client et le taux d'interrogation en cas de panne.

Soutenu par AWS Kits SDK et outils

Le tableau suivant répertorie la disponibilité du comportement de nouvelle tentative mis à jour dans chaque SDK. Pour SDK-specific plus de détails, notamment la version minimale, les valeurs par défaut avant/après et des exemples de code, consultez le GitHub problème de suivi.