Clusters Auto Scaling Valkey e Redis OSS - Amazon 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á.

Clusters Auto Scaling Valkey e Redis OSS

Pré-requisitos

ElastiCache O Auto Scaling está limitado ao seguinte:

  • Clusters Valkey ou Redis OSS (modo de cluster ativado) executando Valkey 7.2 em diante ou executando o mecanismo Redis versão 6.0 em diante OSS

  • Clusters de armazenamento de dados em camadas (modo de cluster ativado) executando Valkey 7.2 em diante ou executando o mecanismo Redis OSS versão 7.0.7 em diante

  • Tamanhos de instância - GrandeXLarge, 2 XLarge

  • Famílias de tipo de instância: R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn

  • O Auto Scaling in não ElastiCache é compatível com clusters executados em datastores globais, Outposts ou Locais Zones.

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 auto scaling 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 AWS Management Console 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 AWS Management Console. As métricas personalizadas não estão disponíveis para seleção ao usar o AWS Management Console. Como alternativa, você pode usar o Application Auto Scaling AWS CLI ou o Application Auto Scaling API para aplicar uma política de escalabilidade com base em uma métrica predefinida ou personalizada.

ElastiCache com Valkey ou Redis OSS suporta escalabilidade para as seguintes dimensões:

  • Fragmentos: adicionar/remover fragmentos automaticamente no cluster semelhantes à refragmentação manual online. Nesse caso, o escalonamento ElastiCache automático aciona o escalonamento em seu nome.

  • Replicas (Réplicas): adicionar/remover automaticamente réplicas no cluster semelhantes às operações manuais de aumentar/diminuir réplicas. ElastiCache com o escalonamento OSS automático Valkey ou Redis, adiciona/remove réplicas uniformemente em todos os fragmentos do cluster.

ElastiCache com Valkey ou Redis OSS suporta os seguintes tipos de políticas de escalabilidade automática:

Imagem de escalonamento automático para ElastiCache com Valkey ou Redis OSS

As etapas a seguir resumem o processo de escalonamento OSS automático ElastiCache com Valkey ou Redis, 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 com Valkey ou Redis OSS 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 utilização desejada por um longo período de tempo. 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 de tempo específico, CloudWatch acionará um alarme que invoca o escalonamento automático para avaliar sua política de escalabilidade.

  4. ElastiCache com o escalonamento OSS automático Valkey ou Redis, emite uma solicitação de modificação para ajustar a capacidade do cluster.

  5. ElastiCache com Valkey ou Redis OSS processa a solicitação de modificação, aumentando (ou diminuindo) dinamicamente a capacidade de fragmentos/réplicas do cluster para que ela se aproxime da utilização desejada.

Para entender como o ElastiCache Valkey ou o Redis Auto OSS Scaling funciona, suponha que você tenha um cluster chamado. UsersCluster 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 CPU utilização do UsersCluster cluster. ElastiCache o auto scaling usa seu algoritmo de rastreamento de metas para garantir que os fragmentos provisionados de 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 do cluster para que os fragmentos se rebalanceiem. ElastiCache com Valkey ou Redis Auto OSS Scaling modifica as configurações de recursos somente quando a carga de trabalho real permanece elevada (ou deprimida) por um período sustentado de vários minutos. O algoritmo de rastreamento de metas de escalonamento automático busca manter a utilização alvo igual ou próxima ao valor escolhido a longo prazo.

IAMPermissões necessárias para o Auto Scaling

ElastiCache com Valkey ou Redis, o Auto OSS Scaling é possível graças a uma combinação do CloudWatch,, e ElastiCache do Application Auto Scaling. APIs Os clusters são criados e atualizados com ElastiCache (RedisOSS), os alarmes são criados com e as políticas de escalabilidade são criadas com CloudWatch o Application Auto Scaling. Além das IAM permissões padrão para criar e atualizar clusters, o IAM usuário 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. IAMos usuários devem ter permissões para usar as ações mostradas no exemplo de política a seguir:

{ "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" } ] }

Perfil vinculado a serviço

O serviço de escalonamento OSS automático ElastiCache com Valkey ou Redis também precisa de permissão para descrever seus clusters e CloudWatch alarmes, além de permissões para modificar sua capacidade ElastiCache alvo em seu nome. Se você habilitar o Auto Scaling para 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 escalonamento ElastiCache automático 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 o escalonamento ElastiCache automático. Para obter mais informações, consulte Funções vinculadas a serviços para escalonamento automático ElastiCache (Redis) no Guia do usuário do Application OSS Auto Scaling.

Práticas recomendadas de escalabilidade automática

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

  1. Use apenas uma métrica de rastreamento — identifique se seu cluster tem CPU cargas de trabalho com uso intenso de dados e use uma métrica predefinida correspondente para definir a política de escalabilidade.

    • MotorCPU: ElastiCachePrimaryEngineCPUUtilization (dimensão do fragmento) 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 com Valkey ou Redis, o OSS Auto Scaling expandirá a meta escalável se alguma política de rastreamento de alvos estiver pronta para ser expandida, mas só será ampliada se todas as políticas de rastreamento de alvos (com a parte de expansão 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 monitoramento do objetivo: seja cauteloso ao usar métricas personalizadas para o monitoramento do objetivo, pois o ajuste de escala automático é mais adequado para aumentar/reduzir a escala horizontalmente de modo proporcional às alterações 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 workload é determinística (alcança um nível alto/baixo em um momento específico), recomendamos usar a escalabilidade programada e configurar sua capacidade de destino 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. Desabilite a redução da escala horizontalmente: a autoescalabilidade no monitoramento do objetivo é mais adequada para clusters com aumento/diminuição gradual da workload, já que picos/queda nas métricas podem desencadear oscilações consecutivas de aumento/redução da escala horizontalmente. 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 sua aplicação: recomendamos que você teste sua aplicação com suas workloads mínimas e máximas estimadas para determinar os mínimos e máximos absolutos de fragmentos/réplicas necessários para o cluster enquanto cria políticas de escalabilidade a fim de 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 on Target Tracking é mais adequado para clusters com distribuição uniforme de cargas de trabalho na dimensão de fragmentos/réplicas. Ter distribuição não uniforme pode levar a:

    • Escalar quando não for necessário devido a picos/quedas de workload em alguns fragmentos/réplicas quentes.

    • Não escalar quando necessário devido à média geral perto do destino, mesmo tendo fragmentos/réplicas quentes.

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 Valkey ou Redis OSS 7.0 ou superior e seu aplicativo usar Funções, recomendamos carregar todas as suas funções em todos os fragmentos antes de escalar 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.

    • Aumento/diminuição manual dos fragmentos/réplicas além da capacidade mínima e máxima configurada durante a criação da política.