Concevoir des applications tolérantes aux pannes et résilientes sur AWS

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Concevoir pour la résilience

Défaillances temporaires

 

• Connaître les modes de défaillance courants :
• Les erreurs temporaires disparaissent d'elles‑mêmes ; réessayer est généralement sûr.

Délais d'attente (timeouts)

 

• Connaître les modes de défaillance courants :
• Les erreurs temporaires disparaissent d'elles‑mêmes ; réessayer est généralement sûr.
• Timeouts : un service externe met trop de temps à répondre.

Erreurs permanentes

 

• Connaître les modes de défaillance courants :
• Les erreurs temporaires disparaissent d'elles‑mêmes ; réessayer est généralement sûr.
• Timeouts : un service externe met trop de temps à répondre.
• Erreurs permanentes : la requête est fondamentalement erronée ; réessayer n'aidera pas.

Limites d'API

 

• Connaître les modes de défaillance courants :
• Les erreurs temporaires disparaissent d'elles‑mêmes ; réessayer est généralement sûr.
• Timeouts : un service externe met trop de temps à répondre.
• Erreurs permanentes : la requête est fondamentalement erronée ; réessayer n'aidera pas.
• Limites de débit d'API : trop de requêtes ; HTTP 429 Too Many Requests.

Stratégies de reprise

• Les pannes dans les systèmes distribués sont souvent temporaires.
• Une requête réessayée réussit souvent.
• Ajoutez des reprises avec soin ; des reprises aveugles peuvent aggraver la situation.
• Recul exponentiel : augmenter le délai entre les reprises.
• Gigue : ajouter de l'aléatoire pour éviter les pics de reprises.
• Limites de reprises : éviter les boucles infinies.

 

Fonctions natives des SDK AWS

• Les SDK AWS gèrent automatiquement la logique de reprise.
• Les reprises intégrées incluent recul exponentiel et gigue.
• Les requêtes en échec ou limitées sont reprises avec des délais croissants.
• Réduit la quantité de code de gestion d'erreurs à écrire.

 

Gérer la logique de reprise

 

• La logique de reprise n'est pas toujours la solution.
• Erreurs HTTP 4xx : le serveur a compris mais refusé votre requête.
• Requêtes non idempotentes : réessayer peut créer des doublons ou des incohérences.

Gérer les délais d'attente

 

• Réessayer sans limites peut amplifier les problèmes sous charge.
• Combiner reprises et délais d'attente.
• Un délai d'attente fixe le temps d'attente maximal d'une réponse.
• Chaque appel à un service externe doit avoir un délai d'attente.

Disjoncteurs

• Si un service échoue en continu, les reprises ne suffisent pas.
• Continuer d'envoyer des requêtes peut surcharger le service défaillant.
• Le motif « disjoncteur » arrête temporairement les requêtes vers une dépendance non saine.
• État fermé : les requêtes circulent normalement.

 

Disjoncteurs

• Quand les échecs dépassent un seuil, le disjoncteur s'ouvre.
• Les requêtes suivantes sont bloquées.

 

Disjoncteurs

• Après un refroidissement, le disjoncteur passe en demi‑ouvert pour tester la reprise.
• Réponse du service réussie : reprise du fonctionnement normal.
• Échec persistant : le disjoncteur reste ouvert.
• Implémentez les disjoncteurs au niveau applicatif.

 

Dead Letter Queues

 

• Les messages qui échouent sans cesse peuvent bloquer le système.
• Les sortir du flux principal de traitement.
• Les messages en échec vont dans une Dead Letter Queue.
• Élément clé pour bâtir des applications résilientes.
• Mais bien comprendre les compromis.

Limites des API AWS

 

• Vous interagissez avec les services AWS via des API.
• Chaque service définit ses propres limites de débit.
• Dépasser les limites entraîne du bridage (HTTP 429 Too Many Requests).
• Concevez votre application pour gérer le bridage avec souplesse.

Intégrer des services tiers

• Les services tiers ajoutent de l'incertitude.
• Vous ne contrôlez ni leur performance ni leur disponibilité.
• Définissez des délais d'attente pour éviter les longues attentes.
• Utilisez des reprises avec recul pour les problèmes temporaires.
• Isolez les dépendances pour limiter l'impact.

 

Intégrer des services tiers

• Envisager de passer de la communication synchrone à asynchrone.
• Votre système continue de traiter même si le service externe est lent.

 

Passons à la pratique !

Développer des applications sur AWS