# Diseño de interacciones en un sistema distribuido para mitigar o tolerar errores
Los sistemas distribuidos dependen de las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable aunque se pierdan datos o haya latencia en estas redes. Los componentes del sistema distribuido deben funcionar de manera que no afecten negativamente a otros componentes o a la carga de trabajo. Estas prácticas recomendadas permiten que las cargas de trabajo toleren el estrés o los errores, se recuperen más rápidamente de ellos y mitiguen el impacto de dichos errores. El resultado es un tiempo medio de recuperación (MTTR) mejor.
Estas prácticas recomendadas previenen los fallos y mejoran el tiempo medio entre errores (MTBD).
**Topics**
+ [REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Limitación de las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Respuesta rápida a los errores y limitación de las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definición de los tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Creación de sistemas sin estado cuando sea posible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementación de recursos de emergencia](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles
Los componentes de la aplicación deben seguir desempeñando su función principal incluso si las dependencias dejan de estar disponibles. Es posible que proporcionen datos ligeramente obsoletos, datos alternativos o incluso ningún dato. Esto garantiza que los errores localizados solo impidan lo mínimo del funcionamiento general del sistema y, al mismo tiempo, se obtenga el valor empresarial central.
**Resultado deseado:** cuando las dependencias de un componente no están en buen estado, el propio componente puede seguir funcionando, aunque con capacidad mermada. Los modos de errores de los componentes deben considerarse parte del funcionamiento normal. Los flujos de trabajo deben diseñarse de tal manera que dichos errores no produzcan un fallo total o, al menos, lleven a estados predecibles y recuperables.
**Patrones comunes de uso no recomendados:**
+ No identificar la funcionalidad empresarial principal necesaria. No probar que los componentes funcionen, incluso durante los errores de dependencia.
+ No proporcionar datos en caso de error o cuando solo una de las múltiples dependencias no está disponible y aún se pueden devolver resultados parciales.
+ Crear un estado incoherente cuando una transacción falla parcialmente.
+ No tener una forma alternativa de acceder a un almacén de parámetros central.
+ Invalidar o vaciar un estado local como resultado de un fallo de actualización sin tener en cuenta las consecuencias.
**Beneficios de establecer esta práctica recomendada:** la degradación gradual mejora la disponibilidad del sistema en su conjunto y mantiene la funcionalidad de las funciones más importantes incluso cuando hay errores.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
La implementación de una degradación gradual ayuda a minimizar el impacto de los errores de dependencia en la función de los componentes. Lo ideal sería que un componente detectara los errores de dependencia y siguiese funcionando de una forma que afectara lo menos posible a otros componentes o clientes.
Diseñar una arquitectura que permita una degradación gradual implica considerar los posibles modos de errores durante el diseño de las dependencias. Para cada modo de error, disponga de una forma de ofrecer la mayoría o, al menos la funcionalidad más crítica del componente, a las personas que llaman o a los clientes. Estos factores pueden convertirse en requisitos adicionales que se pueden probar y verificar. Lo ideal es que un componente pueda desempeñar su función principal de manera aceptable incluso cuando falla una o varias dependencias.
Se trata tanto de una cuestión empresarial como técnica. Todos los requisitos empresariales son importantes y deben cumplirse si es posible. Sin embargo, es lógico preguntarse qué debe suceder cuando no se puedan cumplir todos. Se puede diseñar un sistema para que esté disponible y sea coherente, pero en circunstancias en las que haya que eliminar un requisito, ¿cuál es más importante? En el caso del procesamiento de pagos, puede ser la coherencia. En una aplicación en tiempo real, puede ser la disponibilidad. En el caso de un sitio web orientado al cliente, la respuesta dependería de las expectativas del cliente.
Lo que esto significa depende de los requisitos del componente y de lo que deba considerarse su función principal. Por ejemplo:
+ Un sitio web de comercio electrónico podría mostrar en su página de inicio los datos de varios sistemas diferentes, como las recomendaciones personalizadas, los productos mejor clasificados y el estado de los pedidos de los clientes. Cuando un sistema anterior falla, sigue siendo lógico mostrar todo lo demás en lugar de mostrar una página de error al cliente.
+ Un componente que lleva a cabo escrituras por lotes puede seguir procesando un lote si se produce un error en una de las operaciones individuales. Implementar un mecanismo de reintento debería ser sencillo. Para hacerlo, se puede devolver a la persona que llama información sobre qué operaciones se han hecho correctamente, cuáles han fallado y por qué han fallado, o colocar las solicitudes que han fallado en una cola de mensajes fallidos para implementar reintentos asíncronos. También se debe registrar la información sobre las operaciones que han fallado.
+ Un sistema que procese las transacciones debe verificar que se ejecuten todas o ninguna de las actualizaciones individuales. En el caso de las transacciones distribuidas, se puede usar el patrón Saga para revertir operaciones anteriores en caso de que falle una operación posterior de la misma transacción. En este caso, la función principal es mantener la coherencia.
+ Los sistemas en los que el tiempo es crítico deberían contar con la capacidad de gestionar de manera oportuna las dependencias que no respondan. En estos casos, se puede utilizar el patrón del disyuntor. Cuando se agota el tiempo de espera de las respuestas de una dependencia, el sistema puede cambiar a un estado cerrado en el que no se hacen llamadas adicionales.
+ Una aplicación puede leer parámetros de un almacén de parámetros. Puede resultar útil crear imágenes de contenedores con un conjunto predeterminado de parámetros y utilizarlos en caso de que ese almacén de parámetros no esté disponible.
Tenga en cuenta que las soluciones que se adopten en caso de fallo de un componente deben probarse y ser significativamente más sencillas que la solución principal. En general, [se debe evitar el uso de estrategias alternativas](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Pasos para la implementación
Identifique las dependencias externas e internas. Considere qué tipos de errores pueden producirse en ellas. Piense en formas de minimizar el impacto negativo en los sistemas anteriores y posteriores y en los clientes durante esos errores.
A continuación, tenemos una lista de dependencias y la descripción de cómo degradar correctamente cuando fallan:
1. **Errores parciales de dependencias:** un componente puede hacer varias solicitudes a los sistemas posteriores, ya sean varias solicitudes a un sistema o una sola solicitud destinada a varios sistemas. En función del contexto empresarial, es posible que haya diferentes formas apropiadas de gestionar este problema (para obtener más información, consulte los ejemplos anteriores en la Guía de implementación).
1. **Un sistema descendente no puede procesar las solicitudes debido a la alta carga:** si las solicitudes a un sistema descendente fallan constantemente, no tiene sentido volver a intentarlo. Esto puede suponer una carga adicional para un sistema ya sobrecargado y dificultar la recuperación. Aquí se puede utilizar el patrón de disyuntor, que supervisa las llamadas que fallaron al enviarlas a un sistema posterior. Si falla un gran número de llamadas, dejará de enviar más solicitudes al sistema posterior y solo permitirá ocasionalmente el paso de las llamadas para comprobar si el sistema posterior vuelve a estar disponible.
1. **Un almacén de parámetros no está disponible:** para transformar un almacén de parámetros, se puede utilizar el almacenamiento en caché de dependencia flexible o los valores predeterminados en buen estado que se incluyen en las imágenes de contenedores o máquinas. Tenga en cuenta que estos valores predeterminados deben mantenerse actualizados e incluirse en los conjuntos de pruebas.
1. **Un servicio de supervisión u otra dependencia no funcional no está disponible:** si un componente no puede enviar registros, métricas o rastros de forma intermitente a un servicio de monitorización central, suele ser mejor seguir ejecutando las funciones empresariales como de costumbre. No registrar ni subir métricas de forma silenciosa durante mucho tiempo no suele ser aceptable. Además, algunos casos de uso pueden requerir entradas de auditoría completas para satisfacer los requisitos de cumplimiento.
1. **Es posible que una instancia principal de una base de datos relacional no esté disponible:** Amazon Relational Database Service, como casi todas las bases de datos relacionales, solo puede tener una instancia de escritura principal. Esto crea un único punto de error para las cargas de trabajo de escritura y dificulta el escalamiento. Este problema se puede mitigar parcialmente mediante el uso de una configuración Multi-AZ para lograr alta disponibilidad o de Amazon Aurora sin servidor para mejorar el escalado. Cuando los requisitos de disponibilidad son muy altos, podría ser conveniente no utilizar en absoluto el escritor principal. Para consultas de solo lectura, se pueden utilizar réplicas de lectura, que proporcionan redundancia y capacidad de escalado horizontal, no solo vertical. Las escrituras se pueden almacenar en búfer, por ejemplo, en una cola de Amazon Simple Queue Service, de modo que las solicitudes de escritura de los clientes puedan seguir aceptándose incluso si la principal no está disponible temporalmente.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (summarizes Circuit Breaker from “Release It\$1” book)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Error Retries and Exponential Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software”](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Amazon Builders' Library: Evitar los planes alternativos en los sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Cómo evitar demoras de colas insuperables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: Tiempos de espera, reintentos y retardo con fluctuación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Videos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP02 Limitación de las solicitudes
Limite las solicitudes para mitigar el agotamiento de los recursos debido a aumentos inesperados de la demanda. Las solicitudes por debajo de los índices de limitación se procesan, pero las que superan el límite definido se rechazan y se envía un mensaje que indica que la solicitud no se ha procesado a causa de la limitación.
**Resultado deseado:** la limitación de las solicitudes mitiga los grandes picos de volumen, ya sea debido a un aumento repentino del tráfico de clientes, a ataques por desbordamiento o a tormentas de reintentos, lo que permite que las cargas de trabajo sigan procesando de manera normal el volumen de solicitudes admitido.
**Patrones comunes de uso no recomendados:**
+ Las limitaciones de puntos de conexión de la API no se implementan o se mantienen en los valores predeterminados sin tener en cuenta los volúmenes esperados.
+ Los puntos de conexión de la API no se someten a pruebas de carga ni se prueban las limitaciones.
+ Los índices de solicitudes se limitan sin tener en cuenta el tamaño o la complejidad de las solicitudes.
+ Los índices o el tamaño máximos de las solicitudes se prueban, pero por separado.
+ Los recursos no se aprovisionan con los mismos límites establecidos en las pruebas.
+ No se han configurado ni considerado planes de uso para los consumidores de API de aplicación a aplicación (A2A).
+ Los consumidores de cola que escalan horizontalmente no tienen configurado un valor máximo de simultaneidad.
+ No se ha implementado la limitación de índices por dirección IP.
**Beneficios de establecer esta práctica recomendada:** las cargas de trabajo que establecen límites pueden funcionar con normalidad y procesar correctamente la carga de solicitudes aceptada en caso de que se produzcan picos de volumen inesperados. Los picos repentinos o sostenidos de solicitudes a las API y las colas se limitan y no agotan los recursos de procesamiento de solicitudes. Hay límites de índices que limitan a solicitantes individuales para que un gran volumen de tráfico desde una sola dirección IP o un único consumidor de API no agote los recursos y afecte a otros consumidores.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Los servicios deben diseñarse para procesar una capacidad de solicitudes conocida; esta capacidad se puede establecer mediante pruebas de carga. Si los índices de llegada de solicitudes superan los límites, se emite la respuesta correspondiente que indica que la solicitud no se ha procesado a causa de las limitaciones. Esto permite al consumidor gestionar el error y volver a intentarlo más tarde.
Cuando su servicio requiera la implementación de limitaciones, considere la posibilidad de implementar el algoritmo del bucket de tokens, en el que un token se refiere a una solicitud. Los tokens se recargan a un índice de limitación por segundo y se vacían de forma asíncrona a un ritmo de un token por solicitud.
![\[Diagrama que describe el algoritmo del bucket de tokens.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) implementa el algoritmo del bucket de tokens de acuerdo con los límites de la cuenta y la región, y se puede configurar por cliente con planes de uso. Además, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) y [Amazon Kinesis](https://aws.amazon.com/kinesis/) pueden almacenar las solicitudes en búfer para reducir la tasa de solicitudes y permitir tasas de limitación más altas para las solicitudes que se pueden atender. Por último, puede implementar una limitación de velocidad con [AWS WAF](https://aws.amazon.com/waf/) para limitar los consumidores de API específicos que generan una carga inusualmente alta.
## Pasos para la implementación
Puede configurar API Gateway con límites de limitación para sus API y devolver errores `429 Too Many Requests` cuando se superen los límites. Puede utilizar AWS WAF con sus puntos de conexión de AWS AppSync y API Gateway para habilitar la limitación de índices por dirección IP. Además, si su sistema tolera el procesamiento asíncrono, puede colocar los mensajes en una cola o secuencia para acelerar las respuestas a los clientes del servicio, lo que le permite ampliar los índices de limitación más altos.
Con el procesamiento asíncrono, cuando haya configurado Amazon SQS como origen de eventos de AWS Lambda, podrá [configurar la máxima simultaneidad](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) para evitar que las altas tasas de eventos consuman la cuota de ejecución simultánea de la cuenta disponible necesaria para otros servicios de su carga de trabajo o cuenta.
Si bien API Gateway proporciona una implementación administrada del bucket de tokens, en los casos en que no pueda usar API Gateway, puede utilizar las implementaciones de código abierto específicas de cada lenguaje (consulte los ejemplos relacionados en Recursos) del bucket de tokens para sus servicios.
+ Comprenda y configure los [límites de limitación de API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) en la cuenta por región, API por etapa y clave de API por nivel de plan de uso.
+ Aplique [reglas de limitación de tasas de AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) a API Gateway y a los puntos de conexión de AWS AppSync para protegerse contra las inundaciones y bloquear las IP maliciosas. Las reglas de limitación de índices también se pueden configurar en las claves de API de AWS AppSync para los consumidores de A2A.
+ Analice si necesita un control de limitación superior a la limitación de índices para las API de AWS AppSync y, de ser así, configure una API Gateway enfrente de su punto de conexión de AWS AppSync.
+ Cuando las colas de Amazon SQS se configuran como activadores para los consumidores de colas de Lambda, defina la [simultaneidad máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) en un valor que procese lo suficiente como para cumplir sus objetivos de nivel de servicio, pero que no consuma los límites de simultaneidad que afecten a otras funciones de Lambda. Considere la posibilidad de configurar la simultaneidad reservada en otras funciones de Lambda de la misma cuenta y región cuando consuma colas con Lambda.
+ Utilice API Gateway con integraciones de servicios nativos para Amazon SQS o Kinesis para almacenar en búfer las solicitudes.
+ Si no puede utilizar API Gateway, consulte las bibliotecas específicas del lenguaje para implementar el algoritmo del bucket de tokens para su carga de trabajo. Consulte la sección de ejemplos e investigue por su cuenta para encontrar una biblioteca adecuada.
+ Pruebe los límites que tiene pensado establecer o que va a permitir que se aumenten, y documente los límites probados.
+ No aumente los límites por encima de lo que establezca en las pruebas. Cuando aumente un límite, antes de aplicar ese aumento, compruebe que los recursos aprovisionados sean equivalentes o superiores a los de las situaciones de prueba.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL04-BP03 Trabajo constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
**Documentos relacionados:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF: Rate-based rule statement ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introducing maximum concurrency of AWS Lambda when using Amazon SQS as an event source ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: Maximum Concurrency ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Ejemplos relacionados:**
+ [ The three most important AWS WAF rate-based rules ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Python token-bucket ](https://pypi.org/project/token-bucket/)
+ [ Node token-bucket ](https://www.npmjs.com/package/tokenbucket)
+ [ .NET System Threading Rate Limiting ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Videos relacionados:**
+ [ Implementing GraphQL API security best practices with AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Herramientas relacionadas:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [Sala de espera virtual en AWS](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)
# REL05-BP03 Control y limitación de las llamadas de reintento
Utilice un retroceso exponencial para reintentar las solicitudes a intervalos progresivamente más largos entre cada reintento. Introduzca una fluctuación entre reintentos para aleatorizar los intervalos de reintentos. Limite el número máximo de reintentos.
**Resultado deseado:** entre los componentes típicos de un sistema de software distribuido se incluyen servidores, equilibradores de carga, bases de datos y servidores DNS. Durante el funcionamiento normal, estos componentes pueden responder a las solicitudes con errores temporales o limitados, y también con errores que serían persistentes independientemente de los reintentos. Cuando los clientes hacen solicitudes a los servicios, esas solicitudes consumen recursos, como memoria, subprocesos, conexiones, puertos o cualquier otro recurso limitado. Controlar y limitar los reintentos es una estrategia para liberar y minimizar el consumo de recursos, de modo que los componentes del sistema sometidos a presión no se sobrecarguen.
Cuando se agota el tiempo de espera de las solicitudes del cliente o se reciben respuestas de error, deben determinar si deben volver a intentarlo o no. Si lo vuelven a intentar, lo hacen con un retroceso exponencial con fluctuaciones y un valor de reintento máximo. Como resultado, los servicios y procesos de backend tienen menos carga y más tiempo para recuperarse automáticamente, lo que se traduce en una recuperación más rápida y una tramitación satisfactoria de las solicitudes.
**Patrones comunes de uso no recomendados:**
+ Implementar los reintentos sin agregar valores de retroceso exponencial, fluctuación y reintentos máximos. El retroceso y la fluctuación ayudan a evitar picos de tráfico artificiales debidos a reintentos coordinados involuntariamente a intervalos comunes.
+ Implementar reintentos sin probar sus efectos o asumir que los reintentos ya están integrados en un SDK sin probar los escenarios de reintento.
+ No entender los códigos de error publicados de las dependencias, lo que lleva a volver a intentar todos los errores, incluidos los que tienen una causa clara que indica una falta de permisos, un error de configuración u otro problema que es de esperar que no se pueda resolver sin una intervención manual.
+ No utilizar prácticas de observabilidad, como supervisión y alertas en caso de errores de servicio repetidos, para conocer problemas subyacentes y poder solucionarlos.
+ Desarrollar mecanismos de reintento personalizados cuando son suficientes las capacidades de reintento integradas o de terceros.
+ Reintentar en varias capas de la pila de aplicaciones de una forma que se acumulen, lo que consume aún más recursos en una tormenta de reintentos. Asegúrese de entender cómo afectan estos errores a las dependencias en las que se basa y, a continuación, implemente los reintentos en un solo nivel.
+ Reintentar llamadas de servicio que no son idempotentes, lo que provoca efectos secundarios inesperados, como resultados duplicados.
**Beneficios de establecer esta práctica recomendada:** los reintentos ayudan a los clientes a obtener los resultados deseados cuando las solicitudes fallan, pero también consumen más tiempo del servidor para obtener las respuestas satisfactorias que desean. Cuando los errores son poco frecuentes o transitorios, los reintentos funcionan bien. Cuando los errores se deben a una sobrecarga de recursos, los reintentos pueden empeorar las cosas. Agregar un retroceso exponencial con fluctuaciones para los reintentos de los clientes permite que los servidores se recuperen cuando los errores se deben a una sobrecarga de recursos. La fluctuación evita que haya picos de solicitudes y el retroceso disminuye el escalamiento de la carga provocado por la adición de reintentos a la carga normal de solicitudes. Por último, es importante configurar un número de reintentos máximo o un tiempo transcurrido máximo para evitar que se acumulen tareas pendientes que generen errores metaestables.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Controle y limite las llamadas de reintento. Use el retroceso exponencial para los reintentos tras intervalos cada vez más largos. Introduzca una fluctuación para aleatorizar los intervalos de reintento y limite el número máximo de reintentos.
Algunos AWS SDK implementan los reintentos y el retroceso exponencial de forma predeterminada. Utilice estas implementaciones de AWS integradas cuando corresponda en su carga de trabajo. Implemente una lógica similar en su carga de trabajo cuando llame a servicios que sean idempotentes y en los que los reintentos mejoren la disponibilidad de sus clientes. Decida cuáles son los tiempos de espera y cuándo dejar de reintentar según su caso de uso. Cree y ejecute situaciones de prueba para esos casos de uso de reintentos.
## Pasos para la implementación
+ Determine la capa óptima de la pila de aplicaciones para implementar los reintentos de los servicios de los que depende su aplicación.
+ Tenga en cuenta que los SDK existentes implementan estrategias de reintento probadas con retroceso exponencial y fluctuaciones para el lenguaje que elija, y dé preferencia a estas estrategias en lugar de escribir sus propias implementaciones de reintentos.
+ Verifique que los [servicios sean idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) antes de implementar los reintentos. Una vez implementados, asegúrese de que se prueben y se utilicen regularmente en producción.
+ Al llamar a las API del servicio de AWS, utilice los [AWS SDK](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) y [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) y comprenda las opciones de configuración de reintentos. Determine si los valores predeterminados funcionan para su caso de uso, pruébelos y ajústelos según sea necesario.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL04-BP04 Cómo hacer idempotentes las operaciones de mutación](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Limitación de las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 Respuesta rápida a los errores y limitación de las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definición de los tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](rel_withstand_component_failures_monitoring_health.md)
**Documentos relacionados:**
+ [Error Retries and Exponential Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: Tiempos de espera, reintentos y retardo con fluctuación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Exponential Backoff and Jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ Making retries safe with idempotent APIs ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Ejemplos relacionados:**
+ [ Spring Retry ](https://github.com/spring-projects/spring-retry)
+ [ Resilience4j Retry ](https://resilience4j.readme.io/docs/retry)
**Videos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Herramientas relacionadas:**
+ [AWS SDKs and Tools: Retry behavior ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: Reintentos de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Respuesta rápida a los errores y limitación de las colas
Cuando un servicio no pueda responder correctamente a una solicitud, responda rápido a los errores. Esto permite que se liberen los recursos asociados a una solicitud y que un servicio se recupere cuando se le agotan los recursos. La respuesta rápida a los errores es un patrón de diseño de software bien establecido que se puede utilizar para conseguir cargas de trabajo enormemente fiables en la nube. Las colas también son un patrón de integración empresarial bien establecido que puede suavizar la carga y permitir a los clientes liberar recursos cuando se pueda tolerar el procesamiento asíncrono. Cuando un servicio puede responder correctamente en condiciones normales, pero falla cuando el índice de solicitudes es demasiado alto, utilice una cola para almacenar en búfer las solicitudes. Sin embargo, no permita que se acumulen largas colas de tareas pendientes, ya que eso podría hacer que se procesaran solicitudes obsoletas a las que un cliente ya ha renunciado.
**Resultado deseado:** cuando los sistemas sufren contención de recursos, tiempos de espera, excepciones o errores grises que hacen que los objetivos de nivel de servicio sean inalcanzables, las estrategias de respuesta rápida a los errores permiten recuperar el sistema más rápido. Los sistemas que deben absorber los picos de tráfico y pueden adaptarse al procesamiento asíncrono pueden mejorar la fiabilidad al permitir a los clientes liberar rápidamente las solicitudes mediante el uso de colas para almacenar en búfer las solicitudes a los servicios de backend. Cuando las solicitudes a las colas se almacenan en búfer, se implementan estrategias de administración de colas para evitar retrasos insuperables.
**Patrones comunes de uso no recomendados:**
+ Implementar colas de mensajes, pero no configurar colas de mensajes fallidos (DLQ) ni alarmas en los volúmenes de DLQ para detectar cuándo está fallando un sistema.
+ No medir la antigüedad de los mensajes de una cola, que es una medida de la latencia para saber cuándo los usuarios de la cola sufren retrasos o producen errores que dan lugar a reintentos.
+ No borrar los mensajes pendientes de una cola cuando no sirve de nada procesar esos mensajes si la empresa ya no necesita hacerlo.
+ Configurar colas de primero en entrar/primero en salir (FIFO) cuando las colas de último en entrar, primero en salir (LIFO) responderían mejor a las necesidades de los clientes, por ejemplo, cuando no se requieren pedidos estrictos y el procesamiento pendiente retrasa todas las solicitudes nuevas y urgentes, lo que hace que se infrinjan los niveles de servicio de todos los clientes.
+ Exponer las colas internas a los clientes en lugar de exponer las API que administran la entrada de trabajo y colocan las solicitudes en colas internas.
+ Combinar demasiados tipos de solicitudes de trabajo en una sola cola puede agravar las condiciones de las tareas pendientes al distribuir la demanda de recursos entre los tipos de solicitudes.
+ Procesar solicitudes complejas y simples en la misma cola, a pesar de necesitar diferentes niveles de supervisión, tiempos de espera y asignaciones de recursos.
+ No validar las entradas ni utilizar afirmaciones para implementar mecanismos de respuesta rápida a los errores en el software que envíen las excepciones a componentes de nivel superior que puedan gestionar los errores con facilidad.
+ No eliminar los recursos que fallan del enrutamiento de solicitudes, especialmente cuando los errores grises emiten tanto éxitos como errores debido a bloqueos y reinicios, errores de dependencia intermitentes, una reducción de la capacidad o la pérdida de paquetes de red.
**Beneficios de establecer esta práctica recomendada:** los sistemas que responden rápido a los errores son más fáciles de depurar y corregir y, a menudo, revelan problemas de codificación y configuración antes de que las versiones se publiquen en producción. Los sistemas que incorporan estrategias de puesta en cola eficaces tienen una mayor resiliencia y fiabilidad a los picos de tráfico y a las condiciones de errores intermitentes del sistema.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Las estrategias de respuesta rápida a los errores pueden codificarse en soluciones de software y también configurarse en la infraestructura. Además de la respuesta rápida a los errores, las colas son una técnica arquitectónica sencilla, pero potente, para desacoplar los componentes del sistema sin problemas de carga. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) proporciona capacidades para supervisar los errores y alertar en caso de que existan. Una vez que se sabe que un sistema está fallando, se pueden invocar estrategias de mitigación, como el alejamiento de los recursos deteriorados. Cuando los sistemas implementan colas con [Amazon SQS](https://aws.amazon.com/sqs/) y otras tecnologías de cola para facilitar la carga, deben considerar cómo administrar los atrasos en las colas, así como los errores en el consumo de mensajes.
## Pasos para la implementación
+ Implemente afirmaciones programáticas o métricas específicas en su software y utilícelas para alertar explícitamente sobre problemas del sistema. Amazon CloudWatch le ayuda a crear métricas y alarmas basadas en el patrón de registro de la aplicación y la instrumentación del SDK.
+ Utilice métricas y alarmas de CloudWatch para alejarse de los recursos deteriorados que aumentan la latencia del procesamiento o que no procesan las solicitudes de forma reiterada.
+ Utilice el procesamiento asíncrono diseñando API que acepten solicitudes y las anexen a las colas internas mediante Amazon SQS y, a continuación, respondan al cliente que produce los mensajes con un mensaje de éxito, de modo que el cliente pueda liberar recursos y continuar con otras tareas mientras los consumidores de la cola del backend procesan las solicitudes.
+ Para medir y supervisar la latencia de procesamiento de las colas, genere una métrica de CloudWatch cada vez que se retire un mensaje de una cola mediante la comparación en ese momento con la marca de tiempo del mensaje.
+ Cuando los errores impidan procesar correctamente los mensajes o los picos de tráfico en los volúmenes que no se pueden procesar dentro de los acuerdos de nivel de servicio, aparte el tráfico antiguo o excesivo y colóquelo en una cola secundaria. Esto permite procesar de forma prioritaria los trabajos nuevos y dejar los antiguos para cuando haya capacidad disponible. Esta técnica es una aproximación al procesamiento LIFO y permite que el sistema procese normalmente todos los trabajos nuevos.
+ Utilice colas de mensajes fallidos o redireccione las colas para sacar de la lista de espera los mensajes que no se puedan procesar y colocarlos en una ubicación que pueda investigarse y resolverse más adelante
+ Vuelva a intentarlo o, cuando sea tolerable, elimine los mensajes antiguos. Para ello, compárelos en ese momento con la marca de tiempo del mensaje y descarte los mensajes que ya no sean pertinentes para el cliente que los ha solicitado.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL04-BP02 Implementación de dependencias con acoplamiento débil](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Limitación de las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 Definición y cálculo de métricas (agregación)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Supervisión del seguimiento de las solicitudes de principio a fin en todo el sistema](rel_monitor_aws_resources_end_to_end.md)
**Documentos relacionados:**
+ [ Cómo evitar demoras de colas insuperables ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Fail Fast](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ ¿Cómo puedo evitar que se acumulen mensajes en mi cola de Amazon SQS? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: Zonal Shift ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Amazon Application Recovery Controller: Routing control for traffic failover ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Ejemplos relacionados:**
+ [ Enterprise Integration Patterns: Dead Letter Channel ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Videos relacionados:**
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Herramientas relacionadas:**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Definición de los tiempos de espera del cliente
Defina tiempos de espera adecuados para las conexiones y las solicitudes, verifíquelos sistemáticamente y no use los valores predeterminados, ya que no tienen en cuenta las características específicas de la carga de trabajo.
**Resultado deseado:** en los tiempos de espera de los clientes, se debe tener en cuenta el costo para el cliente, el servidor y la carga de trabajo asociados a la espera de las solicitudes que tardan un tiempo anormal en completarse. Dado que no es posible conocer la causa exacta de ningún tiempo de espera, los clientes deben utilizar el conocimiento de los servicios para fijar expectativas sobre las causas probables y los tiempos de espera adecuados
El tiempo de espera de las conexiones del cliente se agota en función de los valores configurados. Cuando el tiempo de espera se agota, los clientes toman la decisión de dar marcha atrás y volver a intentarlo o abrir un [disyuntor](https://martinfowler.com/bliki/CircuitBreaker.html). Estos patrones evitan que se emitan solicitudes que puedan agravar una condición de error subyacente.
**Patrones comunes de uso no recomendados:**
+ No estar al tanto de los tiempos de espera del sistema o de los tiempos de espera predeterminados.
+ No estar al tanto del tiempo normal de finalización de las solicitudes.
+ No conocer las posibles causas por las que las solicitudes tardan un tiempo anormalmente largo en completarse ni los costos para el rendimiento del cliente, el servicio o la carga de trabajo asociados a la espera a que se completen.
+ No conocer la probabilidad de que la red deteriorada haga que una solicitud falle solo una vez que se haya agotado el tiempo de espera, ni de los costos que supone para el rendimiento del cliente y la carga de trabajo no utilizar un tiempo de espera más corto.
+ No probar escenarios de tiempo de espera tanto para las conexiones como para las solicitudes.
+ Definir tiempos de espera demasiado altos, lo que puede provocar tiempos de espera prolongados y aumentar el uso de los recursos.
+ Definir tiempos de espera demasiado bajos, lo que provoca errores artificiales.
+ Pasar por alto los patrones para solucionar los errores de tiempo de espera de las llamadas remotas, como disyuntores y reintentos.
+ No considerar la posibilidad de supervisar los índices de errores de las llamadas de servicio, los objetivos de nivel de servicio referentes a la latencia y los valores atípicos de latencia. Estas métricas pueden proporcionar información sobre tiempos de espera agresivos o permisivos
**Beneficios de establecer esta práctica recomendada:** los tiempos de espera de las llamadas remotas están configurados y los sistemas están diseñados para gestionar los tiempos de espera correctamente, de modo que los recursos se conserven cuando las llamadas remotas responden con una lentitud anormal y los clientes del servicio gestionan correctamente los errores de tiempo de espera.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Defina un tiempo de espera de conexión y un tiempo de espera de solicitud en cualquier llamada de dependencia del servicio y, normalmente, en todas las llamadas de los procesos. Muchos marcos integran capacidades de tiempo de espera, pero tenga cuidado, ya que algunos tienen valores predeterminados que son infinitos o superiores a lo aceptable para sus objetivos de servicio. Un valor demasiado alto reduce la utilidad del tiempo de espera porque se siguen consumiendo recursos mientras el cliente espera a que transcurra el tiempo de espera. Un valor demasiado bajo puede generar un aumento del tráfico en el backend y un aumento de la latencia debido a que las solicitudes hacen demasiados reintentos. En algunos casos, esto puede producir una interrupción completa si se reintentan todas las solicitudes.
Tenga en cuenta lo siguiente al determinar las estrategias de tiempo de espera:
+ Las solicitudes pueden tardar más de lo normal en procesarse debido a su contenido, a deficiencias en un servicio de destino o a un error en la partición de la red.
+ Las solicitudes con contenido anormalmente caro podrían consumir recursos innecesarios del servidor y del cliente. En este caso, si se agota el tiempo de espera de estas solicitudes y no se vuelven a intentar, se pueden conservar los recursos. Los servicios también deberían protegerse del contenido anormalmente caro con restricciones y tiempos de espera del lado del servidor.
+ Se puede agotar el tiempo de espera y volver a intentar las solicitudes que tarden un tiempo anormalmente largo debido a una interrupción del servicio. Se deben tener en cuenta los costos del servicio de la solicitud y el reintento, pero si la causa es una deficiencia localizada, es probable que el reintento no sea caro y reduzca el consumo de recursos del cliente. El tiempo de espera también puede liberar recursos del servidor según la naturaleza de la deficiencia.
+ Se puede agotar el tiempo de espera y volver a intentar las solicitudes que tarden mucho en completarse porque la red no ha podido entregar la solicitud o la respuesta. Como la solicitud o la respuesta no se han entregado, el resultado habría sido un error independientemente del tiempo de espera. En este caso, el tiempo de espera no liberará los recursos del servidor, pero sí liberará los recursos del cliente y mejorará el rendimiento de la carga de trabajo.
Aproveche patrones de diseño bien establecidos, como los reintentos y los disyuntores, para gestionar los tiempos de espera correctamente y ofrecer enfoques de respuesta rápida a los errores. [AWS Los SDK](https://docs.aws.amazon.com/index.html#sdks) y [AWS CLI](https://aws.amazon.com/cli/) permiten configurar los tiempos de espera de conexión y solicitud y los reintentos con retrocesos y fluctuaciones exponenciales. Las funciones de [AWS Lambda](https://aws.amazon.com/lambda/) permiten configurar los tiempos de espera y, con [AWS Step Functions](https://aws.amazon.com/step-functions/), se pueden crear disyuntores con poco código que aprovechen las integraciones predefinidas con servicios de AWS y SDK. [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy incluye capacidades de tiempo de espera y de disyuntor.
## Pasos para la implementación
+ Configure tiempos de espera en las llamadas de servicio remotas y aproveche las características integradas de tiempo de espera del lenguaje o las bibliotecas de tiempo de espera de código abierto.
+ Cuando su carga de trabajo haga llamadas con un AWS SDK, consulte la documentación para ver la configuración del tiempo de espera específica de cada lenguaje.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Cuando utilice AWS SDK o comandos de la AWS CLI en su carga de trabajo, defina los valores predeterminados de tiempo de espera mediante la configuración de los [valores predeterminados de configuración](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) de AWS para `connectTimeoutInMillis` y `tlsNegotiationTimeoutInMillis`.
+ Aplique las [opciones de línea de comandos](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` y `cli-read-timeout` para controlar comandos únicos de la AWS CLI para los servicios de AWS.
+ Supervise las llamadas de servicio remotas para comprobar si hay tiempos de espera y configure alarmas en caso de errores persistentes para poder gestionar los escenarios de error de forma proactiva.
+ Implemente [métricas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) y la [detección de anomalías de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) en los índices de error de las llamadas, los objetivos de nivel de servicio en lo que se refiere a la latencia y los valores atípicos de latencia para proporcionar información sobre la administración de tiempos de espera demasiado agresivos o permisivos.
+ Configure los tiempos de espera en las [funciones de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ Los clientes de API Gateway deben implementar sus propios reintentos al gestionar los tiempos de espera. API Gateway admite un [tiempo de espera de integración de 50 milisegundos a 29 segundos](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) para las integraciones posteriores y no lo vuelve a intentar cuando la integración solicita el tiempo de espera.
+ Implemente el patrón de [disyuntor](https://martinfowler.com/bliki/CircuitBreaker.html) para que no se hagan llamadas remotas cuando se agote el tiempo de espera. Abra el circuito para evitar llamadas fallidas y ciérrelo cuando las llamadas respondan con normalidad.
+ Para las cargas de trabajo basadas en contenedores, consulte las funciones de [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) para aprovechar los tiempos de espera y los disyuntores integrados.
+ Utilice AWS Step Functions para crear disyuntores de poco código para las llamadas de servicio remotas, especialmente cuando se utilizan AWS SDK nativos e integraciones de Step Functions compatibles para simplificar la carga de trabajo.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Respuesta rápida a los errores y limitación de las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 Supervisión del seguimiento de las solicitudes de principio a fin en todo el sistema](rel_monitor_aws_resources_end_to_end.md)
**Documentos relacionados:**
+ [AWS SDK: Retries and Timeouts](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon Builders' Library: Tiempos de espera, reintentos y retardo con fluctuación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Cuotas de Amazon API Gateway y notas importantes ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: Command line options ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: Configure API Timeouts ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore using the config object and Config Reference ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK para .NET: Retries and Timeouts ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: Configuración de funciones de Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Ejemplos relacionados:**
+ [ Using the circuit breaker pattern with AWS Step Functions and Amazon DynamoDB ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler: CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Herramientas relacionadas:**
+ [AWS SDK ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 Creación de sistemas sin estado cuando sea posible
Los sistemas deben o bien no requerir estado o bien descargar el estado, de forma que entre solicitudes de clientes distintos no haya dependencia en los datos almacenados localmente en disco y en memoria. Esto permite reemplazar los servidores a voluntad sin que la disponibilidad resulte afectada.
Cuando los usuarios o los servicios interactúan con una aplicación, suelen llevar a cabo una serie de interacciones que constituyen una sesión. Una sesión es un dato único para los usuarios que persiste entre las solicitudes mientras utilizan la aplicación. Una aplicación sin estado es aquella que no necesita conocer las interacciones anteriores y no almacena la información de la sesión.
Una vez se ha diseñado para no tener estado, puede utilizar servicios de computación sin servidor, como AWS Lambda o AWS Fargate.
Además del reemplazo del servidor, otro beneficio de las aplicaciones sin estado es que pueden escalar horizontalmente porque cualquiera de los recursos de computación disponibles (como las instancias de EC2 y las funciones de AWS Lambda) puede dar servicio a cualquier solicitud.
**Beneficios de establecer esta práctica recomendada:** los sistemas que se han diseñado para no tener estado se adaptan mejor al escalado horizontal, lo que permite agregar o eliminar capacidad en función de la fluctuación del tráfico y la demanda. También son intrínsecamente resistentes a los errores y proporcionan flexibilidad y agilidad en el desarrollo de aplicaciones.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Cree aplicaciones sin estado. Las aplicaciones sin estado permiten el escalado horizontal y toleran el error de un nodo individual. Analice y comprenda los componentes de la aplicación que mantienen el estado dentro de la arquitectura. Esto le ayuda a evaluar el posible impacto de la transición a un diseño sin estado. Una arquitectura sin estado desacopla los datos del usuario y descarga los datos de la sesión. Esto proporciona la flexibilidad para escalar cada componente de forma independiente para cumplir con las diferentes demandas de carga de trabajo y optimizar el uso de los recursos.
### Pasos para la implementación
+ Identifique y comprenda los componentes con estado de la aplicación.
+ Para desacoplar los datos, separe y administre los datos de usuario de la lógica principal de la aplicación.
+ [Amazon Cognito](https://aws.amazon.com/cognito/) puede desacoplar los datos de usuario del código de la aplicación mediante características, tales como [grupos de identidades](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html), [grupos de usuarios](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html) y [Amazon Cognito Sync](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html).
+ Para usar [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) a fin de desacoplar los datos de usuario, almacene los secretos en una ubicación segura y centralizada. Esto significa que el código de la aplicación no necesita almacenar secretos, lo que la hace más segura.
+ Plantéese utilizar [Amazon S3](https://aws.amazon.com/s3/) para almacenar datos no estructurados y de gran volumen, como imágenes y documentos. La aplicación puede recuperar estos datos cuando sea necesario, lo que elimina la necesidad de almacenarlos en la memoria.
+ Utilice [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) para almacenar información, como, por ejemplo, perfiles de usuario. La aplicación puede consultar estos datos prácticamente en tiempo real.
+ Descargue los datos de la sesión en una base de datos, caché o archivos externos.
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/), Amazon DynamoDB, [Amazon Elastic File System](https://aws.amazon.com/efs/) (Amazon EFS) y [Amazon MemoryDB](https://aws.amazon.com/memorydb/) son ejemplos de servicios de AWS que puede usar para descargar datos de sesión.
+ Diseñe una arquitectura sin estado después de identificar qué datos de estado y de usuario deben conservarse con la solución de almacenamiento que elija.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL11-BP03 Automatización de la reparación en todas las capas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html)
**Documentos relacionados:**
+ [Amazon Builders' Library: Evitar los planes alternativos en los sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Cómo evitar demoras de colas insuperables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Prácticas recomendadas para el nivel web sin estado en AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html)
# REL05-BP07 Implementación de recursos de emergencia
Los recursos de emergencia son procesos rápidos que pueden mitigar el impacto en la disponibilidad de la carga de trabajo.
Los recursos de emergencia desactivan, limitan o cambian el comportamiento de componentes o dependencias mediante mecanismos conocidos y probados. Esto puede aliviar las deficiencias de la carga de trabajo causadas por el agotamiento de los recursos debido a los aumentos inesperados de la demanda y reducir el impacto de los fallos en los componentes no críticos de la carga de trabajo.
**Resultado deseado:** al implementar recursos de emergencia, puede establecer procesos que se sabe que son buenos para mantener la disponibilidad de los componentes críticos de su carga de trabajo. La carga de trabajo debe degradarse de forma estable y seguir llevando a cabo sus funciones críticas para la empresa durante la activación de un recurso de emergencia. Para obtener más información sobre la degradación estable, consulte [REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
**Patrones comunes de uso no recomendados:**
+ El fallo de las dependencias no críticas repercute en la disponibilidad de su carga de trabajo principal.
+ No probar o verificar el comportamiento de los componentes críticos durante el deterioro de los componentes no críticos.
+ No definir criterios claros y deterministas para la activación o desactivación de un recurso de emergencia.
**Beneficios de establecer esta práctica recomendada:** la implementación de recursos de emergencia puede mejorar la disponibilidad de los componentes críticos de su carga de trabajo al proporcionar a sus solucionadores procesos establecidos para responder a picos inesperados de demanda o fallos de dependencias no críticas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
+ Identifique los componentes críticos de su carga de trabajo.
+ Diseñe y cree los componentes críticos de su carga de trabajo para que resistan los fallos de los componentes no críticos.
+ Haga pruebas para validar el comportamiento de sus componentes críticos durante el fallo de los componentes no críticos.
+ Defina y supervise las métricas o los factores desencadenantes relevantes para iniciar los procedimientos de recursos de emergencia.
+ Defina los procedimientos (manuales o automáticos) que componen el recurso de emergencia.
### Pasos para la implementación
+ Identifique los componentes críticos para la empresa en su carga de trabajo.
+ Cada componente técnico de su carga de trabajo debe asignarse a su función empresarial relevante y clasificarse como crítico o no crítico. Para ver ejemplos de funciones críticas y no críticas de Amazon, consulte [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Se trata de una decisión tanto técnica como empresarial, y varía según la organización y la carga de trabajo.
+ Diseñe y cree los componentes críticos de su carga de trabajo para que resistan los fallos de los componentes no críticos.
+ Durante el análisis de dependencias, tenga en cuenta todos los modos de fallo potenciales y verifique que sus mecanismos de recursos de emergencia proporcionan la funcionalidad crítica a los componentes descendentes.
+ Haga pruebas para validar el comportamiento de sus componentes críticos durante la activación de sus recursos de emergencia.
+ Evite el comportamiento bimodal. Para obtener más información, consulte [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Defina, supervise y alerte sobre las métricas relevantes para iniciar el procedimiento del recurso de emergencia.
+ Encontrar las métricas adecuadas para supervisar depende de su carga de trabajo. Algunos ejemplos de métricas son la latencia o el número de solicitudes fallidas a una dependencia.
+ Defina los procedimientos manuales o automáticos que componen el recurso de emergencia.
+ Esto puede incluir mecanismos como el [desbordamiento de carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), la [limitación de solicitudes](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) o la implementación de una [degradación estable](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Limitación de las solicitudes](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Documentos relacionados:**
+ [ Automatización de implementaciones seguras y sin intervención ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Videos relacionados:**
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)