Pilares de confiabilidade e eficiência de desempenho

O pilar de Confiabilidade do Well-Architected Framework garante que uma carga de trabalho execute sua função prevista de forma correta e consistente quando necessário. A confiabilidade abrange três áreas: fundamentos (cotas de serviço e topologia de rede), arquitetura da carga de trabalho (sistemas distribuídos e prevenção de pontos únicos de falha) e gerenciamento de alterações e falhas (monitoramento, escalabilidade e recuperação de falhas). O objetivo é criar sistemas que se recuperem automaticamente de interrupções na infraestrutura ou nos serviços.

A AWS aplica cotas de serviço (antes chamadas de limites) aos recursos para proteger todos os clientes. Por exemplo, há limites padrão para instâncias do EC2 por região, limites de VPC e execuções simultâneas do Lambda. Se sua carga de trabalho atingir uma cota inesperadamente, as solicitações serão limitadas ou rejeitadas, causando falhas de confiabilidade. Use o console do Service Quotas ou a CLI para consultar os limites atuais e solicitar aumentos antes que sejam necessários. Monitore as métricas de uso para detectar quando você estiver se aproximando dos limites, antes que eles afetem a disponibilidade.

O pilar de Confiabilidade enfatiza a recuperação automática sem intervenção humana. A AWS oferece vários mecanismos de autocorreção: o EC2 Auto Recovery restaura automaticamente uma instância no mesmo hardware ou a move para um hardware íntegro quando ela falha nas verificações subjacentes. As verificações de integridade do ASG encerram instâncias não íntegras e iniciam substitutas. O RDS Multi-AZ executa automaticamente o failover para a instância em espera. Projete sua arquitetura para que a maioria dos cenários de falha acione ações de recuperação automática registradas nos alarmes do CloudWatch.

O pilar de Confiabilidade recomenda escalar horizontalmente (adicionar mais instâncias menores) em vez de verticalmente (aumentar para instâncias maiores) para obter mais confiabilidade. Uma única instância grande é um ponto único de falha. Muitas instâncias menores atrás de um balanceador de carga fazem com que qualquer falha individual tenha impacto mínimo. O AWS Auto Scaling ajusta automaticamente o tamanho da frota para atender à demanda, garantindo que você tenha capacidade suficiente e não pague por recursos ociosos durante períodos de baixa atividade.

O pilar de Confiabilidade exige testar os procedimentos de recuperação — não presumir que eles funcionam. Use o AWS Fault Injection Simulator (FIS) para injetar falhas no sistema de forma controlada: encerrar instâncias aleatórias do EC2, limitar chamadas de API e inserir latência de rede. Execute esses experimentos em produção (com proteções) para validar se o monitoramento detecta as falhas, o escalonamento automático responde e a recuperação é concluída dentro do seu RTO. Procedimentos de recuperação não testados frequentemente falham sob o estresse de um incidente real.

O pilar de Eficiência de desempenho concentra-se no uso eficiente dos recursos computacionais para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda e as tecnologias evoluem. Princípios fundamentais de design: democratizar tecnologias avançadas — usar serviços gerenciados (RDS, SageMaker) em vez de criá-los do zero. Alcançar escala global em minutos — implantar em várias regiões com o CloudFormation. Usar arquiteturas sem servidor — eliminar o gerenciamento da infraestrutura. Experimentar com mais frequência — testar diferentes tipos e configurações de instância.

A Eficiência de desempenho começa com a seleção do tipo de computação adequado para sua carga de trabalho. O EC2 tem dezenas de famílias de instâncias otimizadas para diferentes casos de uso: c-series para tarefas com uso intensivo de computação (codificação de vídeo e processamento em lote), r-series para tarefas com uso intensivo de memória (bancos de dados em memória e armazenamento em cache), i-series para tarefas com uso intensivo de armazenamento (NoSQL e armazenamento de dados) e p/g-series para cargas de trabalho de GPU (treinamento de ML). Usar o tipo de instância errado significa pagar por uma capacidade que você não consegue utilizar ou prejudicar o desempenho.

O armazenamento em cache é uma técnica fundamental de eficiência de desempenho que reduz a latência e a carga do banco de dados. O ElastiCache (Redis/Memcached) armazena resultados de consultas ao banco de dados na memória, permitindo acesso em milissegundos. O CloudFront armazena respostas HTTP em locais de borda próximos aos usuários. O armazenamento em cache do API Gateway reduz as invocações do Lambda ao armazenar respostas de API. O DAX (DynamoDB Accelerator) adiciona um cache em memória de microssegundos na frente do DynamoDB. Escolha a camada de cache adequada com base na localização do gargalo — banco de dados, API ou entrega na borda.

A escolha do armazenamento afeta significativamente o desempenho. O io2 Block Express EBS fornece até 256.000 IOPS para bancos de dados de alto desempenho. O gp3 é o padrão para a maioria das cargas de trabalho, com custo menor. O armazenamento de instância fornece os maiores IOPS (NVMe) para dados temporários. O S3 escala para milhares de solicitações por segundo no armazenamento de objetos. O EFS fornece acesso compartilhado a arquivos POSIX. Combine o armazenamento ao padrão de E/S: leituras sequenciais se beneficiam do st1 (HDD otimizado para Throughput), enquanto E/S aleatórias exigem volumes SSD.

A Eficiência de desempenho não é uma decisão única — você deve monitorar continuamente as métricas de desempenho e reavaliar suas escolhas à medida que a AWS lança novos serviços. Use painéis do CloudWatch para acompanhar os percentis de latência p50, p90 e p99 (não apenas médias, que ocultam a latência da cauda). Use rastreamentos do X-Ray para identificar as partes mais lentas de uma cadeia de solicitações. Configure a detecção de anomalias do CloudWatch para estabelecer automaticamente uma linha de base e alertar sobre desvios anormais de desempenho. Consulte regularmente os anúncios da AWS — tipos de instância mais novos frequentemente oferecem melhor desempenho a um custo menor.

A Eficiência de desempenho às vezes exige compensações com outros pilares. Adicionar um cache (ElastiCache) melhora o desempenho, mas aumenta a complexidade operacional (uma compensação com a Excelência operacional) e o custo (uma compensação com a Otimização de custos). Usar o DynamoDB em vez do RDS melhora o desempenho em escala, mas exige o redesenho do seu modelo de dados (um esforço de Excelência operacional). O Well-Architected Framework reconhece essas compensações e solicita que você as faça conscientemente, documentando a justificativa. Em questões de prova, procure a opção que atinge os objetivos de desempenho com a menor sobrecarga operacional.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: Confiabilidade exige recuperação automática, escalabilidade horizontal e testes regulares de falhas; Eficiência de desempenho exige selecionar o tipo adequado de computação, armazenamento e banco de dados para cada carga de trabalho; e o armazenamento em cache em várias camadas reduz a latência e a carga do banco de dados. Ambos os pilares exigem monitoramento contínuo e disposição para reavaliar as decisões de arquitetura. A seguir, exploraremos os pilares de Otimização de custos e Sustentabilidade.