Comportement de nouvelle tentative

Le comportement des nouvelles tentatives inclut les paramètres relatifs à la manière dont la SDKs tentative de reprise après des échecs résultant de demandes adressées à Services AWS.

Configurez cette fonctionnalité à l'aide des méthodes suivantes :

retry_mode- réglage AWS config du fichier partagé

AWS_RETRY_MODE- variable d'environnement

aws.retryMode- propriété JVM du système : Java/Kotlin uniquement

Spécifie la manière dont l'SDKoutil de développement tente de réessayer.

Valeur par défaut : Cette valeur est spécifique à votreSDK. Vérifiez votre SDK guide spécifique ou votre base SDK de code pour connaître sa valeur par défautretry_mode.

Valeurs valides:

• standard— (Recommandé) L'ensemble recommandé de règles de nouvelle tentative sur AWS SDKs l'ensemble du territoire. Ce mode inclut un ensemble standard d'erreurs réessayées et ajuste automatiquement le nombre de tentatives pour optimiser la disponibilité et la stabilité. Ce mode peut être utilisé en toute sécurité dans les applications multi-locataires. Le nombre maximum de tentatives par défaut avec ce mode est de trois, sauf si cela max_attempts est explicitement configuré.

• adaptive— Un mode de nouvelle tentative, adapté uniquement aux cas d'utilisation spécialisés, qui inclut les fonctionnalités du mode standard ainsi que la limitation automatique du débit côté client. Ce mode de nouvelle tentative n'est pas recommandé pour les applications à locataires multiples, sauf si vous prenez soin d'isoler les locataires de l'application. Pour plus d’informations, consultez Choix entre les standard modes et adaptive nouvelle tentative. Ce mode est expérimental et il est susceptible de modifier le comportement dans le futur.

• legacy— (Non recommandé) Spécifique à votre SDK (consultez votre SDK guide spécifique ou votre base SDK de code).

max_attempts- réglage AWS config du fichier partagé

AWS_MAX_ATTEMPTS- variable d'environnement

aws.maxAttempts- propriété JVM du système : Java/Kotlin uniquement

Spécifie le nombre maximal de tentatives à effectuer sur une demande.

Valeur par défaut : si cette valeur n'est pas spécifiée, sa valeur par défaut dépend de la valeur du retry_mode paramètre :

• Si retry_mode c'est le cas legacy — Utilise une valeur par défaut spécifique à votre SDK (consultez votre SDK guide spécifique ou la base SDK de code de votre choix pour les valeurs max_attempts par défaut).

• Si retry_mode c'est le cas standard — Fait trois tentatives.

• Si retry_mode c'est le cas adaptive — Fait trois tentatives.

Valeurs valides : nombre supérieur à 0.

Choix entre les standard modes et adaptive nouvelle tentative

Nous vous recommandons d'utiliser le mode standard nouvelle tentative, sauf si vous êtes certain que votre utilisation vous convient le mieux. adaptive

Note

Le adaptive mode suppose que vous regroupez des clients en fonction de l'étendue dans laquelle le service principal peut limiter les demandes. Si vous ne le faites pas, les limitations d'une ressource peuvent retarder les demandes pour une ressource non liée si vous utilisez le même client pour les deux ressources.

Standard	Adaptatif
Cas d'utilisation des applications : Tous.	Cas d'utilisation des applications : Insensible à la latence. Le client n'accède qu'à une seule ressource, ou vous fournissez une logique pour regrouper vos clients séparément en fonction de la ressource de service à laquelle il accède.
Supporte la coupure des circuits pour les empêcher SDK de réessayer en cas de panne.	Supporte la coupure des circuits pour les empêcher SDK de réessayer en cas de panne.
Utilise un recul exponentiel agité en cas de panne.	Utilise des durées d'interruption dynamiques pour tenter de minimiser le nombre de demandes ayant échoué, en échange du risque d'augmentation de la latence.
Ne retarde jamais la première tentative de demande, uniquement les nouvelles tentatives.	Peut limiter ou retarder la tentative de demande initiale.

Si vous choisissez d'utiliser adaptive le mode, votre application doit créer des clients conçus en fonction de chaque ressource susceptible d'être limitée. Dans ce cas, une ressource est plus fine que de simplement penser à chacune d'elles. Service AWS Services AWS peuvent avoir des dimensions supplémentaires qu'ils utilisent pour limiter les demandes. Prenons l'exemple du service Amazon DynamoDB. DynamoDB Région AWS utilise plus la table accessible pour limiter les demandes. Cela signifie qu'une table à laquelle votre code accède peut être plus limitée que d'autres. Si votre code utilise le même client pour accéder à toutes les tables et que les demandes adressées à l'une de ces tables sont limitées, le mode de nouvelle tentative adaptatif réduira le taux de demandes pour toutes les tables. Votre code doit être conçu pour avoir un client par egion-and-table paire R. Si vous rencontrez une latence inattendue lors de l'utilisation du adaptive mode, consultez le guide de AWS documentation spécifique au service que vous utilisez.

Détails de mise en œuvre du mode Réessai

Ils AWS SDKs utilisent des compartiments à jetons pour décider si une demande doit être réessayée et (dans le cas du mode adaptive nouvelle tentative) à quelle vitesse les demandes doivent être envoyées. Deux compartiments de jetons sont utilisés par le SDK : un compartiment de jetons de nouvelle tentative et un compartiment de jetons de taux de demande.

