Recomendações para conceber uma estratégia de dimensionamento fiável

  • Artigo

Aplica-se a esta recomendação da lista de verificação de fiabilidade do Azure Well-Architected Framework:

RE:06 Implemente uma estratégia de dimensionamento atempadamente e fiável ao nível da aplicação, dos dados e da infraestrutura.

Guia relacionado:Criação de partições de dados

Este guia descreve as recomendações para conceber uma estratégia de dimensionamento fiável.

Definições

Termo Definição
Dimensionamento vertical Uma abordagem de dimensionamento que adiciona capacidade de computação aos recursos existentes.
Dimensionamento horizontal Uma abordagem de dimensionamento que adiciona instâncias de um determinado tipo de recurso.
Dimensionamento automático Uma abordagem de dimensionamento que adiciona ou remove recursos automaticamente quando um conjunto de condições é cumprido.

Nota

As operações de dimensionamento podem ser estáticas (dimensionamento diário agendado regularmente para acomodar padrões de carga normais), automático (um processo automatizado em resposta às condições que estão a ser cumpridas) ou manual (um operador executa uma operação de dimensionamento único em reação a uma alteração de carga imprevista). O dimensionamento vertical e horizontal pode ser efetuado através de qualquer um destes métodos. No entanto, o dimensionamento vertical automático requer um desenvolvimento de automatização personalizado adicional e pode causar tempo de inatividade consoante os recursos que estão a ser dimensionados.

Principais estratégias de conceção

Para conceber uma estratégia de dimensionamento fiável para as suas cargas de trabalho, concentre-se na identificação de padrões de carga para os fluxos de utilizador e sistema para cada carga de trabalho que conduz a uma operação de dimensionamento. Eis exemplos dos diferentes padrões de carga:

  • Estático: todas as noites por 23:00 EST, o número de utilizadores ativos é inferior a 100 e a utilização da CPU para os servidores de aplicações diminui 90% em todos os nós.

  • Dinâmico, regular e previsível: todas as segundas-feiras de manhã, 1000 colaboradores em várias regiões iniciam sessão no sistema ERP.

  • Dinâmico, irregular e previsível: o lançamento de um produto ocorre no primeiro dia do mês e existem dados históricos de lançamentos anteriores sobre como o tráfego aumenta nestas situações.

  • Dinâmico, irregular e imprevisível: um evento de grande escala provoca um pico na procura de um produto. Por exemplo, as empresas que fabricam e vendem desumidificadores podem sofrer um aumento repentino de tráfego após um furacão ou outro evento de inundação quando as pessoas nas áreas afectadas precisam de secar salas em sua casa.

Depois de identificar estes tipos de padrões de carga, pode:

  • Identifique como a alteração de carga associada a cada padrão afeta a sua infraestrutura.

  • Crie automatização para abordar o dimensionamento de forma fiável.

Para os exemplos anteriores, as estratégias de dimensionamento podem ser:

  • Estático: tem uma escala agendada dos nós de computação para a contagem mínima (2) entre as 23:00 e as 6:00 EST.

  • Dinâmico, regular e previsível: tem um aumento horizontal agendado dos nós de computação para a capacidade diária normal antes de a primeira região começar a funcionar.

  • Dinâmico, irregular e previsível: define um aumento vertical agendado único das instâncias de computação e base de dados na manhã do lançamento de um produto e reduz verticalmente após uma semana.

  • Dinâmico, irregular e imprevisível: tem limiares de dimensionamento automático definidos para contabilizar picos de tráfego não planeados.

Ao conceber a automatização de dimensionamento, confirme que tem em conta estes problemas:

  • Que todos os componentes da carga de trabalho devem ser candidatos para a implementação do dimensionamento. Na maioria dos casos, os serviços globais, como Microsoft Entra ID, são dimensionados de forma automática e transparente para si e para os seus clientes. Certifique-se de que compreende as capacidades de dimensionamento dos controladores de entrada e saída de rede e a solução de balanceamento de carga.

  • Os componentes que não podem ser aumentados horizontalmente. Um exemplo seria bases de dados relacionais grandes que não têm a fragmentação ativada e não podem ser refatoradas sem um impacto significativo. Documente os limites de recursos publicados pelo seu fornecedor de cloud e monitorize esses recursos de perto. Inclua esses recursos específicos no seu planeamento futuro para migrar para serviços dimensionáveis.

  • O tempo que demora a executar a operação de dimensionamento para que agende corretamente a operação antes de a carga adicional atingir a infraestrutura. Por exemplo, se um componente como Gestão de API demorar 45 minutos a dimensionar, ajustar o limiar de dimensionamento para 65% em vez de 90% poderá ajudá-lo a dimensionar mais cedo e a preparar-se para o aumento previsto da carga.

  • A relação dos componentes do fluxo em termos de ordem das operações de dimensionamento. Certifique-se de que não sobrecarrega inadvertidamente um componente a jusante ao dimensionar primeiro um componente a montante.

  • Quaisquer elementos de aplicação com monitorização de estado que possam ser interrompidos por uma operação de dimensionamento e qualquer afinidade de sessão (ou persistência de sessão) implementada. A persistência pode limitar a sua capacidade de dimensionamento e introduz pontos únicos de falha.

  • Potenciais estrangulamentos. Aumentar horizontalmente não corrige todos os problemas de desempenho. Por exemplo, se a base de dados de back-end estiver com estrangulamento, não ajuda adicionar mais servidores Web. Identifique e resolva primeiro os estrangulamentos no sistema antes de adicionar mais instâncias. As partes com monitorização de estado do sistema são a causa mais provável dos estrangulamentos.

