Considerações sobre o planeamento de capacidade
O planeamento de capacidade básico 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 de servidor/datacenter tradicionais, a capacidade da cloud parece ser infinita. De facto, a cloud proporciona um nível de dimensionamento totalmente novo. 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 VMs mais do que suficientes se você estiver apenas começando. 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. No entanto, alguns serviços têm limites máximos, que pode encontrar na seguinte ligação.
Subscrição do Azure e limites, quotas e restrições do serviço
Estes limites e quotas são algo a ter em conta e a controlar. Vejamos algumas formas de o fazer.
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.
Com código
Você pode usar o Usage - List ponto de extremidade para qualquer serviço do Azure para obter as informações de uso de recursos atuais 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"
}
Pode ver que o número atual de Redes Virtuais do Azure (VNets) que estão a ser utilizadas é 124 relativamente a 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 para a sua organização compreender os custos do ambiente de cloud e que, em geral, adicionar mais recursos equivale 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 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.
- Consultar os gastos mensais atuais e previstos 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. Por vezes, dimensionar não é a solução ou não é a solução completa. Em alguns casos, o que pode parecer ser uma necessidade de dimensionamento é, na verdade, um problema causado por uma codificação ou configuração incorreta.
Poderá poupar tempo e dinheiro ao localizar os erros antes de aumentar horizontalmente 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 tiver consultas de base de dados ineficientes, torne-as mais eficazes antes de atribuir mais recursos à base 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 incorretamente, as conexões do banco de dados poderão ficar 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 programador for ineficiente, pode escrever 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 estas podem proporcionar poupanças 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.