• Le bucket de jetons de réessai est utilisé pour déterminer s'il SDK convient de désactiver temporairement les nouvelles tentatives afin de protéger les services en amont et en aval en cas de panne. Les jetons sont acquis dans le compartiment avant toute tentative, et les jetons sont renvoyés au compartiment lorsque les demandes aboutissent. Si le compartiment est vide lors d'une nouvelle tentative, la demande ne SDK sera pas réessayée.

• Le bucket de jetons de taux de demande est utilisé uniquement en mode adaptive nouvelle tentative pour déterminer le taux d'envoi des demandes. Les jetons sont acquis dans le compartiment avant qu'une demande ne soit envoyée, et les jetons sont renvoyés au compartiment à un rythme déterminé dynamiquement sur la base des réponses de régulation renvoyées par le service.

Voici le pseudocode de haut niveau pour les modes standard et adaptive nouvelle tentative :

MakeSDKRequest() {
  attempts = 0
  loop {
    GetSendToken()
    response = SendHTTPRequest()
    RequestBookkeeping(response)
    if not Retryable(response)
      return response
    attempts += 1
    if attempts >= MAX_ATTEMPTS:
      return response
    if not HasRetryQuota(response)
      return response
    delay = ExponentialBackoff(attempts)
    sleep(delay)
  }
}

Vous trouverez ci-dessous des informations supplémentaires sur les composants utilisés dans le pseudocode :

GetSendToken:

Cette étape n'est utilisée qu'en mode adaptive nouvelle tentative. Cette étape permet d'acquérir un jeton à partir du bucket de jetons du taux de demande. Si un jeton n'est pas disponible, il attendra qu'il soit disponible. Des options de configuration sont SDK peut-être disponibles pour échouer à la demande au lieu d'attendre. Les jetons contenus dans le compartiment sont rechargés à un rythme déterminé dynamiquement, en fonction du nombre de réponses de régulation reçues par le client.

SendHTTPRequest:

Cette étape envoie la demande à AWS. La plupart AWS SDKs utilisent une HTTP bibliothèque qui utilise des pools de connexions pour réutiliser une connexion existante lors d'une HTTP demande. En général, les connexions sont réutilisées si une demande a échoué en raison d'erreurs de régulation, mais pas si une demande échoue en raison d'une erreur transitoire.

RequestBookkeeping:

Les jetons sont ajoutés au compartiment de jetons si la demande aboutit. Pour le mode adaptive nouvelle tentative uniquement, le taux de remplissage du compartiment de jetons de taux de demande est mis à jour en fonction du type de réponse reçue.

Retryable:

Cette étape détermine si une réponse peut être réessayée en fonction des éléments suivants :

• Le code HTTP de statut.

• Le code d'erreur renvoyé par le service.

• Les erreurs de connexion, définies comme toute erreur reçue par le SDK service qui ne reçoit aucune HTTP réponse du service.

Les erreurs transitoires (codes d'HTTPétat 400, 408, 500, 502, 503 et 504) et les erreurs de régulation (codes d'HTTPétat 400, 403, 429, 502, 503 et 509) peuvent toutes potentiellement être réessayées. SDKle comportement des nouvelles tentatives est déterminé en combinaison avec les codes d'erreur ou d'autres données du service.

MAX_ATTEMPTS:

Le nombre maximal de tentatives par défaut est défini par le retry_mode paramètre, sauf s'il est remplacé par le max_attempts paramètre.

HasRetryQuota

Cette étape permet d'acquérir un jeton dans le compartiment de jetons Retry. Si le compartiment de jetons de nouvelle tentative est vide, la demande ne sera pas réessayée.

ExponentialBackoff

Dans le cas d'une erreur pouvant être tentée à nouveau, le délai de nouvelle tentative est calculé à l'aide d'une réduction exponentielle tronquée. Ils SDKs utilisent un ralentissement exponentiel binaire tronqué avec instabilité. L'algorithme suivant montre comment la durée de sommeil, en secondes, est définie pour une réponse à une demande i :

seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)

Dans l'algorithme précédent, les valeurs suivantes s'appliquent :

b = random number within the range of: 0 <= b <= 1

r = 2

MAX_BACKOFF = 20 secondspour la plupartSDKs. Consultez votre SDK guide ou code source spécifique pour obtenir une confirmation.

Compatibilité avec AWS SDKs

Les éléments suivants SDKs prennent en charge les fonctionnalités et les paramètres décrits dans cette rubrique. Toute exception partielle est notée. Tous les paramètres des propriétés JVM du système sont pris en charge par le AWS SDK for Java et le Kit AWS SDK pour Kotlin seul.

SDK	Pris en charge	Remarques ou informations supplémentaires
AWS CLI v2	Oui
SDKpour C++	Oui
SDKpour Go V2 (1.x)	Oui
SDKpour Go 1.x (V1)	Non
SDKpour Java 2.x	Oui
SDKpour Java 1.x	Oui	JVMpropriétés du système : utiliser com.amazonaws.sdk.maxAttempts au lieu de aws.maxAttempts ; utiliser com.amazonaws.sdk.retryMode au lieu deaws.retryMode.
SDKpour JavaScript 3.x	Oui
SDKpour JavaScript 2.x	Non	Prend en charge un nombre maximal de tentatives, un recul exponentiel avec instabilité et une option pour une méthode personnalisée d'annulation des nouvelles tentatives.
SDKpour Kotlin	Oui
SDKpour. NET3. x	Oui
SDKpour PHP 3.x	Oui
SDKpour Python (Boto3)	Oui
SDKpour Ruby 3.x	Oui
SDKpour Rust	Oui
Outils pour PowerShell	Oui