Seguir o padrão de conceção do carimbo de implementação ajuda na gestão geral da infraestrutura. Basear o seu design de dimensionamento em selos como unidades de escala também é vantajoso. Além disso, ajuda-o a controlar fortemente as suas operações de dimensionamento em várias cargas de trabalho e subconjunto de cargas de trabalho. Em vez de gerir os agendamentos de dimensionamento e os limiares de dimensionamento automático de muitos recursos distintos, pode aplicar um conjunto limitado de definições de dimensionamento a um carimbo de implementação e, em seguida, espelhar isso entre selos, conforme necessário.

Desvantagem: aumentar verticalmente tem implicações de custos, por isso, otimize a sua estratégia para reduzir verticalmente o mais rapidamente possível para ajudar a manter os custos sob controlo. Certifique-se de que a automatização que está a utilizar para aumentar verticalmente também tem acionadores para reduzir verticalmente.

Facilitação do Azure

Está disponível uma funcionalidade de dimensionamento automático em muitos serviços do Azure. Permite-lhe configurar facilmente condições para dimensionar automaticamente instâncias na horizontal. Alguns serviços têm funcionalidades limitadas ou não incorporadas para dimensionar automaticamente, por isso certifique-se de que documenta estes casos e define processos para lidar com o dimensionamento.

Muitos serviços do Azure oferecem APIs que pode utilizar para conceber operações de dimensionamento automático personalizadas com Automatização do Azure, como os exemplos de código em Dimensionar automaticamente o seu Hub IoT do Azure. Pode utilizar ferramentas como a KEDA para dimensionamento automático orientado por eventos, que está disponível no Azure Kubernetes Service e no Azure Container Apps.

O dimensionamento automático do Azure Monitor fornece um conjunto comum de funcionalidades de dimensionamento automático para o Azure Conjuntos de Dimensionamento de Máquinas Virtuais, Serviço de Aplicações do Azure, Azure Spring Apps e muito mais. O dimensionamento pode ser efetuado com base numa agenda ou com base numa métrica de runtime, como utilização da CPU ou da memória. Veja o guia do Azure Monitor para obter as melhores práticas.

Vantagens e desvantagens

Considerações sobre o dimensionamento automático

O dimensionamento automático não é uma solução instantânea. A simples adição de recursos a um sistema ou a execução de mais instâncias de um processo não garante a melhoria do desempenho desse sistema. Ao desenhar uma estratégia de dimensionamento automático, considere os seguintes pontos:

O sistema tem de ser desenhado para ser dimensionável horizontalmente. Evite fazer suposições sobre a afinidade de instância. Não crie soluções que exijam que o código esteja sempre em execução numa instância específica de um processo. Ao dimensionar horizontalmente um serviço cloud ou site, não suponha que uma série de pedidos da mesma origem são sempre encaminhados para a mesma instância. Pelo mesmo motivo, desenhe os serviços de modo a que não tenham estado, para evitar que seja necessário encaminhar sempre uma série de pedidos de uma aplicação para a mesma instância de um serviço. Ao desenhar um serviço que lê mensagens de uma fila e as processa, não faça suposições relativamente a que instância do serviço processa uma mensagem específica. O dimensionamento automático pode iniciar mais instâncias de um serviço à medida que o comprimento da fila aumenta. O padrão Consumidores Concorrentes descreve como lidar com este cenário.

Se a solução implementar uma tarefa de execução longa, desenhe essa tarefa para suportar o aumento e a redução horizontal. Sem o devido cuidado, tal tarefa pode impedir que uma instância de um processo seja encerrada de forma limpa quando o sistema é reduzido horizontalmente. Em alternativa, pode perder dados se o processo for forçado a terminar. Idealmente, reformule uma tarefa de execução longa e divida o processamento que a mesma realiza em segmentos mais pequenos e discretos. O padrão Pipes e Filtros fornece um exemplo de como pode alcançar esta solução.

Em alternativa, pode implementar um mecanismo de ponto de verificação que regista informações de estado sobre a tarefa em intervalos regulares. Em seguida, pode guardar este estado no armazenamento durável que pode ser acedido por qualquer instância do processo que executa a tarefa. Desta forma, se o processo for encerrado, o trabalho que estava a executar pode ser retomado a partir do último ponto de verificação por outra instância. Existem bibliotecas que fornecem esta funcionalidade, como NServiceBus e MassTransit. Persistem de forma transparente no estado em que os intervalos estão alinhados com o processamento de mensagens de filas no Azure Service Bus.

