As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Como funciona o escalonamento de rastreamento de metas para o Application Auto Scaling
Este tópico descreve como o escalonamento de rastreamento de metas funciona e apresenta os principais elementos de uma política de escalabilidade de rastreamento de metas.
Conteúdo
Como funcionam
Para usar a escala de rastreamento de metas, você cria uma política de escalabilidade de rastreamento de metas e especifica o seguinte:
-
Métrica — uma CloudWatch métrica a ser monitorada, como a utilização média da CPU ou a contagem média de solicitações por alvo.
-
Valor de destino: o valor de destino da métrica, como 50% de utilização da CPU ou mil solicitações por destino por minuto.
O Application Auto Scaling cria e gerencia os CloudWatch alarmes que invocam a política de escalabilidade e calcula o ajuste de escalabilidade com base na métrica e no valor alvo. Ele adiciona e remove capacidade, conforme necessário, para manter a métrica no valor de destino especificado ou próxima a ele.
Quando a métrica está acima do valor de destino, o Application Auto Scaling aumenta a escala horizontalmente ao adicionar capacidade para reduzir a diferença entre o valor da métrica e o valor de destino. Quando a métrica está abaixo do valor de destino, o Application Auto Scaling reduz a escala horizontalmente ao remover a capacidade.
As atividades de escalabilidade são executadas com períodos de esfriamento entre elas para evitar flutuações rápidas na capacidade. Opcionalmente, é possível configurar os períodos de esfriamento para a política de escalabilidade.
O diagrama a seguir mostra uma visão geral de como uma política de escalonamento com monitoramento do destino funciona quando a configuração é concluída.
![Diagrama de visão geral de uma política de escalabilidade de rastreamento de metas](images/target-tracking-scaling-policy.png)
Observe que uma política de escalabilidade de rastreamento de destinos é mais agressiva na adição de capacidade quando a utilização aumenta do que na remoção de capacidade quando a utilização diminui. Por exemplo, se a métrica especificada da política atingir seu valor do objetivo, a política pressupõe que sua aplicação já esteja muito carregada. Assim, ela responde adicionando capacidade proporcional ao valor da métrica o mais rápido possível. Quanto maior a métrica, mais capacidade é adicionada.
Quando a métrica fica abaixo do valor de destino, a política espera que a utilização aumente novamente. Nesse caso, ela vai desacelerar a escalabilidade removendo capacidade somente quando a utilização ultrapassar um limite suficientemente abaixo do valor do objetivo (geralmente mais de 10% menor) para que a utilização seja considerada reduzida. A intenção desse comportamento mais conservador é garantir que a remoção de capacidade aconteça somente quando o aplicativo não estiver mais tendo demanda no mesmo alto nível que estava anteriormente.
Escolher métricas
É possível criar políticas de escalabilidade de rastreamento de destino com métricas predefinidas ou personalizadas.
Ao criar uma política de escalação com rastreamento de destino com um tipo de métrica predefinida, você escolhe uma métrica na lista de métricas predefinidas em Métricas predefinidas para políticas de escalação com rastreamento de destino.
Lembre-se do seguinte ao escolher uma métrica:
-
Nem todas as métricas personalizadas funcionam para rastreamento de destino. A métrica deve ser de utilização válida e descrever o quão ocupado um destino escalável está. O valor da métrica deve aumentar ou diminuir proporcionalmente à capacidade do destino escalável, de modo que os dados da métrica possam ser usados para escalá-lo proporcionalmente.
-
Para usar a métrica
ALBRequestCountPerTarget
, é necessário especificar o parâmetroResourceLabel
a fim de identificar o grupo de destino que está associado à métrica. -
Quando uma métrica emite valores reais de 0 para CloudWatch (por exemplo,
ALBRequestCountPerTarget
), o Application Auto Scaling pode ser escalado para 0 quando não há tráfego para seu aplicativo por um longo período de tempo. Para que o seu destino escalável tenha a escala reduzida para 0 quando nenhuma solicitação é roteada, a capacidade mínima do destino escalável deve ser definida como 0. -
Em vez de publicar novas métricas para usar em sua política de escalabilidade, é possível usar a matemática métrica para combinar métricas existentes. Para ter mais informações, consulte Crie uma política de escalabilidade de rastreamento de destino para o Application Auto Scaling usando matemática em métricas.
-
Para ver se o serviço que você está usando é compatível com a especificação de uma métrica personalizada no console, consulte a documentação do serviço.
-
Recomendamos que você use as métricas que estão disponíveis em intervalos de um minuto para ajudar a escalar mais rapidamente em resposta a alterações na utilização. O rastreamento de destino avaliará as métricas agregadas com uma granularidade de um minuto para todas as métricas predefinidas e personalizadas, mas a métrica subjacente talvez publique os dados com menos frequência. Por exemplo, todas as métricas do Amazon EC2 são enviadas em intervalos de cinco minutos, por padrão, mas podem ser configuradas para um minuto (o que é conhecido como monitoramento detalhado). Essa escolha depende dos serviços individuais. A maioria tenta usar o menor intervalo possível.
Definir valor de objetivo
Ao criar uma política de escalabilidade com monitoramento de objetivo, você deve especificar um valor para o objetivo. O valor-alvo representa o uso ou o throughput médio ideal para o seu aplicativo. Para usar os recursos de maneira econômica, defina o valor do objetivo com o número mais alto possível considerando um buffer razoável para aumentos inesperados de tráfego. Quando seu aplicativo aumentar a escala horizontalmente para um fluxo de tráfego normal, o valor efetivo da métrica deve estar no valor desejado ou logo abaixo dele.
Quando uma política de dimensionamento é baseada no throughput, como o número de solicitações por destino para um Application Load Balancer, E/S de rede ou outras métricas de contabilização, o valor de destino representa o throughput médio ideal de uma única entidade (p. ex., um único destino do seu grupo de destinos do Application Load Balancer), por um período de um minuto.
Definir períodos de esfriamento
Opcionalmente, você pode definir períodos de esfriamento na política de escalação com rastreamento de destino.
O período de esfriamento especifica quanto tempo a política de escalação espera até uma atividade anterior de escalação ter efeito.
Há dois tipos de período de esfriamento:
-
Com o período de desaquecimento após expansão, a intenção é expandir de forma contínua (mas não excessiva). Depois que o Application Auto Scaling aumenta a escala horizontalmente com êxito usando uma política de escalação em etapas, ele começa a calcular o tempo de esfriamento. A política de escalação não aumentará a capacidade desejada novamente a menos que um aumento maior da escala horizontal seja disparado ou que o período de esfriamento termine. Enquanto o período de desaquecimento após expansão estiver em vigor, a capacidade adicionada pela ação de expansão de início será calculada como parte da capacidade desejada para a próxima ação de expansão.
-
Com o período de esfriamento da redução da escala horizontal, a intenção é reduzir de maneira conservadora para proteger a disponibilidade da aplicação, de modo que as ações de redução de escala horizontal fiquem bloqueadas o período de esfriamento expirar. No entanto, se outro alarme acionar uma ação de ampliação durante o período de desaquecimento da redução da escala, o Application Auto Scaling expandirá o destino imediatamente. Nesse caso, o período de esfriamento da redução da escala horizontal é interrompido e não é concluído.
Cada período de desaquecimento é medido em segundos e se aplica somente a ações de escalabilidade relacionadas à política. Durante um período de desaquecimento, quando uma ação programada começa no horário programado, ela pode acionar uma ação de escalabilidade imediatamente, sem esperar que o período de desaquecimento expire.
É possível começar com os valores padrão, que podem ser ajustados posteriormente. Por exemplo, talvez seja necessário aumentar um período de desaquecimento para evitar que sua política de escalabilidade de rastreamento de destino seja muito agressiva em relação às alterações que ocorrem em curtos períodos.
Valores padrão
O Application Auto Scaling fornece um valor padrão de 600 para grupos de ElastiCache replicação e um valor padrão de 300 para os seguintes destinos escaláveis:
-
AppStream 2.0 frotas
-
clusters de bancos de dados Aurora
-
serviços da ECS
-
Clusters do Neptune
-
SageMaker variantes de endpoint
-
SageMaker componentes de inferência
-
SageMaker Concorrência provisionada sem servidor
-
Spot Fleets
-
Piscina de WorkSpaces
-
Recursos personalizados
Para todos os outros destinos escaláveis, o valor padrão é 0 ou nulo:
-
Classificação de documentos e endpoints de reconhecimento de entidade do Amazon Comprehend
-
Tabelas e índices secundários globais do DynamoDB
-
Tabelas do Amazon Keyspaces
-
Simultaneidade provisionada do Lambda
-
Armazenamento de agentes do Amazon MSK
Os valores nulos são tratados da mesma forma que os valores zero quando o Application Auto Scaling avalia o período de esfriamento.
Você pode atualizar qualquer um dos valores padrão, inclusive os valores nulos, para definir seus próprios períodos de esfriamento.
Considerações
As considerações a seguir são aplicáveis ao trabalhar com políticas de escalabilidade com monitoramento de objetivo:
-
Não crie, edite ou exclua os CloudWatch alarmes usados com uma política de escalabilidade de rastreamento de metas. O Application Auto Scaling cria e gerencia CloudWatch os alarmes associados às suas políticas de escalabilidade de rastreamento de destino e os exclui quando não são mais necessários.
-
Se faltarem pontos de dados na métrica, isso fará com que o estado do CloudWatch alarme mude para
INSUFFICIENT_DATA
. Quando isso acontece, o Application Auto Scaling não poderá dimensionar seu destino dimensionável até que novos pontos de dados sejam encontrados. Para obter mais informações, consulte Configurando como CloudWatch os alarmes tratam dados perdidos no Guia CloudWatch do usuário da Amazon. -
A matemática métrica pode ser útil se a métrica for intencionalmente relatada de maneira esparsa. Por exemplo, para usar os valores mais recentes, use a função
FILL(m1,REPEAT)
, na qualm1
é a métrica. -
É possível ver lacunas entre o valor de destino e os pontos de dados de métrica reais. Isso ocorre porque o Application Auto Scaling sempre funciona de maneira segura por arredondamento para cima ou para baixo, quando ele determina a capacidade a ser adicionada ou removida. Isso evita que ele adicione capacidade insuficiente ou remova muita capacidade. No entanto, para um destino dimensionável com capacidade pequena, os pontos de dados de métricas reais podem parecer distantes do valor de destino.
Para um destino dimensionável com maior capacidade, a adição ou remoção de capacidade causa uma lacuna menor entre o valor de destino e os pontos de dados de métricas reais.
-
Uma política de escalabilidade de rastreamento de destino pressupõe que ela deve aumentar a escalabilidade quando a métrica especificada estiver acima do valor de destino. Você não pode usar uma política de escalabilidade de rastreamento de destino para expandir quando a métrica especificada estiver abaixo do valor de destino.
Várias políticas de escalabilidade
Você pode ter várias políticas de escalabilidade de rastreamento de destino para um destino escalável, desde que cada uma delas use uma métrica diferente. A intenção do Application Auto Scaling é sempre priorizar a disponibilidade, portanto, seu comportamento será diferente dependendo se as políticas de monitoramento do objetivo estão prontas para aumentar ou reduzir a escala. Ele vai expandir o destino dimensionável se qualquer uma das políticas de rastreamento de destino estiverem prontas para expandir, mas vai reduzir somente se todas as políticas de rastreamento de destino (com a parte de redução habilitada) estiverem prontas para reduzir
Se várias políticas de dimensionamento instruírem o destino dimensionável a aumentar ou reduzir a escala na horizontal ao mesmo tempo, o Application Auto Scaling fará a escalabilidade com base na política que forneça a maior capacidade tanto para aumentar como para reduzir a escala horizontalmente. Isso proporciona maior flexibilidade para abordar vários cenários e garante que sempre haja capacidade suficiente para processar suas workloads.
Você pode desabilitar a parte de redução de escala horizontal de uma política de escalação com rastreamento de destino para usar um método de reduzir a escala horizontalmente diferente do que usa para aumentar a escala horizontalmente. Por exemplo, é possível usar uma política de escalabilidade em etapas pra reduzir ao mesmo tempo que usa uma política de escalabilidade de rastreamento de dentro para expandir,
No entanto, recomendamos cautela ao usar políticas de escalabilidade de rastreamento de destino com políticas de escalabilidade de etapas, pois conflitos entre essas políticas podem causar um comportamento indesejável. Por exemplo, se a política de escalabilidade de etapas iniciar uma atividade de redução antes que a política de rastreamento de destino esteja pronta para ser reduzida, a atividade de redução não será bloqueada. Após a conclusão da atividade de redução, a política de rastreamento de destino pode instruir o destino escalável a expandir novamente.
Para cargas de trabalho de natureza cíclica, você também tem a opção de automatizar alterações de capacidade em uma programação usando escalabilidade programada. Para cada ação programada, um novo valor de capacidade mínima e um novo valor de capacidade máxima podem ser definidos. Esses valores formam os limites da política de escalabilidade. A combinação da escalabilidade programada e da escalabilidade de rastreamento de destino pode ajudar a reduzir o impacto de um aumento acentuado nos níveis de utilização, quando a capacidade é necessária imediatamente.
Comandos normalmente usados para criação, exclusão e gerenciamento de política de escalabilidade
Os comandos comumente usados para trabalhar com políticas de escalabilidade incluem:
-
register-scalable-targetregistrar AWS ou personalizar recursos como alvos escaláveis (um recurso que o Application Auto Scaling pode escalar) e suspender e retomar o escalonamento.
-
put-scaling-policypara adicionar ou modificar políticas de escalabilidade para um alvo escalável existente.
-
describe-scaling-activitiespara retornar informações sobre atividades de escalabilidade em uma AWS região.
-
describe-scaling-policiespara retornar informações sobre políticas de escalabilidade em uma AWS região.
-
delete-scaling-policypara excluir uma política de escalabilidade.
Recursos relacionados
Para obter mais informações sobre a criação de políticas de escalabilidade de monitoramento do objetivo para grupos do Auto Scaling, consulte Políticas de escalabilidade de monitoramento do objetivo para o Amazon EC2 Auto Scaling no Guia do usuário do Amazon EC2 Auto Scaling.
Limitações
Veja a seguir as limitações ao usar políticas de escalabilidade em etapas:
-
O destino escalável não pode ser um cluster do Amazon EMR. As política de dimensionamento com monitoramento do objetivo não são compatíveis com o Amazon EMR.
-
Quando um cluster do Amazon MSK é o destino escalável, a redução é desabilitada e não pode ser ativada.
-
Você não pode usar as operações da
PutScalingPolicy
APIRegisterScalableTarget
ou da API para atualizar um plano AWS Auto Scaling de escalabilidade. -
O acesso ao console para visualizar, adicionar, atualizar ou remover políticas de escalabilidade de monitoramento do objetivo em recursos escaláveis depende do recurso utilizado. Para ter mais informações, consulte Serviços da AWS que você pode usar com o Application Auto Scaling.