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:
| 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 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. |
Nota
As operações de dimensionamento podem ser estáticas (dimensionamento diário regularmente programado 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 imprevista). O dimensionamento vertical e horizontal pode ser realizado através de qualquer um destes métodos. No entanto, o dimensionamento vertical automático requer desenvolvimento adicional de automação personalizada e pode causar tempo de inatividade, dependendo dos recursos que estão sendo dimensionados.
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 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 funcionar.
Dinâmico, irregular e previsível: você define uma escala programada única vez 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 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 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.
Os componentes que não podem ser expandidos. 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 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 de ordem de operações de escala. Certifique-se de não sobrecarregar inadvertidamente um componente downstream dimensionando um componente upstream primeiro.
Qualquer elemento de aplicativo com monitoração de estado que possa ser interrompido 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.
Potenciais estrangulamentos. 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 com monitorização de estado do sistema são a causa mais provável dos estrangulamentos.
Seguir o padrão de design de carimbo de implantação ajuda no gerenciamento 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.
Compensação: a expansão tem implicações em termos de custos, 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 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 Kubernetes do Azure e nos Aplicativos de Contêiner do Azure.
O 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.
Vantagens e desvantagens
Considerações sobre 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 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, 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 esse 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 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, reformule uma tarefa de execução longa e divida o processamento que a mesma realiza em segmentos mais pequenos e discretos. O padrão Tubos e Filtros 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 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 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 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 é 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 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 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 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.
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. 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 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 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 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 as diretrizes de dimensionamento da arquitetura de referência de linha de base do AKS.
Ligações relacionadas
Lista de verificação de fiabilidade
Consulte o conjunto completo de recomendações.