Compartilhar via

Recomendações para projetar 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 colocação em escala oportuna e confiável nos níveis do aplicativo, dados e infraestrutura.

Guia relacionado: Particionamento de dados

Este guia descreve as recomendações para projetar 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 (dimensionamento diário programado regularmente para acomodar padrões de carga normais), automáticas (um processo automatizado em resposta às condições atendidas) ou manuais (um operador executa uma operação de dimensionamento única em reação a uma mudança de carga inesperada). O dimensionamento vertical e horizontal pode ser realizado por meio de qualquer um desses métodos. No entanto, o dimensionamento vertical automático requer desenvolvimento de automação personalizado adicional e pode causar tempo de inatividade, dependendo dos recursos que estão sendo dimensionados.

Principais estratégias de design

Para projetar uma estratégia de dimensionamento confiável para suas cargas de trabalho, concentre-se na identificação de padrões de carga para o usuário e 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, às 23h 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 fazem login no sistema ERP.

  • Dinâmico, irregular e previsível: um lançamento de produto acontece 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 de grande escala causa um pico 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 os quartos em suas casas.

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

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

  • Crie automação para lidar com 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 23h e 6h EST.

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

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

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

Ao projetar sua automação de dimensionamento, certifique-se de levar em conta estes problemas:

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

  • Aqueles componentes que não podem ser expandidos. Um exemplo seriam grandes bancos de dados relacionais que não têm fragmentação habilitada e não podem ser refatorados sem impacto significativo. Documente os limites de recursos publicados pelo seu 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ê programe corretamente a operação para acontecer antes que a carga extra atinja sua infraestrutura. Por exemplo, se um componente como o Gerenciamento de API levar 45 minutos para ser dimensionado, ajustar o limite de dimensionamento para 65% em vez de 90% pode ajudá-lo a dimensionar mais cedo e se preparar para o aumento de carga previsto.

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

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

  • Possíveis gargalos. A expansão horizontal não corrige todos os problemas de desempenho. Por exemplo, se o banco de dados de back-end for o afunilamento, não adianta adicionar mais servidores Web. Identifique e resolva os gargalos no sistema primeiro antes de 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 carimbo de implantação ajuda no gerenciamento geral da infraestrutura. Basear seu projeto de dimensionamento em selos como unidades de escala também é benéfico. E ajuda você a controlar rigorosamente suas operações de dimensionamento em várias cargas de trabalho e subconjuntos de cargas de trabalho. Em vez de gerenciar as agendas 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 carimbo de implantação e, em seguida, espelhá-lo entre carimbos conforme necessário.

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

Azure facilitation

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 funcionalidade interna limitada ou nenhuma para dimensionar 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 projetar operações de dimensionamento automático personalizadas usando a Automação do Azure, como os exemplos de código em Autoscale seu Hub IoT do Azure. Você pode usar ferramentas como o KEDA para dimensionamento automático controlado por eventos, que está disponível no Serviço de Kubernetes do Azure e nos Aplicativos de Contêiner do Azure.

A escala automática do Azure Monitor fornece um conjunto comum de funcionalidades de dimensionamento automático para Conjuntos de Dimensionamento de Máquina Virtual do Azure, Serviço de Aplicativo do Azure, Aplicativos Spring do Azure e muito mais. O dimensionamento pode ser executado em uma agenda ou com base em uma métrica de tempo de execução, como uso de CPU ou memória. Consulte o guia do Azure Monitor para obter as práticas recomendadas.

Compensações

Considerações sobre o 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 site horizontalmente, não assuma que uma série de solicitações da mesma origem são sempre roteadas 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 o devido cuidado, essa tarefa pode impedir que uma instância de um processo seja encerrada de forma limpa quando o sistema for dimensionado. 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 and 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 em um armazenamento durável que pode ser acessado por qualquer instância do processo que executa a tarefa. Dessa forma, se o processo for encerrado, o trabalho que ele estava executando pode 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 o estado, onde os intervalos são alinhados com o processamento de mensagens de filas no 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 em serviços de nuvem, talvez seja necessário dimensionar diferentes partes do aplicativo usando políticas de dimensionamento diferentes. Por exemplo, talvez seja necessário implantar instâncias de computação de interface do usuário (UI) extras 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ços básicos e premium, talvez seja necessário expandir os recursos de computação para pacotes de serviços premium de forma mais agressiva do que para pacotes de serviços básicos para atender a 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 basear as decisões de dimensionamento é usar o tempo entre quando uma mensagem foi enviada e quando seu processamento foi concluído. Esse intervalo é conhecido como 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 é de 500 ms, e o ponto de extremidade está lidando com a integração com um serviço Web de terceiros para enviar e-mails. As partes interessadas do negócio provavelmente considerariam que esse era um período de tempo que não justificaria gastar dinheiro extra para escalar.

Por outro lado, poderia haver 500 mensagens em uma fila, com o mesmo tempo crítico de 500 ms, mas o endpoint faz parte do caminho crítico em algum jogo online em tempo real onde as partes interessadas do negócio definiram um tempo de resposta de 100 ms ou menos. Nesse caso, o dimensionamento 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 é o 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, certifique-se de entender 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 processos de negócios.

Para evitar que um sistema tente expandir 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 escalonamento automático permite que você especifique o número mínimo e máximo de instâncias para 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.

Lembre-se de que o dimensionamento automático pode não ser o mecanismo mais apropriado para lidar com uma explosão 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 o pico de demanda pode passar no momento em que 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 o uso de 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 acionou, 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 pode iniciar manualmente mais recursos, se necessário. Nessas circunstâncias, o operador também pode ser responsável por remover manualmente esses recursos depois que a carga de trabalho diminuir.

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