Escalabilidade e elasticidade

As 2 formas de um plano para mais tráfego dar errado

Uma rede de varejo dimensiona os servidores de checkout para um dia médio de vendas e é esmagada na primeira vez que uma promoção relâmpago dobra o tráfego da noite para o dia; requisições ficam na fila, páginas travam, e a promoção vira a história da queda em vez da história de faturamento. Um outro time exagera na direção oposta: provisiona servidores suficientes para sobreviver ao maior dia de vendas do ano e paga por essa mesma frota nos outros 364 dias, a maioria deles rodando com uma fração da capacidade. Nenhum dos 2 times resolveu o problema real, que tem 2 partes separadas: o sistema consegue crescer, e ele cresce (e encolhe) sozinho para acompanhar o que está acontecendo agora.

Recapitulando: crescimento que você já sabe fazer

A lição de computação anterior neste curso cobriu o scaling horizontal, adicionar mais instâncias do mesmo tamanho atrás de um load balancer, como uma resposta para ficar sem capacidade. O que ela não cobriu foi quem decide quando adicionar essas instâncias, ou quando tirá-las de novo depois que a carga passa. Essa lacuna, a camada de decisão em cima do scaling horizontal, é exatamente o que esta lição preenche.

Escalabilidade: a capacidade de crescer

Escalabilidade é a capacidade de um sistema de lidar com mais carga adicionando recursos, seja redimensionando 1 máquina (scaling vertical) ou adicionando mais máquinas do mesmo tamanho (scaling horizontal). Nada nessa definição diz que o crescimento precisa ser automático. Um time que percebe o tráfego subindo e sobe manualmente mais 3 instâncias escalou o sistema. Também escalou um departamento de TI on-premises que encomenda e instala 2 servidores físicos novos ao longo de um mês. Os 2 melhoraram a capacidade do sistema de lidar com carga; nenhum dos 2 fez isso sozinho, em tempo real, nem devolveu capacidade nenhuma depois que ela deixou de ser necessária.

Elasticidade: ajustar capacidade à demanda, automaticamente

Elasticidade é o que acontece quando essa decisão é automatizada nas 2 direções: a capacidade sobe conforme a demanda sobe e desce conforme a demanda cai, sem uma pessoa olhando um painel e clicando um botão a cada vez. É uma ideia genuinamente nativa da nuvem. Um servidor físico que você já comprou não reduz sua conta quando fica ocioso de madrugada; uma instância de nuvem encerrada durante um período calmo para de custar qualquer coisa no momento em que some. Elasticidade é o motivo de "pague só pelo que usar" ser mais que um slogan: o sistema precisa perceber de verdade quando "o que você usa" mudou, e agir sobre isso, continuamente, sem esperar por uma pessoa.

Imagine uma rodovia que engenheiros conseguem alargar com uma obra ao longo de vários meses, e compare com uma rodovia com uma faixa reversível que abre sozinha quando sensores detectam tráfego no horário de pico e fecha de novo assim que ele passa. Alargar a rodovia é escalabilidade: capacidade real, esforço real, e nenhum motivo para desfazer depois. A faixa reversível é elasticidade: a mesma via, redimensionada na hora e automaticamente para o tráfego que está nela agora, e fechada de novo assim que deixa de ser necessária. Force a comparação além desse ponto, porém, e ela quebra: a faixa reversível é uma peça fixa de infraestrutura que só é ligada e desligada, não criada e destruída, enquanto uma instância de nuvem é provisionada e desmontada por completo a cada vez, o que é exatamente o que faz ela não custar nada enquanto está fora do ar.

Exemplo prático: 1 dia dentro de um Auto Scaling group

Um Auto Scaling group é o mecanismo da AWS que automatiza isso. Digamos que um grupo está configurado com capacidade mínima de 4 instâncias, capacidade desejada de 6 e capacidade máxima de 12. Mínimo e máximo são limites rígidos que o grupo nunca cruza em nenhuma direção; a capacidade desejada é o ponto de partida que uma política de scaling ajusta dentro desse intervalo.

Às 9h, o tráfego sobe e o uso médio de CPU do grupo passa do alvo. Uma política de target tracking sobe instâncias novas, 1 ou 2 de cada vez, até o uso de CPU se estabilizar perto do alvo, com a capacidade chegando perto de 10 instâncias no meio da manhã. O tráfego se mantém ao longo do dia e cai às 18h; a mesma política agora encerra instâncias conforme o uso de CPU fica abaixo do alvo, reduzindo a capacidade de volta para perto de 6, e mais ainda em direção ao mínimo de 4 durante a madrugada. O grupo nunca toca o teto de 12 instâncias naquele dia, e nunca roda abaixo de 4. O time paga por cerca de 10 instâncias durante as 9 horas de movimento que precisam delas, e por bem menos durante a madrugada, em vez de rodar 12 (ou até 10 fixas) pelas 24 horas.

Políticas de scaling: 3 formas de dizer ao grupo quando agir

Essas políticas não se excluem. Um time de varejo pode rodar scaling programado para pré-aquecer capacidade pouco antes do pico conhecido das 9h, e deixar o target tracking cuidar das flutuações menores do resto do dia em cima desse ponto de partida.

Elasticidade também significa autocorreção

Auto Scaling groups fazem mais do que redimensionar para a demanda. Eles fazem health check contínuo em cada instância e substituem qualquer uma que falhe, automaticamente, para manter o grupo na capacidade desejada mesmo quando nada mudou no tráfego. Isso se conecta direto com a lição anterior: um Auto Scaling group distribuído em várias zonas de disponibilidade é parte de como uma arquitetura altamente disponível é construída desde o início, não uma preocupação separada dela.

Equívoco: "Auto Scaling" não é só sobre crescer

É tentador ouvir "Auto Scaling" e imaginar só a metade empolgante: adicionar capacidade automaticamente para sobreviver a um pico de tráfego. A metade que realmente economiza dinheiro é escalar para dentro, removendo capacidade assim que a demanda cai. Um grupo sem um mínimo que faça sentido ou sem política de scale-in vira só uma versão cara e autodisparada da escalabilidade comum: cresce sozinha, mas nunca devolve nada, e a vantagem de custo que a elasticidade deveria entregar nunca aparece na conta.

Dicas para a prova: lendo uma questão de escalabilidade versus elasticidade

Onde isso deixa você

Escalabilidade responde se um sistema consegue crescer. Elasticidade responde se ele cresce, e encolhe, sozinho, automaticamente, acompanhando uma demanda que muda minuto a minuto. Toda carga de trabalho na nuvem precisa da primeira. Só cargas de trabalho com demanda genuinamente variável tiram valor real da segunda, o que é a maioria delas, já que tráfego que nunca varia é raro fora de alguns sistemas internos estáveis. A próxima lição parte do princípio de que tudo isso já existe, redundância, health checks, capacidade no tamanho certo, e pergunta o que fazer quando, mesmo assim, uma falha é maior do que qualquer coisa aqui consegue absorver, e um time precisa recorrer a backups e a um plano de recuperação de desastres.