

# Projetar a workload para se adaptar às mudanças na demanda
<a name="design-your-workload-to-adapt-to-changes-in-demand"></a>

 Uma **workload** escalável fornece elasticidade para adicionar ou remover recursos automaticamente, de modo que eles correspondam perfeitamente à demanda atual em determinado momento. 

**Topics**
+ [REL07-BP01: Usar automação ao obter ou escalar recursos](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Obter recursos após a detecção de danos em uma workload](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Obter recursos após determinar que mais recursos são necessários para uma workload](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Fazer o teste de carga da workload](rel_adapt_to_changes_load_tested_adapt.md)

# REL07-BP01: Usar automação ao obter ou escalar recursos
<a name="rel_adapt_to_changes_autoscale_adapt"></a>

 A base da confiabilidade na nuvem é a definição programática, o provisionamento e o gerenciamento de sua infraestrutura e recursos. A automação ajuda você a otimizar o provisionamento de recursos, facilitar implantações consistentes e seguras e escalar recursos em toda a sua infraestrutura. 

 **Resultado desejado**: você gerencia sua infraestrutura como código (IaC). Você define e mantém seu código de infraestrutura em sistemas de controle de versão (VCS). Você delega o provisionamento de recursos da AWS a mecanismos automatizados e aproveita serviços gerenciados, como Application Load Balancer (ALB), Network Load Balancer (NLB) e grupos do Auto Scaling. Você provisiona seus recursos usando pipelines de integração contínua/entrega contínua (CI/CD) para que as alterações do código iniciem automaticamente as atualizações dos recursos, incluindo as atualizações das configurações do Auto Scaling. 

 **Práticas comuns que devem ser evitadas:** 
