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á.
Políticas de escalabilidade de rastreamento de destino
Com as políticas de escalabilidade de rastreamento de metas, você seleciona uma métrica e define um valor alvo. ElastiCache para Valkey e Redis, o OSS Auto Scaling cria e gerencia CloudWatch os alarmes que acionam a política de escalabilidade e calcula o ajuste de escalabilidade com base na métrica e no valor alvo. A política de escalabilidade adiciona ou remove fragmentos conforme necessário para manter a métrica no valor de destino especificado ou próxima a ele. Além de manter a métrica próxima ao valor de destino, uma política de escalabilidade de rastreamento de destino também se ajusta às flutuações na métrica, devido a um padrão de carga de flutuação, e minimiza as flutuações rápidas na capacidade da frota.
Por exemplo, considere uma política de escalabilidade que use a métrica predefinida de média ElastiCachePrimaryEngineCPUUtilization
com valor de destino configurado. Essa política pode manter a utilização da CPU em, ou próxima do valor de destino especificado.
Métricas predefinidas
Uma métrica predefinida é uma estrutura que se refere a um nome, dimensão e estatística (average
) específicos de uma determinada CloudWatch métrica. Sua política de ajuste de escala automático define as seguintes métricas predefinidas para seu cluster:
Nome da métrica predefinida | CloudWatch Nome da métrica | CloudWatch Dimensão métrica | Tipos de instância inelegíveis |
---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId, Função = Primária |
Nenhum |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Métricas do grupo de replicação do Valkey ou Redis OSS |
Nenhum |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Métricas do grupo de replicação do Valkey ou Redis OSS |
R6gd |
Os tipos de instância em camadas de dados não podem usar ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage
, pois esses tipos de instância armazenam dados na memória e no SSD. O caso de uso previsto para instâncias em camadas de dados é usar 100% de memória e preencher o SSD conforme necessário.
Critérios do Auto Scaling para fragmentos
Quando o serviço detecta que sua métrica predefinida é igual ou maior que a configuração de meta, ele aumentará automaticamente a capacidade de seus fragmentos. ElastiCache para Valkey e Redis, o OSS expande seus fragmentos de cluster em uma contagem igual ao maior de dois números: variação percentual do Target e 20% dos fragmentos atuais. Para aumentar a escala, ElastiCache não aumentará automaticamente a menos que o valor geral da métrica esteja abaixo de 75 por cento da meta definida.
Para um exemplo de aumento de escala na horizontal, se você tiver 50 fragmentos e
-
se seu Target violar em 30 por cento, ElastiCache aumenta em 30 por cento, o que resulta em 65 fragmentos por cluster.
-
se o Target violar em 10 por cento, por padrão, ElastiCache aumenta no mínimo 20 por cento, o que resulta em 60 fragmentos por cluster.
Para um exemplo de aumento de escala, se você selecionou um valor alvo de 60 por cento, ElastiCache não será ampliado automaticamente até que a métrica seja menor ou igual a 45 por cento (25 por cento abaixo da meta de 60 por cento).
Considerações sobre o Auto Scaling
Lembre-se das seguintes considerações:
-
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 metas para escalar quando a métrica especificada está abaixo do valor alvo. ElastiCache para Valkey e Redis, o OSS expande os fragmentos em um desvio mínimo de 20% da meta dos fragmentos existentes no cluster.
-
Uma política de escalabilidade de rastreamento de destino não escala quando a métrica especificada tem dados insuficientes. Ela não reduz a escala horizontalmente, porque não interpreta dados insuficientes como baixa utilização.
-
É possível ver lacunas entre o valor de destino e os pontos de dados de métrica reais. Isso ocorre porque o ElastiCache Auto Scaling sempre age de forma conservadora, arredondando para cima ou para baixo ao determinar a capacidade a ser adicionada ou removida. Isso evita que ele adicione capacidade insuficiente ou remova muita capacidade.
-
Para garantir a disponibilidade da aplicação, o serviço aumenta a escala na horizontal proporcionalmente à métrica o mais rápido possível, mas é reduz a escala na horizontal de forma mais conservadora.
-
Você pode ter várias políticas de escalabilidade de rastreamento de destino para um cluster OSS ElastiCache para Valkey e Redis, desde que cada uma delas use uma métrica diferente. A intenção do ElastiCache Auto Scaling é sempre priorizar a disponibilidade, portanto, seu comportamento difere dependendo se as políticas de rastreamento de alvos estão prontas para expansão horizontal ou ampliação. Ele vai aumentar o serviço se qualquer uma das políticas de monitoramento do objetivo estiverem prontas para aumentar, mas vai reduzir somente se todas as políticas de monitoramento do objetivo (com a parte de redução habilitada) estiverem prontas para reduzir.
-
Não edite nem exclua os CloudWatch alarmes que o ElastiCache Auto Scaling gerencia para uma política de escalabilidade de rastreamento de metas. ElastiCache O Auto Scaling exclui os alarmes automaticamente quando você exclui a política de escalabilidade.
-
ElastiCache O Auto Scaling não impede que você modifique manualmente os fragmentos do cluster. Esses ajustes manuais não afetam nenhum CloudWatch alarme existente associado à política de escalabilidade, mas podem afetar as métricas que podem acionar esses CloudWatch alarmes.
-
Esses CloudWatch alarmes gerenciados pelo Auto Scaling são definidos pela métrica do AVG em todos os fragmentos do cluster. Assim, ter fragmentos quentes pode resultar em qualquer cenário de:
-
dimensionamento quando não é necessário devido à carga em alguns fragmentos quentes que acionam um alarme CloudWatch
-
não escalar quando necessário devido ao AVG agregado em todos os fragmentos que afetam o alarme não violarem.
-
-
ElastiCache os limites padrão de nós por cluster ainda se aplicam. Então, ao optar pelo Auto Scaling, se você espera que os nós máximos sejam mais do que o limite padrão, solicite um aumento de limite em Limites de serviço da AWS e escolha o tipo de limite Nós por cluster por tipo de instância.
-
Certifique-se de ter ENIs (interfaces de rede elásticas) suficientes disponíveis em sua VPC, o que é necessário durante a expansão. Para obter mais informações, consulte Interfaces de rede elástica.
-
Se não houvesse capacidade suficiente disponível EC2, o ElastiCache Auto Scaling não escalaria e seria adiado até que a capacidade estivesse disponível.
-
ElastiCache para Redis OSS, o Auto Scaling durante a escalabilidade não removerá fragmentos com slots com um tamanho de item maior que 256 MB após a serialização.
-
Durante a redução de escala na horizontal, ele não removerá fragmentos se houver memória insuficiente disponível na configuração de fragmento resultante.