Auto Scaling Valkey- und Redis-Cluster OSS - Amazon ElastiCache

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Auto Scaling Valkey- und Redis-Cluster OSS

Voraussetzungen

ElastiCache Auto Scaling ist auf Folgendes beschränkt:

  • Valkey- oder Redis-Cluster OSS (Clustermodus aktiviert), auf denen Valkey 7.2 oder Redis 6.0 oder höher ausgeführt wird OSS

  • Cluster mit Datenklassierung (Clustermodus aktiviert), auf denen Valkey 7.2 oder Redis 7.0.7 oder höher ausgeführt wird OSS

  • Instanzgrößen — Groß, 2 XLarge XLarge

  • Instance-Familien – R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn

  • Auto Scaling in ElastiCache wird nicht für Cluster unterstützt, die in globalen Datenspeichern, Outposts oder Local Zones ausgeführt werden.

Automatisches Kapazitätsmanagement mit ElastiCache Auto Scaling mit Valkey oder Redis OSS

ElastiCache Auto Scaling mit Valkey oder Redis OSS ist die Möglichkeit, die gewünschten Shards oder Repliken in Ihrem Service automatisch zu erhöhen oder zu verringern. ElastiCache ElastiCache nutzt den Application Auto Scaling Scaling-Dienst, um diese Funktionalität bereitzustellen. Weitere Informationen finden Sie unter Application Auto Scaling. Um die automatische Skalierung zu verwenden, definieren und wenden Sie eine Skalierungsrichtlinie an, die von Ihnen CloudWatch zugewiesene Metriken und Zielwerte verwendet. ElastiCache Auto Scaling verwendet die Richtlinie, um die Anzahl der Instanzen als Reaktion auf tatsächliche Workloads zu erhöhen oder zu verringern.

Sie können die verwenden AWS Management Console , um eine Skalierungsrichtlinie anzuwenden, die auf einer vordefinierten Metrik basiert. Eine predefined metric ist in einer Aufzählung definiert, sodass Sie sie im Code durch einen Namen angeben oder in der AWS Management Console verwenden können. Benutzerdefinierte Metriken können nicht über die AWS Management Console ausgewählt werden. Alternativ können Sie entweder das AWS CLI oder das Application Auto Scaling verwenden, API um eine Skalierungsrichtlinie anzuwenden, die auf einer vordefinierten oder benutzerdefinierten Metrik basiert.

ElastiCache für Valkey und Redis OSS unterstützt die Skalierung für die folgenden Dimensionen:

  • Shards— Automatisches Hinzufügen/Entfernen von Shards im Cluster ähnlich wie beim manuellen Online-Resharding. In diesem Fall löst ElastiCache Auto Scaling die Skalierung in Ihrem Namen aus.

  • Replikate — Automatisch und add/remove replicas in the cluster similar to manual Increase/Decrease replica operations. ElastiCache auto scaling for Valkey and Redis OSS adds/removes einheitlich auf allen Shards im Cluster repliziert.

ElastiCache for Valkey und Redis OSS unterstützt die folgenden Arten von Richtlinien für die automatische Skalierung:

  • Skalierungsrichtlinien für die Ziel-Nachverfolgung Erhöhen oder Verringern der Anzahl der Aufgaben, die von Ihrem Service ausgeführt werden, auf Grundlage eines Zielwerts für eine bestimmte Metrik. Dies ähnelt der Art und Weise, wie ein Thermostat die Temperatur in Ihrem Zuhause konstant hält. Sie wählen eine Temperatur aus und der Thermostat erledigt den Rest.

  • Geplante Skalierung für Ihre Anwendung. — ElastiCache Für Valkey und Redis kann OSS Auto Scaling die Anzahl der Shard/Replicas, die Ihr Service ausführt, je nach Datum und Uhrzeit erhöhen oder verringern.

Bild der auto Skalierung ElastiCache für Valkey und Redis OSS

Die folgenden Schritte fassen den OSS auto Skalierungsprozess ElastiCache für Valkey und Redis zusammen, wie im vorherigen Diagramm dargestellt:

  1. Sie erstellen eine ElastiCache Auto Scaling-Richtlinie für Ihre Replikationsgruppe.

  2. ElastiCache Auto Scaling erstellt in Ihrem Namen ein Paar CloudWatch Alarme. Jedes Paar stellt die Ober- und Untergrenze für Metriken dar. Diese CloudWatch Alarme werden ausgelöst, wenn die tatsächliche Auslastung des Clusters über einen längeren Zeitraum von Ihrer Zielauslastung abweicht. Sie können jetzt -Alarme in der -Konsole anzeigen.

  3. Wenn der konfigurierte Metrikwert Ihre Zielauslastung für einen bestimmten Zeitraum überschreitet (oder unter das Ziel fällt), wird ein Alarm CloudWatch ausgelöst, der Auto Scaling auslöst, um Ihre Skalierungsrichtlinie zu bewerten.

  4. ElastiCache Auto Scaling gibt eine Modifizierungsanforderung aus, um Ihre Clusterkapazität anzupassen.

  5. ElastiCache verarbeitet die Modifizierungsanforderung und erhöht (oder verringert) die Kapazität der Cluster-Shards/Replicas dynamisch, sodass sie sich Ihrer Zielauslastung annähert.

