Tornar os aplicativos escalonáveis

Agora que você entende os conceitos básicos de preparação para o crescimento e está ciente dos fatores a serem considerados no planejamento da capacidade, poderá assumir o desafio de tornar seus aplicativos o mais escalonáveis possível.

Revisões de arquitetura

Um ponto importante a ser lembrado é que você deve executar revisões de arquitetura regulares 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 seus recursos de plataforma subjacentes.

A execução de uma revisão arquitetônica ajuda você a identificar as áreas que precisam de melhorias.

O Centro de Arquitetura do Azure tem uma 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 do aplicativo no link a seguir:

Centro de Arquitetura do Azure

Cenário: arquitetura da Tailwind Traders

Uma primeira etapa é fazer uma avaliação da arquitetura e do aplicativo , não apenas para determinar onde estão suas fraquezas, mas também para reconhecer 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 decomporam o aplicativo em microsserviços menores, e alguns desses serviços estão sentados 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 Funções e Aplicativos Lógicos.

Essa alteração é boa, mas há algumas melhorias que tornariam o aplicativo mais escalonável. Por exemplo, concentre-se agora no serviço Produtos. No diagrama, o serviço de produto está em execução no Kubernetes, mas presumimos que ele esteja em execução em uma VM no Azure. Os conceitos de dimensionamento, possivelmente com uma implementação ligeiramente diferente, podem ser aplicados a aplicativos, sejam eles em execução 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 escalar horizontalmente. Você pode fazer isso usando conjuntos de dimensionamento de máquinas virtuais do Azure, que permitem criar e gerenciar um grupo de VMs idênticas e com balanceamento de carga. Como agora você tem mais de uma VM, é necessário introduzir um balanceador de carga para distribuir o tráfego entre as VMs.

Conjuntos de dimensionamento de máquinas virtuais

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 zonas de disponibilidade (AZ), que são datacenters independentes independentes em uma região do Azure. Com o suporte do AZ, você pode espalhar suas VMs por vários AZs, o que torna seu aplicativo mais confiável e protege contra falhas de 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 fica mais fácil. Os conjuntos de dimensionamento de máquinas virtuais dão suporte ao uso do Balanceador de Carga do Azure para a distribuição básica de tráfego da 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.

Há alguns fatores importantes que você precisa considerar antes de implementar conjuntos de dimensionamento. Especificamente:

• Evitar a adesão 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.
• Projetar para redução horizontal. Também é importante que o seu aplicativo possa ser reduzido verticalmente com facilidade mais uma vez. Ele precisa lidar de forma eficiente não apenas com mais instâncias adicionadas ao grupo de servidores que lidam com o tráfego, mas também com a finalização abrupta de instâncias quando a demanda diminui. O aspecto de redução vertical do dimensionamento costuma ser ignorado.

Desacoplamento

Você adicionou mais VMs com conjuntos de dimensionamento. Escalar horizontalmente é a resposta típica para "precisamos dimensionar". No entanto, você só pode dimensionar em uma única métrica e essa resposta pode não ser relevante para todas as tarefas executadas pelo serviço do seu produto.

Em nosso cenário, o serviço de produtos tem um trabalho. Ele pega uma imagem do produto e, em seguida, carrega essa imagem. 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 de CPU, mas o uso geral é intensivo de memória.

O processamento de imagem é 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. O desacoplamento permite escalar os dois serviços de forma independente – um na memória (o serviço de produto) e outro (o serviço de processamento de imagem) na CPU ou até mesmo no comprimento da fila, permitindo que outro conjunto de escalonamento 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.
• 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 Filas de 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 aplicativo é implementar um cache na memória.

Agora você sabe que o desempenho não é igual à escalabilidade exatamente, mas ao melhorar o desempenho do aplicativo, você pode reduzir a carga em outros recursos. Essa melhoria significa que talvez você não precise expandir tão cedo.

O Cache do Azure para Redis é uma oferta gerenciada do Redis. O Redis pode ser usado para muitos 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 no cache conforme necessário, tornando seu aplicativo mais performante e reduzindo a carga no banco de dados.

O Redis também pode ser usado como uma fila de mensagens para cachear o conteúdo web ou para cache de sessões de usuário. Esse tipo de cache pode ser mais adequado para outros serviços no sistema, como o serviço de carrinho de compras, em que você pode armazenar dados de 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, dê uma olhada no 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 escalar do que 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 inferior a quatro segundos. Usando uma chamada de API simples no SQL do Azure ou usando um controle deslizante no portal.

Se esse dimensionamento não atender aos seus requisitos, dependendo das características de tráfego, poderá ser adequado distribuir as leituras para o banco de dados. Permitindo que você encaminhe o tráfego de leitura para a réplica de leitura.

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 ApplicationIntent atributo na cadeia de conexão do banco de dados para especificar para qual servidor você deseja se conectar. Use ReadOnly se você 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 relacionado a produtos precisar da capacidade de ler e escrever?

Nesse caso, você pode examinar o dimensionamento do banco de dados 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 para distribuir grandes quantidades de dados estruturados de forma idêntica em muitos 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 se ajustar às 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, portanto, torna seu 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 bancos de dados SQL fragmentados no Azure a partir da lógica do aplicativo.