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 dimensionamento com monitoramento do objetivo, você seleciona uma métrica e define um valor pretendido. ElastiCache com Valkey ou Redis, o Auto OSS 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 CPU utilização no valor alvo especificado ou próximo a ele.
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 OSS replicação Valkey ou Redis |
Nenhum |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Métricas do grupo de OSS replicação Valkey ou Redis |
R6gd |
Os tipos de instância em camadas de dados não podem ser usadosElastiCacheDatabaseMemoryUsageCountedForEvictPercentage, pois esses tipos de instância armazenam dados na memória e. SSD O caso de uso esperado para instâncias em camadas de dados é ter 100% de uso de memória e ser SSD preenchida conforme necessário.
Critérios do Auto Scaling para fragmentos
Quando o serviço detectar que sua métrica predefinida é igual ou maior que a configuração de destino, ele aumentará automaticamente a capacidade dos fragmentos. ElastiCache com Valkey ou Redis 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 com o Valkey ou o Redis, a OSS escala aumenta em 30 por cento, o que resulta em 65 fragmentos por cluster.
-
se o Target violar em 10 por cento, ElastiCache com o Valkey ou o Redis OSS escalável por padrão. Mínimo de 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%, ElastiCache com Valkey ou Redis, OSS não haverá escalabilidade automática 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 com Valkey ou Redis OSS expande os fragmentos em um desvio mínimo de 20% do alvo 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, ElastiCache com o Valkey ou o RedisOSS, o Auto Scaling sempre age de forma conservadora, arredondando para cima ou para baixo ao determinar quanta capacidade adicionar ou remover. 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 OSS cluster ElastiCache com Valkey ou Redis, desde que cada uma delas use uma métrica diferente. A intenção do Auto Scaling ElastiCache (RedisOSS) é sempre priorizar a disponibilidade, portanto, seu comportamento difere dependendo se as políticas de rastreamento de destino estão prontas para expansão horizontal ou ampliada. 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, ElastiCache com o Valkey ou o Redis OSS Auto Scaling, gerencia para uma política de escalabilidade de rastreamento de destino. 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 AVG métrica 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 é escalável quando necessário devido à agregação de AVG todos os fragmentos que afeta o alarme de não violação.
-
-
ElastiCache com Valkey ou Redis, os limites OSS 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 que você tenha ENIs (interfaces de rede elásticas) suficientes disponíveis no seuVPC, 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ívelEC2, o ElastiCache Auto Scaling não escalaria e seria adiado até que a capacidade estivesse disponível.
-
ElastiCache (RedisOSS) O Auto Scaling durante a expansão 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.