Um zu verstehen, wie ElastiCache Auto Scaling funktioniert, nehmen wir an, Sie haben einen Cluster mit dem NamenUsersCluster. Durch die Überwachung der CloudWatch Metriken bestimmen Sie die maximale Anzahl an Shards, die der Cluster benötigt, wenn der Verkehr seinen Höhepunkt erreicht, und die Mindestanzahl an Shards, wenn der Verkehr am niedrigsten Punkt ist. UsersCluster Sie legen auch einen Zielwert für die CPU Auslastung des UsersCluster Clusters fest. ElastiCache Auto Scaling verwendet seinen Target-Tracking-Algorithmus, um sicherzustellen, dass die bereitgestellten Shards von UsersCluster nach Bedarf angepasst werden, sodass die Auslastung auf oder nahe dem Zielwert bleibt.

Anmerkung

Die Skalierung kann viel Zeit in Anspruch nehmen und erfordert zusätzliche Cluster-Ressourcen, damit die Shards wieder ausgeglichen werden können. ElastiCache Auto Scaling ändert die Ressourceneinstellungen nur, wenn die tatsächliche Arbeitslast über einen längeren Zeitraum von mehreren Minuten erhöht (oder reduziert) bleibt. Der Auto Scaling Target-Tracking-Algorithmus versucht, die Zielauslastung langfristig auf oder nahe dem von Ihnen gewählten Wert zu halten.

IAMFür Auto Scaling erforderliche Berechtigungen

ElastiCache für Valkey und Redis wird OSS Auto Scaling durch eine Kombination aus ElastiCache CloudWatch, und Application Auto Scaling ermöglicht. APIs Cluster werden mit Application Auto Scaling erstellt und aktualisiert ElastiCache CloudWatch, Alarme werden mit erstellt und Skalierungsrichtlinien werden erstellt. Zusätzlich zu den IAM Standardberechtigungen für das Erstellen und Aktualisieren von Clustern muss der IAM Benutzer, der auf die ElastiCache Auto Scaling Scaling-Einstellungen zugreift, über die entsprechenden Berechtigungen für die Dienste verfügen, die dynamische Skalierung unterstützen. IAMBenutzer müssen über Berechtigungen verfügen, um die in der folgenden Beispielrichtlinie aufgeführten Aktionen verwenden zu können:

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

Servicegebundene Rolle

Der OSS Auto Scaling-Dienst ElastiCache für Valkey und Redis benötigt außerdem die Erlaubnis, Ihre Cluster und CloudWatch Alarme zu beschreiben, sowie Berechtigungen, Ihre ElastiCache Zielkapazität in Ihrem Namen zu ändern. Wenn Sie Auto Scaling für Ihren Cluster aktivieren, wird eine dienstverknüpfte Rolle mit dem Namen AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG erstellt. Diese dienstbezogene Rolle gewährt ElastiCache Auto Scaling-Berechtigungen, um die Alarme für Ihre Richtlinien zu beschreiben, die aktuelle Kapazität der Flotte zu überwachen und die Kapazität der Flotte zu ändern. Die serviceverknüpfte Rolle ist die Standardrolle für ElastiCache Auto Scaling. Weitere Informationen finden Sie unter Dienstbezogene Rollen ElastiCache für Redis OSS Auto Scaling im Application Auto Scaling Scaling-Benutzerhandbuch.

Bewährte Methoden für die Auto Scaling

