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 levar em consideração as seguintes considerações:

• Limites e quotas de serviço
• Limitações de custos
• Ineficiências de código e configuração
• Dependências

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

Limites e quotas de serviço

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

Ao olhar para o seu sistema e sua arquitetura, você precisa entender os limites para os serviços de nuvem que você está usando. Por exemplo, por padrão, você pode ter um máximo de 200 VMs por disponibilidade de VM definida no Azure. Esse limite pode parecer mais do que VMs suficientes se estiver apenas a começar. No entanto, quando você atinge esse limite, não consegue 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. Estes limites são ambos exemplos de limites suaves que podem ser aumentados. Mas alguns serviços têm limites máximos, que pode encontrar no seguinte link.

Limites, quotas e restrições de subscrição e serviço do Azure

Estes limites e quotas são algo a ter em conta e a controlar. 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 por categoria de serviço, como rede/computação e região do Azure. Ele mostra onde você está contra os limites.

Via código

Pode usar o endpoint Usage - List de qualquer serviço Azure para obter informações sobre o uso atual de recursos e os limites de recursos computacionais da sua subscrição, como mostrado neste exemplo resumido.

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 Redes Virtuais do Azure (VNets) sendo usadas é 124 contra um limite de 1000. Aumentar um limite requer uma solicitação de suporte, portanto, certifique-se de saber com antecedência quando pode chegar perto do limite.

Limitações de custos

Escalar não é apenas jogar mais recursos no problema. É importante que sua organização entenda o custo do seu ambiente de nuvem e que adicionar mais recursos geralmente equivale a mais custo. 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 realizar revisões regulares de seus sistemas já em execução. O Azure oferece ferramentas que podem ajudá-lo a:

• Planeje o custo de um ambiente usando a calculadora do Azure.
• Analise os gastos mensais atuais e projetados no portal do Azure.
• Configure orçamentos no Microsoft Cost Management. Essa ferramenta pode permitir que você examine seus custos em diferentes escopos, 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 economizar dinheiro e tempo encontrando os bugs primeiro, antes de expandir os recursos. Eis alguns exemplos desta abordagem:

• Se você tem um banco de dados mal projetado com partições quentes, como usar apenas uma partição em um enorme banco de dados noSQL, ele é lento, não importa o quanto você escala.
• Se você tiver consultas de banco de dados ineficientes, torne-as mais eficientes antes de lançar 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 100x.
• Se os tempos limite estiverem definidos de forma incorreta, as conexões com o banco de dados podem ficar saturadas devido a repetidas tentativas resultantes 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ê pode escrever um código mais eficiente para resolver o problema? Talvez o código não libere memória quando poderia, então você tem usado VMs de memória maiores quando isso não é necessário. Correções como essa podem proporcionar economias de custos significativas.

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.

Poderá não conseguir implementar todas estas recomendações inteiramente sozinho. No entanto, se você entender o sistema de nuvem e suas capacidades e características, você pode se tornar um driver para a mudança na melhoria de seus sistemas e sua escalabilidade e confiabilidade.