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
Bei Skalierungsrichtlinien für die Zielverfolgung wählen Sie eine Metrik aus und legen einen Zielwert fest. ElastiCache für Valkey und 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. Eine solche Richtlinie kann die CPU-Nutzung auf oder nahe an dem Zielwert halten.
Vordefinierte Metriken
Eine vordefinierte Metrik ist eine Struktur, die sich auf einen bestimmten Namen, eine Dimension und eine Statistik (average) einer bestimmten Metrik bezieht. CloudWatch Ihre Auto-Scaling-Richtlinie definiert eine der folgenden vordefinierten Metriken für Ihren Cluster:
| Vordefinierter Metrikname | CloudWatch Metrikname | CloudWatch Metrische Dimension | Nicht geeignete Instance-Typen |
|---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId, Rolle = Primär |
Keine |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Metriken für Valkey- oder Redis OSS-Replikationsgruppen |
Keine |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Metriken für die OSS-Replikationsgruppe von Valkey oder Redis |
R6gd |
Instance-Typen mit Daten-Tiering können ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage nicht verwenden, da diese Instance-Typen Daten sowohl im Arbeitsspeicher als auch im SSD-Speicher ablegen. Der erwartete Anwendungsfall für Instances mit Daten-Tiering ist eine 100-prozentige Speichernutzung und das Auffüllen des SSD-Speichers nach Bedarf.
Kriterien für die Auto Scaling für Shards
Wenn der Service feststellt, dass Ihre vordefinierte Metrik gleich oder größer als die Zieleinstellung ist, erhöht er die Kapazität Ihrer Shards automatisch. ElastiCache für Valkey und Redis OSS skaliert OSS Ihre Cluster-Shards um eine Anzahl, 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ücken um 30 Prozent überschreitet, wird eine ElastiCache Skalierung um 30 Prozent vorgenommen, was zu 65 Shards pro Cluster führt.
-
Wenn Ihr Target die Sicherheitslücken um 10 Prozent überschreitet, wird standardmäßig ein Minimum von 20 Prozent ElastiCache skaliert, was zu 60 Shards pro Cluster führt.
Wenn Sie beispielsweise einen Zielwert von 60 Prozent ausgewählt haben, erfolgt die auto Skalierung ElastiCache erst, 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 für Valkey und Redis skaliert OSS die Shards um eine Abweichung von mindestens 20 Prozent vom Ziel vorhandener Shards im Cluster.
-
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. Das liegt daran, dass ElastiCache Auto Scaling immer konservativ agiert, 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 zur Zielverfolgung für einen OSS-Cluster ElastiCache für Valkey und Redis verwenden, vorausgesetzt, dass jeder von ihnen eine andere Metrik verwendet. Die Absicht von ElastiCache Auto Scaling besteht darin, der Verfügbarkeit immer Priorität einzuräumen. Daher unterscheidet sich das Verhalten je nachdem, ob die Zielverfolgungsrichtlinien für die horizontale Skalierung oder für die Skalierung 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 Auto Scaling für eine Skalierungsrichtlinie zur Zielverfolgung verwaltet. 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 anhand der AVG-Metrik für alle Shards im Cluster definiert. So kann Hot-Shards zu einem beliebigen Szenario führen:
-
Skalierung, wenn sie nicht erforderlich ist, weil die Belastung einiger Hot-Shards einen Alarm auslöst CloudWatch
-
nicht skalieren, wenn dies erforderlich ist, aufgrund aggregierter AVG über alle Shards, die den Alarm nicht verletzen.
-
-
ElastiCache Die Standardgrenzwerte für Knoten pro Cluster gelten weiterhin. 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 Ihrer VPC genügend ENIs (Elastic Network Interfaces) verfügbar sind, die beim Scale-Out benötigt werden. Weitere Informationen finden Sie unter Elastic-Network-Schnittstellen.
-
Wenn nicht genügend Kapazität verfügbar ist EC2, wird ElastiCache Auto Scaling nicht skaliert und verzögert, bis die Kapazität verfügbar ist.
-
ElastiCache für Redis OSS 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.
