O que é escalabilidade de software e serviços e seus padrões mais comuns

Sistema escalável é aquele que tem a capacidade de lidar com mudanças rápidas nas cargas de trabalho e nas demandas dos usuários. Capacidade de expansão é como o sistema reage às mudanças, adicionando ou retirando recursos para atender às demandas. Arquitetura é o hardware, o software, a tecnologia e as práticas recomendadas usadas para criar as redes, as aplicações, os processos e os serviços que compõem todo o sistema.

Um sistema (a arquitetura, os serviços, os produtos e tudo o que define sua marca) é considerado escalável quando pode:

• Adicionar recursos e expandir para lidar com o aumento na demanda dos clientes e na carga de trabalho.
• Retirar recursos com facilidade quando a demanda e as cargas de trabalho diminuem.

A ideia é criar um sistema que ajuste a capacidade para atender a uma demanda em constante mudança. O sistema precisa ser altamente acessível e estar disponível para todos os clientes, quando e onde eles precisarem. 

Um site escalável e bem projetado vai funcionar sempre, não importa se um ou milhares de usuários o acessam simultaneamente. Não pode haver nenhuma diminuição perceptível na funcionalidade à medida que mais usuários entram nele.

O que é padrão de escalabilidade?

Você já brincou de LEGO®? Já aconteceu de você ter construído uma estrutura sem seguir as instruções e ela desmontou? Mas, ao seguir as instruções meticulosamente ilustradas, você criou uma estrutura sólida, que só desmontaria se você separasse deliberadamente as peças. As técnicas mostradas nas instruções foram testadas e comprovadas como soluções para problemas estruturais comuns, encontrados por muitos construtores.

No desenvolvimento da computação, os padrões arquitetônicos são semelhantes às técnicas de construção encontradas nas instruções do LEGO®. Esse conjunto de técnicas comprovadas para desenvolvimento e programação resolvem problemas comuns no desenvolvimento dos sistemas de computador. São padrões com um bom design e propriedades bem definidas, que já resolveram outros problemas no passado. 

Porém, isso não significa que todos os padrões de escalabilidade funcionarão para você. O desafio é selecionar os padrões adequados e adaptá-los para resolver os problemas específicos do seu sistema. Os padrões de escalabilidade economizam tempo porque muito do trabalho já foi feito para você.

Quais são os padrões comuns de escalabilidade?

São vários os padrões expansíveis de arquitetura à disposição. Abordaremos aqui alguns dos padrões mais comuns na resolução de problemas na escalabilidade arquitetônica. 

Cubo de expansão AKF

É um modelo tridimensional que define três abordagens para a expansão ao longo dos eixos X, Y e Z.

Expansão no eixo X

O eixo X usa várias instâncias do mesmo componente para descrever a expansão. Isso é feito clonando ou replicando um serviço, uma aplicação ou um conjunto de dados por trás de um balanceador de carga. Portanto, se você tiver N clones de uma aplicação em execução, cada instância lidará com 1/N da carga.

Os padrões de expansão do eixo X são fáceis de implementar e aumentam a expansão das transações. Porém, a manutenção pode ser cara, pois são replicados conjuntos de dados inteiros em vários servidores, e os caches de dados crescem exponencialmente.

Expansão no eixo Y

A expansão no eixo Y é definida pela divisão ou segmentação de componentes distintos em vários serviços macro ou micro na relação verbo/substantivo. Por exemplo: um segmento com um verbo pode definir um serviço como finalização de compra. Um segmento com um substantivo pode descrever o carrinho de compras.

Como cada serviço pode ser expandido de forma independente, você pode aplicar mais recursos somente aos serviços que precisam deles no momento. Para garantir a alta disponibilidade, cada serviço deve ter um conjunto próprio de dados não compartilhados. 

Esse conjunto fornece o isolamento das falhas para que você possa diagnosticar e corrigir os problemas de forma rápida e fácil, sem ter que verificar todo o sistema. Porém, o eixo Y demora para ser configurado e é difícil de implementar.

Expansão no eixo Z

Enquanto o eixo Y divide componentes distintos, o eixo Z aborda a segmentação de componentes semelhantes no sistema. Cada servidor executa uma cópia idêntica do código, mas apenas num subconjunto (ou fragmento) desses dados.

Um uso comum da divisão do eixo Z é "cliente por localização geográfica" ou "cliente por tipo". Por exemplo: os clientes pagantes de um site de notícias por assinatura podem ter acesso ilimitado a todo o conteúdo do site. Já os clientes não pagantes têm acesso aos mesmos dados, mas só podem ler três ou quatro artigos por mês. 

Essa configuração pode reduzir os custos operacionais, pois os segmentos dos dados são menores e exigem menos recursos de armazenamento. Porém, o eixo Z demora para ser projetado e implementado, além de exigir muita automação para reduzir a sobrecarga do sistema. 

Padrões de escalabilidade horizontal e vertical

É possível expandir para cima (vertical) ou para fora (horizontal). 

Escalabilidade vertical

Expansão vertical é quando se aumenta a capacidade de um componente, como um servidor, para melhorar o desempenho dele. Por exemplo: quanto mais tráfego chega ao servidor, pior o desempenho dele. A adição de RAM e de unidades de armazenamento aumenta o desempenho do servidor para que ele suporte o aumento do tráfego.

A expansão vertical é fácil de implementar, economiza dinheiro (não precisa adquirir novos recursos) e é de fácil manutenção. Porém, por serem um ponto único de falha, podem resultar num tempo significativo de inatividade.

