Share via

Recomendações para criar uma estratégia de dimensionamento confiável

  • Artigo

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

RE:06 Implemente uma estratégia de dimensionamento oportuna e confiável nos níveis de aplicativo, dados e infraestrutura.

Guia relacionado:Particionamento de dados

Este guia descreve as recomendações para criar uma estratégia de dimensionamento confiá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 é atendido.

Observação

As operações de dimensionamento podem ser estáticas (escala diária agendada regularmente para acomodar padrões de carga normais), automáticas (um processo automatizado em resposta às condições que estão sendo atendidas) ou manual (um operador executa uma operação de dimensionamento único em reação a uma alteração de carga inesperada). O dimensionamento vertical e horizontal pode ser executado por meio de qualquer um desses métodos. No entanto, o dimensionamento vertical automático requer desenvolvimento de automação personalizada adicional e pode causar tempo de inatividade dependendo dos recursos que estão sendo dimensionados.

Principais estratégias de design

Para criar uma estratégia de dimensionamento confiável para suas cargas de trabalho, concentre-se em identificar padrões de carga para o usuário e os fluxos do sistema para cada carga de trabalho que leva a uma operação de dimensionamento. Aqui estão exemplos dos diferentes padrões de carga:

  • Estático: todas as noites até 23:00 EST, o número de usuários ativos está abaixo de 100 e a utilização da CPU para os servidores de aplicativos cai 90% em todos os nós.

  • Dinâmico, regular e previsível: todas as segundas-feiras de manhã, 1000 funcionários em várias regiões se inscrevem no sistema ERP.

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

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

Depois de identificar esses tipos de padrões de carga, você poderá:

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

  • Crie automação para resolver o dimensionamento de forma confiável.

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

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

  • Dinâmico, regular e previsível: você tem uma escala horizontal agendada de seus nós de computação para a capacidade diária normal antes que a primeira região inicie o trabalho.

  • Dinâmico, irregular e previsível: você define uma escala de escala agendada única de suas instâncias de computação e banco de dados na manhã de lançamento de um produto e reduz verticalmente após uma semana.

  • Dinâmico, irregular e imprevisível: você tem limites de dimensionamento automático definidos para considerar picos de tráfego não planejados.

Ao projetar sua automação de dimensionamento, lembre-se de considerar esses problemas:

  • Que todos os componentes da carga de trabalho devem ser candidatos à implementação de dimensionamento. Na maioria dos casos, serviços globais como Microsoft Entra ID são dimensionados de forma automática e transparente para você e seus clientes. Lembre-se de entender os recursos de dimensionamento dos controladores de entrada e saída de rede e da solução de balanceamento de carga.

  • Esses componentes que não podem ser escalados horizontalmente. Um exemplo seria bancos de dados relacionais grandes que não têm a fragmentação habilitada e não podem ser refatorados sem impacto significativo. Documente os limites de recursos publicados pelo provedor de nuvem e monitore esses recursos de perto. Inclua esses recursos específicos em seu planejamento futuro para migrar para serviços escalonáveis.

  • O tempo necessário para executar a operação de dimensionamento para que você agende corretamente a operação para acontecer antes que a carga extra atinja sua infraestrutura. Por exemplo, se um componente como Gerenciamento de API levar 45 minutos para ser dimensionado, ajustar o limite de dimensionamento para 65% em vez de 90% poderá ajudá-lo a dimensionar mais cedo e se preparar para o aumento previsto na carga.

  • A relação dos componentes do fluxo em termos de ordem de operações de escala. Verifique se você não sobrecarrega inadvertidamente um componente downstream dimensionando um componente upstream primeiro.

  • Todos os elementos de aplicativo com estado que podem ser interrompidos por uma operação de dimensionamento e qualquer afinidade de sessão (ou stickiness de sessão) implementada. A adesão pode limitar sua capacidade de dimensionamento e introduz pontos únicos de falha.

  • Possíveis gargalos. O dimensionamento não corrige todos os problemas de desempenho. Por exemplo, se o banco de dados de back-end for o gargalo, não ajudará a adicionar mais servidores Web. Identifique e resolve os gargalos no sistema primeiro antes de apenas adicionar mais instâncias. Partes com estado do sistema são a causa mais provável de gargalos.

