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 prepara adequadamente para ele, o crescimento pode criar problemas. Um desses problemas é o efeito do crescimento da 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 não se importam se não conseguem acessar seu site devido a um código cheio de bugs ou porque muitas outras pessoas estão tentando usar seu site perfeitamente codificado ao mesmo tempo.

A escalabilidade é a capacidade de se adaptar ao aumento das demandas ou à alteração das necessidades. Seus aplicativos e serviços devem ser capazes de lidar com uma quantidade maior de carga de trabalho para acomodar o crescimento. Aplicativos escalonáveis são capazes de lidar com um número crescente de solicitações ao longo do tempo sem um efeito negativo sobre a disponibilidade ou o desempenho.

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

Relação de escalabilidade/confiabilidade

A boa notícia é que tornar seu aplicativo mais escalonável também pode torná-lo mais confiável. Por exemplo, se o seu sistema for dimensionado automaticamente, então, ao ocorrer uma falha de componente em uma única máquina virtual, o serviço de dimensionamento automático provisiona outra instância para atender aos requisitos mínimos de quantidade de máquinas virtuais (VM). Seu sistema se torna mais confiável. Em outro exemplo, você está usando um serviço de nível superior, como Armazenamento do Azure que é inerentemente escalonável. Se você tiver um problema de armazenamento, o serviço será criado para ser confiável, portanto, seus dados serão replicados.

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

A confiabilidade geralmente é um benefício secundário da escalabilidade. Se você projetar seus sistemas para serem escalonáveis, eles provavelmente também serão mais confiáveis.

Escalabilidade e planejamento de capacidade

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

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

• Crescimento esperado dos negócios
• Flutuações periódicas (sazonais e assim por diante)
• Restrições de aplicativo
• Identificação de gargalos e fatores de limitação

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 de forma confiável esses objetivos à medida que a carga de trabalho e o ambiente mudam.

O planejamento de capacidade é um processo iterativo. Conforme percorremos este módulo, você aprenderá a mapear os requisitos de recursos para componentes do aplicativo.

Conceitos e terminologia

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

• Dimensionamento: aumentar um componente para lidar com uma carga de trabalho maior. Também chamado de escalonamento vertical.
• Dimensionamento: adicionando mais componentes ou recursos para espalhar a carga por uma arquitetura distribuída. Por exemplo, usando uma arquitetura simples que tem vários back-ends por trás de um conjunto de front-ends. À medida que a carga aumenta, adicionamos mais servidores de 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 ficar claro, o valor é ajustado para cima e para baixo com base em uma carga aumentada ou reduzida.
• Escala DIY: dimensionamento "Faça você mesmo" pelo qual você precisa configurar o dimensionamento automático.
• Escala inerente: Os serviços foram criados para serem escaláveis e gerenciar essa escala de forma automática, sem nenhuma intervenção de sua parte. Da sua perspectiva, eles parecem quase infinitamente escalonáveis porque você pode apenas consumir mais recursos sem precisar provisioná-los manualmente.

Arquitetura da Tailwind Traders

Neste módulo, usaremos uma arquitetura de exemplo de uma empresa de hardware fictícia chamada Tailwind Traders. Sua plataforma de comércio eletrônico tem esta aparência:

Este diagrama é bastante complexo à primeira vista, então vamos percorrê-lo. O site tem um front-end. É sobre isso que você fala ao acessar tailwindtraders.com.

O front-end se comunica 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 estão executando no Serviço de Kubernetes do Azure. Há outras partes e tecnologias em jogo com este aplicativo. Você só precisa se concentrar no front-end e nos serviços de back-end em execução no Kubernetes.

Pontos únicos de falha

Agora que você viu toda a arquitetura, vamos tirar um momento para examinar os pontos únicos de falha e os locais nos quais devemos focar ao pensar em escalabilidade.

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

Posteriormente neste módulo, examinaremos outras maneiras de projetar esses serviços para serem mais escalonáveis e confiáveis.

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 a pré-provisionação da capacidade:

diagrama completo de arquitetura do aplicativo com serviços de IA do Azure, Cosmos DB e Banco de Dados SQL realçados.

Por exemplo, com o Cosmos DB, preparamos antecipadamente a capacidade de processamento. Se excedermos esses limites, começaremos a retornar mensagens de erro aos nossos clientes. Com Serviços de IA do Azure, selecionamos a camada e essa camada tem um número máximo de solicitações por segundo. Após atingirmos um desses 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? No momento, não sabemos. Este assunto é outro que examinaremos mais adiante neste módulo.

Custos

Mesmo quando fazemos as coisas certas, ainda precisamos planejar o crescimento. Aqui estão os serviços de pagamento por uso:

Aqui, estamos usando Aplicativos Lógicos do Azure e Azure Functions, que são exemplos de tecnologia sem servidor. Esses serviços escalam automaticamente e pagamos por solicitação. Sua fatura cresce conforme sua base de clientes aumenta. Devemos pelo menos estar cientes do impacto que os próximos eventos, como um lançamento de produto, podem ter em nossos gastos com nuvem. Também trabalhamos para entender e prever nossos gastos em nuvem posteriormente neste módulo.