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.
Skalierungsrichtlinien für die Ziel-Nachverfolgung
Mit Skalierungsrichtlinien für die Zielverfolgung wählen Sie eine Metrik aus und legen einen Zielwert fest. ElastiCache mit Valkey oder Redis erstellt und verwaltet OSS Auto Scaling die CloudWatch Alarme, die die Skalierungsrichtlinie auslösen, und berechnet die Skalierungsanpassung auf der Grundlage der Metrik und des Zielwerts. Durch die Skalierungsrichtlinie wird so viel Kapazität wie erforderlich hinzugefügt oder entfernt, damit die Metrik auf oder nahe an dem Zielwert gehalten wird. Abgesehen davon, dass eine Skalierungsrichtlinie für die Ziel-Nachverfolgung die Metrik nahe an dem Zielwert hält, passt sie sich auch an die Schwankungen in der Metrik aufgrund eines schwankenden Lastmusters an und verringert schnelle Schwankungen der Kapazität der Flotte.
Nehmen wir zum Beispiel eine Skalierungsrichtlinie, die die vordefinierte ElastiCachePrimaryEngineCPUUtilization-Durchschnittsmetrik mit konfiguriertem Zielwert verwendet. Mit einer solchen Richtlinie kann die CPU Auslastung auf oder nahe dem angegebenen Zielwert gehalten werden.
Vordefinierte Metriken
Eine vordefinierte Metrik ist eine Struktur, die sich auf einen bestimmten Namen, eine Dimension und eine Statistik (average) einer bestimmten CloudWatch Metrik bezieht. Ihre Auto-Scaling-Richtlinie definiert eine der folgenden vordefinierten Metriken für Ihren Cluster:
| Vordefinierter Metrikname | CloudWatch Name der Metrik | CloudWatch Metrische Dimension | Nicht geeignete Instance-Typen |
|---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId, Rolle = Primär |
None |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Metriken für Valkey- oder OSS Redis-Replikationsgruppen |
None |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Metriken für Valkey- oder OSS Redis-Replikationsgruppen |
R6gd |
Instance-Typen mit Datenschicht können nicht verwendet werdenElastiCacheDatabaseMemoryUsageCountedForEvictPercentage, da diese Instance-Typen Daten sowohl im Arbeitsspeicher als auch speichern. SSD Der erwartete Anwendungsfall für datengestützte Instances besteht darin, dass der Speicher zu 100 Prozent genutzt und bei Bedarf aufgefüllt wird. SSD
Kriterien für die Auto Scaling für Shards
Wenn der Service erkennt, dass Ihre vordefinierte Metrik gleich oder größer als die Zieleinstellung ist, wird die Shards-Kapazität automatisch erhöht. ElastiCache mit Valkey oder Redis werden Ihre Cluster-Shards um eine Anzahl OSS skaliert, die der größeren von zwei Zahlen entspricht: prozentuale Abweichung von Target und 20 Prozent der aktuellen Shards. Bei Scale-In erfolgt ElastiCache keine auto Skalierung, es sei denn, der Gesamtmetrikwert liegt unter 75 Prozent Ihres definierten Ziels.
Wenn Sie für ein Scal-Out-Beispiel 50 Shards und
-
Wenn Ihr Target die Sicherheitslücke um 30 Prozent überschreitet, OSS skaliert es ElastiCache mit Valkey oder Redis um 30 Prozent, was zu 65 Shards pro Cluster führt.
-
wenn Ihr Target die Sicherheitslücke um 10 Prozent überschreitet, wird ElastiCache mit Valkey oder Redis standardmäßig mindestens 20 Prozent OSS skaliert, was zu 60 Shards pro Cluster führt.
Ein Beispiel für eine Skalierung: Wenn Sie einen Zielwert von 60 Prozent ausgewählt haben, ElastiCache werden Valkey oder Redis OSS erst auto skalieren, wenn die Metrik 45 Prozent oder weniger beträgt (25 Prozent unter dem Ziel von 60 Prozent).
Überlegungen zum Auto Scaling
Beachten Sie folgende Überlegungen:
-
Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung geht davon aus, dass sie eine horizontale Skalierung nach oben vornehmen soll, wenn die angegebene Metrik über dem Zielwert liegt. Sie können keine Skalierungsrichtlinie für die Zielverfolgung verwenden, um eine Skalierung vorzunehmen, wenn die angegebene Metrik unter dem Zielwert liegt. ElastiCache mit Valkey oder Redis werden Shards um eine Abweichung von mindestens 20 Prozent vom Sollwert vorhandener Shards im Cluster OSS skaliert.
-
Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung nimmt keine Skalierung vor, wenn die angegebene Metrik unzureichende Daten aufweist. Es wird keine Abskalierung vorgenommen, da unzureichende Daten nicht als geringe Auslastung interpretiert werden.
-
Möglicherweise werden Lücken zwischen den Datenpunkten für den Zielwert und die aktuelle Metrik angezeigt. Dies liegt daran, dass OSS Auto Scaling ElastiCache bei Valkey oder Redis immer konservativ vorgeht, indem es auf- oder abrundet, wenn es bestimmt, wie viel Kapazität hinzugefügt oder entfernt werden soll. Dadurch wird verhindert, dass zu wenig Kapazität hinzufügt oder zu viel Kapazität entfernt wird.
-
Um die Verfügbarkeit der Anwendung sicherzustellen, wird der Service schnellstmöglich proportional zur Metrik hochskaliert, jedoch etwas langsamer herunterskaliert.
-
Sie können mehrere Skalierungsrichtlinien für die Zielverfolgung für einen OSS Cluster ElastiCache mit Valkey oder Redis verwenden, vorausgesetzt, dass jede von ihnen eine andere Metrik verwendet. Die Absicht von ElastiCache (RedisOSS) Auto Scaling besteht darin, der Verfügbarkeit immer Priorität einzuräumen. Daher unterscheidet sich das Verhalten je nachdem, ob die Zielverfolgungsrichtlinien für Scale-Out oder Scale-In bereit sind. Sofern Richtlinien für die Ziel-Nachverfolgung für die Skalierung nach oben bereit sind, findet eine Skalierung des Service nach oben statt. Eine Skalierung nach unten wird jedoch nur vorgenommen, wenn alle Richtlinien für die Ziel-Nachverfolgung (mit aktivierter Skalierung nach unten) zur Skalierung nach unten bereit sind.
-
Bearbeiten oder löschen Sie nicht die CloudWatch Alarme, die ElastiCache mit Valkey oder Redis OSS Auto Scaling für eine Skalierungsrichtlinie zur Zielverfolgung verwaltet werden. ElastiCache Auto Scaling löscht die Alarme automatisch, wenn Sie die Skalierungsrichtlinie löschen.
-
ElastiCache Auto Scaling verhindert nicht, dass Sie Cluster-Shards manuell ändern. Diese manuellen Anpassungen wirken sich nicht auf bestehende CloudWatch Alarme aus, die mit der Skalierungsrichtlinie verknüpft sind, können sich jedoch auf Metriken auswirken, die diese CloudWatch Alarme auslösen können.
-
Diese von Auto Scaling verwalteten CloudWatch Alarme werden über die AVG Metrik für alle Shards im Cluster definiert. So kann Hot-Shards zu einem beliebigen Szenario führen:
-
Skalierung, wenn sie aufgrund der Belastung einiger Hot-Shards, die einen Alarm auslösen, nicht erforderlich ist CloudWatch
-
wird nicht skaliert, wenn dies erforderlich ist, da alle Shards aggregiert werden, AVG was dazu führt, dass der Alarm nicht überschritten wird.
-
-
ElastiCache Bei Valkey oder Redis gelten weiterhin die OSS Standardgrenzwerte für Knoten pro Cluster. Wenn Sie sich also für Auto Scaling entscheiden und erwarten, dass maximale Knoten mehr als die Standardgrenze sind, fordern Sie eine Limiterhöhung bei AWS -Service-Limits an und wählen Sie den Limit-Typ Knoten pro Cluster pro Instance-Typ.
-
Stellen Sie sicher, dass in Ihrem System genügend ENIs (Elastic Network Interfaces) zur Verfügung stehenVPC, die beim Scale-Out benötigt werden. Weitere Informationen finden Sie unter Elastic-Network-Schnittstellen.
-
Wenn nicht genügend Kapazität verfügbar istEC2, wird ElastiCache Auto Scaling nicht skaliert und verzögert, bis die Kapazität verfügbar ist.
-
ElastiCache (RedisOSS) Auto Scaling entfernt beim Scale-In keine Shards mit Steckplätzen, die nach der Serialisierung eine Objektgröße von mehr als 256 MB haben.
-
Während des Scale-Ins werden Shards nicht entfernt, wenn nicht genügend Speicher für die resultierende Shard-Konfiguration verfügbar ist.
