View a markdown version of this page

Auto Scaling de clusters Valkey e Redis OSS - Amazônia ElastiCache

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á.

Auto Scaling de clusters Valkey e Redis OSS

Pré-requisitos

ElastiCache O Auto Scaling está limitado ao seguinte:

  • Clusters Valkey ou Redis OSS (modo cluster habilitado) que executem o Valkey 7.2 em diante ou que executem o Redis OSS 6.0 em diante

  • Clusters em camadas de dados (modo cluster habilitado) que executem o Valkey 7.2 em diante ou que executem o Redis OSS 7.0.7 em diante

  • Tamanhos de instância: Large, XLarge, 2XLarge

  • Famílias de tipos de instância - R8g, R7g, R6g, R6gd, R5, M8g, M7g, M6g, M5, C8gn, C7gn

  • O Auto Scaling in não ElastiCache é suportado para clusters executados em armazenamentos de dados globais, postos avançados ou zonas locais.

Gerenciando a capacidade automaticamente com o ElastiCache Auto Scaling com Valkey ou Redis OSS

ElastiCache o escalonamento automático com Valkey ou Redis OSS é a capacidade de aumentar ou diminuir automaticamente os fragmentos ou réplicas desejados em seu serviço. ElastiCache ElastiCache aproveita o serviço Application Auto Scaling para fornecer essa funcionalidade. Para obter mais informações, consulte Application Auto Scaling. Para usar o escalonamento automático, você define e aplica uma política de escalabilidade que usa CloudWatch métricas e valores-alvo que você atribui. ElastiCache o escalonamento automático usa a política para aumentar ou diminuir o número de instâncias em resposta às cargas de trabalho reais.

Você pode usar o Console de gerenciamento da AWS para aplicar uma política de escalabilidade com base em uma métrica predefinida. Uma predefined metric é definida em uma enumeração, para que você possa especificá-la por nome no código ou usá-la no Console de gerenciamento da AWS. As métricas personalizadas não estão disponíveis para seleção ao usar o Console de gerenciamento da AWS. Como alternativa, você pode usar a API Application Auto Scaling AWS CLI ou a API Application Auto Scaling para aplicar uma política de escalabilidade com base em uma métrica predefinida ou personalizada.

ElastiCache para Valkey e Redis, o OSS suporta escalabilidade para as seguintes dimensões:

  • Estilhaços — add/remove fragmenta automaticamente no cluster de forma semelhante à refragmentação manual on-line. Nesse caso, o escalonamento ElastiCache automático aciona o escalonamento em seu nome.

  • Réplicas — add/remove réplicas automáticas no cluster, de forma semelhante às operações manuais de Increase/Decrease réplica. ElastiCache escalabilidade automática para adds/removes réplicas do Valkey e do Redis OSS de maneira uniforme em todos os fragmentos do cluster.

ElastiCache para Valkey e Redis, o OSS oferece suporte aos seguintes tipos de políticas de escalabilidade automática:

  • Políticas de escalabilidade de rastreamento de destino— aumente ou diminua o número de shards/replicas execuções do seu serviço com base em um valor alvo para uma métrica específica. Isso é semelhante à forma como o termostato mantém a temperatura da casa. Você seleciona a temperatura, e o termostato faz o resto.

  • Escalabilidade programada para seu aplicativo. — ElastiCache para Valkey e Redis OSS, o escalonamento automático pode aumentar ou diminuir o número de execuções do shards/replicas seu serviço com base na data e na hora.

Imagem de escalonamento automático ElastiCache para Valkey e Redis OSS

As etapas a seguir resumem o processo ElastiCache de escalonamento automático do Valkey e do Redis OSS, conforme mostrado no diagrama anterior:

  1. Você cria uma política de escalabilidade ElastiCache automática para seu grupo de replicação.

  2. ElastiCache o escalonamento automático cria um par de CloudWatch alarmes em seu nome. Cada par representa seus limites superiores e inferiores para métricas. Esses CloudWatch alarmes são acionados quando a utilização real do cluster se desvia da sua meta de utilização por um período prolongado. Agora, é possível visualizar os alarmes no console.

  3. Se o valor da métrica configurada exceder sua meta de utilização (ou ficar abaixo da meta) por um período específico, CloudWatch acionará um alarme que invoca o dimensionamento automático para avaliar sua política de escalabilidade.

  4. ElastiCache o escalonamento automático emite uma solicitação de modificação para ajustar a capacidade do cluster.

  5. ElastiCache processa a solicitação Modificar, aumentando (ou diminuindo) dinamicamente a Shards/Replicas capacidade do cluster para que ela se aproxime da utilização desejada.

