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

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

Guia relacionado:Particionamento de dados

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

Definições

Principais estratégias de design

Design de acordo com padrões de carga

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 em 90% em todos os nós.

• dinâmico, regular e previsível: Todas as segundas-feiras pela 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 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 programada para os seus nós de computação serem reduzidos ao número mínimo (2) entre as 23h e as 6h, hora padrão do leste.

• Dinâmico, regular e previsível: Há uma expansão planeada dos seus nós de computação para a capacidade normal diária antes que a primeira região inicie suas atividades.

• dinâmico, irregular e previsível: define-se um aumento programado único das suas instâncias de computação e banco de dados na manhã do lançamento do produto e reduz a escala após uma semana.

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

Automatize estratégias de dimensionamento

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

• Que todos os componentes da sua carga de trabalho devem ser candidatos para a implementação de dimensionamento. Na maioria dos casos, serviços globais como Microsoft Entra ID dimensionam-se automaticamente e de forma transparente para si e para os 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.

• Os componentes que não podem ser dimensionados. Um exemplo seriam bancos de dados relacionais grandes 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 de migração para serviços escalá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 o Gerenciamento de API demorar 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 da sequência de operações de escala. Certifique-se de não sobrecarregar inadvertidamente um componente downstream dimensionando um componente upstream primeiro.

• Qualquer elemento de aplicação com estado que possa ser interrompido por uma operação de dimensionamento e qualquer afinidade de sessão (ou persistência de sessão) implementada. A aderência pode limitar sua capacidade de dimensionamento e introduz pontos únicos de falha.

• Potenciais gargalos. A expansão não resolve todos os problemas de desempenho. Por exemplo, se o banco de dados de back-end for o gargalo, não adianta adicionar mais servidores Web. Identifique e resolva os gargalos no sistema primeiro antes de apenas adicionar mais instâncias. As partes do sistema que mantêm estado são a causa mais provável de gargalos.

Seguir o padrão de design do carimbo de implantação ajuda na gestão geral da infraestrutura. Basear seu design de escala 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.

Tradeoff: A expansão 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 a escala.

Facilitação do Azure

Um recurso de dimensionamento automático está disponível em muitos serviços do Azure. Ele permite configurar facilmente as condições para dimensionar automaticamente as instâncias horizontalmente. Alguns serviços têm funcionalidade interna limitada ou nenhuma para escalar 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 de 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 Kubernetes do Azure e nos Aplicativos de Contêiner do Azure .

de dimensionamento automático do Azure Monitor fornece um conjunto comum de funcionalidade de dimensionamento automático para Conjuntos de Escala de Máquina Virtual do Azure, Serviço de Aplicativo do Azure, Aplicativos Azure Spring e muito mais. O dimensionamento pode ser executado em um cronograma 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 práticas recomendadas.

Concessões

Considerações de dimensionamento automático

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

O sistema deve ser concebido de modo a ser escalável horizontalmente. Evite fazer suposições sobre afinidade de instância. Não projete 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 fonte são sempre roteadas para a mesma instância. Pelo mesmo motivo, os serviços devem ser concebidos sem estado para evitar exigir que uma série de solicitações de uma aplicação seja sempre direcionada para a mesma instância de um serviço. Ao projetar um serviço que lê mensagens de uma fila e as processa, não faça suposições sobre qual instância do serviço lida com uma mensagem específica. O dimensionamento automático pode iniciar mais instâncias de um serviço à medida que a extensão da fila aumenta. O padrão Consumidores concorrentes descreve como lidar com esse cenário.

Se a solução implementar uma tarefa de longa execução, projete essa tarefa para dar suporte tanto ao escalonamento para fora quanto ao escalonamento para dentro. Sem o devido cuidado, tal tarefa poderia impedir que uma instância de um processo fosse encerrada de forma limpa quando o sistema é dimensionado. Ou pode perder dados se o processo for encerrado à força. Idealmente, refatore uma tarefa de longa duração e divida o processamento que ela executa em partes menores e discretas. O padrão Tubos e Filtros fornece um exemplo de como você pode alcançar 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 armazenamento durável que pode ser acessado 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 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 do 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 diferentes políticas de dimensionamento. 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 dimensionar 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 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 critério para sua estratégia de dimensionamento automático. Esse 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, no qual basear as decisões de dimensionamento é usar o tempo entre quando uma mensagem foi enviada e quando seu processamento foi concluído. Este 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 é de 500 ms, e o endpoint 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 é 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, a expansão 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 colocados 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 dimensionamento automático permite especificar o número mínimo e máximo de instâncias para uma regra. Além disso, considere degradar de forma controlada a funcionalidade que o sistema fornece se o número máximo de instâncias tiver sido implementado 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 pelo momento em que esses recursos extras estiverem disponíveis. Nesse cenário, talvez seja melhor limitar o serviço. Para obter mais informações, consulte o padrão de limitação de .

Por outro lado, se você precisar de capacidade para 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 agendada que inicia um número suficiente de instâncias para atender à carga máxima antes que essa carga 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 incorpore esse recurso. Analise as informações para ajudar a medir a eficácia da estratégia de dimensionamento automático e ajuste-a, se necessário. Você pode ajustar tanto a curto prazo, à medida que os padrões de uso se tornam mais óbvios, quanto a longo prazo, à medida que os negócios se expandem ou os requisitos do aplicativo evoluem. Se um aplicativo atingir o limite superior definido para o dimensionamento automático, o mecanismo também poderá alertar um operador que poderá 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 a arquitetura de referência de linha de base do AKS e as diretrizes de dimensionamento.

Ligações úteis

• Escalonamento da eficiência de desempenho
• Práticas recomendadas para o autoscale

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.