Seguir o padrão de design de selo de implantação ajuda no gerenciamento geral da infraestrutura. Basear seu design de dimensionamento em selos como unidades de escala também é benéfico. E isso ajuda você a controlar firmemente suas operações de dimensionamento em várias cargas de trabalho e subconjuntos de cargas de trabalho. Em vez de gerenciar os agendamentos de dimensionamento e os limites de dimensionamento automático de muitos recursos distintos, você pode aplicar um conjunto limitado de definições de dimensionamento a um selo de implantação e, em seguida, espelho isso entre selos conforme necessário.

Compensação: o dimensionamento tem implicações de custo, portanto, otimize sua estratégia para reduzir o mais rápido possível para ajudar a manter os custos sob controle. Verifique se a automação que você está empregando para escalar verticalmente também tem gatilhos para reduzir verticalmente.

Facilitação do Azure

Um recurso de dimensionamento automático está disponível em muitos serviços do Azure. Ele permite que você configure facilmente as condições para dimensionar automaticamente as instâncias horizontalmente. Alguns serviços têm funcionalidades internas limitadas ou não para serem dimensionados automaticamente, portanto, certifique-se de documentar esses casos e definir processos para lidar com o dimensionamento.

Muitos serviços do Azure oferecem APIs que você pode usar para criar operações de dimensionamento automático personalizadas usando Automação do Azure, como os exemplos de código em Dimensionamento automático de Hub IoT do Azure. Você pode usar ferramentas como KEDA para dimensionamento automático controlado por eventos, que está disponível em Serviço de Kubernetes do Azure e aplicativos de contêiner do Azure.

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 Aplicativo do Azure, Azure Spring Apps e muito mais. O dimensionamento pode ser executado em um agendamento ou com base em uma métrica de runtime, como uso de CPU ou memória. Confira o guia do Azure Monitor para obter práticas recomendadas.

Compensações

Considerações sobre dimensionamento automático

O dimensionamento automático não é uma solução imediata. Apenas adicionar recursos a um sistema ou executar mais instâncias de um processo não garante que o desempenho do sistema vai melhorar. Considere os seguintes pontos ao criar uma estratégia de dimensionamento automático:

O sistema deve ser projetado para ser escalonável horizontalmente. Evite fazer suposições sobre afinidade de instância. Não crie soluções que exijam que o código esteja sempre em execução em uma instância específica de um processo. Ao dimensionar um serviço de nuvem ou um site horizontalmente, não suponha que uma série de solicitações da mesma origem sejam sempre roteada para a mesma instância. Projete os serviços, por essa mesma razão, como sem monitoração de estado, evitando assim a exigência de que uma série de solicitações de um aplicativo sejam sempre roteadas para a mesma instância de um serviço. Ao criar um serviço que lê as mensagens de uma fila e as processa, não faça suposições sobre qual instância do serviço lidará com qual mensagem. O dimensionamento automático pode iniciar mais instâncias de um serviço à medida que o comprimento da fila aumenta. O Padrão de Consumidores Concorrentes descreve como administrar esse cenário.

Se a solução implementa uma tarefa de execução longa, projete-a para oferecer suporte tanto a escalar quanto a reduzir horizontalmente. Sem os devidos cuidados, tal tarefa poderia impedir que uma instância de um processo fosse desligada de forma limpa quando o sistema escalasse. Ou pode perder dados se o processo for encerrado à força. Idealmente, refatore uma tarefa de execução longa e divida o processamento que ela executa em blocos menores e distintos. O padrão Pipes e Filters fornece um exemplo de como você pode obter essa solução.

Como alternativa, você pode implementar um mecanismo de ponto de verificação que registra informações de estado sobre a tarefa em intervalos regulares. Em seguida, você pode salvar esse estado no armazenamento durável que pode ser acessado por qualquer instância do processo que executa a tarefa. Dessa forma, se o processo for desligado, o trabalho que ele estava executando poderá ser retomado do último ponto de verificação por outra instância. Há bibliotecas que fornecem essa funcionalidade, como NServiceBus e MassTransit. Eles persistem de forma transparente, onde os intervalos são alinhados com o processamento de mensagens de filas em Barramento de Serviço do Azure.

