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 von Valkey- und Redis OSS-Clustern
Voraussetzungen
ElastiCache Auto Scaling ist auf Folgendes beschränkt:
-
Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert), auf denen Valkey 7.2 oder ab Redis OSS 6.0 ausgeführt wird
-
Daten-Tiering (Clustermodus aktiviert) Cluster, auf denen Valkey 7.2 oder höher ausgeführt wird, oder auf denen Redis OSS 7.0.7 ausgeführt wird
-
Instance-Größen - Large, XLarge, 2xLarge
-
Instance-Typfamilien: R8g, R7g, R6g, R6gd, R5, M8g, M7g, M6g, M5, C8gn, C7gn
-
Auto ElastiCache Scaling In wird für Cluster, die in globalen Datenspeichern, Outposts oder lokalen Zonen ausgeführt werden, nicht unterstützt.
Automatische Kapazitätsverwaltung mit ElastiCache Auto Scaling mit Valkey oder Redis OSS
ElastiCache Auto Scaling mit Valkey oder Redis OSS ist die Möglichkeit, die Anzahl der gewünschten Shards oder Replikate in Ihrem Service automatisch zu erhöhen oder zu verringern. ElastiCache ElastiCache nutzt den Application Auto 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 Instances als Reaktion auf die tatsächlichen Workloads zu erhöhen oder zu verringern.
Sie können die verwenden AWS-Managementkonsole , 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-Managementkonsole verwenden können. Benutzerdefinierte Metriken können nicht über die AWS-Managementkonsole ausgewählt werden. Alternativ können Sie entweder die AWS CLI oder die Application Auto Scaling API verwenden, um eine Skalierungsrichtlinie anzuwenden, die auf einer vordefinierten oder benutzerdefinierten Metrik basiert.
ElastiCache für Valkey und Redis unterstützt OSS die Skalierung für die folgenden Dimensionen:
-
Shards — Automatische add/remove Shards im Cluster, ähnlich wie manuelles Online-Resharding. In diesem Fall löst die ElastiCache automatische Skalierung die Skalierung in Ihrem Namen aus.
-
Replikate — Automatische add/remove Replikate im Cluster, ähnlich wie bei manuellen Increase/Decrease Replikationsvorgängen. ElastiCache Automatische Skalierung für Valkey- und Redis adds/removes OSS-Replikate, einheitlich auf alle Shards im Cluster.
ElastiCache für Valkey und Redis unterstützt OSS die folgenden Arten von Richtlinien zur automatischen Skalierung:
-
Skalierungsrichtlinien für die Ziel-Nachverfolgung— Erhöhen oder verringern Sie die Anzahl der von shards/replicas Ihrem Service ausgeführten Aktionen auf der 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 ausgeführten shards/replicas Dienste je nach Datum und Uhrzeit erhöhen oder verringern.
Die folgenden Schritte fassen den Autoscaling-Prozess ElastiCache für Valkey und Redis OSS zusammen, wie im vorherigen Diagramm dargestellt:
-
Sie erstellen eine ElastiCache Auto Scaling-Richtlinie für Ihre Replication Group.
-
ElastiCache Auto Scaling erstellt in Ihrem Namen ein Paar von CloudWatch Alarmen. Jedes Paar stellt die Ober- und Untergrenze für Metriken dar. Diese CloudWatch Alarme werden ausgelöst, wenn die tatsächliche Auslastung des Clusters für einen längeren Zeitraum von Ihrer Zielauslastung abweicht. Sie können jetzt -Alarme in der -Konsole anzeigen.
-
Wenn der konfigurierte Metrikwert Ihre Zielauslastung für einen bestimmten Zeitraum überschreitet (oder unter den Zielwert fällt), CloudWatch löst dies einen Alarm aus, der Auto Scaling zur Bewertung Ihrer Skalierungsrichtlinie auslöst.
-
ElastiCache Auto Scaling gibt eine Modify-Anfrage aus, um Ihre Cluster-Kapazität anzupassen.
-
ElastiCache verarbeitet die Modify-Anfrage und erhöht (oder verringert) die Shards/Replicas Clusterkapazität dynamisch, sodass sie sich Ihrer Zielauslastung nähert.
Um zu verstehen, wie ElastiCache Auto Scaling funktioniert, nehmen Sie an, Sie haben einen Cluster benanntUsersCluster. Durch die Überwachung der CloudWatch Metriken für UsersCluster ermitteln Sie die maximale Anzahl der Shards, die der Cluster benötigt, wenn der Verkehr seinen Höhepunkt erreicht hat, und die Mindestanzahl der Shards, wenn der Verkehr seinen Tiefpunkt erreicht hat. Sie legen auch einen Zielwert für die CPU-Auslastung für den UsersCluster Cluster 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 einige 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 niedrig) bleibt. Der Auto Scaling-Algorithmus zur Zielverfolgung versucht, die Zielauslastung langfristig auf oder in der Nähe des von Ihnen gewählten Werts zu halten.
Für Auto Scaling sind IAM-Berechtigungen erforderlich
ElastiCache für Valkey und Redis OSS Auto Scaling wird durch eine Kombination der APIs ElastiCache, CloudWatch, und Application Auto Scaling ermöglicht. Cluster werden mit Application Auto Scaling erstellt und aktualisiert ElastiCache CloudWatch, Alarme werden mit erstellt und Skalierungsrichtlinien werden erstellt. Zusätzlich zu den Standard-IAM-Berechtigungen zum Erstellen und Aktualisieren von Clustern muss der IAM-Benutzer, der auf die ElastiCache Auto Scaling-Einstellungen zugreift, über die entsprechenden Berechtigungen für die Dienste verfügen, die dynamische Skalierung unterstützen. In dieser neuesten Richtlinie haben wir Unterstützung für die vertikale Skalierung von Memcached mit der Aktion hinzugefügt. elasticache:ModifyCacheCluster IAM-Benutzer müssen die Berechtigung haben, die Aktionen in der folgenden Beispielrichtlinie zu verwenden:
Service-linked 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, um Ihre ElastiCache Zielkapazität in Ihrem Namen zu ändern. Wenn Sie Auto Scaling für Ihren Cluster aktivieren, wird eine serviceverknüpfte Rolle mit dem Namen erstellt. AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG Diese serviceverknüpfte Rolle gewährt ElastiCache Auto Scaling die Berechtigung, 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 Service-linked Rollen ElastiCache für Redis OSS Auto Scaling im Application Auto Scaling-Benutzerhandbuch.
Bewährte Methoden für die Auto Scaling
Wir empfehlen vor der Registrierung für Auto Scaling Folgendes:
-
Verwenden Sie nur eine Tracking-Metrik – Ermitteln Sie, ob Ihr Cluster über CPU- oder datenintensive Workloads verfügt, und verwenden Sie eine entsprechende vordefinierte Metrik, um die Skalierungsrichtlinie zu definieren.
-
Engine-CPU:
ElastiCachePrimaryEngineCPUUtilization(Shard-Dimension) oderElastiCacheReplicaEngineCPUUtilization(Replikatdimension) -
Datenbanknutzung:
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentageDiese Skalierungsrichtlinie funktioniert am besten, wenn „maxmemory-policy“ im Cluster auf „noeviction“ festgelegt ist.
Wir empfehlen Ihnen, mehrere Richtlinien pro Dimension im Cluster zu vermeiden. ElastiCache für Valkey und Redis OSS Auto Scaling skaliert das skalierbare Ziel, wenn Ziel-Tracking-Richtlinien für das Scale-Out bereit sind. Die Skalierung erfolgt jedoch nur, 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.
-
-
Maßgeschneiderte Metriken für Target Tracking — Seien Sie vorsichtig, wenn Sie benutzerdefinierte Metriken für Target Tracking verwenden, da Auto Scaling am besten geeignet ist, um out/in proportional zu Änderungen der für die Richtlinie ausgewählten Metriken zu skalieren. 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.
-
Geplante Skalierung — Wenn Sie feststellen, dass Ihr Workload deterministisch ist (er wird high/low zu einem bestimmten Zeitpunkt erreicht), empfehlen wir Ihnen, Scheduled Scaling 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.
-
Deaktivieren Scale-In — Die automatische Skalierung bei Target Tracking eignet sich am besten für Cluster mit increase/decrease schrittweisen Arbeitslasten, da spikes/dip Kennzahlen aufeinanderfolgende Skalierungsschwankungen auslösen können. 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.
-
Testen Sie Ihre Anwendung — Wir empfehlen Ihnen, Ihre Anwendung mit Ihren geschätzten Min/Max Workloads zu testen, um die für den Cluster shards/replicas erforderlichen absoluten Mindest- und Höchstwerte zu ermitteln 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.
-
Zielwert definieren — Sie können die entsprechenden CloudWatch Metriken für die Cluster-Auslastung ü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.
-
AutoScaling on Target Tracking eignet sich am besten für Cluster mit einer gleichmäßigen Verteilung der Workloads über shards/replicas die einzelnen Dimensionen. Eine ungleichmäßige Verteilung kann zu folgenden Faktoren führen:
-
Skalierung, wenn sie aufgrund der Arbeitslast spike/dip auf einigen heißen shards/replicas Geräten nicht erforderlich ist.
-
Wird nicht bei Bedarf skaliert, da der Gesamtdurchschnitt nahe am Zielwert liegt, obwohl er gerade heiß shards/replicas ist.
-
Anmerkung
Beim Skalieren Ihres Clusters ElastiCache werden automatisch die Funktionen, die in einem der vorhandenen Knoten geladen wurden (zufällig ausgewählt), 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
Beachten Sie nach der Registrierung bei 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.
-
Ändern
ReservedMemoryPercent-Parameter. -
Manuell increasing/decreasing shards/replicas über die bei der Erstellung der Richtlinie konfigurierte Min/Max Kapazität hinaus.
-
