O que é escalabilidade?

Concluído

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. Não sabem ou não estão interessados em saber se não conseguem aceder ao seu site devido a código com erros ou porque muitas outras pessoas estão a tentar utilizar o seu site adequadamente codificado em simultâneo.

A escalabilidade é a capacidade de adaptação a um aumento das exigências ou a necessidades dinâmicas. As suas aplicações e serviços têm de ser capazes de lidar com um aumento da carga de trabalho para contemplar o crescimento. As aplicações dimensionáveis são capazes de lidar com um número crescente de pedidos 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, ao tornar a sua aplicação mais dimensionável, também poderá torná-la mais fiá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 costuma ser 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 planeamento de capacidade

O planeamento de capacidade implica determinar os recursos necessários para satisfazer as exigências presentes e futuras. Você faz esse planejamento analisando seu uso atual de recursos e, em seguida, projetando para crescimento futuro.

Para calcular as necessidades de capacidade no futuro, deve considerar fatores como:

  • Crescimento esperado da empresa
  • Flutuações periódicas (sazonais, etc.)
  • Restrições da aplicação
  • Identificação de estrangulamentos e fatores limitadores

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 planeamento 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, usando uma arquitetura simples que tenha vários back-ends atrás de um conjunto de front-ends. À 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 que foram criados para serem escaláveis e lidarem com esse dimensionamento para você nos bastidores sem qualquer intervenção de sua parte. Do seu ponto de vista, parecem quase infinitamente dimensionáveis uma vez que é possível consumir mais recursos sem ter de aprovisionar os mesmos manualmente.

arquitetura da Tailwind Traders

Neste módulo, vamos usar uma arquitetura de exemplo de uma empresa de hardware fictícia chamada Tailwind Traders. A sua plataforma de comércio eletrónico tem o seguinte aspeto:

Full architecture diagram of applications with frontend, backend and other components.

Este diagrama é bastante complexo à primeira vista, então vamos acompanhá-lo. O site tem um front-end. É com isso que você fala se for a tailwindtraders.com.

Full architecture diagram of application with frontend component highlighted.

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.

Full architecture diagram of application with backend component highlighted.

Pontos únicos de falha

Agora que viu toda a arquitetura, vamos analisar os pontos únicos de falha e os pontos aos quais podemos dedicar a nossa atenção quando consideramos o dimensionamento.

Full architecture diagram of application with backend components and SQL DB highlighted.

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é-aprovisionada

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:

Full architecture diagram of application with Azure AI services, Cosmos DB, and SQL DB highlighted

Por exemplo, com o Cosmos DB, pré-provisionamos a taxa de transferência. Se excedermos esses limites, começaremos a devolver 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 bem as coisas, continuamos a ter de planear para o crescimento. Aqui estão os serviços de pagamento por utilização:

Full architecture diagram of application with Azure Logic Apps and Azure Functions highlighted.

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 fatura cresce em proporção do crescimento da base de clientes. Devemos, pelo menos, ter em atenção o impacto que os próximos eventos, como o lançamento de um produto, podem ter nos nossos gastos com a cloud. Trabalhamos para entender e prever nossos gastos na nuvem mais tarde neste módulo também.

Verifique o seu conhecimento

1.

Tornar a sua aplicação ou serviço mais dimensionável também pode:

2.

Tornar a sua aplicação ou serviço mais dimensionável também pode:

3.

O processo de adicionar mais componentes ou recursos para repartir a carga por uma arquitetura distribuída é conhecido como: