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 Service AWS échoue en raison d'une erreur transitoire ou d'un ralentissement, 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 nouvelles tentatives utilisée par le SDK et le nombre de nouvelles tentatives.

Choix d'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 traditionnel.

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'attente du réseau) et des délais plus longs pour les erreurs de régulation (telles que). ThrottlingException

Le mode standard inclut un quota de nouvelles tentatives, un bucket de jetons qui déduit les jetons à 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, de sorte que votre application échoue rapidement au lieu d'attendre des 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. Pendant le fonctionnement normal, le quota reste plein et n'a aucun effet. Le quota de nouvelles tentatives ne retarde ni ne bloque jamais la demande initiale. Seules les nouvelles tentatives sont concernées. Pour en savoir plus, consultez Quota de nouvelles tentatives (bucket 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 tout le mode standard, plus un limiteur de débit côté client. Le limiteur de débit suit les réponses de régulation et ajuste le débit auquel 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'un étranglement est détecté.

Le limiteur de débit fonctionne par instance client 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 pas recommandé par défaut.

Mode Héritage

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 de nouvelles tentatives normalisé. Certains SDK (tels que Java) avaient leurs propres implémentations de quotas de nouvelles tentatives en mode ancien, mais le comportement n'est pas uniforme d'un SDK à l'autre. Sans quota standardisé, un client continue de réessayer à plein régime en cas d'interruption de service. Cela bloque les threads et les connexions lorsque les demandes ont peu de chances d'aboutir, tout en ajoutant une charge susceptible de retarder le rétablissement du service.

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

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 traditionnel, passez en mode standard.

Réglages de nouvelle tentative

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 de 3 signifie que le SDK effectue une demande initiale et jusqu'à deux nouvelles tentatives. Définissez le nombre maximum de tentatives sur 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 suit 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 en tant que variable d'environnement et retry_mode=standard en tant que variable d'environnement~/.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 selon la langue. Consultez le guide du développeur de votre SDK pour connaître les options de configuration spécifiques au langage, telles que les stratégies de latence personnalisées, les erreurs supplémentaires susceptibles d'être réessayées et le réglage du quota de nouvelles tentatives.

Comment fonctionnent les nouvelles tentatives

Cette section décrit la manière dont AWS les SDK traitent les demandes ayant échoué : quelles erreurs déclenchent de nouvelles tentatives, combien de temps le SDK attend entre les tentatives et quand il arrête de réessayer.

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 maximal 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 dernière erreur.

Quelles erreurs sont réessayées

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

La classification est basée sur le code d'erreur et le code d'état HTTP figurant 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 régulation 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 régulation 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 afin de donner au service le temps de récupérer sa capacité. Consultez Combien de temps le SDK attend-il les délais spécifiques.

Combien de temps le SDK attend-il

Le SDK utilise un ralentissement exponentiel avec une instabilité totale. En moyenne, chaque nouvelle tentative attend plus longtemps que la précédente, et la randomisation permet de répartir les demandes provenant de plusieurs clients.

Retards de base par type d'erreur

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

Formule Backoff

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 d'attente est de 20 secondes. Aucun délai individuel ne dépasse 20 secondes, quel que soit le nombre de tentatives effectuées.

Exemples réussis

Exemple 1 : erreur transitoire, 3 tentatives maximum

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

Exemple 2 : erreur de limitation, 3 tentatives maximum

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

Exemple 3 : erreur transitoire, atteinte du plafond de réduction

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

Le plafond prend effet à la 10e tentative (11e tentative) pour les erreurs transitoires. Pour les erreurs de régulation 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é full jitter. Sans cela, tous les clients qui rencontraient une erreur en même temps réessaieraient en même temps, ce qui créerait un pic de trafic de nouvelles tentatives (le problème du « tonnerre »). L'instabilité totale 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 flot constant de demandes au lieu de pics synchronisés.

Supposons, par exemple, que 1 000 clients reçoivent tous un 503 au même moment. Full Jitter répartit leurs premières tentatives de manière uniforme sur une fenêtre de 50 ms au lieu de les faire toutes les 1 000 tentatives exactement à 50 ms.

Server-directed réessayer le chronométrage

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 de temporisation calculé et au maximum au délai de temporisation calculé majoré de 5 000 ms. Le délai calculé étant lui-même plafonné à 20 secondes, le délai maximal 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 au moment où il prévoit disposer de la capacité disponible.

Quota de nouvelles tentatives (bucket de jetons)

Le SDK gère un budget interne de jetons qui permet de suivre le ratio entre les demandes réussies et les échecs. Lorsque les défaillances sont généralisées, le budget s'épuise et le SDK renvoie directement les erreurs. Votre application échoue rapidement au lieu d'attendre de nouvelles tentatives qui ont peu de chances de réussir. Cela réduit également le trafic 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 au point de départ plein. Chaque nouvelle tentative déduit des jetons. Lorsqu'une nouvelle tentative réussit, 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 tentatives transitoires reflète leur schéma d'échec différent. Les erreurs transitoires telles que les 500 et les défaillances de connexion indiquent souvent un problème à l'échelle du service. Dans ces situations, il est peu probable que la poursuite des tentatives aboutisse. Cela augmente la latence de vos appels, bloque les ressources des clients et peut retarder le rétablissement pour tout le monde. Les erreurs de régulation indiquent que le service a besoin de plus de temps avant que la demande puisse aboutir. Le SDK attend plus longtemps entre les tentatives afin d'améliorer les chances de réussite.

Quand le bloc de quotas réessaie-t-il ?

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

Une nouvelle tentative réussie rétablit uniquement son propre coût en jetons (14 ou 5 jetons), et non le coût des tentatives infructueuses précédentes dans le cadre de 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 toutes les tentatives sont épuisées sans succès, mais il s'épuise également progressivement lorsque les demandes nécessitent plusieurs tentatives avant d'aboutir.

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 % en cas d'erreurs de limitation. En dessous de ces taux, les demandes réussies réapprovisionnent le budget plus rapidement que les tentatives infructueuses ne l'épuisent.

Le solde de départ de 500 jetons du budget fournit une marge de manœuvre qui permet d'absorber les défaillances de courte durée. Une brève augmentation du nombre d'erreurs, même grave, ne bloque pas les nouvelles tentatives, sauf si elle persiste suffisamment longtemps pour épuiser 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 à Amazon DynamoDB et à DynamoDB Streams.

Long-polling opérations

Certaines AWS opérations utilisent de longs sondages. Ils peuvent maintenir une connexion ouverte en attendant l'arrivée des travaux. Ces opérations font l'objet d'un traitement spécial pour les nouvelles tentatives :

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

Cela est important car les longues opérations de sondage sont généralement organisées en boucle étroite. Votre code appelleReceiveMessage, traite tous les messages, puis appelle ReceiveMessage à nouveau immédiatement. Sans ce recul forcé, un budget de jetons épuisé entraînerait le renvoi d'erreurs par le SDK sans délai. Votre boucle de sondage enverra alors immédiatement la demande suivante, ce qui augmentera l'utilisation du processeur du client et générera du trafic supplémentaire. Le délai d'attente forcé met fin à ce cycle, ce qui permet de gérer l'utilisation des ressources des clients et le taux d'interrogation en cas de panne.

Support par AWS Kits SDK et outils

Le tableau suivant indique 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.