+  Implantar recursos manualmente usando a linha de comandos ou pelo Console de gerenciamento da AWS (também conhecido como *click-ops*). 
+  Acoplar fortemente os componentes ou recursos da aplicação e, como resultado, criar arquiteturas inflexíveis. 
+  Implementar políticas de escalabilidade inflexíveis que não se adaptam às mudanças nos requisitos de negócios, aos padrões de tráfego ou aos novos tipos de recursos. 
+  Estimar manualmente a capacidade para atender à demanda prevista. 

 **Benefícios de implementar essa prática recomendada:** a infraestrutura como código (IaC) permite que a infraestrutura seja definida de maneira programática. Isso ajuda você a gerenciar as mudanças na infraestrutura por meio do mesmo ciclo de vida de desenvolvimento de software das alterações nas aplicações, o que promove consistência e repetibilidade e reduz o risco de tarefas manuais propensas a erros. Você pode simplificar ainda mais o processo de provisionamento e atualização de recursos por meio da implementação de IaC com pipelines de entrega automatizados. Você pode implantar atualizações de infraestrutura de forma confiável e eficiente sem a necessidade de intervenção manual. Essa agilidade é particularmente importante ao escalar recursos para atender às demandas flutuantes. 

 Você pode alcançar uma escalabilidade dinâmica e automatizada de recursos em conjunto com IaC e pipelines de entrega. Ao monitorar as principais métricas e aplicar políticas de escalabilidade predefinidas, o Auto Scaling pode provisionar ou desprovisionar recursos automaticamente conforme necessário, o que melhora o desempenho e a economia. Isso reduz o potencial de erros manuais ou atrasos em resposta às mudanças nos requisitos da aplicação ou da workload. 

 A combinação de IaC, pipelines de entrega automatizados e Auto Scaling ajuda as organizações a provisionar, atualizar e escalar seus ambientes com confiança. Essa automação é essencial para manter uma infraestrutura de nuvem responsiva, resiliente e gerenciada com eficiência. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para configurar a automação com pipelines de CI/CD e infraestrutura como código (IaC) para sua arquitetura da AWS, escolha um sistema de controle de versão, como o Git, para armazenar modelos e configurações de IaC. Esses modelos podem ser escritos usando ferramentas como [AWS CloudFormation](https://aws.amazon.com/cloudformation/). Para começar, defina os componentes da infraestrutura (como VPCs da AWS, grupos do Amazon EC2 Auto Scaling e bancos de dados Amazon RDS) dentro desses modelos. 

 Depois, integre esses modelos de IaC a um pipeline de CI/CD para automatizar o processo de implantação. O [AWS CodePipeline](https://aws.amazon.com/codepipeline/) fornece uma solução integrada e nativa da AWS, mas você também pode usar outras soluções de CI/CD de terceiros. Crie um pipeline que seja ativado quando ocorrerem alterações no seu repositório de controle de versão. Configure o pipeline para incluir estágios que vinculam e validam os modelos de IaC, implantam a infraestrutura em um ambiente de preparação, executam testes automatizados e, por fim, implantam na produção. Incorpore etapas de aprovação quando necessário para manter o controle sobre as mudanças. Esse pipeline automatizado não apenas acelera a implantação, mas também facilita a consistência e a confiabilidade em todos os ambientes. 

 Configure o ajuste de escala automático dos recursos, como instâncias do Amazon EC2, tarefas do Amazon ECS e réplicas de banco de dados, na IaC para aumentar e reduzir horizontalmente a escala de forma automática, conforme necessário. Essa abordagem aprimora a disponibilidade e o desempenho das aplicações e otimiza os custos ajustando dinamicamente os recursos com base na demanda. Para conferir uma lista dos recursos compatíveis, consulte [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) e [AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). 

### Etapas de implementação
<a name="implementation-steps"></a>

1.  Crie e use um repositório de código-fonte para armazenar o código que controla sua configuração de infraestrutura. Confirme as alterações nesse repositório para refletir as alterações em andamento que você queira fazer. 

1.  Selecione uma solução de infraestrutura como código, como o AWS CloudFormation, para manter a infraestrutura atualizada e detectar inconsistências (desvios) em relação ao estado pretendido. 

1.  Integre sua plataforma de IaC ao seu pipeline de CI/CD para automatizar as implantações. 

1.  Determine e colete as métricas apropriadas para o ajuste de escala automático de recursos. 

1.  Configure o ajuste de escala automático dos recursos usando políticas de aumento e redução horizontal da escala para os componentes da workload. Considere usar a escalabilidade programada para padrões de uso previsíveis. 

1.  Monitore as implantações para detectar falhas e regressões. Implemente mecanismos de reversão em sua plataforma de CI/CD para reverter as alterações, se necessário. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling: como os planos de ajuste de escala funcionam](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: produtos que podem ser usados com o Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Usar um balanceador de carga com um grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
+  [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+  [O que é o AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
+  [O que é o Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) 
+  [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [O que é Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+  [O que é um Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [O que é um Application Load Balancer?](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) 

 **Vídeos relacionados:** 
+  [De volta ao básico: implante seu código no 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 Obter recursos após a detecção de danos em uma workload
<a name="rel_adapt_to_changes_reactive_adapt_auto"></a>

 Escale recursos de modo reativo quando necessário, se a disponibilidade for afetada, para restaurar a disponibilidade da workload. 

 Primeiro, você deve configurar as verificações de integridade e os critérios nessas verificações para indicar quando a disponibilidade é afetada pela falta de recursos. Notifique o pessoal apropriado para escalar manualmente o recurso ou inicie a automação para escalá-lo automaticamente. 

 A escala pode ser ajustada manualmente para a workload (por exemplo, alterando o número de instâncias do EC2 em um grupo do Auto Scaling ou modificando o throughput de uma tabela do DynamoDB por meio do Console de gerenciamento da AWS ou da AWS CLI). No entanto, a automação deve ser usada sempre que possível (consulte **Usar automação ao obter ou escalar recursos**). 

 **Resultado desejado:** as atividades de escalação (automática ou manual) são iniciadas para restaurar a disponibilidade após a detecção de uma falha ou degradação da experiência do cliente. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Implemente a observabilidade e o monitoramento em todos os componentes da workload para monitorar a experiência do cliente e detectar falhas. Defina os procedimentos, manuais ou automatizados, que escalam os recursos necessários. Para obter mais informações, consulte [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html). 

### Etapas de implementação
<a name="implementation-steps"></a>
+  Defina os procedimentos, manuais ou automatizados, que escalam os recursos necessários. 
  +  Os procedimentos de ajuste de escala dependem de como os diferentes componentes da workload são projetados. 
  +  Eles também variam dependendo da tecnologia subjacente utilizada. 
    +  Os componentes que usam o AWS Auto Scaling podem utilizar planos de ajuste de escala para configurar um conjunto de instruções para escalar os recursos. Se você usa o AWS CloudFormation ou adiciona tags a recursos da AWS, é possível configurar planos de ajuste de escala para diferentes conjuntos de recursos por aplicação. O Auto Scaling faz recomendações de estratégias de ajuste de escala personalizadas para cada recurso. Depois que você criar seu plano de ajuste de escala, o Auto Scaling combinará o ajuste de escala dinâmico com os métodos de escalabilidade preditiva para oferecer suporte à sua estratégia de ajuste de escala. Para obter mais detalhes, consulte [Como os planos de ajuste de escala funcionam](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html). 
    +  O Amazon EC2 Auto Scaling verifica se você tem o número correto de instâncias do Amazon EC2 disponíveis para processar a carga da sua aplicação. Você cria coleções de instâncias EC2, chamadas de grupos de Auto Scaling. É possível especificar o número mínimo e máximo de instâncias em cada grupo do Auto Scaling, e o Amazon EC2 Auto Scaling garantirá que o grupo nunca fique abaixo ou acima desses limites. Para obter mais detalhes, consulte [O que é o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)? 
    +  O Auto Scaling do Amazon DynamoDB usa o serviço Application Auto Scaling para ajustar dinamicamente a capacidade de throughput provisionado em seu nome em resposta aos padrões de tráfego reais. Isso permite que uma tabela ou um índice secundário global aumente a capacidade provisionada de leitura e gravação para processar aumentos repentinos no tráfego, sem limitações. Para obter mais detalhes, consulte [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [REL07-BP01 Usar automação ao obter ou escalar recursos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html) 

 **Documentos relacionados:** 
+  [AWS Auto Scaling: como os planos de ajuste de escala funcionam](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP03 Obter recursos após determinar que mais recursos são necessários para uma workload
<a name="rel_adapt_to_changes_proactive_adapt_auto"></a>

 Um dos atributos mais valiosos da computação em nuvem é a capacidade de provisionar recursos de maneira dinâmica. 

 Em ambientes computacionais on-premises tradicionais, você deve identificar e provisionar capacidade suficiente com antecedência para atender aos picos de demanda. Isso é um problema porque é caro e porque representa riscos à disponibilidade se você subestimar as necessidades de capacidade máxima da workload. 

 Na nuvem, isso não é necessário. Em vez disso, você pode provisionar a capacidade de computação, banco de dados e outros recursos conforme necessário para atender à demanda atual e prevista. Soluções automatizadas, como o Amazon EC2 Auto Scaling e o Application Auto Scaling, podem disponibilizar recursos on-line para você com base em métricas especificadas. Isso pode tornar o processo de escalabilidade mais fácil e previsível, além de tornar a workload significativamente mais confiável, garantindo que você tenha recursos suficientes disponíveis o tempo todo. 

 **Resultado desejado**: você configura o ajuste de escala automático da computação e de outros recursos para atender à demanda. Você fornece espaço suficiente nas políticas de escalabilidade para permitir que piscos de tráfego sejam atendidos enquanto recursos adicionais são colocados on-line. 

 **Práticas comuns que devem ser evitadas:** 
+  Provisionar um número fixo de recursos escaláveis. 
+  Escolher uma métrica de escalabilidade que não se correlaciona com a demanda real. 
+  Não fornecer espaço suficiente nos planos de escalabilidade para acomodar picos de demanda. 
+  As políticas de escalabilidade aumentam a capacidade tarde demais, o que leva à exaustão da capacidade e à degradação do serviço, enquanto recursos adicionais são colocados on-line. 
+  Não configurar corretamente as contagens mínima e máxima de recursos, o que leva a falhas de escalabilidade. 

 **Benefícios de implementar essa prática recomendada:** ter recursos suficientes para atender à demanda atual é fundamental para fornecer alta disponibilidade de workload e cumprir os objetivos definidos de nível de serviço (SLOs). O ajuste de escala automático permite que você forneça a quantidade certa de recursos de computação, banco de dados e outros que a workload precisa para atender à demanda atual e prevista. Você não precisa determinar as necessidades de pico de capacidade e alocar recursos estaticamente para atendê-las. Em vez disso, à medida que a demanda aumenta, você pode alocar mais recursos para acomodá-la e, depois que a demanda cair, pode desativar recursos para reduzir custos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Primeiro, determine se o componente da workload é adequado para o ajuste de escala automático. Esses componentes são chamados de *escaláveis horizontalmente* porque fornecem os mesmos recursos e se comportam de forma idêntica. Exemplos de componentes escaláveis horizontalmente incluem instâncias do EC2 que são configuradas da mesma forma, tarefas do [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) e pods executados no [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/). *Esses recursos computacionais geralmente estão localizados atrás de um balanceador de carga e são chamados de réplicas.* 

 Outros recursos replicados podem incluir réplicas de leitura de banco de dados, tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) e clusters do [Amazon ElastiCache](https://aws.amazon.com/elasticache/) (Redis OSS). Para obter uma lista completa dos recursos compatíveis, consulte [Serviços da AWS que você pode usar com o Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html). 

 Para arquiteturas baseadas em contêineres, talvez seja necessário escalar de duas maneiras diferentes. Primeiro, talvez seja necessário escalar os contêineres que fornecem serviços escaláveis horizontalmente. Depois, talvez seja necessário escalar os recursos de computação a fim de criar espaço para novos contêineres. Existem diferentes mecanismos de ajuste de escala automático para cada camada. Para escalar tarefas do ECS, você pode usar o [Application Auto](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) Scaling. Para escalar os pods do Kubernetes, você pode usar o [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) ou o [Kubernetes Event-driven Autoscaling (KEDA)](https://keda.sh/). Para escalar os recursos de computação, você pode usar [provedores de capacidade](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html) para o ECS ou, para Kubernetes, você pode usar o [Karpenter](https://karpenter.sh) ou o [Cluster Autoscaler](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/). 

 Em seguida, selecione como você executará o ajuste de escala automático. Há três opções principais: escalabilidade baseada em métrica, escalabilidade programada e escalabilidade preditiva. 

 **Escalabilidade baseada em métrica** 

 A escalabilidade baseada em métrica provisiona recursos com base no valor de uma ou mais *métricas de escalabilidade*. Uma métrica de escalabilidade corresponde à demanda da workload. Uma boa maneira de determinar métricas de escalabilidade adequadas é executar testes de carga em um ambiente que não seja de produção. Durante os testes de carga, mantenha fixo o número de recursos escaláveis e aumente aos poucos a demanda (por exemplo, throughput, simultaneidade ou usuários simulados). Em seguida, procure métricas que aumentem (ou diminuam) à medida que a demanda cresce e, inversamente, diminuam (ou aumentem) à medida que a demanda cai. Métricas de escalabilidade típicas incluem utilização da CPU, profundidade da fila de trabalhos (como uma fila do [Amazon SQS](https://aws.amazon.com/sqs/)), número de usuários ativos e throughput da rede. 

**nota**  
 A AWS observou que, na maioria das aplicações, a utilização de memória aumenta à medida que a aplicação se aquece, depois atinge um valor estável. Quando a demanda diminui, a utilização da memória normalmente permanece elevada em vez de diminuir paralelamente. Como a utilização da memória não corresponde à demanda em ambas as direções, ou seja, cresce e diminui com a demanda, reflita antes de selecionar essa métrica para ajuste de escala automático. 

 A escalabilidade baseada em métrica é uma *operação latente*. Pode levar vários minutos para que as métricas de utilização se propaguem para os mecanismos de ajuste de escala automático e esses mecanismos normalmente esperam por um sinal claro de aumento da demanda antes de reagir. Então, à medida que o mecanismo de ajuste de escala automático cria recursos, pode levar mais tempo para que eles fiquem totalmente operacionais. Por isso, é importante não definir suas metas métricas de escalabilidade muito próximas da utilização total (por exemplo, 90% de utilização da CPU). Fazer isso apresenta o risco de esgotar a capacidade de recursos existente antes que a capacidade adicional possa ser disponibilizada. As metas típicas de utilização de recursos podem variar entre 50 e 70% para uma disponibilidade ideal, dependendo dos padrões de demanda e do tempo necessário para provisionar recursos adicionais. 

 **Escalabilidade programada** 

 A escalabilidade programada provisiona ou remove recursos com base no calendário ou na hora do dia. É frequentemente usada para workloads com demanda previsível, como pico de utilização durante o horário comercial em dias úteis ou eventos de promoções. Tanto o [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) quanto o [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) oferecem suporte à escalabilidade programada. O [cron scaler](https://keda.sh/docs/latest/scalers/cron/) da KEDA oferece suporte à escalabilidade programada de pods do Kubernetes. 

 **Escalabilidade preditiva** 

 A escalabilidade preditiva usa machine learning para escalar automaticamente os recursos com base na demanda prevista. A escalabilidade preditiva analisa o valor histórico de uma métrica de utilização fornecida por você e prevê continuamente o valor futuro dela. O valor previsto é então usado para aumentar ou diminuir a escala do recurso. O [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) pode executar escalabilidade preditiva. 

### Etapas de implementação
<a name="implementation-steps"></a>

1.  Determine se o componente da workload é adequado para o ajuste de escala automático. 

1.  Determine que tipo de mecanismo de escalabilidade é mais apropriado para a workload: baseada em métrica, programada ou preditiva. 

1.  Selecione o mecanismo de ajuste de escala automático apropriado para o componente. Para instâncias do Amazon EC2, use o Amazon EC2 Auto Scaling. Para outros serviços da AWS, use o Application Auto Scaling. Para pods do Kubernetes (como aqueles executados em um cluster do Amazon EKS), considere o Horizontal Pod Autoscaler (HPA) ou o Kubernetes Event-driven Autoscaling (KEDA). Para nós do Kubernetes ou EKS, considere o Karpenter e o Cluster Auto Scaler (CAS). 

1.  Para escalabilidade baseada em métrica ou programada, realize testes de carga para determinar as métricas de escalabilidade e os valores-alvo apropriados para a workload. Para a escalabilidade programada, determine o número de recursos necessários nas datas e horários selecionados. Determine o número máximo de recursos necessários para atender ao pico de tráfego esperado. 

1.  Configure o escalador automático com base nas informações coletadas acima. Consulte a documentação do serviço de ajuste de escala automático para obter mais detalhes. Verifique se os limites máximo e mínimo de escalabilidade estão configurados corretamente. 

1.  Verifique se a configuração de escalabilidade está funcionando conforme esperado. Execute testes de carga em um ambiente que não seja de produção, observe como o sistema reage e ajuste conforme necessário. Ao ativar o ajuste de escala automático na produção, configure os alarmes apropriados para notificá-lo sobre qualquer comportamento inesperado. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+  [AWS Prescriptive Guidance: Load testing applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/) 
+  [AWS Marketplace: produtos que podem ser usados com o Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Ajuste de escala preditivo para o EC2 com Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [Ajuste de escala agendado para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+  [Histórias sobre a Lei de Little](https://brooker.co.za/blog/2018/06/20/littles-law.html) 

# REL07-BP04 Fazer o teste de carga da workload
<a name="rel_adapt_to_changes_load_tested_adapt"></a>

 Adote uma metodologia de teste de carga para avaliar se a ação de ajuste de escala atende aos requisitos da workload. 

 É importante realizar testes de carga sustentada. Os testes de carga devem descobrir o ponto de interrupção e testar a performance da workload. A AWS facilita a configuração de ambientes de teste temporários que modelam a escala de sua workload de produção. Na nuvem, é possível criar um ambiente de teste em escala de produção sob demanda, concluir seus testes e desativar os recursos. Como você paga somente pelo ambiente de teste quando está em execução, é possível simular seu ambiente ativo por uma fração do custo dos testes on-premises. 

 Os testes de carga em produção também devem ser considerados como parte dos game days em que o sistema de produção é destacado, durante horas de menor utilização do cliente, com todo o pessoal disponível para interpretar os resultados e resolver os problemas que surgirem. 

 **Práticas comuns que devem ser evitadas:** 
+  Executar testes de carga em implantações que não têm a mesma configuração da sua produção. 
+  Executar testes de carga apenas em componentes individuais da workload, e não nela toda. 
+  Executar testes de carga com um subconjunto de solicitações, e não com um conjunto representativo de solicitações reais. 
+  Executar testes de carga para um pequeno fator de segurança acima da carga esperada. 

 **Benefícios de implementar esta prática recomendada:** você sabe quais componentes em sua arquitetura falham sob carga e pode identificar as métricas que devem ser observadas para indicar que você está se aproximando dessa carga a tempo de resolver o problema, evitando o impacto dessa falha. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>
+  Realize testes de carga para identificar qual aspecto da workload indica que é necessário adicionar ou remover capacidade. Os testes de carga devem ter tráfego representativo semelhante ao que você recebe na produção. Aumente a carga enquanto observa as métricas que você preparou para determinar aquelas que indicam quando é necessário adicionar ou remover recursos. 
  +  [Teste de carga distribuída na AWS: simular milhares de usuários conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
    +  Identifique a combinação de solicitações. Diversas combinações de solicitações são possíveis. Portanto, você deve examinar vários períodos ao identificar a combinação de tráfego. 
    +  Implemente um direcionador de carga. É possível usar código personalizado, código aberto ou um software comercial para implementar um direcionador de carga. 
    +  Faça o teste de carga inicialmente com uma pequena capacidade. Você percebe alguns efeitos imediatos ao direcionar a carga para uma capacidade menor, possivelmente tão pequena quanto uma instância ou um contêiner. 
    +  Faça o teste de carga com uma capacidade maior. Os efeitos serão diferentes em uma carga distribuída, portanto, recomenda-se testar o mais próximo possível de um ambiente de produto. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Teste de carga distribuída na AWS: simular milhares de usuários conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
+  [Aplicações de teste de carga](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html) 

 **Vídeos relacionados:** 
+  [AWS Summit ANZ 2023: Acelerar com confiança com o teste de carga distribuída da AWS](https://www.youtube.com/watch?v=4J6lVqa6Yh8) 