Uma empresa recém-fundada pode usar a expansão vertical para manter os custos baixos. Porém, a abordagem vertical acabará atingindo os limites de RAM e de armazenamento, e será preciso adicionar recursos para acompanhar a demanda. 

Escalabilidade horizontal

A expansão horizontal é quando se aumenta a capacidade de desempenho ao adicionar o mesmo tipo de recursos ao sistema. Por exemplo: em vez de aumentar a capacidade do servidor para melhorar o desempenho, você adiciona servidores ao sistema. O balanceador de carga distribui a carga de trabalho entre diferentes servidores, dependendo da disponibilidade. Isso aumenta o desempenho geral do sistema.

Mais recursos de computação significam mais tolerância a falhas e menos riscos de inatividade. Porém, adicionar servidores e balanceadores de carga pode sair caro. Você deve considerar uma combinação de recursos locais e recursos em nuvem para lidar com o aumento do tráfego.

Balanceamento de carga

O balanceador de carga distribui, com eficiência, as solicitações dos usuários e a carga de trabalho num grupo de servidores de back-end. A ideia é equilibrar o trabalho entre vários recursos para que nenhum deles se sobrecarregue. Com o balanceamento da carga, o departamento de TI garante a disponibilidade e a escalabilidade dos serviços.

As tarefas do balanceador de carga são:

• Descobrir quais recursos estão disponíveis no sistema.
• Verificar a integridade do recurso para saber quais recursos não só estão disponíveis como suportam a carga de trabalho. Se um servidor disponível for corrompido, o balanceador de carga deverá se desconectar dele e trocar de servidor sem que o usuário note atraso ou inatividade.
• Determinar o algoritmo a ser usado para equilibrar o trabalho entre vários servidores íntegros de back-end.

Os métodos comuns de balanceamento de carga (algoritmos) são:

• Método da menor conexão: o tráfego é roteado para o servidor com menos conexões ativas.
• Método do menor tempo de resposta: o balanceador de carga mede o tempo que o servidor leva para responder a uma solicitação de monitoramento de integridade. O tráfego é enviado para o servidor mais íntegro e com o menor tempo de resposta. Alguns balanceadores de carga usam esse algoritmo para considerar as conexões ativas. 
• Método round robin ou algoritmo round robin: o tráfego é enviado para o primeiro servidor disponível, não importa a carga de trabalho e as conexões ativas no momento. Após o servidor trabalhar na solicitação, o balanceador de carga o transfere para o fim da fila. O risco é um servidor receber solicitações que exigem o uso intenso do processador e ainda estar ocupado ao chegar novamente ao início da fila.
• Métodos de hash: a decisão de qual servidor receberá a solicitação depende de um hash de dados do pacote recebido. Esses dados podem incluir informações como endereço IP, número da porta ou nome do domínio.

Armazenamento em cache - redes de fornecimento de conteúdo (CDN)

CDN é uma rede global de servidores usados para otimizar e acelerar o acesso e a distribuição de propriedades estáticas da web. Exemplo de propriedades estáticas são Javascript, CSS, imagens e outros arquivos de mídia que não mudam com frequência.

Um site pode ser composto por até 80% de conteúdo estático. Os vídeos disponíveis num serviço de streaming, por exemplo, não mudam com frequência. Alguns acabam sendo muito procurados e podem receber milhões de acessos todos os dias. A transferência desse conteúdo estático para uma CDN reduz a carga no servidor original, aprimora o conteúdo no geral e aproxima os dados dos clientes, sendo facilmente acessíveis e altamente disponíveis.

Microsserviços

Microsserviços são essencialmente várias aplicaçõezinhas diferentes que podem funcionar juntas. Cada microsserviço tem propósito e responsabilidade específicos. E diferentes equipes podem desenvolvê-los independentemente de outros microsserviços. Os microsserviços não se dependem entre si para funcionar, mas precisam se comunicar entre si. 

Os microsserviços são fáceis de expandir, pois você só expande aqueles que precisam no momento. Eles podem ser implementados de forma independente, sem necessidade de várias equipes de desenvolvimento. Os microsserviços funcionam bem em aplicações da web, no desenvolvimento e na implementação rápidos e em equipes espalhadas por todo o mundo.

Os microsserviços expandem, com eficiência, transações e grandes conjuntos de dados, e ajudam você a isolar as falhas para manter os sistemas altamente disponíveis. Além disso, como grandes recursos podem ser divididos em serviços menores, a complexidade da base de códigos é reduzida.

Fragmentação

Basicamente, é a divisão de um grande banco de dados em componentes menores, mais gerenciáveis e flexíveis. Quanto maior o banco de dados, mais solicitações e transações são feitas nele. Bancos dedados grandes não só retardam o tempo de resposta nas consultas como podem ser muito caros de ser mantidos.

Fragmento é uma partição do banco de dados. Para distribuir a carga de trabalho, essas partições podem existir e ser distribuídas em vários servidores distribuídos de banco de dados. 

É recomendável usar a fragmentação quando os bancos de dados ficarem grandes demais, pois:

• Bancos de dados menores são mais fáceis de gerenciar.
• Bancos de dados menores são mais rápidos, e cada fragmento pode funcionar melhor do que um enorme banco de dados.
• Bancos de dados menores são mais fáceis de expandir, pois novos fragmentos de dados podem ser criados e distribuídos em vários servidores.
• A fragmentação pode reduzir os custos, pois você não precisa de servidores enormes e caros para hospedar os fragmentos.

A implementação dos padrões expansíveis de arquitetura no seu sistema serve para você manter o desempenho de sistema e, ao mesmo tempo, aumentar a carga de entrada.