Para entender como o ElastiCache Auto Scaling funciona, suponha que você tenha um cluster chamadoUsersCluster. Ao monitorar as CloudWatch métricasUsersCluster, você determina o máximo de fragmentos que o cluster exige quando o tráfego está no pico e o mínimo de fragmentos quando o tráfego está no ponto mais baixo. Você também decide um valor alvo para a utilização da CPU para o UsersCluster cluster. ElastiCache o escalonamento automático usa seu algoritmo de rastreamento de destino para garantir que os fragmentos provisionados do UsersCluster sejam ajustados conforme necessário para que a utilização permaneça no valor alvo ou próximo dele.

nota

O escalonamento pode levar um tempo perceptível e exigirá recursos extras de cluster para que os fragmentos sejam rebalanceados. ElastiCache O Auto Scaling modifica as configurações de recursos somente quando a carga de trabalho real permanece elevada (ou deprimida) por um período prolongado de vários minutos. O algoritmo de monitoramento do objetivo do ajuste de escala automático procura manter a utilização pretendida no valor escolhido ou próximo a ele em longo prazo.

Permissões do IAM necessárias para o Auto Scaling

ElastiCache para Valkey e Redis, o OSS Auto Scaling é possível graças a uma combinação das APIs ElastiCache, CloudWatch, e Application Auto Scaling. Os clusters são criados e atualizados com ElastiCache, os alarmes são criados com CloudWatch e as políticas de escalabilidade são criadas com o Application Auto Scaling. Além das permissões padrão do IAM para criar e atualizar clusters, o usuário do IAM que acessa as configurações do ElastiCache Auto Scaling deve ter as permissões apropriadas para os serviços que oferecem suporte ao escalonamento dinâmico. Nessa política mais recente, adicionamos suporte à escalabilidade vertical do Memcached, com a ação elasticache:ModifyCacheCluster. Os usuários do IAM precisam ter as permissões para usar as ações exibidas na política de exemplo a seguir:

JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "application-autoscaling:*", "elasticache:DescribeReplicationGroups", "elasticache:ModifyReplicationGroupShardConfiguration", "elasticache:IncreaseReplicaCount", "elasticache:DecreaseReplicaCount", "elasticache:DescribeCacheClusters", "elasticache:DescribeCacheParameters", "cloudwatch:DeleteAlarms", "cloudwatch:DescribeAlarmHistory", "cloudwatch:DescribeAlarms", "cloudwatch:DescribeAlarmsForMetric", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics", "cloudwatch:PutMetricAlarm", "cloudwatch:DisableAlarmActions", "cloudwatch:EnableAlarmActions", "iam:CreateServiceLinkedRole", "sns:CreateTopic", "sns:Subscribe", "sns:Get*", "sns:List*" ], "Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster" } ] }

Service-linked papel

O serviço ElastiCache de escalonamento automático do Valkey e Redis OSS também precisa de permissão para descrever seus clusters e CloudWatch alarmes e permissões para modificar sua capacidade ElastiCache alvo em seu nome. Se você ativar o Auto Scaling em seu cluster, ele criará uma função vinculada ao serviço chamada AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG. Essa função vinculada ao serviço concede permissão de escalabilidade ElastiCache automática para descrever os alarmes de suas políticas, monitorar a capacidade atual da frota e modificar a capacidade da frota. A função vinculada ao serviço é a função padrão para escalabilidade ElastiCache automática. Para obter mais informações, consulte as Service-linked funções do escalonamento automático do Redis OSS no Guia do usuário do Application Auto Scaling. ElastiCache

Práticas recomendadas de escalabilidade automática

