Recomendações para projetar uma estratégia de escalabilidade confiável
Aplica-se a esta recomendação da 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 escalabilidade confiável.
Definições
| Termo | Definição |
|---|---|
| Dimensionamento vertical | Uma abordagem de dimensionamento que adiciona capacidade computacional aos recursos existentes. |
| Escalonamento horizontal | Uma abordagem de dimensionamento que adiciona instâncias de um determinado tipo de recurso. |
| Dimensionamento automático | Uma abordagem de escalabilidade 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 único em reação a uma mudança de carga imprevista). Tanto o dimensionamento vertical quanto o horizontal podem ser realizados 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
Dimensionamento de acordo com padrões de carga
Para projetar uma estratégia de dimensionamento confiável para suas cargas de trabalho, concentre-se em identificar padrões de carga para os fluxos do usuário e 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: o lançamento de um 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 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 os cômodos de 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 escalabilidade 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 planejada 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 vertical programada única de suas instâncias de computação e banco de dados na manhã do lançamento de um 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 estes problemas:
Que todos os componentes de sua carga de trabalho devem ser candidatos à implementação de dimensionamento. Na maioria dos casos, os 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 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 para migrar para serviços escalonáveis.
O tempo necessário para executar a operação de escalabilidade 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 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 previsto na carga.
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 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.
Gargalos potenciais. A expansão não corrige 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 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 do selo 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 rigidamente suas operações de escalabilidade em várias cargas de trabalho e subconjuntos de cargas de trabalho. Em vez de gerenciar os agendamentos de escalabilidade e os limites de escalonamento automático de muitos recursos distintos, você pode aplicar um conjunto limitado de definições de escalabilidade a um selo de implantação e, em seguida, espelhá-lo entre selos conforme necessário.
Compensação: 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 que você configure facilmente as condições para dimensionar automaticamente as instâncias horizontalmente. Alguns serviços têm funcionalidade interna limitada ou nenhuma funcionalidade para reduzir horizontalmente automaticamente, portanto, certifique-se de documentar esses casos e definir processos para lidar com a redução.
Muitos serviços do Azure oferecem APIs que você pode usar para criar operações de dimensionamento automático personalizadas usando a Automação do Azure, como os exemplos de código em Dimensionamento automático do 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.
O dimensionamento automático do Azure Monitor fornece um conjunto comum de funcionalidade de dimensionamento automático para Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, 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 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 a 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 presuma que uma série de solicitações da mesma origem seja 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 o devido cuidado, essa tarefa pode impedir que uma instância de um processo seja desligada corretamente 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 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, em que 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 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 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 basear as decisões de dimensionamento é usar o tempo entre o momento em que uma mensagem foi enviada e o momento em que 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, não será necessá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 da Web de terceiros para enviar e-mails. As partes interessadas do negócio provavelmente considerariam esse um período de tempo que não justificaria gastar dinheiro extra para dimensionar.
Por outro lado, pode 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 em que as partes interessadas de negócios 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 fazer com 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, 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 empresariais.
Para evitar que um sistema tente escalar 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 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 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 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 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 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.
Links relacionados
Lista de verificação de confiabilidade
Consulte o conjunto completo de recomendações.