Escalabilidade de cargas de computação

Capacidade é uma decisão que alguém toma, e a pergunta é se esse alguém é uma pessoa olhando um dashboard ou uma política olhando uma métrica. Este tópico cobre como a AWS adiciona e remove computação por você: o Auto Scaling group que segura uma frota num tamanho declarado, os 5 tipos de política que decidem qual deve ser esse tamanho, os controles de ciclo de vida que tornam uma substituição segura, e como as mesmas ideias se traduzem quando a unidade de capacidade é uma task de contêiner ou uma única requisição.

O que este tópico cobre

• Os 3 números de capacidade de um Auto Scaling group, qual deles uma política de escala move, e por que os outros 2 são limites em vez de alvos
• Fontes de health check, o health check grace period e seus padrões diferentes no console e na CLI, o balanço entre zonas, a política de terminação padrão, e o que a proteção contra scale in não cobre
• Target tracking, step, simple, scheduled e predictive scaling, incluindo quais métricas o target tracking não consegue usar e como a AWS resolve várias políticas apontando para um mesmo grupo
• A diferença entre um período de cooldown e um instance warmup, e quais tipos de política usam cada um
• Os estados do ciclo de vida de instância no Auto Scaling, lifecycle hooks de launch e de terminação, warm pools para aplicações de boot lento, e standby versus detach
• Instance refresh: percentuais mínimo e máximo saudáveis, checkpoints, skip matching, auto rollback, e os padrões que mudam entre o console e a CLI
• Application Auto Scaling para serviços ECS, a segunda camada de escala embaixo de clusters em EC2, escala de pods e nós no EKS, e concorrência do Lambda

Por que isso importa

As questões de escala do SOA-C03 raramente perguntam o que é um Auto Scaling group. Elas entregam um sintoma (o grupo não passa de 12 instâncias, as substitutas morrem segundos depois do launch, as tasks ficam em PROVISIONING, uma função Lambda é estrangulada bem abaixo do limite de concorrência) e esperam que você nomeie o ajuste responsável. Isso exige conhecer os padrões, e não só os recursos, porque a maior parte dessas falhas é um padrão que ninguém escolheu.

A mesma habilidade decide como um incidente real termina. Uma frota que escala 6 minutos atrasada, um rollout que encerrou instâncias antes de as substitutas estarem prontas, ou um serviço colocando tasks num cluster sem espaço são todos recuperáveis em minutos se você souber qual camada está se comportando mal, e viram uma indisponibilidade longa se não souber.