Antes de se registrar no Auto Scaling, recomendamos o seguinte:

  1. Use apenas uma métrica de monitoramento: identifique se o cluster tem workloads com uso intenso da CPU ou de dados e use uma métrica predefinida correspondente para definir a política de ajuste de escala.

    • CPU do mecanismo: ElastiCachePrimaryEngineCPUUtilization (dimensão fragmentada) ou ElastiCacheReplicaEngineCPUUtilization (dimensão da réplica)

    • Uso do banco de dados: ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage essa política de ajuste de escala funciona melhor com maxmemory-policy definido como noeviction no cluster.

    Recomendamos que você evite várias políticas por dimensão no cluster. ElastiCache para Valkey e Redis OSS, o escalonamento automático expandirá a meta escalável se alguma política de rastreamento de alvos estiver pronta para ser expandida, mas aumentará somente se todas as políticas de rastreamento de metas (com a parte de expansão inicial ativada) estiverem prontas para serem ampliadas. Se várias políticas instruírem o destino escalável a aumentar ou reduzir a escala na horizontal ao mesmo tempo, ele escalará com base na política que forneça a maior capacidade tanto para reduzir quanto para aumentar a escala na horizontal.

  2. Métricas personalizadas para rastreamento de alvos — Tenha cuidado ao usar métricas personalizadas para rastreamento de alvos, pois o escalonamento automático é mais adequado para escalar out/in proporcionalmente às mudanças nas métricas escolhidas para a política. Se essas métricas não forem alteradas proporcionalmente às ações de ajuste de escala usadas para a criação de políticas, elas poderão aumentar ou reduzir a escala horizontalmente das ações de forma contínua, o que pode afetar a disponibilidade ou o custo.

    Para clusters de armazenamento de dados em camadas (tipos de instância da família r6gd), evite usar métricas baseadas em memória para ajuste de escala.

  3. Escalabilidade programada — Se você identificar que sua carga de trabalho é determinística (chega high/low em um horário específico), recomendamos usar a escalabilidade programada e configurar sua capacidade alvo de acordo com a necessidade. O monitoramento do objetivo é mais adequado para workloads não determinísticas e para o cluster operar na métrica de destino necessária, aumentando a escala horizontalmente quando você precisar de mais recursos e reduzindo a escala horizontalmente quando precisar de menos recursos.

  4. Desativar Scale-In — O escalonamento automático no Target Tracking é mais adequado para clusters com cargas increase/decrease de trabalho graduais, pois as spikes/dip métricas podem acionar oscilações de escala consecutivas. out/in Para evitar tais oscilações, é possível começar com a opção de reduzir a escala horizontalmente desabilitada e, mais tarde, você pode reduzir a escala horizontalmente manualmente de acordo com sua necessidade.

  5. Teste seu aplicativo — Recomendamos que você teste seu aplicativo com suas Min/Max cargas de trabalho estimadas para determinar o mínimo e o máximo absolutos shards/replicas necessários para o cluster e, ao mesmo tempo, criar políticas de escalabilidade para evitar problemas de disponibilidade. A autoescalabilidade pode aumentar a escala horizontalmente até o máximo e reduzir a escala horizontalmente até o mínimo limite configurado para o destino.

  6. Definindo o valor alvo — Você pode analisar CloudWatch as métricas correspondentes para a utilização do cluster em um período de quatro semanas para determinar o limite do valor alvo. Se você ainda não tem certeza de qual valor escolher, recomendamos começar com o valor mínimo de métrica predefinida compatível.

  7. AutoScaling o on Target Tracking é mais adequado para clusters com distribuição uniforme de cargas de trabalho em todas as shards/replicas dimensões. Ter distribuição não uniforme pode levar a:

    • Escalabilidade quando não é necessário devido à carga de trabalho spike/dip em alguns pontos quentes. shards/replicas

    • Não é escalável quando necessário devido à média geral próxima da meta, mesmo estando quente. shards/replicas

nota

Ao escalar seu cluster, ElastiCache replicará automaticamente as funções carregadas em um dos nós existentes (selecionados aleatoriamente) para o (s) novo (s) nó (s). Se seu cluster tiver o Valkey ou Redis OSS 7.0 ou posterior e sua aplicação usar Funções, recomendamos carregar todas as suas funções em todos os fragmentos antes de aumentar a escala horizontalmente para que seu cluster não tenha funções diferentes em fragmentos diferentes.

Depois de se registrar AutoScaling, observe o seguinte:

  • Há limitações nas configurações compatíveis com a autoescalabilidade. Portanto, recomendamos que não altere a configuração de um grupo de replicação registrado para escalabilidade automática. Veja os exemplos a seguir:

    • Modificação manual do tipo de instância para tipos sem suporte.

    • Associação do grupo de replicação a um datastore global.

    • Alteração do parâmetro ReservedMemoryPercent.

    • Manualmente increasing/decreasing shards/replicas além da Min/Max capacidade configurada durante a criação da política.