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 OSS Engine Version 6.0 oder höher ausgeführt wird

  • Cluster mit Datenklassierung (Clustermodus aktiviert), auf denen Valkey 7.2 oder Redis Engine ab Version 7.0.7 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 mit Valkey oder Redis wird OSS die Skalierung für die folgenden Dimensionen unterstützt:

  • 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.

  • Replicas— Automatisches Hinzufügen/Entfernen von Replikaten im Cluster ähnlich wie bei manuellen Erhöhen/Verringern von Replikaten. ElastiCache mit Valkey oder Redis OSS Auto Scaling werden Replikate einheitlich für alle Shards im Cluster hinzugefügt/entfernt.

ElastiCache mit Valkey oder Redis werden die folgenden Arten von Richtlinien für die automatische Skalierung unterstütztOSS:

Bild der auto Skalierung für ElastiCache mit Valkey oder Redis OSS

Die folgenden Schritte fassen den OSS auto Skalierungsprozess ElastiCache mit Valkey oder Redis zusammen, wie im vorherigen Diagramm dargestellt:

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

  2. ElastiCache Die auto Skalierung mit Valkey oder Redis OSS 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 zur Bewertung Ihrer Skalierungsrichtlinie auslöst.

  4. ElastiCache Bei Valkey oder Redis gibt OSS Auto Scaling eine Modifizierungsanforderung aus, um Ihre Clusterkapazität anzupassen.

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

Um zu verstehen, wie OSS Auto Scaling ElastiCache mit Valkey oder Redis funktioniert, nehmen wir an, Sie haben einen Cluster mit dem Namen. UsersCluster Indem Sie die CloudWatch Metriken überwachenUsersCluster, bestimmen Sie die maximale Anzahl an Shards, die der Cluster benötigt, wenn der Verkehr seinen Höhepunkt erreicht hat, und die Mindestanzahl an Shards, wenn der Verkehr am niedrigsten Punkt ist. 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 mit Valkey oder Redis ändert OSS Auto Scaling 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 mit Valkey oder Redis wird OSS Auto Scaling durch eine Kombination aus ElastiCache CloudWatch, und Application Auto Scaling ermöglicht. APIs Cluster werden mit ElastiCache (RedisOSS) erstellt und aktualisiert, Alarme werden mit CloudWatch Application Auto Scaling 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 with Valkey oder 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 für ElastiCache (RedisOSS) 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 Mit Valkey oder Redis skaliert OSS Auto Scaling das skalierbare Ziel, wenn Richtlinien für die Zielverfolgung bereit sind, aber es wird nur dann skaliert, wenn alle Zielverfolgungsrichtlinien (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. Deaktivieren von Abskalierungen – Die automatische Skalierung mit Target Tracking eignet sich am besten für Cluster mit allmählicher Zunahme/Abnahme des Workloads, da Spitzen/Einbrüche in den Metriken aufeinanderfolgende Schwankungen bei Auf-/Abskalierungen auslösen können. 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 Ihrer Anwendung – Wir empfehlen Ihnen, Ihre Anwendung mit Ihren geschätzten minimalen und maximalen Workloads zu testen, um die absoluten minimalen und maximalen Shards/Replikate zu ermitteln, die für den Cluster erforderlich sind, während Sie Skalierungsrichtlinien 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 nicht erforderlich, aufgrund von Workload Spike/Dip auf ein paar Hot-Shards/Repliken.

    • 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.

    • Manuelles Erhöhen/Verringern von Shards/Replikaten über die bei der Richtlinienerstellung konfigurierte Mindest- und Maximalkapazität.