Torne os aplicativos escalá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 de capacidade, pode aceitar o desafio de tornar seus aplicativos o mais escaláveis possível.

Revisões arquitetônicas

Um ponto-chave a ser lembrado é que você deve realizar revisões regulares da arquitetura de seus sistemas.

Você sabe que pode aplicar práticas como infraestrutura como código para melhorar a forma como implanta seus recursos de nuvem. Você atualiza e melhora o código do aplicativo regularmente e deve fazer o mesmo com os recursos da plataforma subjacente.

Realizar uma revisão arquitetônica ajuda a identificar as áreas que precisam de melhorias.

O Centro de Arquitetura do Azure tem uma grande variedade de recursos para ajudá-lo a arquitetar seus aplicativos na nuvem, e há muitas recomendações de escalabilidade que você pode encontrar no guia de arquitetura de aplicativos no seguinte link:

Centro de Arquitetura do Azure

Cenário: Arquitetura da Tailwind Traders

Um primeiro passo é fazer uma avaliação da arquitetura e da aplicação – não só para determinar onde estão os seus pontos fracos, mas também para reconhecer os seus pontos fortes. O que há de bom nisso?

Dê outra olhada no cenário que você viu na unidade anterior. Aqui está um diagrama da arquitetura da organização novamente.

Eles decompuseram o aplicativo em microsserviços menores, e alguns desses serviços estão sentados como contêineres no Serviço Kubernetes do Azure ou podem estar sendo executados em VMs ou Serviço de Aplicativo. Você está usando alguns serviços inerentemente escaláveis , como Funções e Aplicativos Lógicos.

Essa mudança é boa, mas há algumas melhorias que tornariam o aplicativo mais escalável. Como exemplo, concentre-se agora no serviço de Produtos. No diagrama, o serviço do produto está sendo executado no Kubernetes, mas assumimos, para esta explicação, que ele está sendo executado em uma VM no Azure. Os conceitos de dimensionamento, possivelmente com uma implementação ligeiramente diferente, podem ser aplicados a aplicativos, estejam eles sendo executados em servidores, Serviço de Aplicativo ou em contêineres.

Atualmente, o produto é executado em uma única VM, conectada a um único banco de dados SQL do Azure. Você precisa habilitar essa VM para expansão. Você pode fazer isso usando conjuntos de escala de máquina virtual do Azure, que permitem criar e gerenciar um grupo de VMs idênticas com balanceamento de carga. Como agora você tem mais de uma VM, precisa introduzir um balanceador de carga para distribuir o tráfego entre as VMs.

Conjuntos de dimensionamento de máquinas virtuais

Ao aplicar conjuntos de dimensionamento de máquina virtual em VMs únicas, você obtém alguns benefícios:

• Você pode dimensionar automaticamente com base em métricas de host, métricas internas, análises de aplicações ou através de um agendamento.
• Você pode usar Zonas de Disponibilidade (AZ), que são datacenters autônomos independentes dentro de uma região do Azure. Com o suporte AZ, você pode distribuir suas VMs por várias AZs, o que torna seu aplicativo mais confiável e o protege contra falhas no datacenter. Novas instâncias dentro de um conjunto de escala são distribuídas automaticamente uniformemente entre AZs.
• Adicionar 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 distribuição básica de tráfego da Camada 4. Eles também oferecem 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 conjuntos de escala. Mais especificamente:

• Evite a aderência da instância, para que nenhum cliente fique preso a um back-end específico.
• Remova dados persistentes da VM e armazene-os em outro lugar, como no Armazenamento do Azure ou em um banco de dados.
• Design para otimização de escala. Também é importante que a sua aplicação possa ser facilmente escalável para baixo. Ele tem que lidar graciosamente não apenas com mais instâncias adicionadas ao pool de servidores que lidam com o tráfego, mas também com o encerramento abrupto de instâncias à medida que a carga cai. O aspeto de redução de escala do dimensionamento é muitas vezes negligenciado.

Desacoplamento

Você adicionou mais VMs com conjuntos de escala. A expansão é a resposta típica para "precisamos escalar". Mas, você só pode escalar em uma única métrica, e essa resposta pode não ser relevante para todas as tarefas executadas pelo seu serviço de produto.

No nosso cenário, o serviço de produtos tem um trabalho. Ele tira uma imagem do produto e, em seguida, essa imagem é carregada. Ele transcodifica essa imagem e a armazena em vários tamanhos diferentes para miniaturas, imagens no catálogo e assim por diante. O processamento de imagem é intensivo em CPU, mas o uso geral é intensivo em memória.

