Tornar aplicativos escalonáveis
Agora que você entende os conceitos básicos da preparação para o crescimento e está ciente dos fatores a serem considerados no planejamento da capacidade, você pode assumir o desafio de tornar seus aplicativos tão escalonáveis quanto possível.
Revisões da arquitetura
Um ponto importante a ser lembrado é que você deve executar revisões regulares da arquitetura dos seus sistemas.
Você sabe que pode aplicar práticas como a infraestrutura como código para aprimorar a maneira como implanta seus recursos de nuvem. Você atualiza e aprimora seu código do aplicativo regularmente, e deve fazer o mesmo com os recursos de plataforma subjacentes.
A execução de uma revisão da arquitetura ajuda a identificar as áreas que precisam de aperfeiçoamento.
O Centro de Arquitetura do Azure tem uma infinidade de recursos para ajudar você a arquitetar seus aplicativos na nuvem, e há várias recomendações de escalabilidade que você pode encontrar no guia de arquitetura do aplicativo no seguinte link:
Centro de Arquitetura do Azure
Cenário: Arquitetura da Tailwind Traders
A primeira etapa é fazer uma avaliação da arquitetura e do aplicativo, não apenas para determinar onde estão os pontos fracos, mas também para reconhecer os pontos fortes deles. O que há de bom nisso?
Dê uma olhada no cenário visto na unidade anterior. Aqui está um diagrama de arquitetura da organização novamente:
Eles dividiram o aplicativo em microsserviços menores, e alguns desses serviços estão como contêineres no Serviço de Kubernetes do Azure ou podem estar em execução em VMs ou no Serviço de Aplicativo. Você está usando alguns serviços inerentemente escalonáveis, como o Functions e os Aplicativos Lógicos.
Essa mudança é boa, no entanto existem algumas melhorias que tornariam o aplicativo mais escalonável. Como exemplo, concentre-se agora no serviço de Produtos. No diagrama, o serviço do produto está em execução no Kubernetes, mas presumiremos, para essa explicação, que ele esteja sendo executado em uma VM no Azure. Os conceitos de escala, possivelmente com uma implementação um pouco diferente, podem ser aplicados aos aplicativos, estejam eles em execução em servidores, no Serviço de Aplicativo ou em contêineres.
O produto é executado atualmente em uma única VM, conectada a um único banco de dados SQL do Azure. Você precisa habilitar essa VM para escalar horizontalmente. Você pode fazer isso usando os conjuntos de dimensionamento de máquinas virtuais do Azure, que permitem que você crie e gerencie um grupo de VMs idênticas e com balanceamento de carga. Como agora você tem mais de uma VM, introduza um balanceador de carga para distribuir o tráfego entre as VMs.
conjuntos de escala de máquina virtual
Aplicando conjuntos de dimensionamento de máquinas virtuais em VMs individuais, você obtém alguns benefícios:
- É possível dimensionar automaticamente com base nas métricas do host, nas métricas do convidado, nos insights do aplicativo ou em um agendamento.
- Você pode usar AZs (Zonas de Disponibilidade), que são datacenters autônomos independentes em uma região do Azure. Com o suporte às AZs, você pode distribuir suas VMs entre várias AZs, o que torna seu aplicativo mais confiável e o protege contra falhas do datacenter. As novas instâncias de um conjunto de dimensionamento são distribuídas igualmente entre as AZs.
- A adição de um balanceador de carga torna-se mais fácil. Os conjuntos de dimensionamento de máquinas virtuais dão suporte ao uso do Azure Load Balancer para a distribuição básica de tráfego de Camada 4. Eles também dão suporte ao Gateway de Aplicativo do Azure para distribuição de tráfego L7 mais avançada e terminação SSL.
Existem alguns fatores importantes que você precisa considerar antes de implementar os conjuntos de dimensionamento. Especificamente:
- Evitar a adesão da instância para que nenhum cliente fique preso a um back-end específico.
- Remover dados persistentes da VM e armazená-los em outro lugar, como no Armazenamento do Microsoft Azure ou em um banco de dados.
- Projetar para redução horizontal. Também é importante que o seu aplicativo possa ser reduzido verticalmente com facilidade mais uma vez. Ele precisa lidar normalmente não apenas com mais instâncias adicionadas ao pool de servidores que manipulam o tráfego, contudo também com a finalização abrupta de instâncias à medida que a carga diminui. O aspecto de redução vertical do dimensionamento costuma ser ignorado.
Desacoplamento
Você adicionou mais VMs com conjuntos de dimensionamento. A expansão é a resposta típica para "Precisamos usar a escala", mas você só pode fazer a expansão com base em uma só métrica, e essa resposta pode não ser relevante para todas as tarefas executadas pelo seu serviço do produto.
Em nosso cenário, o serviço de produtos tem um trabalho. Ele usa uma imagem do produto e, depois que essa imagem é carregada. Ele codifica essa imagem e a armazena em vários tamanhos diferentes para miniaturas, imagens no catálogo etc. O processamento de imagem tem uso intensivo de CPU, porém o uso geral tem uso intensivo de memória.
O processamento de imagens é uma tarefa assíncrona que pode ser dividida em um trabalho em segundo plano. Faça isso separando o serviço de processamento de imagens usando uma fila. A separação permite escalar ambos os serviços de maneira independente: um na memória (o serviço do produto) e o outro (o serviço de processamento de imagens) na CPU ou mesmo no comprimento da fila. Faça com que outro conjunto de dimensionamento consuma essas mensagens e processe as imagens.
Dimensionar com filas
O Azure tem dois tipos de ofertas de fila:
- As filas do Barramento de Serviço do Azure são uma oferta de enfileiramento mais avançada, que faz parte do produto mais amplo do Barramento de Serviço do Azure, oferecendo publicação/assinatura e outros padrões de integração mais avançados.
- As Filas de Armazenamento do Azure são uma interface de fila simples baseada em REST, criada com base no Armazenamento do Azure. Ele oferece mensagens confiáveis e persistentes.
Seus requisitos nesse cenário são simples, portanto, você pode usar as Filas do Armazenamento do Azure. Sua camada de produtos não precisa ser escalada, porque você separou essa tarefa em segundo plano.
cache na memória
Outra maneira de melhorar o desempenho do seu aplicativo é implementar um cache na memória.
Agora você sabe que o desempenho não se equipara à escalabilidade exata, contudo, ao aprimorar o desempenho do seu aplicativo, você pode reduzir a carga sobre outros recursos. Essa melhoria significa que você pode não precisar dimensionar o quanto antes.
O cache do Azure para Redis é uma oferta Redis gerenciada. O Redis pode ser usado para vários padrões e casos de uso. Para o serviço do produto neste cenário, você provavelmente implementaria o padrão de reserva de cache. Nesse padrão, você carrega itens do banco de dados para o cache conforme necessário, tornando seu aplicativo mais eficaz e reduzindo a carga no banco de dados.
O Redis também pode ser usado como uma fila de mensagens para armazenar em cache o conteúdo da Web ou a sessão do usuário. Esse tipo de cache pode ser mais adequado para outros serviços do sistema, como o serviço de carrinho de compras, no qual você pode armazenar dados do carrinho de compras por sessão no Redis em vez de usar um cookie.
Dimensionar o banco de dados
Agora que você tornou seus recursos de computação mais escalonáveis, verifique o seu banco de dados. Nesse cenário, você está usando o banco de dados SQL do Azure, que é uma oferta gerenciada do SQL Server do Azure.
Bancos de dados relacionais são mais difíceis de serem escalados do que bancos de dados não relacionais. A primeira coisa que você pode fazer para dimensionar seu banco de dados é realizar escalabilidade vertical do tamanho do banco de dados. Esse redimensionamento pode ser feito facilmente com um tempo de inatividade médio de menos de quatro segundos. Usando uma chamada simples à API no SQL do Azure ou usando um controle deslizante no portal.
Se esse escalonamento vertical não atender às suas necessidades, dependendo das características do tráfego, pode ser adequado expandir as leituras para o banco de dados. Permitindo que você encaminhe o tráfego de leitura para a réplica de leitura.
Observação
Com o Azure SQL, se você estiver usando as camadas Premium ou Comercialmente Crítico, a Leitura da Escalabilidade Horizontal será habilitada por padrão. Ela não pode ser habilitada nas camadas básica ou padrão.
Essa alteração deve ser implementada no código. Veja como fazer isso:
#Azure SQL Connection String
#Master Connection String
ApplicationIntent=ReadWrite
#Read Replica Connection String
ApplicationIntent=ReadOnly
#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
Atualize o atributo ApplicationIntent na cadeia de conexão de banco de dados para especificar o servidor ao qual você deseja se conectar. Use ReadOnly caso queira se conectar à réplica ou ReadWrite para se conectar ao mestre.
Como esse comando precisa ser implementado no código, ele pode não ser uma solução adequada para sua situação. E se cada serviço de produto único precisar da capacidade de leitura e gravação?
Nesse caso, você pode analisar a expansão do BD SQL usando a fragmentação.
Fragmentação do banco de dados
Se, após a escalabilidade vertical ou a implementação de Réplicas de Leitura os recursos do banco de dados ainda não atenderem às necessidades do seu sistema, a próxima opção é a fragmentação.
A fragmentação é uma técnica usada para distribuir grandes volumes de dados estruturados de maneira idêntica entre vários bancos de dados independentes. A fragmentação pode ser necessária por vários motivos. Por exemplo:
- A quantidade total de dados é muito grande para caber nas restrições de um banco de dados individual.
- A taxa de transferência da transação da carga de trabalho geral excede os recursos de um banco de dados individual.
- Locatários separados precisam residir em diferentes bancos de dados físicos por motivos de conformidade (esse requisito não é exatamente sobre o dimensionamento, mas é outra situação na qual a fragmentação é usada).
Seu aplicativo adiciona os dados relevantes ao fragmento relevante e, portanto, torna o sistema escalonável além das restrições do banco de dados individual.
O SQL do Azure oferece as ferramentas do Banco de Dados Elástico do Azure. Essas ferramentas ajudam você a criar, manter e consultar os bancos de dados SQL fragmentados no Azure por meio da lógica do aplicativo.