Padrões arquiteturais de software: escala, resiliência e observabilidade

Fundamentos de Escala - Apresentação

Apresentando o instrutor e o objetivo do módulo

Olá, pessoal! Meu nome é Maurício, eu sou o CTO da Alura. Tenho 20 anos de experiência trabalhando com software em times e sistemas de diferentes tamanhos, já passei por Big Tech (grandes empresas de tecnologia) e, neste módulo, vamos começar a abordar fundamentos de escala.

Quando falamos de escala, pensamos em ampliar um serviço de software que passou a receber centenas, milhares, talvez milhões de usuários enviando requisições e esperando respostas. Vamos discutir como nós lidamos com esse crescimento.

Detalhando estratégias de escala e balanceamento de carga

Vamos cobrir tópicos como escala vertical, que é geralmente a forma como times de software começam a escalar um sistema que apresenta sinais de crescimento. Em seguida, abordaremos escala horizontal e, depois, escala diagonal — isto é, combinar vertical e horizontal — para ganharmos escala e flexibilidade quando isso acontecer.

Também trataremos de balanceamento de carga. Quando temos muitas máquinas trabalhando para nós, precisamos distribuir a carga: uma requisição chega e a encaminhamos para um servidor; outra requisição chega e vai para outro servidor, e assim por diante.

Implementando auto-scaling e serviços stateless

Vamos abordar auto-scaling (escala automática), prática essencial em sistemas de grande porte que enfrentam picos de tráfego. Esses picos podem nos surpreender, mas precisamos ser capazes de responder a esse aumento de forma indolor, sem necessidade de intervenção humana.

Em seguida, discutiremos a ideia de stateless services (serviços sem estado). Ao escalar horizontalmente — adicionando mais máquinas e servidores executando o mesmo serviço para atender a um grande volume de requisições — é importante que as instâncias não mantenham estado. Isso facilita a escala e a distribuição de carga entre várias instâncias do serviço.

Planejando capacidade e próximos passos

Por fim, trataremos de planejamento de capacidade. Quando operamos em grande escala e identificamos, a partir de dados históricos, momentos de pico — como em uma loja virtual durante a Black Friday —, precisamos nos planejar para que, nesses períodos críticos para a empresa, não sejamos surpreendidos e nosso sistema não fique fora do ar.

Vamos seguir nessa jornada.

Fundamentos de Escala - Escala Vertical

Explicando o escalonamento vertical

Neste vídeo, nós vamos tratar de escalonamento vertical. O escalonamento vertical é a maneira mais simples de escalar um serviço. Imaginemos que passamos a receber muitas solicitações, o número de pessoas usuárias aumentou e precisamos ampliar a capacidade computacional para suportar essa nova escala. O escalonamento vertical consiste basicamente em utilizar a mesma máquina onde o software já está em execução e aumentar o seu tamanho.

Suponhamos que hoje temos, por exemplo, 1 CPU e 1 GB de RAM. Ao escalar verticalmente, trocamos essa máquina por outra com, por exemplo, 2 CPUs e 2 GB de RAM. Se precisarmos escalar mais, podemos ir para 4 CPUs e 8 GB de RAM.

Essa é a ideia: aumentar o tamanho da máquina que já temos. Chamamos de escalonamento vertical porque ampliamos, para cima, os recursos dessa mesma máquina.

Destacando a facilidade e vantagens

O escalonamento vertical costuma ser a primeira opção das equipes porque, em geral, é mais fácil, especialmente hoje com o uso da nuvem. Em provedores como Amazon, Oracle ou Microsoft, basicamente solicitamos uma máquina maior.

A principal vantagem é que não precisamos alterar o programa: aumentamos o tamanho da máquina, reiniciamos o software e tudo continua funcionando.

Isso é diferente do que veremos quando abordarmos o escalonamento horizontal. Por essa razão, o escalonamento vertical frequentemente é a primeira alternativa, por ser muito simples de executar.

Abordando benefícios, limites e recomendações

Escalonamento vertical

O escalonamento vertical é muito atraente na fase inicial precisamente por sua simplicidade. Ainda não sabemos quantos usuários teremos, qual será o volume de dados com que lidaremos, quais problemas surgirão quando começarmos a receber mais pessoas acessando o serviço e assim por diante. Em vez de pensar em uma arquitetura muito complexa para fazer o sistema escalar, simplificamos e aumentamos o tamanho da máquina.

O escalonamento vertical, como praticamente toda decisão de arquitetura de software, em algum momento começa a mostrar seus problemas. As máquinas têm limites: chegaremos a um número máximo de CPUs que podemos colocar nessa máquina, a um máximo de memória RAM que podemos instalar, ou o custo começará a subir muito rápido, porque quanto maiores as máquinas, mais caras elas são. Em algum momento, veremos que ou esbarramos na barreira do limite físico da máquina, ou no limite do orçamento, pois computadores maiores são mais caros.

Em geral, nossa sugestão é sempre começar com o escalonamento vertical. É a opção mais simples: podemos apertar um botão no provedor de nuvem e escalar, sem precisar alterar o software; tudo continua funcionando. Agora, quando começarmos a perceber que estamos nos aproximando do tamanho máximo de máquina que o provedor de nuvem oferece, ou que o custo passou a crescer de forma exponencial, talvez seja o momento de considerar outra alternativa, como o escalonamento horizontal.

Fundamentos de Escala - Escala Horizontal

Contextualizando a necessidade de escala horizontal

