View a markdown version of this page

Cluster Auto Scaling Valkey e Redis OSS - Amazon ElastiCache

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Cluster Auto Scaling Valkey e Redis OSS

Prerequisiti

ElastiCache L'Auto Scaling è limitato a quanto segue:

  • Cluster Valkey o Redis OSS (modalità cluster abilitata) che eseguono Valkey 7.2 e versioni successive o Redis OSS 6.0 in poi

  • Cluster di dati su più livelli (modalità cluster abilitata) che eseguono Valkey 7.2 e versioni successive o Redis OSS 7.0.7 in poi

  • Dimensioni istanza - Large, XL, 2xLarge

  • Famiglie di tipi di istanza: R8g, R7g, R6g, R6gd, R5, M8g, M7g, M6g, M5, C8gn, C7gn

  • L'Auto ElastiCache Scaling in non è supportato per i cluster in esecuzione in datastore globali, Outposts o zone locali.

Gestione automatica della capacità con ElastiCache Auto Scaling con Valkey o Redis OSS

ElastiCache il ridimensionamento automatico con Valkey o Redis OSS è la capacità di aumentare o diminuire automaticamente i frammenti o le repliche desiderati nel servizio. ElastiCache ElastiCache sfrutta il servizio Application Auto Scaling per fornire questa funzionalità. Per ulteriori informazioni, consulta Application Auto Scaling. Per utilizzare il ridimensionamento automatico, è necessario definire e applicare una politica di ridimensionamento che utilizza CloudWatch metriche e valori target assegnati dall'utente. ElastiCache il ridimensionamento automatico utilizza la policy per aumentare o diminuire il numero di istanze in risposta ai carichi di lavoro effettivi.

È possibile utilizzare il Console di gestione AWS per applicare una politica di scalabilità basata su una metrica predefinita. Un predefined metric viene definito in un'enumerazione in modo che tu possa specificarlo per nome nel codice o utilizzarlo nella Console di gestione AWS. I parametri personalizzati non possono essere selezionati tramite Console di gestione AWS. In alternativa, puoi utilizzare l'API Application Auto Scaling AWS CLI o l'API Application Auto Scaling per applicare una politica di scalabilità basata su una metrica predefinita o personalizzata.

ElastiCache per Valkey e Redis OSS supporta il ridimensionamento per le seguenti dimensioni:

  • Frammenti: frammenti add/remove automatici nel cluster in modo simile al resharding manuale online. In questo caso, il ridimensionamento ElastiCache automatico attiva il ridimensionamento per tuo conto.

  • Repliche: add/remove repliche automatiche nel cluster simili alle operazioni di replica manuali. Increase/Decrease ElastiCache scalabilità automatica per le adds/removes repliche OSS Valkey e Redis in modo uniforme su tutti gli shard del cluster.

ElastiCache per Valkey e Redis OSS supporta i seguenti tipi di politiche di scalabilità automatica:

  • Policy di dimensionamento con monitoraggio degli obiettivi— Aumenta o diminuisci il numero di shards/replicas esecuzioni del servizio in base a un valore target per una metrica specifica. Questa operazione può essere paragonata al modo in cui il termostato regola la temperatura di una casa. Tu selezioni la temperatura, il termostato si occupa del resto.

  • Scalabilità pianificata per la tua applicazione. — ElastiCache per Valkey e Redis OSS, il ridimensionamento automatico può aumentare o diminuire il numero di esecuzioni del shards/replicas servizio in base alla data e all'ora.

Immagine del ridimensionamento automatico ElastiCache per Valkey e Redis OSS

I passaggi seguenti riassumono il processo di ridimensionamento automatico ElastiCache per Valkey e Redis OSS, come mostrato nel diagramma precedente:

  1. Crei una policy di ridimensionamento ElastiCache automatico per il tuo Replication Group.

  2. ElastiCache il ridimensionamento automatico crea un paio di CloudWatch allarmi per conto dell'utente. Ogni coppia rappresenta i tuoi limiti superiore e inferiore per i parametri. Questi CloudWatch allarmi vengono attivati quando l'utilizzo effettivo del cluster si discosta dall'utilizzo previsto per un periodo di tempo prolungato. Puoi ora visualizzare gli allarm nella console .

  3. Se il valore della metrica configurata supera l'utilizzo previsto (o scende al di sotto del target) per un determinato periodo di tempo, CloudWatch attiva un allarme che richiama il ridimensionamento automatico per valutare la politica di scalabilità.

  4. ElastiCache auto scaling invia una richiesta di modifica per regolare la capacità del cluster.

  5. ElastiCache elabora la richiesta Modify, aumentando (o diminuendo) dinamicamente la Shards/Replicas capacità del cluster in modo che si avvicini all'utilizzo previsto.

