Auto Scaling e alta disponibilidade tratam de garantir que seu servico nunca caia, mesmo quando componentes individuais falham.
Pense em gerenciar um restaurante. Durante o horario do almoco, voce chama pessoal extra (Auto Scaling para fora). Quando acalma a tarde, voce dispensa funcionarios (Auto Scaling para dentro). Voce distribui os clientes em todas as mesas disponiveis (Balanceamento de carga). Se uma cozinha pega fogo, a outra cozinha continua cozinhando (failover Multi-AZ). Esta e a essencia do design de alta disponibilidade na AWS.
Auto Scaling Group (ASG) — Ajustar automaticamente o numero de servidores
Um ASG adiciona ou remove instancias EC2 automaticamente com base na demanda.
Launch Template — A receita para criar instancias
Um Launch Template e como uma receita culinaria: define quais ingredientes usar (AMI, tipo de instancia) e como prepara-los (grupos de seguranca, par de chaves, configuracao de rede). Ele tambem inclui o script de User Data que e executado automaticamente quando uma instancia e iniciada, permitindo instalar software ou configurar ajustes na inicializacao.
Launch Configuration e um metodo antigo que ainda funciona mas nao e mais recomendado. Launch Template tem mais funcionalidades: versionamento, suporte a varios tipos de instancias e configuracao de Spot.
Configuracoes de capacidade
| Configuracao | Significado | Exemplo | |-------------|------------|---------| | Minimo | Nunca descer abaixo deste numero | Sempre manter pelo menos 2 | | Desejado | O numero-alvo agora mesmo | Atualmente apontando para 5 | | Maximo | Nunca exceder este numero | Nunca ultrapassar 20 independente da carga |
Definir Minimo como 0 permite escalar para zero (sem custo quando nao ha trafego), mas isso e arriscado para sistemas de producao. A maioria dos ambientes de producao mantем um minimo de 2 instancias.
Politicas de escalabilidade — Quando adicionar e remover servidores
Target Tracking
A politica de escalabilidade mais simples e recomendada. Voce define um valor-alvo de metrica e o ASG ajusta automaticamente o numero de instancias para mante-lo. Por exemplo: "manter o uso medio de CPU em 50%." Pense em um termostato: voce define a temperatura e o sistema cuida do aquecimento e resfriamento automaticamente.
Step Scaling
Diferentes limites de alarme acionam diferentes acoes de escala. Por exemplo: CPU 60-70%: adicionar 1 instancia CPU 70-80%: adicionar 2 instancias CPU acima de 80%: adicionar 3 instancias
Quando a carga e alta mas nao extrema, voce adiciona um pouco. Quando a carga e muito alta, voce adiciona mais agressivamente.
Scheduled Scaling
Escalabilidade baseada em tempo para padroes de trafego previsiveis. Por exemplo: "as 8:30 da manha de cada dia util, defina a capacidade para 10; as 18:00, reduza para 3." Perfeito para aplicacoes empresariais internas onde o uso e alto durante o horario comercial e quase zero a noite.
Predictive Scaling
Usa aprendizado de maquina para analisar padroes de trafego historicos e escalar proativamente antes que a demanda chegue. Se sua aplicacao consistentemente ve um pico de trafego toda segunda de manha, o Predictive Scaling comeca a adicionar instancias no domingo a noite.
| Politica | Mecanismo | Melhor para | |---------|----------|------------| | Target Tracking | Definir valor-alvo, ASG o mantem | A maioria das cargas de trabalho | | Step Scaling | Acoes diferentes em limiares diferentes | Controle detalhado | | Scheduled Scaling | Programacao baseada em tempo | Padroes de trafego previsiveis | | Predictive Scaling | ML prevê demanda futura | Picos recorrentes, escalabilidade proativa |
!4 tipos de política de Auto Scaling
ELB — Distribuindo trafego entre multiplos servidores
ELB (Elastic Load Balancer) distribui solicitacoes entrantes entre multiplas instancias EC2. Como um banco: em vez de todos os clientes fazerem fila para um unico caixa, eles sao distribuidos entre varios guiches.
Quatro tipos de ELB
ALB (Application Load Balancer) opera na Camada 7 (HTTP/HTTPS). Pode rotear solicitacoes para diferentes grupos de servidores com base no caminho da URL, nome do host, cabecalhos HTTP ou parametros de consulta. Por exemplo: solicitacoes para vao para seus servidores de API, e solicitacoes para vao para seus servidores de conteudo. Use ALB para aplicacoes web e microsservicos.
NLB (Network Load Balancer) opera na Camada 4 (TCP/UDP). Lida com milhoes de solicitacoes por segundo com latencia extremamente baixa. Pode ter enderecos IP estaticos. Use NLB para servidores de jogos, dispositivos IoT, sistemas de trading financeiro.
CLB (Classic Load Balancer) e o balanceador de carga original da AWS. Ainda funciona mas tem menos recursos. Nao use para novos sistemas.
GWLB (Gateway Load Balancer) opera na Camada 3 e e usado para inserir appliances de rede (firewalls, sistemas de deteccao/prevencao de intrusao) de forma transparente no seu caminho de trafego.
| Tipo ELB | Camada | Recurso-chave | Caso de uso | |---------|-------|-------------|------------| | ALB | Camada 7 (HTTP) | Roteamento por caminho/host | Apps web, microsservicos | | NLB | Camada 4 (TCP/UDP) | Ultra baixa latencia, IP estatico | Gaming, IoT, financas | | CLB | Camada 4/7 | Legado | Apenas sistemas existentes | | GWLB | Camada 3 | Insercao transparente de appliances | Firewalls, IDS/IPS |
Health Checks — Saber quando um servidor esta com defeito
Um health check verifica periodicamente se cada instancia esta funcionando. Se uma instancia falha no health check, o balanceador de carga para de enviar trafego para ela e o ASG a substitui.
Health Check EC2 vs Health Check ELB
| Tipo | O que verifica | O que detecta | |------|--------------|--------------| | Health check EC2 | Hardware fisico e hipervisor | Falha de hardware: a maquina fisica esta morta | | Health check ELB | Resposta da aplicacao (codigo HTTP) | Falha de aplicacao: o app esta retornando erros |
Este e um dos pontos de exame mais importantes neste dominio: se voce configura um ASG apenas com o health check EC2 padrao (sem o health check ELB), sua aplicacao pode cair e comecar a retornar erros HTTP 500, mas a propria instancia EC2 (a maquina fisica) continua funcionando normalmente. O health check EC2 diz "saudavel." O ASG nunca substitui a instancia quebrada.
Para corrigir isso, habilite os health checks ELB no ASG. Agora quando a aplicacao falha e retorna erros, o health check ELB falha e diz ao ASG que a instancia nao esta saudavel, e o ASG a encerra e substitui automaticamente.
Design Multi-AZ — Sobreviver quando uma localizacao falha
Uma Zona de Disponibilidade (AZ) e essencialmente um data center independente. Se uma AZ cair devido a uma queda de energia ou desastre natural, as outras AZs nao sao afetadas.
O principio central do design Multi-AZ: distribua seus recursos em pelo menos duas AZs.
Configure seu ASG para abranger multiplas AZs. Se uma AZ tiver problemas, as instancias nas outras AZs continuam processando o trafego.
ALB e NLB distribuem automaticamente o trafego entre instancias em multiplas AZs.
RDS Multi-AZ replica seu banco de dados de forma sincrona para uma instancia em standby em uma AZ diferente. Se o banco de dados primario falhar, a AWS promove automaticamente o standby, geralmente em 60-120 segundos. O endpoint permanece o mesmo, portanto nenhuma alteracao de codigo de aplicacao e necessaria.
ElastiCache com replicas em multiplas AZs melhora o desempenho de leitura e fornece capacidade de failover.
Politica de Instancias Mistas — Reduzir custos com instancias Spot
As instancias On-Demand estao sempre disponiveis a um preco fixo mas sao caras. As instancias Spot usam a capacidade sobressalente da AWS com ate 90% de desconto, mas a AWS pode recupera-las com 2 minutos de aviso.
A Politica de Instancias Mistas permite que um unico ASG combine ambas. Voce usa On-Demand para sua capacidade base estavel e Spot para capacidade adicional quando precisa escalar.
Exemplo: sempre manter 4 instancias On-Demand rodando. Quando o trafego aumenta, o ASG adiciona instancias Spot. Quando o trafego diminui, as instancias Spot sao encerradas primeiro.
Capacity Rebalancing: quando a AWS esta prestes a recuperar uma instancia Spot, ela proativamente inicia uma instancia substituta antes de encerrar a antiga, evitando quedas repentinas de capacidade.
Especificar varios tipos de instancias: listando varios tipos similares (m5.large, m5a.large, m4.large), voce da ao ASG mais opcoes no mercado Spot.
Capacity Reservations
Pre-reserve capacidade de instancias em uma AZ especifica. Use quando tem requisitos de conformidade ou planos de DR que garantem "devemos sempre ter 10 instancias c5.xlarge disponiveis em us-east-1a."
Pontos-chave do exame
"Forma mais simples de manter CPU em 50%" -- Target Tracking
"Adicionar numeros diferentes de instancias em diferentes niveis de CPU" -- Step Scaling