APRENDER. PRATICAR. EVOLUIR.Contar a capacidade que sobrevive
Num serviço fictício, três zonas têm duas instâncias cada. Cada instância sustenta 80 pedidos por segundo nas condições do ensaio, e a procura prevista é 350. Após perder uma zona, quatro instâncias fornecem 320 pedidos por segundo neste modelo: faltam 30. O diagrama com três zonas não resolve a lacuna. Se o requisito exige servir sem esperar por novos lançamentos, dimensiona capacidade previamente disponível nas zonas sobreviventes e avalia dependências comuns. O cálculo não é um benchmark AWS nem inclui filas, variabilidade ou limites da base de dados. Usa-o para formular o ensaio de aceitação, com carga representativa, margem aprovada e critérios claros para degradação controlada. Capacidade também precisa de estado acessível: se cada sessão existe apenas na memória de uma instância, um pedido seguinte noutro target pode perder o contexto. Externaliza o estado necessário para um serviço partilhado adequado ou concebe pedidos independentes da instância anterior. Inclui a disponibilidade e consistência desse serviço na análise; adicionar instâncias não replica automaticamente sessões.
Interpretar saúde sem prometer isolamento absoluto
Um ALB normalmente seleciona destinos saudáveis no âmbito configurado, mas existe uma exceção importante: se todos os destinos registados do grupo ficam unhealthy nas zonas ativadas, pode ocorrer fail-open e o tráfego continuar a chegar-lhes. Não uses a simples reprovação de um health check como mecanismo garantido de isolamento. No diagnóstico, distingue ResponseCodeMismatch, Timeout e NotInUse; uma instância acessível diretamente pode estar numa zona não ativada ou num grupo sem regra de listener. Examina configuração e evidência antes de alargar o matcher. Aceitar erros como saúde para tornar o painel verde esconde a falha. Define também qual resposta limitada a aplicação consegue fornecer quando uma dependência comum falha.
Separar encaminhamento e substituição
Um worker web está unhealthy no ALB, mas o sistema operativo continua running e os checks EC2 passam. A equipa espera substituição automática pelo grupo. Confirma quais fontes de saúde estão ativadas no Auto Scaling: associar o grupo ao balanceador não basta para concluir que todos os checks de aplicação comandam a substituição. Durante arranque, uma grace period pode evitar substituições prematuras por checks ainda falhados. Essa proteção não mantém uma instância que deixou o estado running. Regista os dois fluxos: decisão de receber tráfego e decisão de substituir capacidade. Uma correção no primeiro fluxo pode deixar o segundo inalterado, pelo que a aceitação precisa de observar ambos.
Escolher o controlo certo para o arranque
Uma instância descarrega configuração antes de servir e depois preenche caches. O lifecycle hook pode manter uma fase de espera até terminar a preparação; inclui resultado, timeout e destino de falha. A grace period trata substituições por saúde durante o arranque. O default instance warmup trata a contribuição de métricas ainda instáveis para decisões de scaling. O slow start do target group, quando compatível com o algoritmo escolhido, aumenta gradualmente a fração de tráfego de um destino saudável. Estes controlos não são intercambiáveis. Desenha uma linha temporal desde lançamento até carga estável. Mede cada intervalo e explica qual sinal termina cada fase, evitando um único temporizador arbitrário para todas as decisões.
Escalar com métricas que respondem à capacidade
Uma equipa quer usar o total de pedidos recebidos como target tracking. Se duplicar as instâncias não altera a procura externa, esse total não mostra a redução de trabalho por instância. Compara uma métrica por destino com a capacidade sustentada, mantendo o intervalo e a distribuição de tráfego explícitos. Latência continua a ser útil para aceitar o serviço, mas uma métrica útil de observação não é automaticamente adequada ao mecanismo de scaling. Confirma ainda min, max, quotas e capacidade de lançamento. Se o grupo já está no máximo, outra violação do objetivo não cria margem adicional. Leva ao comité a procura, o limite encontrado e as opções com custo e risco.
Retirar destinos e aceitar a recuperação
Na retirada de um destino, o deregistration delay ajuda a concluir pedidos em curso, mas não mantém vivo um processo terminado pela aplicação. Alinha draining, encerramento e duração dos pedidos relevantes. Depois de uma falha, recuperar DNS ou contagem de instâncias é apenas uma parte do serviço: valida também estado, dependências, capacidade e resultado de negócio. RPO refere perda de dados tolerada no tempo; RTO refere o tempo objetivo até recuperação acordada. Na oficina documental, reserva quinze minutos para a linha temporal e vinte para uma matriz de resultados esperados em falha parcial, falha comum e recuperação. Os exemplos são fictícios; não foi executado um failover AWS. Entrega critérios observáveis e responsabilidades para o RUN. Se o restauro demora quatro horas e o RTO passa para trinta minutos, avalia warm standby: uma cópia funcional com capacidade reduzida já em execução. Mede crescimento, validação e transição; o nome da estratégia não garante o prazo. Um TTL ainda válido pode manter a resposta DNS anterior em cache, e ligações existentes precisam de tratamento próprio. Na oficina, compara clientes com cache recente e com nova resolução. Confirma ainda permissões e quotas no destino antes de aceitar o plano.
Três zonas com duas instâncias de 80 pedidos/s deixam 320 pedidos/s após perda de uma zona. Para uma procura de 350, a lacuna é 30; lançar substitutos mais tarde não cumpre um requisito sem espera.
Armadilhas comuns
Confundir saúde ALB com substituição ASG; assumir isolamento quando todos estão unhealthy; usar warmup para bloquear tráfego; terminar o processo antes de concluir draining.
Tópicos relacionados: Proteção e recuperação de dados · Recuperação: dependências, capacidade e custo · Computação: compromissos e retoma de batches
Planeia a capacidade que já existe, identifica o mecanismo de cada decisão e mede recuperação até ao serviço validado.
Referência: Disaster recovery options · SAA-C03