O que é escalabilidade?

No mundo dos negócios, o crescimento pode ser benéfico. No entanto, quando o crescimento acontece muito rapidamente, e quando você não se preparou adequadamente para ele, o crescimento pode criar problemas. Um desses problemas é o efeito do crescimento na confiabilidade de aplicativos e serviços que não foram projetados para lidar com um grande aumento no tráfego.

Para seus clientes e usuários, uma interrupção é uma interrupção. Eles não sabem ou se importam se não conseguem acessar seu site por causa de um código com bugs ou porque muitas outras pessoas estão tentando usar seu site perfeitamente codificado ao mesmo tempo.

Escalabilidade é a capacidade de se adaptar a demandas crescentes ou necessidades em mudança. Seus aplicativos e serviços devem ser capazes de lidar com uma quantidade maior de carga de trabalho para acomodar o crescimento. Os aplicativos escaláveis são capazes de lidar com um número crescente de solicitações ao longo do tempo sem um efeito negativo na disponibilidade ou no desempenho.

Nesta unidade, você aprende sobre a relação entre escalabilidade e confiabilidade, a importância do planejamento de capacidade para alcançar a escalabilidade e revisa brevemente alguns conceitos e termos básicos relacionados ao dimensionamento.

Relação escalabilidade/fiabilidade

A boa notícia é que tornar seu aplicativo mais escalável também pode torná-lo mais confiável. Por exemplo, se o sistema for dimensionado automaticamente e, em seguida, dada uma falha de componente em uma única máquina virtual, o serviço de dimensionamento automático provisionará outra instância para atender aos requisitos mínimos de contagem de máquina virtual (VM). O seu sistema torna-se mais fiável. Em outro exemplo, você está usando um serviço de nível superior, como o Armazenamento do Azure, que é inerentemente escalável. Se você tiver um problema de armazenamento, o serviço foi criado para ser confiável, para que seus dados sejam replicados.

Aqui está uma analogia: pense nas rampas de acessibilidade que você costuma ver do lado de fora dos edifícios que foram inicialmente projetados para acomodar pessoas em cadeiras de rodas. Servem esse propósito. Mas, eles também são usados por pais com bebês em carrinhos ou carruagens, ou por crianças pequenas para quem os degraus da escada são muito profundos ou altos. Este uso é um benefício secundário .

A fiabilidade é muitas vezes um benefício secundário da escalabilidade. Se você projetar seus sistemas para serem escaláveis, é provável que eles também sejam mais confiáveis.

Escalabilidade e planejamento de capacidade

O planejamento de capacidade envolve determinar os recursos necessários para atender às demandas presentes e futuras. Você faz esse planejamento analisando seu uso atual de recursos e, em seguida, projetando para crescimento futuro.

Para estimar as necessidades de capacidade no futuro, você deve considerar fatores como:

• Crescimento esperado do negócio
• Flutuações periódicas (sazonais, etc.)
• Restrições de aplicativos
• Identificação de estrangulamentos e fatores limitantes

Você também precisa definir objetivos de nível de serviço para poder criar um plano de gerenciamento de capacidade que atenda ou exceda esses objetivos de forma confiável à medida que a carga de trabalho e o ambiente mudam.

O planejamento de capacidade é um processo iterativo. Ao passarmos por este módulo, você aprenderá a mapear os requisitos de recursos para componentes de aplicativos.

Conceitos e terminologia

Antes de entender completamente os conceitos e estratégias que você encontra neste módulo, você precisa de algum conhecimento pré-requisito de alguns conceitos básicos e termos fundamentais relacionados ao dimensionamento.

• Ampliação: Aumentar um componente para lidar com uma carga de trabalho maior. Também conhecido como dimensionamento vertical.
• Dimensionamento: adicionar mais componentes ou recursos para distribuir a carga por uma arquitetura distribuída. Por exemplo, utilizando uma arquitetura simples que possua vários servidores back-end por trás de um conjunto de servidores front-end. À medida que a carga aumenta, adicionamos mais servidores back-end (e front-end) para lidar com isso. Também conhecido como dimensionamento horizontal.
• Dimensionamento manual: A ação humana é necessária para aumentar a quantidade de recursos.
• Dimensionamento automático: O sistema ajusta automaticamente a quantidade de recursos com base na carga. Para ser claro, o montante é ajustado para cima e para baixo com base em uma carga aumentada ou diminuída.
• Escala DIY: Dimensionamento "faça você mesmo" pelo qual você tem que configurar o dimensionamento automático.
• Escala inerente: Serviços concebidos para serem escaláveis e gerirem este processo de aumento de capacidade para si de forma discreta, sem qualquer intervenção da sua parte. Do seu ponto de vista, eles parecem quase infinitamente escaláveis porque você pode simplesmente consumir mais recursos sem precisar provisioná-los manualmente.

Arquitetura Tailwind Traders

Neste módulo, vamos usar uma arquitetura de exemplo de uma empresa de hardware fictícia chamada Tailwind Traders. Sua plataforma de comércio eletrônico se parece com isto:

Este diagrama é bastante complexo à primeira vista, por isso vamos analisá-lo. O site tem um front-end. É com isto que se fala se fores ao tailwindtraders.com.

O front-end conversa com um conjunto de serviços de back-end. Esses serviços de back-end incluem os itens comuns, como um serviço de cupom, um serviço de carrinho de compras, um serviço de inventário e assim por diante. Todos eles estão sendo executados no Serviço Kubernetes do Azure. Existem outras partes e tecnologias em jogo com esta aplicação. Tudo o que você precisa focar é no front-end e nos serviços de back-end executados no Kubernetes.

Pontos únicos de falha

Agora que você já viu toda a arquitetura, vamos reservar um momento para examinar os pontos de falha únicos e os locais nos quais podemos focar nossa atenção ao considerar a escalabilidade.

Todos esses serviços são um único ponto de falha - eles não são criados para resiliência ou escala. Se um deles ficar sobrecarregado, é provável que falhe, e não há maneira fácil de resolver isso no momento.

Mais adiante neste módulo, analisaremos outras maneiras de projetar esse serviço para ser mais escalável e confiável.

Capacidade pré-provisionada

Vamos dar uma olhada em outra questão que pode ser problemática. Aqui estão os serviços/componentes que exigem que pré-provisionemos a capacidade:

Por exemplo, com o Cosmos DB, pré-configuramos a capacidade de taxa de transferência. Se excedermos esses limites, começaremos a retornar mensagens de erro aos nossos clientes. Com os serviços de IA do Azure, selecionamos a camada e essa camada tem um número máximo de solicitações por segundo. Depois de atingirmos qualquer um dos limites, os clientes serão limitados.

Será que um aumento significativo no tráfego, como o lançamento de um novo produto, nos fará atingir esses limites? Neste momento, não sabemos. Este assunto é outro que analisaremos mais adiante neste módulo.

Custos

Mesmo quando fazemos as coisas corretamente, ainda precisamos planejar o crescimento. Aqui estão os serviços pay-per-use:

Aqui, estamos usando os Aplicativos Lógicos do Azure e o Azure Functions, que são exemplos de tecnologia sem servidor. Estes serviços são dimensionados automaticamente e pagamos por pedido. A sua fatura cresce à medida que a sua base de clientes cresce. Devemos, pelo menos, estar cientes do impacto que os próximos eventos, como o lançamento de um produto, podem ter nos nossos gastos na nuvem. Trabalhamos para entender e prever nossos gastos na nuvem mais tarde neste módulo também.