Wir empfehlen vor der Registrierung für Auto Scaling Folgendes:

  1. Verwenden Sie nur eine Tracking-Metrik — Identifizieren Sie, ob Ihr Cluster datenintensive Workloads hatCPU, und verwenden Sie eine entsprechende vordefinierte Metrik, um die Skalierungsrichtlinie zu definieren.

    • EngineCPU: ElastiCachePrimaryEngineCPUUtilization (Shard-Dimension) oder ElastiCacheReplicaEngineCPUUtilization (Replikat-Dimension)

    • Datenbanknutzung: ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage Diese Skalierungsrichtlinie funktioniert am besten, wenn „maxmemory-policy“ im Cluster auf „noeviction“ festgelegt ist.

    Wir empfehlen, mehrere Richtlinien pro Dimension auf dem Cluster zu vermeiden. ElastiCache Für Valkey und Redis skaliert OSS Auto Scaling das skalierbare Ziel, wenn Richtlinien für die Zielverfolgung bereit sind, aber es wird nur dann skaliert, wenn alle Ziel-Tracking-Richtlinien (mit aktiviertem Scale-In-Teil) skalierbar sind. Wenn mehrere Richtlinien das skalierbare Ziel anweisen, gleichzeitig zu herauf oder herunter zu skalieren, skaliert auf Grundlage der Richtlinie, die die größte Kapazität für das Herauf- und Herunterskalieren bietet.

  2. Benutzerdefinierte Metriken für die Zielverfolgung – Seien Sie vorsichtig, wenn Sie benutzerdefinierte Metriken für die Zielverfolgung verwenden, da die automatische Skalierung am besten geeignet ist, um proportional zu Änderungen der für die Richtlinie ausgewählten Metriken auf-/abzuskalieren. Wenn solche Metriken, die sich nicht proportional zu den Skalierungsaktionen ändern, zur Richtlinienerstellung verwendet werden, kann dies zu kontinuierlichen Auf- oder Abskalierungsaktionen führen, was sich auf Verfügbarkeit oder Kosten auswirken kann.

    Vermeiden Sie bei Daten-Tiering-Clustern (Instance-Familie r6gd) die Verwendung speicherbasierter Metriken für die Skalierung.

  3. Geplante Skalierung – Wenn Sie feststellen, dass Ihre Workload deterministisch ist (erreichen Sie hoch/niedrig zu einem bestimmten Zeitpunkt), empfehlen wir Ihnen, die geplante Skalierung zu verwenden und Ihre Zielkapazität entsprechend den Anforderungen zu konfigurieren. Target Tracking eignet sich am besten für nicht-deterministische Workloads und für einen Cluster für den Betrieb mit der erforderlichen Zielmetrik, indem er aufskaliert, wenn Sie mehr Ressourcen benötigen, und abskaliert, wenn Sie weniger benötigen.

  4. Scale-In deaktivieren — Die automatische Skalierung bei Target Tracking eignet sich am besten für Cluster mit allmählichen Schwankungen. increase/decrease of workloads as spikes/dip in metrics can trigger consecutive scale-out/in Um solche Schwankungen zu vermeiden, können Sie mit deaktivierter Abskalierung beginnen. Später können Sie jederzeit manuell nach Ihren Bedürfnissen abskalieren.

  5. Testen Sie Ihre Anwendung — Wir empfehlen Ihnen, Ihre Anwendung mit Ihrem geschätzten Min/Max workloads to determine absolute Min,Max shards/replicas Bedarf für den Cluster zu testen und gleichzeitig Skalierungsrichtlinien zu erstellen, um Verfügbarkeitsprobleme zu vermeiden. Die automatische Skalierung kann bis zum Maximal- und Minimalwert auf- bzw. abskalieren, der für das Ziel konfiguriert wurde.

  6. Definition des Zielwerts — Sie können die entsprechenden CloudWatch Metriken für die Clusterauslastung über einen Zeitraum von vier Wochen analysieren, um den Schwellenwert für den Zielwert zu ermitteln. Wenn Sie sich immer noch nicht sicher sind, welchen Wert Sie wählen möchten, empfehlen wir, mit dem minimal unterstützten vordefinierten Metrikwert zu beginnen.

  7. AutoScaling On Target Tracking eignet sich am besten für Cluster mit einheitlicher Verteilung der Workloads auf die Shard-/Replica-Dimension. Eine ungleichmäßige Verteilung kann zu folgenden Faktoren führen:

    • Skalierung, wenn sie aufgrund der Arbeitslast nicht erforderlich ist. spike/dip on a few hot shards/replicas

    • Keine Skalierung, wenn erforderlich, da insgesamt durchschnittlich nahe am Ziel liegt, obwohl Hot-Shards/Replikate vorhanden sind.

Anmerkung

Bei der Skalierung Ihres Clusters ElastiCache werden die Funktionen, die in einem der vorhandenen Knoten geladen wurden (zufällig ausgewählt), automatisch auf die neuen Knoten repliziert. Wenn Ihr Cluster über Valkey oder Redis OSS 7.0 oder höher verfügt und Ihre Anwendung Functions verwendet, empfehlen wir, alle Ihre Funktionen vor dem Skalieren auf alle Shards zu laden, damit Ihr Cluster nicht mit unterschiedlichen Funktionen auf verschiedenen Shards endet.

Beachten Sie nach der Registrierung Folgendes AutoScaling:

  • Es gibt Einschränkungen bei den unterstützten Konfigurationen für die automatische Skalierung, daher empfehlen wir, die Konfiguration einer Replikationsgruppe, die für die automatische Skalierung registriert ist, nicht zu ändern. Im Folgenden sind einige Beispiele aufgeführt:

    • Manuelles Ändern des Instance-Typs in nicht unterstützte Typen.

    • Zuordnen der Replikationsgruppe zu einem globalen Datenspeicher.

    • ÄndernReservedMemoryPercent-Parameter.

    • Manuell konfigurierte increasing/decreasing shards/replicas beyond the Min/Max Kapazität bei der Richtlinienerstellung.