# REL 7. ¿Cómo diseña su carga de trabajo para adaptarla a los cambios de la demanda?
Una carga de trabajo escalable proporciona elasticidad para agregar o eliminar recursos automáticamente, de modo que se ajusten perfectamente a la demanda actual en cualquier momento dado.
**Topics**
+ [
# REL07-BP01 Uso de la automatización al obtener o escalar recursos
](rel_adapt_to_changes_autoscale_adapt.md)
+ [
# REL07-BP02 Obtención de recursos tras detectar un impedimento en una carga de trabajo
](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [
# REL07-BP03 Obtención de recursos tras detectar que se necesitan más recursos para una carga de trabajo
](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [
# REL07-BP04 Pruebas en su carga de trabajo
](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 Uso de la automatización al obtener o escalar recursos
La fiabilidad en la nube se basa en aspectos clave como la definición programática, el aprovisionamiento y la administración de la infraestructura y los recursos. La automatización lo ayuda a optimizar el aprovisionamiento de recursos, facilitar las implementaciones coherentes y seguras y escalar los recursos en toda su infraestructura.
**Resultado deseado**: gestione su infraestructura como código (IaC). Define y mantiene su código de infraestructura en los sistemas de control de versiones (VCS). Puede delegar el aprovisionamiento de los recursos de AWS en mecanismos automatizados y aprovechar los servicios gestionados, como los grupos Equilibrador de carga de aplicación (ALB), Equilibrador de carga de red (NLB) y de escalado automático. Los recursos se aprovisionan mediante canalizaciones de integración y entrega continuas (CI/CD) para que los cambios de código inicien automáticamente las actualizaciones de los recursos, incluidas las actualizaciones de las configuraciones de escalado automático.
**Patrones comunes de uso no recomendados:**
+ Los recursos se despliegan manualmente mediante la línea de comandos o la Consola de administración de AWS (también denominado *click-ops*).
+ Combina estrechamente los componentes o los recursos de la aplicación y, como resultado, crea arquitecturas inflexibles.
+ Implementa políticas de escalado inflexibles que no se adaptan a los cambiantes requisitos empresariales, a los patrones de tráfico o a los nuevos tipos de recursos.
+ La capacidad se estima manualmente para satisfacer la demanda prevista.
**Ventajas de establecer esta mejor práctica**: la infraestructura como código (IaC) permite definir la infraestructura mediante programación. Esto ayuda a gestionar los cambios en la infraestructura durante el mismo ciclo de vida de desarrollo de software que los cambios en las aplicaciones, lo que promueve la coherencia y la repetibilidad y reduce el riesgo de realizar tareas manuales propensas a errores. Puede optimizar aún más el proceso de aprovisionamiento y actualización de los recursos mediante la implementación de la IaC con canalizaciones de entrega automatizadas. Puede implementar actualizaciones de infraestructura de manera fiable y eficiente sin necesidad de intervención manual. Esta agilidad es especialmente importante a la hora de escalar los recursos para satisfacer las demandas fluctuantes.
Puede lograr un escalado de recursos dinámico y automatizado junto con la IaC y las canalizaciones de entrega. Al monitorear las métricas clave y aplicar políticas de escalado predefinidas, el escalado automático puede aprovisionar o desaprovisionar recursos automáticamente según sea necesario, lo que mejora el rendimiento y la rentabilidad. Esto reduce la posibilidad de que se produzcan errores manuales o demoras en respuesta a los cambios en los requisitos de las aplicaciones o la carga de trabajo.
La combinación de IaC, canalizaciones de entrega automatizadas y escalado automático ayuda a las organizaciones a aprovisionar, actualizar y escalar sus entornos con confianza. Esta automatización es esencial para mantener una infraestructura en la nube con capacidad de respuesta, resiliente y gestionada de manera eficiente.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Para configurar la automatización con canalizaciones de CI/CD e infraestructura como código (IaC) para su arquitectura de AWS, elija un sistema de control de versiones como Git para almacenar las plantillas y la configuración de IaC. Estas plantillas se pueden escribir con herramientas como [AWS CloudFormation](https://aws.amazon.com/cloudformation/). Para empezar, defina los componentes de su infraestructura (como las VPC de AWS, los grupos de Amazon EC2 Auto Scaling EC2 y las bases de datos de Amazon RDS) en estas plantillas.
A continuación, integre estas plantillas de IaC con una canalización de CI/CD para automatizar el proceso de implementación. [AWS CodePipeline](https://aws.amazon.com/codepipeline/) le ofrece una solución nativa de AWS perfecta, o puede utilizar otras soluciones de CI/CD de terceros. Cree una canalización que se active cuando se produzcan cambios en su repositorio de control de versiones. Configure la canalización para que incluya etapas que analicen y validen sus plantillas de IaC, implementen la infraestructura en un entorno provisional, ejecuten pruebas automatizadas y, por último, las implementen en la producción. Incorpore los pasos de aprobación cuando sea necesario para mantener el control de los cambios. Esta canalización automatizada no solo acelera la implementación, sino que también facilita la coherencia y la fiabilidad en todos los entornos.
Configure el escalado automático de recursos como instancias de Amazon EC2, tareas de Amazon ECS y réplicas de bases de datos en su IaC para proporcionar escalado horizontal y escalado vertical automáticos según sea necesario. Esta estrategia mejora la disponibilidad y el rendimiento de las aplicaciones y optimiza los costes mediante el ajuste dinámico de los recursos en función de la demanda. Para obtener una lista de los recursos compatibles, consulte [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) y [AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html).
### Pasos para la implementación
1. Cree y utilice un repositorio de código fuente para almacenar el código que controla la configuración de su infraestructura. Confirme los cambios en este repositorio para reflejar cualquier cambio en curso que desee realizar.
1. Seleccione una solución de infraestructura como código, por ejemplo, AWS CloudFormation, para mantener su infraestructura actualizada y detectar inconsistencias (desviaciones) con respecto al estado deseado.
1. Integre la plataforma IaC con la canalización de CI/CD para automatizar las implementaciones.
1. Determine y recopile las métricas adecuadas para el escalado automático de los recursos.
1. Configure el escalado automático de los recursos mediante políticas de escalado horizontal y vertical adecuadas para los componentes de la carga de trabajo. Plantéese la opción de utilizar el escalado programado para obtener patrones de uso predecibles.
1. Supervise las implementaciones para detectar errores y regresiones. Implemente mecanismos de reversión en su plataforma de CI/CD para revertir los cambios si es necesario.
## Recursos
**Documentos relacionados:**
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: productos que pueden usarse con escalado automático](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Administración automática de la capacidad de rendimiento con el escalado automático de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Usar un equilibrador de carga con un grupo de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [¿Qué es AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Qué es AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [Qué es Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [What is Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Qué es Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Qué es un equilibrador de carga de red?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Qué es un equilibrador de carga de aplicación?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Integrating Jenkins with AWS CodeBuild and AWS CodeDeploy](https://aws.amazon.com/blogs/devops/setting-up-a-ci-cd-pipeline-by-integrating-jenkins-with-aws-codebuild-and-aws-codedeploy/)
+ [Creating a four stage pipeline with AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html)
**Videos relacionados:**
+ [Back to Basics: Deploy Your Code to Amazon EC2](https://www.youtube.com/watch?v=f2wvEQ_sWS8)
+ [AWS Supports You \$1 Starting Your Infrastructure as Code Solution Using AWS CloudFormation Templates](https://www.youtube.com/watch?v=bgfx76jr7tA)
+ [Streamline Your Software Release Process Using AWS CodePipeline](https://www.youtube.com/watch?v=zMa5gTLrzmQ)
+ [Monitor AWS Resources Using Amazon CloudWatch Dashboards](https://www.youtube.com/watch?v=I7EFLChc07M)
+ [Create Cross Account & Cross Region CloudWatch Dashboards \$1 Amazon Web Services](https://www.youtube.com/watch?v=eIUZdaqColg)
# REL07-BP02 Obtención de recursos tras detectar un impedimento en una carga de trabajo
Escale recursos de forma retroactiva cuando sea necesario si la disponibilidad se ve afectada para restaurar la disponibilidad de la carga de trabajo.
Primero debe configurar las comprobaciones de estado y los criterios de dichas comprobaciones para indicar cuándo se ve afectada la disponibilidad por falta de recursos. A continuación, notifique al personal pertinente para que escale manualmente el recurso o inicie la automatización, a fin de que el escalado se lleve a cabo de forma automática.
La escala puede ajustarse manualmente para su carga de trabajo (por ejemplo, se puede cambiar el número de instancias de EC2 en un grupo de escalado automático o se puede modificar el rendimiento de una tabla de DynamoDB mediante la Consola de administración de AWS o la AWS CLI). Sin embargo, la automatización debe usarse siempre que sea posible (consulte **Usar la automatización al obtener o escalar recursos**).
**Resultado deseado:** se inician las actividades de escalado (de forma automática o manual) para restablecer la disponibilidad al detectar un error o una experiencia del cliente degradada.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Implemente la observabilidad y la supervisión en todos los componentes de su carga de trabajo para supervisar la experiencia del cliente y detectar errores. Defina los procedimientos, manuales o automatizados, que escalan los recursos necesarios. Para obtener más información, consulte [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html).
### Pasos para la implementación
+ Defina los procedimientos, manuales o automatizados, que escalan los recursos requeridos.
+ Los procedimientos de escalado dependen de cómo estén diseñados los distintos componentes de la carga de trabajo.
+ Estos procedimientos también varían según la tecnología subyacente que se utilice.
+ Los componentes que utilizan AWS Auto Scaling pueden usar planes de escalado para configurar un conjunto de instrucciones para escalar los recursos. Si trabaja con AWS CloudFormation o agrega etiquetas a recursos de AWS, puede configurar planes de escalamiento para diferentes conjuntos de recursos por aplicación. Auto Scaling proporciona recomendaciones de estrategias de escalado personalizadas según cada recurso. Tras crear el plan de escalado, Auto Scaling combina el escalado dinámico y los métodos de escalado predictivos para ayudarle en su estrategia de escalado. Para obtener más información, consulte [Cómo funcionan los planes de escalado](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html).
+ Amazon EC2 Auto Scaling verifica que tenga el número correcto de instancias de Amazon EC2 disponibles para gestionar la carga de la aplicación. Crea colecciones de instancias EC2, denominadas grupo de escalado automático. Puede especificar el número mínimo y máximo de instancias en cada grupo de Auto Scaling y Amazon EC2 Auto Scaling garantiza que su grupo nunca tenga un tamaño por encima o por debajo de este límite. Para obtener más información, consulte [¿Qué es Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ El escalado automático de Amazon DynamoDB usa el servicio Auto Scaling de aplicaciones de para ajustar de manera dinámica y automática la capacidad de rendimiento aprovisionada en respuesta a los patrones de tráfico reales. Esto permite a una tabla o índice secundario global incrementar su capacidad de lectura y escritura aprovisionada para abastecer incrementos repentinos del tráfico sin limitaciones. Para obtener más información, consulte [Administración automática de la capacidad de rendimiento con el escalado automático de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html).
## Recursos
**Prácticas recomendadas relacionadas:**
+ [ REL07-BP01 Uso de la automatización al obtener o escalar recursos ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**Documentos relacionados:**
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Administración automática de la capacidad de rendimiento con el escalado automático de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 Obtención de recursos tras detectar que se necesitan más recursos para una carga de trabajo
Una de las características más valiosas de la computación en la nube es la capacidad de aprovisionar recursos de forma dinámica.
En los entornos informáticos tradicionales en las instalaciones, debe identificar y aprovisionar suficiente capacidad con antelación para atender los picos de demanda. Esto supone un problema porque resulta caro y supone un riesgo para la disponibilidad si se subestiman las necesidades de capacidad máxima de la carga de trabajo.
En la nube, no tiene que realizar esta acción. En su lugar, puede aprovisionar la capacidad de cómputo, la base de datos y otros recursos según sea necesario para satisfacer la demanda actual y prevista. Las soluciones automatizadas, como Amazon EC2 Auto Scaling y el escalamiento automático de la aplicación, pueden poner los recursos en línea automáticamente en función de las métricas que especifique. Esto puede facilitar el proceso de escalado y hacerlo más predecible, así como mejorar la fiabilidad de su carga de trabajo al garantizar que haya recursos disponibles suficientes en todo momento.
**Resultado deseado**: configura el escalado automático de los recursos informáticos y otros recursos para satisfacer la demanda. Sus políticas de escalado ofrecen suficiente margen de maniobra para poder atender ráfagas de tráfico y, al mismo tiempo, poner en funcionamiento recursos adicionales.
**Patrones comunes de uso no recomendados:**
+ Aprovisiona un número fijo de recursos escalables.
+ Elige una métrica de escalado que no se correlaciona con la demanda real.
+ No proporciona suficiente margen de maniobra en sus planes de escalado para adaptarse a las ráfagas de demanda.
+ Sus políticas de escalado añaden capacidad demasiado tarde, lo que provoca el agotamiento de la capacidad y la degradación del servicio, a la vez que se ponen en línea recursos adicionales.
+ No configura correctamente los recuentos de recursos mínimos y máximos, lo que provoca errores de escalado.
**Ventajas de establecer esta práctica recomendada:** disponer de recursos suficientes para satisfacer la demanda actual es fundamental para ofrecer una alta disponibilidad de la carga de trabajo y cumplir los objetivos de nivel de servicio (SLO) definidos. El escalado automático le permite proporcionar la cantidad adecuada de recursos informáticos, de bases de datos y de otro tipo que su carga de trabajo necesita para satisfacer la demanda actual y prevista. No es necesario determinar las necesidades de capacidad máxima ni asignar recursos de forma estática para atenderlas. En cambio, a medida que aumenta la demanda, puede asignar más recursos para adaptarla y, una vez que la demanda disminuya, puede desactivar los recursos para reducir los costes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
En primer lugar, determine si el componente de la carga de trabajo es adecuado para el escalado automático. Estos componentes se denominan *escalables horizontalmente* porque proporcionan los mismos recursos y se comportan de forma idéntica. Entre los ejemplos de componentes escalables horizontalmente se incluyen las instancias de EC2 que están configuradas de forma similar, las tareas de [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) y los pods que se ejecutan en [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/). *Estos recursos de cómputo suelen estar ubicados detrás de un equilibrador de carga y se denominan réplicas.*
Otros recursos replicados pueden incluir réplicas de lectura de bases de datos, tablas de [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) y clústeres de [Amazon ElastiCache](https://aws.amazon.com/elasticache/) (Redis OSS). Para obtener una lista completa de los recursos admitidos, consulte [los servicios de AWS que puede utilizar con el escalamiento automático de la aplicación](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html).
En el caso de las arquitecturas basadas en contenedores, es posible que necesite escalar de dos maneras diferentes. En primer lugar, tal vez necesite escalar los contenedores que proporcionan servicios escalables horizontalmente. En segundo lugar, puede que necesite escalar los recursos informáticos para dejar espacio para nuevos contenedores. Existen diferentes mecanismos de escalado automático para cada capa. Para escalar las tareas de ECS, puede usar el [escalamiento automático de la aplicación](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html). Para escalar los pods de Kubernetes, puede usar el [escalador automático de pods horizontal (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) o el [escalado automático controlado por eventos de Kubernetes (KEDA)](https://keda.sh/). Para escalar los recursos de computación, puede usar los [proveedores de capacidad](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html) para ECS o, para Kubernetes, puede usar [Karpenter](https://karpenter.sh) o el [Cluster Autoscaler](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/).
A continuación, seleccione cómo realizará el escalado automático. Hay tres opciones principales: el escalado basado en métricas, el escalado programado y el escalado predictivo.
**Escalado basado en métricas**
El escalado basado en métricas aprovisiona los recursos en función del valor de una o más *métricas de escalado*. Una métrica de escalado es aquella que corresponde a la demanda de su carga de trabajo. Una buena forma de determinar las métricas de escalado adecuadas es realizar pruebas de carga en un entorno que no sea de producción. Durante las pruebas de carga, mantenga fija la cantidad de recursos escalables y aumente lentamente la demanda (por ejemplo, el rendimiento, la simultaneidad o los usuarios simulados). A continuación, busque métricas que aumenten (o disminuyan) a medida que aumente la demanda y, a la inversa, que disminuyan (o aumenten) a medida que la demanda disminuya. Las métricas de escalado típicas incluyen el uso de la CPU, la profundidad de las colas de trabajo (como una cola de [Amazon SQS](https://aws.amazon.com/sqs/)), el número de usuarios activos y el rendimiento de la red.
**nota**
AWS ha observado que, en la mayoría de las aplicaciones, la utilización de la memoria aumenta a medida que la aplicación se calienta y, después, alcanza un valor estable. Cuando la demanda disminuye, la utilización de la memoria suele mantenerse elevada en lugar de disminuir en consecuencia. Como la utilización de la memoria no se corresponde con la demanda en ambas direcciones (es decir, aumentando o disminuyendo según la demanda), piénseselo bien antes de seleccionar esta métrica para el escalado automático.
El escalado basado en métricas es una *operación latente*. Las métricas de utilización pueden tardar varios minutos en propagarse a los mecanismos de escalado automático y, por lo general, estos mecanismos esperan una señal clara de aumento de la demanda antes de reaccionar. Luego, a medida que el escalador automático crea nuevos recursos, es posible que tarde más tiempo en funcionar por completo. Por este motivo, es importante no fijar los objetivos de las métricas de escalado demasiado cerca de la plena utilización (por ejemplo, un 90 % de utilización de la CPU). Si lo hace, se corre el riesgo de agotar la capacidad de recursos existente antes de que se pueda poner en línea capacidad adicional. Los objetivos típicos de utilización de los recursos pueden oscilar entre el 50 % y el 70 % para lograr una disponibilidad óptima, en función de los patrones de demanda y del tiempo necesario para aprovisionar recursos adicionales.
**Escalado programado**
El escalado programado aprovisiona o elimina recursos según el calendario o la hora del día. Se usa con frecuencia para cargas de trabajo que tienen una demanda predecible, como los picos de uso durante el horario laboral de lunes a viernes o en eventos de ventas. Tanto [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) como el [escalamiento automático de la aplicación](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) admiten el escalado programado. El [escalador cron](https://keda.sh/docs/latest/scalers/cron/) de KEDA admite el escalado programado de los pods de Kubernetes.
**Escalado predictivo**
El escalado predictivo utiliza machine learning para escalar automáticamente los recursos en función de la demanda prevista. Analiza el valor histórico de la métrica de utilización que le proporcione y predice continuamente su valor futuro. A continuación, el valor previsto se utiliza para escalar el recurso hacia arriba o hacia abajo. [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) puede realizar un escalado predictivo.
### Pasos para la implementación
1. En primer lugar, determine si el componente de la carga de trabajo es adecuado para el escalado automático.
1. Determine qué tipo de mecanismo de escalado es el más adecuado para la carga de trabajo: escalado basado en métricas, escalado programado o escalado predictivo.
1. Seleccione el mecanismo de escalado automático adecuado para el componente. Para instancias Amazon EC2, utilice Amazon EC2 Auto Scaling. Para otros servicios de AWS, utilice el escalamiento automático de la aplicación. Para los pods de Kubernetes (como los que se ejecutan en un clúster de Amazon EKS), puede usar el escalador automático de pods horizontal (HPA) o el escalado automático controlado por eventos de Kubernetes (KEDA). Para los nodos de Kubernetes o EKS, puede usar Karpenter y Cluster Auto Scaler (CAS).
1. Para el escalado con métricas o programado, realice pruebas de carga para determinar las métricas de escalado y los valores objetivo adecuados para su carga de trabajo. Para el escalado programado, determine la cantidad de recursos necesarios en las fechas y horas que seleccione. Determine el número máximo de recursos necesarios para atender los picos de tráfico previstos.
1. Configure el escalador automático en función de la información recopilada anteriormente. Consulte la documentación del servicio de escalado automático para obtener información más detallada. Compruebe que los límites de escalado máximo y mínimo estén configurados correctamente.
1. Compruebe que la configuración de escalado funciona según lo esperado. Realice las pruebas de carga en un entorno que no sea de producción, observe cómo reacciona el sistema y haga los ajustes pertinentes. Cuando habilite el escalado automático en producción, configure las alarmas adecuadas para que le notifiquen cualquier comportamiento inesperado.
## Recursos
**Documentos relacionados:**
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Orientación normativa de AWS: aplicaciones de prueba de carga](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/)
+ [AWS Marketplace: productos que pueden usarse con escalado automático](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Administración automática de la capacidad de rendimiento con el escalado automático de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Scheduled Scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
# REL07-BP04 Pruebas en su carga de trabajo
Adopte una metodología de prueba de carga para medir si la actividad de escalado satisface los requisitos de la carga de trabajo.
Es importante llevar a cabo pruebas de carga sostenidas. Las pruebas de carga deben descubrir el punto de ruptura y probar el rendimiento de su carga de trabajo. AWS facilita la creación de entornos de prueba temporales que modelan la escala de su carga de trabajo de producción. En la nube, puede crear un entorno de prueba a escala de producción, completar sus pruebas y desmantelar los recursos. Debido a que solo paga por el entorno de prueba cuando se ejecuta, puede simular su entorno real por una fracción del costo de las pruebas en las instalaciones.
Las pruebas de carga en producción también deben considerarse como parte de los días de juegos en los que se estresa el sistema de producción, durante las horas de menor uso por parte de los clientes, con todo el personal a mano para interpretar los resultados y abordar cualquier problema que surja.
**Patrones comunes de uso no recomendados:**
+ Hacer pruebas de carga en implementaciones que no tienen la misma configuración que su producción.
+ Hacer pruebas de carga solo en elementos individuales de su carga de trabajo y no en toda la carga.
+ Hacer pruebas de carga con un subconjunto de solicitudes y no con un conjunto representativo de solicitudes reales.
+ Hacer pruebas de carga con un pequeño factor de seguridad por encima de la carga prevista.
**Beneficios de establecer esta práctica recomendada:** sabrá qué componentes de su arquitectura presentan errores bajo carga y podrá identificar qué métricas se deben vigilar para indicar que se está acercando a esa carga a tiempo para solucionar el problema, con lo que se evitará el impacto de ese error.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
+ Haga pruebas de carga para identificar qué aspecto de su carga de trabajo indica que debe agregar o eliminar capacidad. Las pruebas de carga deben tener un tráfico representativo similar al que se recibe en producción. Aumente la carga mientras vigila las métricas que ha instrumentado para determinar qué métrica indica cuándo debe agregar o eliminar recursos.
+ [Pruebas de carga distribuida en AWS: simular miles de usuarios conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ Identifique la combinación de solicitudes. Es posible que tenga una combinación variada de solicitudes, por lo que deberá tener en cuenta diversos periodos de tiempo a la hora de identificar la combinación de tráfico.
+ Implemente un controlador de carga. Puede utilizar software de código personalizado, de código abierto o comercial para implementar un controlador de carga.
+ Haga la prueba de carga inicialmente con una capacidad pequeña. Ve algunos efectos inmediatos al pasar la carga a una capacidad menor, posiblemente tan pequeña como una instancia o un contenedor.
+ Lleve a cabo una prueba de carga con una capacidad mayor. Los efectos serán diferentes en una carga distribuida, por lo que debe efectuar las pruebas en un entorno lo más parecido al del producto.
## Recursos
**Documentos relacionados:**
+ [Pruebas de carga distribuida en AWS: simular miles de usuarios conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Aplicaciones de pruebas de carga](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
**Videos relacionados:**
+ [AWS Summit ANZ 2023: Accelerate with confidence through AWS Distributed Load Testing](https://www.youtube.com/watch?v=4J6lVqa6Yh8)