Diseñar aplicaciones tolerantes a fallos y resilientes en AWS

Desarrollo de aplicaciones en AWS

Ricardo Sueiras

Principal Technologist

Construir con resiliencia

Fallos temporales

 

• Comprende los modos de fallo comunes:
• Los errores temporales se resuelven solos; normalmente es seguro reintentar.

Timeouts

 

• Comprende los modos de fallo comunes:
• Los errores temporales se resuelven solos; normalmente es seguro reintentar.
• Timeouts: un servicio externo tarda demasiado en responder.

Errores permanentes

 

• Comprende los modos de fallo comunes:
• Los errores temporales se resuelven solos; normalmente es seguro reintentar.
• Timeouts: un servicio externo tarda demasiado en responder.
• Errores permanentes: la solicitud está mal planteada; reintentar no ayuda.

Límites de API

 

• Comprende los modos de fallo comunes:
• Los errores temporales se resuelven solos; normalmente es seguro reintentar.
• Timeouts: un servicio externo tarda demasiado en responder.
• Errores permanentes: la solicitud está mal planteada; reintentar no ayuda.
• Límites de velocidad de API: demasiadas solicitudes; espera HTTP 429 Too Many Requests.

Estrategias de reintento

• En sistemas distribuidos, muchos fallos son temporales.
• Un reintento suele funcionar.
• Añade lógica de reintentos con cuidado; reintentos ciegos pueden empeorar todo.
• Exponential backoff: aumenta el retraso entre reintentos.
• Jitter: añade aleatoriedad para evitar picos de reintentos.
• Límites de reintentos: evita bucles infinitos.

 

Capacidades nativas del AWS SDK

• Los SDK de AWS gestionan los reintentos automáticamente.
• Incluyen backoff exponencial y jitter.
• Las solicitudes fallidas o limitadas se reintentan con retrasos crecientes.
• Reduce el código de gestión de errores que tienes que escribir.

 

Gestionar la lógica de reintentos

 

• La lógica de reintentos no siempre es la solución.
• Errores HTTP 4xx: el servidor entendió y rechazó tu solicitud.
• Solicitudes no idempotentes: reintentar puede duplicar acciones o causar inconsistencias.

Gestionar timeouts

 

• Reintentar sin límites puede amplificar problemas bajo carga.
• Combina reintentos con timeouts.
• Un timeout fija el tiempo máximo de espera por una respuesta.
• Toda llamada a servicios externos debe tener timeout.

Circuit breakers

• Si un servicio falla sin parar, solo reintentos no bastan.
• Seguir enviando solicitudes puede sobrecargarlo.
• El patrón circuit breaker detiene temporalmente solicitudes a una dependencia no sana.
• Estado cerrado: las solicitudes fluyen con normalidad.

 

Circuit breakers

• Si los fallos superan un umbral, el circuito se abre.
• Las solicitudes posteriores se bloquean.

 

Circuit breakers

• Tras un enfriamiento, el circuito pasa a medio abierto para probar la recuperación.
• Si el servicio responde bien: se reanuda la operación normal.
• Si sigue fallando: el circuito permanece abierto.
• Implementa circuit breakers a nivel de aplicación.

 

Dead letter queues

 

• Mensajes que fallan una y otra vez pueden bloquear el sistema.
• Sácalos del flujo principal de procesamiento.
• Los mensajes fallidos van a una Dead Letter Queue.
• Parte clave para crear aplicaciones resilientes.
• Pero entiende los trade-offs.

Límites de la AWS API

 

• Interactúas con AWS mediante APIs.
• Cada servicio define sus propios límites de velocidad.
• Si los superas, hay throttling (HTTP 429 Too Many Requests).
• Diseña tu aplicación para gestionarlo con gracia.

Integración con servicios de terceros

• Los servicios de terceros introducen incertidumbre.
• No controlas su rendimiento ni su disponibilidad.
• Configura timeouts para evitar esperas largas.
• Usa reintentos con backoff para problemas temporales.
• Aísla dependencias para limitar el impacto.

 

Integración con terceros

• Valora pasar de comunicación síncrona a asíncrona.
• Tu sistema sigue procesando aunque el servicio externo se retrase.

 

¡Vamos a practicar!

Desarrollo de aplicaciones en AWS