Per capire come funziona ElastiCache Auto Scaling, supponiamo di avere un cluster denominato. UsersCluster Monitorando le CloudWatch metriche perUsersCluster, si determinano i frammenti massimi richiesti dal cluster quando il traffico è al picco e i frammenti minimi quando il traffico è nel punto più basso. Decidi anche un valore target per l'utilizzo della CPU per il cluster. UsersCluster ElastiCache auto scaling utilizza il suo algoritmo di tracciamento del target per garantire che gli shard of UsersCluster assegnati vengano regolati come richiesto in modo che l'utilizzo rimanga pari o vicino al valore target.

Nota

Il ridimensionamento può richiedere molto tempo e richiedere risorse aggiuntive del cluster per il ribilanciamento degli shard. ElastiCache Auto Scaling modifica le impostazioni delle risorse solo quando il carico di lavoro effettivo rimane elevato (o ridotto) per un periodo prolungato di diversi minuti. L'algoritmo di tracciamento degli obiettivi con scalabilità automatica cerca di mantenere l'utilizzo del target pari o vicino al valore scelto a lungo termine.

Autorizzazioni IAM richieste per Auto Scaling

ElastiCache per Valkey e Redis OSS Auto Scaling è reso possibile da una combinazione delle API ElastiCache, CloudWatch, e Application Auto Scaling. I cluster vengono creati e aggiornati con ElastiCache, gli allarmi con e le politiche di scalabilità vengono create con CloudWatch Application Auto Scaling. Oltre alle autorizzazioni IAM standard per la creazione e l'aggiornamento dei cluster, l'utente IAM che accede alle impostazioni di ElastiCache Auto Scaling deve disporre delle autorizzazioni appropriate per i servizi che supportano il ridimensionamento dinamico. In questa policy più recente abbiamo aggiunto il supporto per il ridimensionamento verticale di Memcached, con l'azione. elasticache:ModifyCacheCluster Gli utenti IAM devono disporre dell'autorizzazione per utilizzare le operazioni nella seguente policy di esempio:

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 ruolo

Il servizio di scalabilità automatica OSS ElastiCache per Valkey e Redis richiede inoltre l'autorizzazione per descrivere i cluster e gli CloudWatch allarmi e le autorizzazioni per modificare la capacità target per conto dell'utente ElastiCache . Se abiliti Auto Scaling per il tuo cluster, viene creato un ruolo collegato al servizio denominato. AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG Questo ruolo collegato ai servizi concede l'autorizzazione di scalabilità ElastiCache automatica per descrivere gli allarmi relativi alle politiche, monitorare la capacità attuale del parco veicoli e modificare la capacità del parco veicoli. Il ruolo collegato ai servizi è il ruolo predefinito per il ridimensionamento automatico. ElastiCache Per ulteriori informazioni, consulta Service-linked i ruoli ElastiCache per Redis OSS auto scaling nella Application Auto Scaling User Guide.

Best practice Auto Scaling

Prima di effettuare la registrazione a Auto Scaling, ti consigliamo di attenerti alle seguenti indicazioni:

  1. Usa una sola metrica di tracciamento: consente di identificare se il cluster dispone di carichi di lavoro che utilizzano notevoli risorse di CPU o dati e di utilizzare la metrica predefinita corrispondente per definire la policy di dimensionamento.

    • CPU del motore: ElastiCachePrimaryEngineCPUUtilization (dimensione partizione) o ElastiCacheReplicaEngineCPUUtilization (dimensione replica)

    • Utilizzo del database: ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage questa policy di dimensionamento è ideale con maxmemory-policy impostato su noeviction sul cluster.

    Ti consigliamo di evitare più policy per dimensione sul cluster. ElastiCache per Valkey e Redis OSS Auto scaling ridimensionerà il target scalabile se alcune policy di tracciamento del target sono pronte per lo scaling out, ma verrà scalato solo se tutte le policy di tracciamento del target (con la parte di scale-in abilitata) sono pronte per la scalabilità. Se più policy impongono alla destinazione scalabile un dimensionamento orizzontale o verticale contemporaneamente, viene dimensionata in base al criterio che fornisce la capacità massima sia per riduzione orizzontale che per il dimensionamento orizzontale.

  2. Metriche personalizzate per il tracciamento degli obiettivi: fai attenzione quando utilizzi metriche personalizzate per il tracciamento degli obiettivi poiché il ridimensionamento automatico è più adatto alla scala, proporzionale alle modifiche delle metriche scelte per la policy. out/in Se tali metriche non cambiano proporzionalmente alle operazioni di dimensionamento utilizzate per la creazione della policy, potrebbero verificarsi operazioni di scalabilità orizzontale o ridimensionamento continue che possono influire sulla disponibilità o sui costi.

    Per i cluster dei livelli di dati (tipi di istanza della famiglia r6gd), evita di utilizzare metriche basate sulla memoria per il dimensionamento.

  3. Scalabilità pianificata: se ritieni che il carico di lavoro è deterministico (viene raggiunto in un high/low momento specifico), ti consigliamo di utilizzare Scheduled Scaling e configurare la capacità target in base alle necessità. Il monitoraggio dell’obiettivo è ideale per carichi di lavoro non deterministici e per il cluster per un funzionamento con la metrica obiettivo richiesta, con aumento orizzontale quando occorrono più risorse e riduzione orizzontale quando occorrono meno risorse.

  4. Disabilita Scale-In: il ridimensionamento automatico su Target Tracking è più adatto per i cluster con carichi di lavoro graduali, poiché spikes/dip le metriche possono increase/decrease innescare oscillazioni di scala consecutive. out/in Per evitare tali oscillazioni, puoi iniziare con la riduzione orizzontale disabilitata e utilizzarla manualmente in un secondo momento in base alla necessità.

  5. Testa la tua applicazione: ti consigliamo di testare l'applicazione con i Min/Max carichi di lavoro stimati per determinare i valori minimi e massimi assoluti shards/replicas richiesti per il cluster durante la creazione di politiche di scalabilità per evitare problemi di disponibilità. La scalabilità automatica può effettuare l’aumento orizzontale fino alla soglia massima e la riduzione orizzontale fino alla soglia minima configurata per l’obiettivo.

  6. Definizione del valore target: puoi analizzare le CloudWatch metriche corrispondenti per l'utilizzo del cluster in un periodo di quattro settimane per determinare la soglia del valore target. Se non sei ancora certo del valore da scegliere, ti consigliamo di iniziare con il valore predefinito minimo supportato della metrica.

  7. AutoScaling on Target Tracking è più adatto per i cluster con una distribuzione uniforme dei carichi di lavoro su tutte le dimensioni. shards/replicas Avere una distribuzione non uniforme può portare a:

    • Scalabilità quando non necessaria a causa del carico di lavoro spike/dip su pochi host. shards/replicas

    • Non scalabile quando necessario a causa della media complessiva vicina al target anche se a caldo. shards/replicas

Nota

Quando si ridimensiona il cluster, ElastiCache replicherà automaticamente le funzioni caricate in uno dei nodi esistenti (selezionati a caso) nei nuovi nodi. Se il tuo cluster ha Valkey o Redis OSS 7.0 o versioni successive e la tua applicazione utilizza le funzioni, ti consigliamo di caricare tutte le funzioni su tutti gli shard prima di ridimensionarle in modo che il cluster non finisca con funzioni diverse su frammenti diversi.

Dopo esserti registrato, tieni presente quanto segue: AutoScaling

  • Esistono limitazioni sulle configurazioni del dimensionamento automatico supportate, per cui è preferibile non modificare la configurazione di un gruppo di replica registrato per il dimensionamento automatico. Di seguito vengono mostrati gli esempi:

    • Modifica manuale del tipo di istanza in tipi non supportati.

    • Associazione del gruppo di replica a un Global Datastore.

    • Modifica ReservedMemoryPercent parametro .

    • Manualmente increasing/decreasing shards/replicas oltre la Min/Max capacità configurata durante la creazione della policy.