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 defeito, pode ter um máximo de 1000 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, pode ter 250 contas de armazenamento por subscrição, por região (este limite pode ser aumentado através de um pedido de suporte). 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 de serviços e de subscrição do Azure, quotas e restrições

Estes limites e quotas são algo a ter em conta e a controlar. Vamos ver maneiras de fazer isso.

Azure portal

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

Via código

Pode usar o endpoint Usage - List para qualquer serviço de Azure para obter a informação atual de utilização de recursos e os limites para recursos de cálculo sob a subscrição, como mostrado neste exemplo truncado. Verifique a referência da API Azure REST para a versão estável mais recente da API.

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" 
}

Pode ver que o número atual de máquinas virtuais utilizadas é 12 contra um limite de 25.000. Alguns limites podem ser aumentados através de um pedido de suporte, por isso certifique-se de saber antecipadamente quando poderá aproximar-se de um limiar.

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 ajudar-te:

• Planeie o custo de um ambiente usando a calculadora Azure.
• Consulte os gastos mensais atuais e projetados no portal 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 tiveres uma base de dados mal desenhada com partições quentes, como usar apenas uma partição numa enorme base de dados NoSQL, é lento, independentemente do quanto escales.
• 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 melhores práticas aqui recomendadas exigem colaboração entre si e esses programadores 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.