Quando as tarefas em segundo plano são executadas em instâncias de computação separadas, como nas funções de trabalho de uma aplicação alojada em serviços cloud, poderá ter de dimensionar diferentes partes da aplicação através de diferentes políticas de dimensionamento. Por exemplo, poderá ter de implementar instâncias de computação de interface de utilizador (IU) adicionais sem aumentar o número de instâncias de computação em segundo plano ou vice-versa. Se oferecer diferentes níveis de serviço, como pacotes de serviços básicos e premium, poderá ter de aumentar horizontalmente os recursos de computação para pacotes de serviço premium de forma mais agressiva do que os pacotes de serviço básicos para cumprir contratos de nível de serviço (SLAs).

Considere o comprimento da fila sobre a qual a IU e as instâncias de computação em segundo plano comunicam. Utilize-o como critério para a sua estratégia de dimensionamento automático. Este problema é um indicador possível de um desequilíbrio ou diferença entre a carga atual e a capacidade de processamento da tarefa em segundo plano. Um atributo um pouco mais complexo, mas melhor, sobre o qual as decisões de dimensionamento base são utilizar o tempo entre quando uma mensagem foi enviada e quando o processamento foi concluído. Este intervalo é conhecido como o tempo crítico. Se este valor de tempo crítico estiver abaixo de um limiar de negócio significativo, é desnecessário dimensionar, mesmo que o comprimento da fila seja longo.

Por exemplo, pode haver 50 000 mensagens numa fila. Mas o momento crítico da mensagem mais antiga é 500 ms e o ponto final está a lidar com a integração com um serviço Web de terceiros para enviar e-mails. Os intervenientes empresariais provavelmente considerariam que este seria um período de tempo que não justificaria gastar dinheiro extra para o dimensionamento.

Por outro lado, pode haver 500 mensagens numa fila, com o mesmo tempo crítico de 500 ms, mas o ponto final faz parte do caminho crítico em algum jogo online em tempo real em que os intervenientes empresariais definiram um tempo de resposta de 100 ms ou menos. Nesse caso, aumentar horizontalmente faria sentido.

Para utilizar o tempo crítico nas decisões de dimensionamento automático, é útil que uma biblioteca adicione automaticamente as informações relevantes aos cabeçalhos das mensagens enquanto são enviadas e processadas. Uma biblioteca que fornece esta funcionalidade é NServiceBus.

Se basear a sua estratégia de dimensionamento automático em contadores que medem processos empresariais, como o número de encomendas efetuadas por hora ou o tempo médio de execução de uma transação complexa, certifique-se de que compreende totalmente a relação entre os resultados destes tipos de contadores e os requisitos reais de capacidade de computação. Poderá ser necessário dimensionar mais do que um componente ou unidade de computação em resposta a alterações nos contadores de processos de negócio.

Para impedir que um sistema tente aumentar horizontalmente excessivamente e evitar os custos associados à execução de muitos milhares de instâncias, considere limitar o número máximo de instâncias que são adicionadas automaticamente. A maioria dos mecanismos de dimensionamento automático permite-lhe especificar o número mínimo e máximo de instâncias de uma regra. Além disso, considere degradar corretamente a funcionalidade que o sistema fornece se o número máximo de instâncias tiver sido implementado e o sistema ainda estiver sobrecarregado.

Tenha em atenção que o dimensionamento automático pode não ser o mecanismo mais adequado para lidar com um pico repentino numa carga de trabalho. Demora algum tempo a aprovisionar e iniciar novas instâncias de um serviço ou a adicionar recursos a um sistema e a procura máxima poderá passar quando estes recursos adicionais estiverem disponíveis. Neste cenário, poderá ser melhor limitar o serviço. Para obter mais informações, veja o padrão limitação.

Por outro lado, se precisar da capacidade para processar todos os pedidos quando o volume flutua rapidamente e o custo não for um dos principais fatores que contribuem, considere utilizar uma estratégia de dimensionamento automático agressiva que inicie mais instâncias mais rapidamente. Também pode utilizar uma política agendada que inicia um número suficiente de instâncias para satisfazer a carga máxima antes de essa carga ser esperada.

O mecanismo de dimensionamento automático deve monitorizar o processo de dimensionamento automático e registar os detalhes de cada evento de dimensionamento automático (o que o acionou, que recursos foram adicionados ou removidos e quando). Se criar um mecanismo de dimensionamento automático personalizado, confirme que o mesmo incorpora esta capacidade. Analise as informações para ajudar a medir a eficácia da estratégia de dimensionamento automático e otimize-a, se necessário. Pode otimizar a curto prazo, à medida que os padrões de utilização se tornam mais evidentes, e a longo prazo, enquanto a empresa se expande ou os requisitos da aplicação evoluem. Se uma aplicação atingir o limite superior definido para o dimensionamento automático, o mecanismo também poderá alertar um operador que pode iniciar manualmente mais recursos, se necessário. Nestas circunstâncias, o operador também pode ser responsável pela remoção manual destes recursos após a facilidade da carga de trabalho.

Exemplo

Veja a documentação de orientação de dimensionamento da arquitetura de referência da linha de base do AKS.

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade