O que é escalabilidade?
No mundo dos negócios, o crescimento pode ser benéfico. No entanto, quando o crescimento opera de maneira muito rápida e você não está preparado adequadamente para ele, isso 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 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 adaptar-se às maiores demandas ou às necessidades de alteração. Seus aplicativos e serviços devem ser capazes de lidar com uma maior quantidade de cargas de trabalho para acomodar o crescimento. Aplicativos escalonáveis são capazes de lidar com um número cada vez maior de solicitações ao longo do tempo, sem efeitos negativos na disponibilidade ou no desempenho.
Nesta unidade, você aprenderá sobre a relação entre escalabilidade e confiabilidade, a importância do planejamento da capacidade para obter escalabilidade e revisará brevemente alguns conceitos e termos básicos relacionados à escala.
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 sistema for escalado automaticamente e, em seguida, receber uma falha de componente em uma máquina virtual individual, o serviço de dimensionamento automático provisionará outra instância para atender aos requisitos mínimos de contagem de VMs (máquinas virtuais). Seu sistema se torna mais confiável. Em outro exemplo, você usa um serviço de nível superior, como o Armazenamento do Azure, que é inerentemente escalonável. Em caso de problemas de armazenamento, o serviço foi criado para ser confiável, ou seja, seus dados serão replicados.
Aqui está uma analogia: Imagine as rampas de acessibilidade que você geralmente vê fora dos edifícios que foram projetadas inicialmente para acomodar as pessoas em cadeiras de rodas. Elas atendem a essa finalidade. No entanto, também são usadas por pais com bebês em carrinhos 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 serão mais confiáveis também.
Escalabilidade e planejamento de capacidade
O planejamento da capacidade envolve a determinação dos recursos necessários para atender às demandas atuais e futuras. Você faz esse planejamento analisando o uso atual de recursos e projetando para o crescimento futuro.
Para estimar as necessidades de capacidade no futuro, você deve considerar esses fatores como:
- Crescimento comercial esperado
- Flutuações periódicas (sazonais, entre outras)
- Restrições do aplicativo
- Identificação de afunilamentos e limitação de fatores
Você também precisa definir os objetivos de nível de serviço para criar um plano de gerenciamento da capacidade que atenderá ou excederá de modo confiável esses objetivos à medida que a carga de trabalho e o ambiente forem alterados.
O planejamento de capacidade é um processo iterativo. À medida que acompanharmos este módulo, você aprenderá a mapear os requisitos de recursos para componentes de aplicativos.
Conceitos e terminologia
Para entender por completo os conceitos e as estratégias que encontrará neste módulo, você precisa ter um pouco de conhecimento prévio sobre alguns conceitos básicos e termos fundamentais relacionados à escala.
- Escalabilidade vertical: torna um componente maior para lidar com uma carga de trabalho maior. Isso também é conhecido como escala vertical.
- Escalabilidade horizontal: adicionar mais componentes ou recursos para distribuir 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 de front-end) para tratá-lo. Isso também é conhecido como escala horizontal.
- Escalabilidade manual: é necessária uma ação humana para aumentar a quantidade de recursos.
- Dimensionamento automático: o sistema ajusta automaticamente a quantidade de recursos com base na carga. Para ficar claro, a quantidade é ajustada para cima e para baixo com base em uma carga aumentada ou diminuída.
- Faça você mesmo a escalabilidade: escala do tipo faça você mesmo, na qual você deve configurar o dimensionamento automático.
- Escala inerente: serviços que foram criados para serem escalonáveis e lidam com esse dimensionamento para você nos bastidores sem nenhuma intervenção de sua parte. Da sua perspectiva, eles parecem quase infinitamente escalonáveis pois você pode apenas consumir mais recursos sem a necessidade de 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. A plataforma de comércio eletrônico dela tem esta aparência:
Esse diagrama pode parecer bem complexo à primeira vista, então, vamos explicá-lo. O site tem um front-end. é com isso que você vai interagir se 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 eles estão em execução no Serviço de Kubernetes do Azure. Existem 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ê já viu toda a arquitetura, vamos examinar os pontos únicos de falha e os lugares em que podemos focar nossa atenção ao pensar no dimensionamento.
Todos esses serviços são um ponto único de falha, eles não são criados para resiliência ou para escala. Se um deles ficar sobrecarregado, provavelmente, ele falhará e não haverá um modo fácil de resolver isso no momento.
Mais adiante neste módulo, veremos outras maneiras de projetar esses serviços para serem mais escalonáveis e confiáveis.
Capacidade previamente provisionada
Vamos dar uma olhada em outra questão que poderia ser problemática. Estes são os serviços/componentes que exigem um provisionamento prévio da capacidade:
Por exemplo, com o Cosmos DB, provisionamos previamente a taxa de transferência. Se excedermos esses limites, começaremos a retornar mensagens de erro para 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. Após atingirmos um desses limites, os clientes verão uma restrição.
Será que um pico significativo no tráfego, como iniciar um novo produto, pode fazer com que consigamos atingir esses limites? No momento, não sabemos. Essa é outra questão que analisaremos mais adiante neste módulo.
Custos
Mesmo quando fazemos as coisas corretamente, ainda precisamos planejar o crescimento. Estes são os serviços de pagamento por uso:
Aqui estamos usando os Aplicativos Lógicos do Azure e Azure Functions, que são exemplos de tecnologia sem servidor. Esses serviços são escalados automaticamente, e os pagamos por solicitação. Sua fatura cresce conforme a sua base de clientes. Devemos, pelo menos, estar cientes do impacto que eventos futuros, como um lançamento de produto, podem ter em nossos gastos com a nuvem. Também trabalharemos na compreensão e na previsão de nossos gastos com a nuvem mais adiante neste módulo.