Neste vídeo, vamos falar sobre escala horizontal. No vídeo anterior, tratamos de escala vertical, que ocorre quando escalamos aumentando o tamanho da máquina que temos, por exemplo, de uma CPU para duas CPUs. Em algum momento, porém, chegamos ao limite dessa técnica: não existem máquinas maiores disponíveis ou o custo se torna muito alto.

O que precisamos fazer? A resposta é simples: adicionar mais máquinas. Em vez de um único servidor respondendo por todas as solicitações da aplicação, colocamos duas máquinas respondendo às solicitações das pessoas usuárias. Quando duas máquinas não forem suficientes, colocamos três; depois quatro, cinco e assim por diante. Percebemos, então, que não temos mais o mesmo limite. Antes, existia um limite físico relacionado ao tamanho da máquina. Agora, não há limite para a quantidade de máquinas que podemos adquirir para distribuir o trabalho de responder a todas as solicitações que chegam. Afinal, é muito mais fácil ir adicionando várias máquinas menores lado a lado do que manter uma máquina gigantesca e continuar tentando escalá-la. Não existe o limite físico anterior; podemos posicionar quantas quisermos lado a lado.

Explicando os desafios de projetar para múltiplas máquinas

Uma desvantagem, entre aspas, da escala horizontal é que precisamos alterar a maneira como projetamos o sistema para que isso funcione. Na escala vertical, isto é, tudo em uma única máquina, não precisamos pensar no fato de haver várias máquinas respondendo a solicitações diferentes de pessoas usuárias distintas. E talvez a mesma pessoa usuária, na primeira solicitação, caia no servidor 1 e, na segunda, caia no servidor 2. Ao pensarmos em escalar horizontalmente, todas essas situações podem ocorrer.

Primeiro, precisamos garantir que as solicitações, quando chegam, sejam divididas de forma aproximadamente equilibrada: com duas máquinas, algo como 50% para cada uma; com três máquinas, cerca de um terço para cada. Portanto, precisamos de um componente na frente para controlar para onde cada solicitação vai.

Adotando serviços sem estado e considerando vantagens e desvantagens

Depois disso, devemos lembrar que, se a solicitação da pessoa usuária chegar à máquina 1, a seguinte pode chegar à máquina 2. Assim, a máquina 1 não pode manter nenhuma informação que a máquina 2 não possua. Isso é o que chamamos de estado compartilhado, e costuma ser uma ideia mais complexa quando pensamos em escala horizontal.

Por isso, preferimos projetar serviços sem estado. Ou seja, se a solicitação chegar ao servidor 1 ou ao servidor 2, tanto faz: qualquer servidor pode responder a qualquer solicitação de qualquer pessoa usuária.

Quando precisamos manter estado, como procedemos? Precisamos recorrer a recursos como banco de dados, cache, etc. Ao programarmos um sistema distribuído, passamos a considerar diversos outros aspectos que, antes, não eram necessários quando tudo estava em uma única máquina.

Em arquitetura de software, sempre existem vantagens e desvantagens em cada técnica. Nada é perfeito; não existe bala de prata.

Detalhando o papel do load balancer e a tolerância a falhas

O componente Load Balancer (balanceador de carga), como mencionamos, tem a função de dividir o tráfego. Quando chega uma requisição, ele analisa todas as máquinas disponíveis e decide: por exemplo, se a máquina número 3 está mais livre, encaminha a requisição para a máquina número 3; na próxima, verifica novamente e, se a máquina número 4 estiver mais disponível, envia para a máquina número 4. O próprio nome indica: o Load Balancer recebe a requisição e determina para onde ela deve ir.

Existem várias técnicas para que o Load Balancer decida o destino de cada requisição, e ele precisa ser suficientemente inteligente para lidar com falhas. Imaginemos que temos 10 máquinas e uma delas cai. Agora ainda existem 10 máquinas previstas, mas apenas 9 estão funcionando. O Load Balancer precisa detectar a falha e deixar de enviar requisições para essa máquina até que volte a operar. Isso adiciona complexidade: o Load Balancer é um software que requer atenção. Normalmente, não o implementamos do zero; provedores de nuvem como Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud Infrastructure (OCI), etc. oferecem esse componente. Porém, precisamos configurá-lo e garantir seu funcionamento.

Consolidando a escolha pela escala horizontal

Escala horizontal

A escala horizontal é, em essência, a escolha natural para software que precisa escalar. Em algum momento, ao atingirmos algumas centenas ou os primeiros milhares de pessoas usuárias, percebemos que uma única máquina não dá conta. A decisão pela escala horizontal torna-se bastante natural.

Na prática, todo serviço de porte moderado ou grande utiliza escala horizontal; é inviável escalar apenas de forma vertical. Costumamos começar com escala vertical quando temos algumas dezenas, talvez poucas centenas de pessoas usuárias; ao ultrapassar esse patamar, o próximo passo passa a ser a escala horizontal.

Neste vídeo, discutimos a ideia de escala horizontal. Qual é a ideia? Em vez de escalar aumentando a capacidade de uma única máquina, tornando-a mais potente, escalamos adicionando várias máquinas menores que, em conjunto, atendem a todas as requisições.

Sobre o curso Padrões arquiteturais de software: escala, resiliência e observabilidade

O curso Padrões arquiteturais de software: escala, resiliência e observabilidade possui 269 minutos de vídeos, em um total de 99 atividades. Gostou? Conheça nossos outros cursos de Arquitetura em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de Escala
• Arquitetura de Dados e Armazenamento
• Sistemas Assíncronos e Mensageria
• Resiliência e Tratamento de Falhas
• Arquitetura de Sistemas Distribuídos
• Observabilidade e Entregas Seguras