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 200 VMs por conjunto de disponibilidade de VM no Azure. Esse limite pode parecer mais do que suficiente de VMs se você estiver 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. 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.

Assinatura do Azure e Limites de Serviço, Cotas e Restrições

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 na categoria de serviço, como rede/computação, e região do Azure. Ele mostra onde você está contra os limites.

Por meio de código

Você pode usar o Usage - List ponto de extremidade para qualquer serviço do Azure para obter as informações atuais de uso de recursos e os limites para recursos de computação na assinatura, conforme mostrado neste exemplo truncado.

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{ 
    "currentValue": 124,
    "/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
    "limit": 1000, 
    "name": { 
        "localizedValue": "Virtual Networks",
        "value": "VirtualNetworks" 
    }, 
    "unit": "Count" 
}

Você pode ver que o número atual de VNets (Redes Virtuais) do Azure sendo usadas é 124 contra um limite de 1000. Aumentar um limite requer uma solicitação de suporte, portanto, verifique se você sabe com antecedência quando pode chegar perto do limite.

Limitações de custo

O dimensionamento não se trata apenas de gerar mais recursos no 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. O Azure oferece ferramentas que podem ajudá-lo:

• Planeje o custo de um ambiente usando a calculadora do Azure.
• Examine os gastos mensais atuais e projetados no portal do Azure.
• Configure orçamentos no 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 ativas, como usar apenas uma partição em um banco de dados noSQL enorme, ele será lento, não importa o quanto você dimensione.
• 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 remover seus custos 100x.
• Se os tempos limite forem definidos incorretamente, suas conexões de banco de dados poderão ser 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.