O processamento de imagens é uma tarefa assíncrona que pode ser dividida em um trabalho em segundo plano. Você pode fazer isso desacoplando seu serviço de processamento de imagem usando uma fila. O desacoplamento permite dimensionar ambos os serviços de forma independente – um na memória (o serviço do produto) e o outro (o serviço de processamento de imagem) na CPU ou até mesmo no comprimento da fila, e fazer com que outro conjunto de escalas consuma essas mensagens e processe as imagens.

Dimensionar com filas

O Azure tem dois tipos de ofertas de fila:

• Filas do Barramento de Serviço do Azure Uma oferta de fila mais avançada, que faz parte do conjunto mais amplo do Barramento de Serviço do Azure, oferecendo padrões de integração de publicação/assinatura e mais avançados.
• Filas de armazenamento do Azure Uma interface de fila simples baseada em REST criada sobre o Armazenamento do Azure. Ele oferece mensagens confiáveis e persistentes.

Seus requisitos neste cenário são simples, portanto, você pode usar as Filas de Armazenamento do Azure. Sua camada de produto não precisa ser dimensionada porque você desacoplou 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 é exatamente igual à escalabilidade, mas melhorando o desempenho do seu aplicativo, você pode reduzir a carga em outros recursos. Esta melhoria significa que poderá não ter de escalar tão cedo.

O Cache Redis do Azure é uma oferta gerenciada do Redis. Redis pode ser usado para muitos padrões e casos de uso. Para o serviço do teu produto neste cenário, provavelmente implementarias o padrão cache-aside. Nesse padrão, você carrega itens do banco de dados no cache conforme necessário, tornando seu aplicativo mais eficiente e reduzindo a carga no banco de dados.

O Redis também pode ser usado como uma fila de mensagens para cachear conteúdo web ou para cache de sessão do utilizador. Este tipo de cache pode ser mais adequado para outros serviços no sistema, como o serviço de carrinho de compras, onde 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 escaláveis, dê uma olhada em seu banco de dados. Nesse cenário, você está usando o Banco de Dados SQL do Azure, que é uma oferta de servidor SQL gerenciado do Azure.

Os bancos de dados relacionais são mais difíceis de expandir do que os bancos de dados não relacionais. A primeira coisa que você pode fazer para dimensionar seu banco de dados é aumentar o tamanho do banco de dados. Esse redimensionamento pode ser feito facilmente com um tempo médio de inatividade de menos de quatro segundos. Usando uma chamada de API simples no SQL do Azure ou usando um controle deslizante no portal.

Se esse redimensionamento não atender aos seus requisitos, dependendo das características do tráfego, pode ser adequado distribuir as leituras pela base de dados. Permitindo que você roteie o tráfego de leitura para sua réplica de leitura.

Esta 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 do banco de dados para especificar a qual servidor você deseja se conectar. Use ReadOnly se quiser se conectar à réplica ou ReadWrite se quiser se conectar ao mestre.

Como esse comando deve 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 precisar da capacidade de ler e escrever?

Nesse caso, você pode examinar a expansão do Banco de Dados SQL usando fragmentação.

Fragmentação de banco de dados

Se, após expandir ou implementar réplicas de leitura, os recursos do banco de dados ainda não atenderem às necessidades do seu sistema, a próxima opção será a fragmentação.

O compartilhamento é uma técnica para distribuir grandes quantidades de dados estruturados de forma idêntica em muitos bancos de dados independentes. A partilha pode ser necessária por muitas razões. Por exemplo:

• A quantidade total de dados é muito grande para caber dentro das restrições de um banco de dados individual.
• A taxa de transferência de transação da carga de trabalho geral excede os recursos de um banco de dados individual.
• Locatários separados precisam residir em bancos de dados físicos diferentes por motivos de conformidade (esse requisito é menos sobre dimensionamento, mas é outra situação em que a fragmentação é usada).

Seu aplicativo adiciona os dados relevantes ao fragmento relevante e, assim, torna seu sistema escalável além das restrições do banco de dados individual.

O Azure SQL oferece as ferramentas do Banco de Dados Elástico do Azure. Essas ferramentas ajudam você a criar, manter e consultar bancos de dados SQL fragmentados no Azure a partir da lógica do seu aplicativo.