Guia para escalar seu App - parte 1

Artigo em formato áudio:

Introdução

Em uma série de 4 partes, vamos discutir a evolução de um website/app passando pelos principais tópicos, esse post é uma sugestão para estudo lembrando que não existe uma solução única para o mesmo problema fique livre para dar sua opinião ou propor modificações 🙂

obs: não vamos falar sobre todas as vantagens e desvantagens nessa série.

Atualização

Decidi exemplificar a teoria utilizando a criação de um sistema do zero vamos desenhar a arquitetura baseado no que estamos falando aqui esse app vai se chamar Leosalesapp.

Arquitetura monolítica vs Microserviço

Vamos começar exemplificando como os sistemas eram criados sem arquitetura distribuída os chamados monolitos e sua evolução para microserviço.

Problemas da arquitetura monolítica

Na figura da arquitetura monolítica possivelmente temos uma API RESTfull para clientes de aplicativos móveis ou web, as imagens e arquivos devem estar no disco local e o banco de dados que também é executado no mesmo servidor.

A arquitetura monolítica provavelmente pode atender a centenas e até milhares de usuários, porém a única maneira de suportar a crescente carga de usuário é aumentar os recursos do servidor como CPU, Memória e etc, e até mesmo o upgrade se tornará recorrente à medida que o servidor chega ao seu limite de capacidade.

Como todo aplicativo executando em um único servidor fica dependendo do uptime exclusivo desse servidor, logo se o servidor cair a aplicação ficará dependente do restart que pode demorar muito tempo tornando a aplicação inacessível em longos períodos.

Por que evoluir para microserviço?

Primeiramente não devemos assumir que a arquitetura de microserviço resolve todos os problemas magicamente. Eles são capazes de resolver desafios no crescimento dos softwares das empresas.

Um dos grandes problemas que os microsserviços resolvem são os isolamentos das responsabilidades, contextos e infraestrutura tornando em pequenos sistemas isso facilita quando precisamos escalar um "pedaço" do sistema que é o mais usado e mais importante, logo uma funcionalidade não comprometerá todo o sistema como visto na arquitetura monolítica.

Entendemos agora que para ter um sistema escalável devemos seguir com arquitetura baseada em microserviço.

Leosalesapp 1.0 - Monolitíco

O Leosalesapp é um ecommerce para venda de produtos tech.

A primeira versão é uma arquitetura tradicional monolítica bastante usada até os dias de hoje. Tudo no mesmo servidor temos:

• API RESTful para manipular as regras de negócio e fornece-las para o app mobile e Web.

• Servidor de aplicativos também disponibiliza conteúdo estático, como imagens que são armazenados diretamente no seu disco local.

• E por fim o servidor se conecta ao banco de dados que também é executado no mesmo servidor.

  

Como mencionado acima a única maneira de escalar é fazendo um upgrade das máquinas, mais CPU, memória etc.

Leosalesapp 2.0 - Mais servidores

A próxima etapa esperada é colocar o banco de dados e os arquivos em um servidor dedicado a eles.

O banco de dados demanda uma carga de trabalho de servidor diferente ao do servidor de aplicativo, ao separa-lo podemos ajustar ambos de forma independente para suas demandas especificas.

Aproveitamos para desacoplar também o servidor onde contem os arquivos se fizer sentido de acordo com o volume de tráfego.

Leosalesapp 3.0 - Load balancer e mais servidores

Com o crescimento do tráfego em algum momento o único servidor de aplicativos ficará sobrecarregado, mesmo podendo redimensionar os servidores a execução da API em um único servidor é ruim do ponto de vista operacional.

Chegou a hora de dimensionar a API horizontalmente introduzindo vários servidores de aplicativos, para fazer isso colocaremos um load balancer entre os aplicativos cliente e os servidores de aplicativos. O balanceador de carga distribuiu as cargas dos clientes em muitos servidores de aplicativos, existe 2 maneiras de distribuir o tráfego, utilizaremos a Round Robin.

Para usar a distribuição round-robin, os dados da sessão do usuário são armazenados no banco de dados. Em cada solicitação, o servidor de aplicativos busca os dados da sessão do usuário do banco de dados antes de processar a solicitação proporcionando maior resiliência no caso de uma falha do servidor, pois ele pode ser substituido facilmente.

Temos outros beneficios como a utilização de TLS que simplifica a implantação de aplicativos seguros.

O balanceador de carga rastreia a integridade de servidores de aplicativos individuais e leva automaticamente cada um para dentro e para fora de serviço com base em sua integridade, tornando a implantação de software sem interrupções do ponto de vista do usuário.

Com um balanceador de carga em vigor, também podemos nos beneficiar de failover e redundância. Se um servidor de aplicativos falhar, o balanceador de carga direcionará automaticamente o tráfego para os servidores íntegros, fornecendo alta disponibilidade e resiliência.

O dimensionamento do servidor de aplicativos traz complexidade extra ao balanceamento de carga. Como podemos ver no resto do artigo, este é um padrão comum: resolvemos um problema introduzindo outro.

Leosalesapp 4.0 - Banco de dados de replica

Conforme contiuamos a crescer os gargalos começarão a aparecer, o banco de dados é provavelmente o primeiro lugar a ter problemas.

O banco de dados por padrão tem problemas para lidar com uma grande número de consultas de leitura enquanto as gravações ocorrem com frequência.

Uma maneira simples de resolver é criando um banco de dados de replica, com esse método implantamos um cluster de banco de dados com um único banco de dados primário para manipular gravações e uma série de réplicas de leitura para manipular leituras, a desvantagem é o atraso na replicação dos dados no banco de dados de leitura.

Para o pequeno número de operações que não podem tolerar atrasos, essas leituras sempre podem ser direcionadas ao banco de dados primário.

Outro problema potencial com bancos de dados relacionais que pode afetar alguns aplicativos é a falta de suporte a pesquisa difusa.

A pesquisa difusa permite a pesquisa, mesmo que haja erros de digitação no termo de pesquisa, o que é útil para aplicativos como o comércio eletrônico on-line, onde permitir que os usuários pesquisem produtos sem exigir o termo de pesquisa correspondente exato é extremamente importante.

Para esses casos de uso específicos, é útil replicar um subconjunto do conjunto de dados em que esses recursos de pesquisa são necessários para um mecanismo de pesquisa de texto completo como o Elasticsearch.

Próximos passos

Nos posts a seguir vamos falar sobre:

• Quando adicionar cache?

• Quando adicionar full-text search engine?

• Quando adicionar mensageria?

• Quando usar um cluster?

Concluímos assim essa primeira parte 🤖