Design de Sistemas Distribuídos — Escalonamento Vertical e Horizontal
Bem vindos ao segundo artigo da série sobre Design de Sistemas e Sistemas Distribuídos!
Você pode ler o artigo anterior da série aqui.
Nesse artigo da série vamos falar sobre um dos principais pontos que devem ser considerados no processo de design de um software distribuído, escalabilidade e suas abordagens.
Complementando a definição utilizada no artigo anterior da série:
Escalabilidade é a capacidade de ajustar o sistema ao desempenho ideal, o que geralmente significa lidar com mais carga de trabalho com baixo custo.
Analisando a imagem acima, tentei retratar da forma mais simples possível a diferença entre os principais tipos de escalonamento (vertical e horizontal), para então detalhar sobre as características, vantagens e desvantagens de cada abordagem.
Escalonamento Vertical
Profissionais com 10 anos ou mais de experiência, conhecem bem a abordagem de escalonamento vertical, pois na época dos Data Centers proprietários, não existia a “Nuvem” (termo utilizado para se referir a Computação na Nuvem ou Cloud Computing) e seu leque de possibilidades.
Comumente os cenários que se destacavam eram: de um lado micro e pequenas empresas utilizando computadores em sua estrutura local como servidores. De outro médias e grandes empresas investindo fortunas em data centers próprios para atender as demandas de seu negócio, sendo estas: hospedagem do site, hospedagem de aplicações como ERP, E-Commerce e gestão de arquivos.
Como é sabido, manter uma infraestrutura própria gera um custo enorme de manutenção. Visto que os negócios crescem a cada dia de forma mais acelerada, fica mais difícil ainda manter tais estruturas principalmente para empresas que não são do segmento de tecnologia.
Nesses cenários a abordagem mais aplicada era a de Escalonamento Vertical, que significa nada mais nada menos que adicionar mais poder de processamento (CPU, Memória RAM) a um servidor existente.
Contextualizando:
Imaginemos uma empresa que possui um e-commerce e hospede-o nesse modelo tentando manter sua loja virtual estável e disponível no dia de uma black friday, por exemplo.
Já seria bem difícil gerir os recursos sob demanda em real-time apenas por adicionar mais recursos nos horários de picos de requisições/tarefas, agora imagine então um cenário onde algum recurso de hardware venha a falhar, por exemplo: um processador queimado. A substituição deixaria o serviço em questão indisponível por longos minutos ou até horas.
O escalonamento vertical se mostra por muitas vezes inviável até nas melhores infraestruturas (empresas de cloud também proporcionam essa abordagem) por questões de custo.
Exemplo:
Algumas características da abordagem vertical:
1 — Único Ponto de Falha
Uma das vantagens dessa abordagem é a identificação e resolução de falhas, pois como se trata de centralização de vários serviços em um único host, facilmente com acesso ao servidor identifica-se motivos de falhas entre os processos. Ao mesmo tempo torna-se uma desvantagem, visto que se a execução da aplicação for interrompida por falha, não existem meios otimizados de recuperar os processos que estavam em execução, ou seja, serviço ficará fora do ar por algum tempo.
2 — Comunicação entre Processos (IPC — Inter-Process Communication)
Como nesse modelo ocorre uma centralização de serviços e aplicações em um único host, a comunicação ocorre a nível de processos, portanto, muito mais rápida que no modelo de escalonamento horizontal, onde têm-se comunicação entre diferentes hosts utilizando comunicação/requisições de rede.
3 — Consistência
Citando novamente a centralização dos dados, isso gera mais consistência dos mesmos, pelo simples fato destas informações não estarem sendo concorridas por várias aplicações diferentes em locais diferentes e nem precisar de técnicas de sincronização para garantir a integridade.
4 — Escalonamento limitado pelo hardware
Um dos pontos mais críticos da abordagem de escalonamento vertical é o simples fato de que todo e qualquer servidor tem um limite de upgrade de hardware, seja pelo próprio hardware ou pela simples viabilidade dos custos.
Escalonamento Horizontal
Em um cenário de produto de grande escala, investir em engenharia de software geralmente é recompensado posteriormente, pois é mais barato adicionar mais capacidade de distribuir o sistema em vários servidores de nó simples com uma sofisticada arquitetura de software.
Entende-se por escalonamento horizontal a abordagem que para aumentar o poder de processamento e execução de tarefas, adiciona-se mais servidores para dividir a carga de trabalho, sendo a abordagem mais adequada no design de sistemas distribuídos.
Abaixo temos um simples exemplo de escalonamento horizontal:
Na imagem acima (antes do escalonamento) identificamos poucos clientes efetuando realizando requisições, portanto, temos poucos servidores dividindo a carga de trabalho.
Já na imagem abaixo (depois do escalonamento), vemos um aumento no número de clientes, que consequentemente aumenta o número de requisições e a necessidade de poder de processamento. Portanto, foram provisionados mais servidores/instâncias da mesma aplicação para suportar a alta demanda.
Algumas características da abordagem horizontal:
1 — Balanceamento de Carga (Load Balancing)
Ao adicionar clones do mesmo nó de serviço lado a lado para distribuir as solicitações entre eles, faz-se necessário um balanceador de carga, similar ao modelo abaixo.
No próximo artigo da série vou explicar detalhadamente o que é Balanceamento de Carga (Load Balancing).
2 — Resiliência
É a capacidade de um sistema responder mesmo em caso de falha (um sistema que não é resiliente ficará fora do ar depois de uma falha).
Citando o Manifesto Reativo:
Resiliência é alcançada por replicação, contenção, isolamento e delegação. A contingência a falhas é feita dentro de cada componente, isolando-os uns dos outros e assim garantindo que partes do sistema podem falhar e se recuperar sem comprometer o sistema como um todo. A recuperação de cada componente é feita por outro componente (externo) e alta disponibilidade é garantida por replicação quando necessário.
Na abordagem horizontal, como conseguimos provisionar novos servidores de acordo com a demanda, facilmente conseguimos recuperar fluxos e processos inteiros, distribuindo e orquestrando os componentes em casos de falha.
3 — Comunicação de Rede (RPC — Remote Process Communication)
Diferente da abordagem vertical, neste cenário temos vários servidores remotos dividindo a execução de tarefas e processos e por esse motivo faz-se necessária a comunicação entre eles, através, por exemplo, de requisições HTTP.
A comunicação RPC é obviamente mais lenta que a IPC e propícia a falhas de rede, mas podem ser contornadas com variadas técnicas.
Uma delas a de balanceamento de carga citada acima.
4 — Inconsistência de Dados
Nesse contexto, consistência é nada mais nada menos que cada leitura numa fonte de dados, retornar a última versão de um registro baseada na escrita mais recente em um banco de dados.
Um dos maiores desafios da computação distribuída ainda é manter a consistência dos dados.
Em anos de estudos foram desenvolvidas várias técnicas para aumentar consideravelmente o grau de confiabilidade e consistência de dados/transações que são processados paralelamente de forma distribuída, mas nenhuma delas garante 100% de integridade desses dados.
Mais adiante detalharemos em outro capítulo as diferentes técnicas que visam garantir a consistência de dados em modelos distribuídos.
5 — Escalonamento "Ilimitado"
No escalonamento horizontal a “nuvem” é o limite, pois quem dita o limite é a carga que a empresa prestadora de serviços de cloud suporta.
Grandes players como a Amazon com a AWS, Microsoft com o Azure e outros, hospedam os produtos dos mais variados tipos e portes.
Portanto dificilmente existirá um limite de escalonamento nesse modelo aliado aos serviços que essas empresas prestam para empresas até maiores que elas.
