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 Azure Architecture Center dispõe de uma vasta quantidade de recursos para o ajudar a arquitetar as suas aplicações na cloud, e há muitas recomendações de escalabilidade que pode encontrar no guia de arquitetura de aplicações 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 decompõem a aplicação em microserviços mais pequenos, e alguns destes serviços estão como contentores no Azure Kubernetes Service ou podem estar a correr em VMs ou App Service. Também estão a usar alguns serviços inerentemente escaláveis , como Funções e Aplicações de Lógica.

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 de produto está a correr no Kubernetes, mas assumimos para esta explicação que está a correr numa 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 corre numa única VM, ligada a uma única base de dados SQL do Azure. Precisas de ativar esta VM para escalar. Pode fazer isto usando conjuntos de escalas de máquinas virtuais do Azure, que permitem criar e gerir um grupo de VMs idênticas e balanceadas 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.
• Pode usar Zonas de Disponibilidade (AZ), que são locais fisicamente separados dentro de uma região Azure, cada um composto por um ou mais centros de dados. Com suporte ao AZ, pode espalhar as suas VMs por vários AZs, o que torna a sua aplicação mais fiável e protege-a contra falhas nos centros de dados. 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 escala de máquinas virtuais suportam o uso do Balanceador de Carga do Azure para distribuição básica de tráfego da Camada 4. Também suportam o Gateway de Aplicação 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 noutro local, como no Armazenamento do Azure ou numa base 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 caso, o serviço de produtos tem uma função: quando uma imagem de produto é carregada, transcodifica essa imagem e armazena-a 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 filas disponíveis:

• Azure Service Bus filas Uma oferta de filas mais avançada, que faz parte do produto mais amplo da Azure Service Bus, oferecendo pub/sub e padrões de integração mais avançados.
• Armazenamento do Azure Queues Uma interface simples de filas baseada em REST construída sobre a plataforma Armazenamento do Azure. Ele oferece mensagens confiáveis e persistentes.

Os seus requisitos neste cenário são simples, por isso pode usar o Armazenamento do Azure Queues. 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.

Azure Managed Redis (anteriormente Cache do Azure para Redis) é uma oferta gerida de 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 fila de mensagens, para cache de conteúdos web ou para cache de sessões de 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 tornou os seus recursos computacionais mais escaláveis, dê uma vista de olhos à sua base de dados. Neste cenário, está a usar o Base de Dados SQL do Azure, que é uma oferta SQL Server gerida 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. Este redimensionamento pode ser feito facilmente com apenas um breve momento de perda de conectividade, seja usando uma chamada simples de API no SQL do Azure ou usando um slider no portal.

Se este dimensionamento não cumprir os seus requisitos, dependendo das características do tráfego, pode ser adequado escalar a leitura no banco de dados, permitindo-lhe redirecionar o tráfego de leitura para a sua réplica de leitura.

Esta alteração deve ser implementada no código. Você especifica a intenção de roteamento definindo o atributo ApplicationIntent na cadeia de ligação da sua base de dados. Use ReadOnly para conectar à réplica, ou ReadWrite para conectar ao primário.

A abordagem recomendada é usar identidades geridas para autenticação, armazenando qualquer configuração necessária no Azure Key Vault:

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

Como esta alteração tem de ser implementada por código, pode não ser uma solução adequada para a sua situação. E se cada serviço de produto precisar da capacidade de ler e escrever?

Nesse caso, podes considerar escalar o Base de Dados SQL do Azure usando sharding.

Fragmentação de banco de dados

Se, depois de ampliar ou implementar réplicas de leitura, os recursos da sua base de dados continuarem a não satisfazer as necessidades do sistema, a opção seguinte é sharding.

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).

A sua aplicação adiciona os dados relevantes ao shard relevante, tornando assim o seu sistema escalável para além das limitações da base de dados individual.

O SQL do Azure oferece as ferramentas Azure Elastic Database. Estas ferramentas ajudam-no a criar, manter e consultar bases de dados SQL fragmentadas no Azure a partir da lógica da sua aplicação.