Quando as tarefas em segundo plano são executadas em instâncias de computação separadas, como em funções de trabalho de um aplicativo hospedado por serviços de nuvem, talvez seja necessário dimensionar diferentes partes do aplicativo usando diferentes políticas de dimensionamento. Por exemplo, talvez seja necessário implantar instâncias de computação extras da interface do usuário (interface do usuário) sem aumentar o número de instâncias de computação em segundo plano ou vice-versa. Se você oferecer diferentes níveis de serviço, como pacotes de serviço básicos e premium, talvez seja necessário escalar horizontalmente os recursos de computação para pacotes de serviço premium de forma mais agressiva do que para pacotes de serviço básicos para atender aos SLAs (contratos de nível de serviço).

Considere o comprimento da fila sobre a qual a interface do usuário e as instâncias de computação em segundo plano se comunicam. Use-o como um critério para sua estratégia de dimensionamento automático. Esse problema é um possível indicador 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, no qual as decisões de dimensionamento base são usar o tempo entre quando uma mensagem foi enviada e quando seu processamento foi concluído. Esse intervalo é conhecido como o tempo crítico. Se esse valor de tempo crítico estiver abaixo de um limite de negócios significativo, será desnecessário dimensionar, mesmo que o comprimento da fila seja longo.

Por exemplo, pode haver 50.000 mensagens em uma fila. Mas o tempo crítico da mensagem mais antiga é 500 ms e o ponto de extremidade está lidando com a integração com um serviço Web de terceiros para enviar emails. Os stakeholders empresariais provavelmente considerariam que esse é um período de tempo que não justificaria gastar dinheiro extra para dimensionamento.

Por outro lado, pode haver 500 mensagens em uma fila, com o mesmo tempo crítico de 500 ms, mas o ponto de extremidade faz parte do caminho crítico em algum jogo online em tempo real em que os stakeholders de negócios definiram um tempo de resposta de 100 ms ou menos. Nesse caso, escalar horizontalmente faria sentido.

Para usar 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 elas são enviadas e processadas. Uma biblioteca que fornece essa funcionalidade é NServiceBus.

Se você basear sua estratégia de dimensionamento automático em contadores que medem processos de negócios, como o número de pedidos feitos por hora ou o tempo médio de execução de uma transação complexa, verifique se você entende completamente a relação entre os resultados desses tipos de contadores e os requisitos reais de capacidade de computação. Pode ser necessário dimensionar mais de um componente ou unidade de computação em resposta a alterações nos contadores de processo empresarial.

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

Tenha em mente que o dimensionamento automático pode não ser o mecanismo mais apropriado para lidar com uma intermitência repentina em uma carga de trabalho. Leva tempo para provisionar e iniciar novas instâncias de um serviço ou adicionar recursos a um sistema, e a demanda de pico pode passar quando esses recursos extras estiverem disponíveis. Nesse cenário, talvez seja melhor limitar o serviço. Para saber mais, confira Padrão de limitação.

Por outro lado, se você precisar da capacidade de processar todas as solicitações quando o volume flutuar rapidamente, e o custo não for um fator contribuinte importante, considere usar uma estratégia agressiva de dimensionamento automático que inicie mais instâncias mais rapidamente. Você também pode usar uma política programada que inicie um número suficiente de instâncias para atender à carga máxima antes que ela seja esperada.

O mecanismo de dimensionamento automático deve monitorar o processo de dimensionamento automático e registrar os detalhes de cada evento de dimensionamento automático (o que o disparou, quais recursos foram adicionados ou removidos e quando). Se você criar um mecanismo de dimensionamento automático personalizado, certifique-se de que ele incorpora essa funcionalidade. Analise as informações para ajudar a medir a eficiência da estratégia de dimensionamento automático e ajustá-la se necessário. Você pode ajustar tanto a curto prazo, conforme os padrões de uso tornam-se mais óbvios, quanto a longo prazo, conforme os negócios se expandem ou os requisitos do aplicativo evoluem. Se um aplicativo atingir o limite superior definido para dimensionamento automático, o mecanismo também poderá alertar um operador que poderia iniciar manualmente mais recursos, se necessário. Nessas circunstâncias, o operador também pode ser responsável por remover manualmente esses recursos após a facilidade de carga de trabalho.

Exemplo

Consulte as diretrizes de dimensionamento da arquitetura de referência de linha de base do AKS.

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade