Auto Scaling dei cluster 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à.

Auto Scaling dei cluster 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 che eseguono il motore Redis dalla versione 6.0 in poi OSS

  • Cluster di data tiering (modalità cluster abilitata) che eseguono Valkey 7.2 e versioni successive o che eseguono il motore Redis dalla versione 7.0.7 in poi OSS

  • Dimensioni XLarge delle istanze: grandi, 2 XLarge

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

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

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

ElastiCache la scalabilità automatica con Valkey o Redis OSS è la capacità di aumentare o diminuire automaticamente gli shard 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 la scalabilità automatica utilizza la policy per aumentare o diminuire il numero di istanze in risposta ai carichi di lavoro effettivi.

È possibile utilizzare il AWS Management Console 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 AWS Management Console. I parametri personalizzati non possono essere selezionati tramite AWS Management Console. In alternativa, puoi utilizzare AWS CLI o Application Auto Scaling API per applicare una politica di scalabilità basata su una metrica predefinita o personalizzata.

ElastiCache con Valkey o Redis OSS supporta la scalabilità per le seguenti dimensioni:

  • Partizioni : Aggiungi/rimuovi automaticamente frammenti nel cluster in modo simile al risharding online manuale. In questo caso, il ridimensionamento ElastiCache automatico attiva la scalabilità per tuo conto.

  • Repliche : Aggiungi/rimuovi automaticamente le repliche nel cluster in modo simile alle operazioni manuali Aumenta/Diminuisci. ElastiCache con la scalabilità OSS automatica Valkey o Redis aggiunge/rimuove le repliche in modo uniforme su tutti gli shard del cluster.

ElastiCache con Valkey o Redis OSS supporta i seguenti tipi di politiche di scalabilità automatica:

Immagine di ridimensionamento automatico per ElastiCache Valkey o Redis OSS

I seguenti passaggi riassumono il processo di ridimensionamento OSS automatico ElastiCache con Valkey o Redis come mostrato nel diagramma precedente:

  1. È possibile creare una policy di scalabilità ElastiCache automatica per il gruppo di replica.

  2. ElastiCache il ridimensionamento automatico con Valkey o Redis OSS crea un paio di CloudWatch allarmi per tuo conto. 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 dell'obiettivo) per un periodo di tempo specifico, CloudWatch attiva un allarme che richiama l'auto scaling per valutare la politica di scalabilità.

  4. ElastiCache con Valkey o Redis OSS auto scaling emette una richiesta di modifica per regolare la capacità del cluster.

  5. ElastiCache con Valkey o Redis OSS elabora la richiesta di modifica, aumentando (o diminuendo) dinamicamente la capacità degli shard/repliche del cluster in modo che si avvicini all'utilizzo previsto.

Per capire come funziona ElastiCache con Valkey o Redis Auto OSS Scaling, supponiamo di avere un cluster denominato. UsersCluster Monitorando le CloudWatch metriche perUsersCluster, si determina il numero massimo di shard richiesti dal cluster quando il traffico è al suo picco e il numero minimo di shard quando il traffico è nel punto più basso. Decidi anche un valore di destinazione per l'CPUutilizzo per il cluster. UsersCluster ElastiCache auto scaling utilizza il suo algoritmo di tracciamento del target per garantire che gli shard di UsersCluster forniti vengano regolati secondo necessità in modo che l'utilizzo rimanga pari o vicino al valore target.

Nota

La scalabilità potrebbe richiedere molto tempo e richiederà risorse di cluster aggiuntive per il ribilanciamento degli shard. ElastiCache con Valkey o Redis Auto OSS Scaling modifica le impostazioni delle risorse solo quando il carico di lavoro effettivo rimane elevato (o depresso) per un periodo prolungato di diversi minuti. L'algoritmo di tracciamento del target con scalabilità automatica cerca di mantenere l'utilizzo del target pari o vicino al valore prescelto a lungo termine.

IAMAutorizzazioni richieste per Auto Scaling

ElastiCache con Valkey o Redis Auto OSS Scaling è reso possibile dalla combinazione di ElastiCache CloudWatch, e Application Auto Scaling. APIs I cluster vengono creati e aggiornati con ElastiCache (RedisOSS), gli allarmi vengono creati e le politiche di scalabilità vengono create con CloudWatch Application Auto Scaling. Oltre alle IAM autorizzazioni standard per la creazione e l'aggiornamento dei cluster, l'IAMutente che accede alle impostazioni di ElastiCache Auto Scaling deve disporre delle autorizzazioni appropriate per i servizi che supportano la scalabilità dinamica. IAMgli utenti devono disporre delle autorizzazioni per utilizzare le azioni mostrate nella seguente politica di esempio:

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

Ruolo collegato al servizio

Il servizio di OSS auto scaling ElastiCache con Valkey o Redis necessita inoltre dell'autorizzazione per descrivere i cluster e gli CloudWatch allarmi e delle autorizzazioni per modificare la capacità target per tuo ElastiCache conto. Se abiliti Auto Scaling per il tuo cluster, viene creato un ruolo collegato al servizio denominato. AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG Questo ruolo collegato al servizio concede l'autorizzazione alla scalabilità ElastiCache automatica per descrivere gli allarmi per le tue politiche, monitorare la capacità attuale del parco veicoli e modificare la capacità del parco veicoli. Il ruolo collegato al servizio è il ruolo predefinito per la scalabilità ElastiCache automatica. Per ulteriori informazioni, consulta Service-linked roles for ElastiCache (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. Utilizza solo una metrica di tracciamento: identifica se il tuo cluster presenta CPU carichi di lavoro a uso intensivo di dati e utilizza una metrica predefinita corrispondente per definire la politica di scalabilità.

    • MotoreCPU: ElastiCachePrimaryEngineCPUUtilization (dimensione del frammento) o (dimensione della replica) ElastiCacheReplicaEngineCPUUtilization

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

    Ti consigliamo di evitare più politiche per dimensione nel cluster. ElastiCache con Valkey o Redis OSS Auto scaling ridimensionerà la destinazione scalabile se alcune policy di tracciamento del target sono pronte per la scalabilità orizzontale, ma la scalerà solo se tutte le politiche di tracciamento del target (con la parte scalabile abilitata) sono pronte per la scalabilità orizzontale. 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 monitoraggio degli obiettivi: prestare attenzione quando si utilizzano le metriche personalizzati per il monitoraggio degli obiettivi, poiché il dimensionamento automatico è più adatto alla scalabilità orizzontale/ridimensionamento proporzionale alle modifiche delle metriche scelte per la policy. 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. Dimensionamento pianificato: se determini che il carico di lavoro è deterministico (aumenta o diminuisce in un momento specifico), ti consigliamo di utilizzare il dimensionamento pianificato e configurare la capacità obiettivo in base alle esigenze. 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 riduzione orizzontale: il dimensionamento automatico nel tracciamento obiettivi è ideale per cluster con aumento e riduzione graduale dei carichi di lavoro, in quanto picchi e gole nelle metriche possono generare oscillazioni di aumento e riduzione orizzontale consecutive. Per evitare tali oscillazioni, puoi iniziare con la riduzione orizzontale disabilitata e utilizzarla manualmente in un secondo momento in base alla necessità.

  5. Test dell'applicazione: è preferibile testare l'applicazione con i carichi di lavoro minimi e massimi stimati per determinare il numero minimo e massimo assoluto di partizioni/repliche necessarie al cluster durante la creazione policy di dimensionamento 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: è possibile 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 distribuzione uniforme dei carichi di lavoro tra la dimensione degli shard/repliche. Avere una distribuzione non uniforme può portare a:

    • Dimensionamento quando non richiesto a causa di picco/dip del carico di lavoro su alcuni hot partizioni/repliche.

    • Non dimensionamento quando richiesto a causa della media complessiva vicina alla destinazione anche se si dispone di partizioni/repliche hot.

Nota

Quando si ridimensiona il cluster, ElastiCache replicherà automaticamente le funzioni caricate in uno dei nodi esistenti (selezionati a caso) sui nuovi nodi. Se il cluster utilizza Valkey o Redis OSS 7.0 o versioni successive e l'applicazione utilizza Functions, consigliamo di caricare tutte le funzioni su tutti gli shard prima di eseguire la scalabilità orizzontale, in modo che il cluster non finisca con funzioni diverse su shard diversi.

Dopo la registrazione a, 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 .

    • Aumento/riduzione manuale di partizioni/repliche oltre la capacità minima/massima configurata durante la creazione delle policy.