Considerações sobre planejamento de capacidade

O planejamento básico da capacidade começa com alguns cálculos simples, mas há fatores que podem complicar o processo. Além dos números de uso simples atuais e previstos, você também deve considerar as seguintes considerações:

• Cotas e limites de serviço
• Limitações de custo
• Ineficiências de código e configuração
• Dependências

Nesta unidade, você verá como essas considerações podem afetar seu planejamento de capacidade e como lidar com cada uma delas.

Cotas e limites de serviço

Há uma tendência de ver a computação em nuvem como um recurso ilimitado. Em comparação com modelos de servidor/datacenter tradicionais, a capacidade da nuvem parece ser infinita. A nuvem oferece um novo nível de escala. No entanto, como todo o resto, ele tem alguns limites. O planejamento de capacidade envolve entender quando você vai atingir esses limites de serviço.

Ao examinar seu sistema e sua arquitetura, você precisa entender os limites dos serviços de nuvem que está usando. Por exemplo, por padrão, você pode ter um máximo de 1.000 VMs por conjunto de disponibilidade de VM em Azure. Esse limite pode parecer mais do que VMs suficientes se você está apenas começando. No entanto, quando você atinge esse limite, não é possível provisionar mais VMs, o que pode resultar em uma interrupção.

Da mesma forma, por padrão, você pode ter 250 contas de armazenamento por assinatura, por região (esse limite pode ser aumentado por meio de uma solicitação de suporte). Esses limites são exemplos de limites suaves que podem ser aumentados. Mas alguns serviços têm limites máximos, que você pode encontrar no link a seguir.

Limites, cotas e restrições de assinatura e serviço do Azure

Esses limites e cotas são algo a ser ciente e monitorado. Vamos ver maneiras de fazer isso.

portal do Azure

Você pode ver as cotas de serviço e onde você está em relação a esses limites na seção Uso + cotas em Assinaturas –> Configurações no painel de navegação. Você pode filtrar em categoria de serviço, como rede/computação, e região do Azure. Ele mostra o ponto em que você está em relação aos limites.

Por meio de código

Você pode usar o ponto de extremidade Usage - List para qualquer serviço Azure para obter as informações atuais de uso de recursos e os limites de recursos de computação na assinatura, conforme mostrado neste exemplo truncado. Verifique a referência da API REST Azure para obter a versão mais recente da API estável.

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2024-07-01
{ 
    "currentValue": 12,
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/westeurope/usages/virtualMachines",
    "limit": 25000, 
    "name": { 
        "localizedValue": "Virtual Machines",
        "value": "virtualMachines" 
    }, 
    "unit": "Count" 
}

Você pode ver que o número atual de máquinas virtuais sendo usadas é 12 contra um limite de 25.000. Alguns limites podem ser aumentados por meio de uma solicitação de suporte, portanto, verifique se você sabe com antecedência quando pode chegar perto de um limite.

Limitações de custo

O dimensionamento não se trata apenas de alocar mais recursos para o problema. É importante que sua organização entenda o custo do seu ambiente de nuvem e que adicionar mais recursos geralmente é igual a mais custos. Esteja ciente desse custo e trabalhe com suas equipes financeiras para garantir que você esteja de acordo sobre os gastos atuais e projetados na nuvem.

Você deve prever o custo ao projetar inicialmente os sistemas e ao executar revisões regulares de seus sistemas já em execução. Azure oferece ferramentas que podem ajudá-lo:

• Planeje o custo de um ambiente usando a calculadora Azure.
• Examine os gastos mensais atuais e projetados no portal Azure.
• Configure orçamentos em Gerenciamento de Custos da Microsoft. Essa ferramenta pode permitir que você examine seus custos em escopos diferentes, incluindo grupo de gerenciamento, grupo de recursos e assinatura.

Ineficiências de código e configuração

Às vezes, direcionar mais recursos pode resolver um problema, mas isso custa dinheiro. Às vezes, o dimensionamento não é a solução ou não é a solução completa. Em alguns casos, pode ser que o que parece ser uma necessidade de dimensionamento seja, na verdade, um problema causado por codificação ou configuração incorreta.

Você pode potencialmente economizar dinheiro e tempo encontrando os bugs primeiro, antes de dimensionar os recursos. Alguns exemplos dessa abordagem incluem:

• Se você tiver um banco de dados mal projetado com partições sobrecarregadas, como usar apenas uma partição em um enorme banco de dados NoSQL, ele será lento, não importa o quanto você escalone.
• Se você tiver consultas de banco de dados ineficientes, torne-as mais eficientes antes de gerar mais recursos no banco de dados. Às vezes, apenas adicionar o índice certo a um banco de dados com base em consultas comuns pode reduzir seus custos em 100 vezes.
• Se os tempos limite estiverem definidos incorretamente e as conexões do banco de dados estiverem sendo saturadas devido a novas tentativas de tempos limite inconsistentes entre o servidor e o banco de dados. Nesse caso, você precisa corrigir as configurações antes de dimensionar o banco de dados.
• Se o código do desenvolvedor for ineficiente, você poderá escrever um código mais eficiente para resolver o problema? Talvez o código não libere memória quando pôde, portanto, você tem usado VMs de memória maiores quando isso não é necessário. Correções como essa podem proporcionar uma economia de custos significativa.

Dependências

As alterações necessárias para resolver alguns dos problemas descritos neste módulo geralmente têm dependências dos desenvolvedores do seu aplicativo. Algumas das soluções e práticas recomendadas aqui exigem colaboração entre você e esses desenvolvedores para que isso aconteça.

Talvez você não consiga implementar todas essas recomendações por conta própria. No entanto, se você entender o sistema de nuvem e suas funcionalidades e características, poderá se tornar um driver para mudanças na melhoria de seus sistemas e sua escalabilidade e confiabilidade.