Considerações de planejamento de capacidade
O planejamento básico de capacidade começa com alguns cálculos diretos, mas há fatores que podem complicar o processo. Além dos simples números de uso atuais e previstos, você também precisa incluir as seguintes considerações:
- Cotas e limites de serviço
- Limitações de custo
- Ineficiências de configuração e código
- Dependências
Nesta unidade, você examinará como essas considerações podem afetar o planejamento da capacidade e como lidar com cada uma delas.
Cotas e limites de serviço
Há uma tendência em considerar a computação em nuvem como um recurso ilimitado. Em comparação com modelos tradicionais de servidor/datacenter, a capacidade da nuvem parece ser infinita. A nuvem oferece um nível totalmente novo de escala. No entanto, como qualquer coisa, ela tem alguns limites. O planejamento da capacidade envolve a compreensão de quando você vai atingir os limites do serviço.
Ao examinar seu sistema e a arquitetura dele, você precisa entender os limites dos serviços de nuvem que está usando. Por exemplo, por padrão, você pode ter no máximo 200 VMs por conjunto de disponibilidade de VMs no Azure. Esse limite pode parecer mais do que VMs suficientes se você está apenas começando. No entanto, quando atingir esse limite, você não poderá provisionar mais VMs, o que poderá resultar em uma interrupção.
Da mesma maneira, por padrão, você pode ter 250 contas de armazenamento por assinatura, por região. Esses são exemplos de limites flexíveis que podem ser aumentados. Contudo, alguns serviços têm limites máximos, que podem ser encontrados no link a seguir.
Assinatura do Azure e limite de serviços, cotas e restrições
Esses limites e essas cotas são algo de que você deve estar ciente e monitorar. Vejamos maneiras de fazer isso.
Portal do Azure
Você poderá ver as cotas de serviço e o ponto em que está em relação a esses limites na seção Uso + cotas em Assinaturas -> Configurações no painel de navegação. Você pode filtrar a categoria de serviço, como rede/computação, bem como a 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 do Azure, a fim de obter as informações de uso do recurso atual 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 observar que o número atual das Redes Virtuais do Azure (VNets) que está sendo usado é 124 em relação a um limite de 1000. Aumentar o limite requer uma solicitação de suporte, portanto, certifique-se de que você sabe antecipadamente quando pode chegar perto do limite.
Limitações de custo
A escala não se trata apenas de lançar 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 custos. Esteja atento a esse custo e trabalhe com suas equipes de finanças para garantir que vocês estejam de acordo com os gastos com a nuvem atuais e projetados.
Você deve prever o custo ao criar inicialmente os sistemas e ao executar revisões regulares dos sistemas já em execução. O Azure oferece ferramentas que podem ajudar você a:
- Planejar o custo de um ambiente usando a calculadora do Azure.
- Revisar os gastos mensais atuais e projetados no portal do Azure.
- Configurar orçamentos no Gerenciamento de Custos da Microsoft. Essa ferramenta possibilita examinar seus custos em escopos diferentes, incluindo grupo de gerenciamento, grupo de recursos e assinatura.
Ineficiências de configuração e código
Às vezes, o direcionamento de 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, talvez o que parece ser uma necessidade de dimensionar é, na verdade, um problema causado por uma codificação ou configuração incorreta.
Potencialmente, você pode economizar dinheiro e tempo encontrando os bugs primeiro, antes de escalar horizontalmente os recursos. Alguns exemplos dessa abordagem incluem:
- Se você tiver um banco de dados mal projetado com partições ativas, como o uso de apenas uma partição em um banco de dados NoSQL enorme, ele ficará lento, independentemente do tamanho da escala.
- Se você tiver consultas de banco de dados ineficientes, torne-as mais eficientes antes de lançar mais recursos nele. Às vezes, apenas adicionar o índice correto a um banco de dados com base em consultas comuns pode diminuir seus custos em 100x.
- 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ê precisará corrigir as configurações antes de escalar o banco de dados.
- Se o código do desenvolvedor não for eficiente, você poderá escrever um código mais eficiente para resolver o problema? Talvez o código não libere memória quando deveria, ou seja, você está usando VMs de memória maior quando isso não é necessário. Correções como essa podem proporcionar uma economia de custo significativa.
Dependências
As alterações necessárias para resolver alguns dos problemas descritos neste módulo geralmente têm dependências nos desenvolvedores do seu aplicativo. Algumas das soluções e das melhores práticas recomendadas aqui exigem a colaboração entre você e esses desenvolvedores para que isso aconteça.
Talvez você não consiga implementar todas essas recomendações inteiramente por conta própria. No entanto, se você entender o sistema de nuvem e as funcionalidades e características dele, poderá se tornar um fator de mudança no aprimoramento dos seus sistemas e da escalabilidade e da confiabilidade deles.