Auto Scaling Scaling-Cluster ElastiCache (Redis OSS) - Amazon ElastiCache (RedisOSS)

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 Scaling-Cluster ElastiCache (Redis OSS)

Voraussetzungen

ElastiCache (Redis OSS) Auto Scaling ist auf Folgendes beschränkt:

  • Redis OSS-Cluster (Clustermodus aktiviert), auf denen die Redis OSS Engine Version 6.0 und höher ausgeführt wird

  • Cluster mit Datenklassierung (Clustermodus aktiviert), auf denen die Redis OSS Engine ab Version 7.0.7 ausgeführt wird

  • Instance-Größen - Large, XLarge, 2xLarge

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

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

Automatisches Kapazitätsmanagement mit ElastiCache (Redis OSS) Auto Scaling

ElastiCache Auto Scaling (Redis OSS) ist die Fähigkeit, die gewünschten Shards oder Replikate in Ihrem ElastiCache (Redis OSS) -Service automatisch zu erhöhen oder zu verringern. ElastiCache (Redis OSS) 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 (Redis OSS) 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 die AWS CLI oder die Application Auto Scaling-API verwenden, um eine Skalierungsrichtlinie anzuwenden, die auf einer vordefinierten oder benutzerdefinierten Metrik basiert.

ElastiCache (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 die auto Skalierung ElastiCache (Redis OSS) 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 (Redis OSS) Auto Scaling fügt Replikate einheitlich auf allen Shards im Cluster hinzu oder entfernt sie.

ElastiCache (Redis OSS) unterstützt die folgenden Arten von Richtlinien für die automatische Skalierung:

Die folgenden Schritte fassen den auto Skalierungsprozess ElastiCache (Redis OSS) zusammen, wie im vorherigen Diagramm dargestellt:

  1. Sie erstellen eine ElastiCache (Redis OSS) Auto Scaling-Richtlinie für Ihre ElastiCache (Redis OSS) Replikationsgruppe.

  2. ElastiCache (Redis OSS) Auto Scaling erstellt in Ihrem Namen zwei 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 die auto Skalierung ElastiCache (Redis OSS) auslöst, um Ihre Skalierungsrichtlinie zu bewerten.

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

  5. ElastiCache (Redis OSS) 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 (Redis OSS) Auto Scaling funktioniert, nehmen wir an, Sie haben einen Cluster mit dem NamenUsersCluster. 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 bestimmen auch einen Zielwert für die CPU-Auslastung für dieUsersCluster-Cluster erstellt. ElastiCache (Redis OSS) 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 (Redis OSS) Auto Scaling ändert Ressourceneinstellungen nur, wenn die tatsächliche Arbeitslast über einen längeren Zeitraum von mehreren Minuten erhöht (oder reduziert) bleibt. Der auto Skalierungs-Tracking-Algorithmus ElastiCache (Redis OSS) versucht, die Zielauslastung langfristig auf oder nahe dem von Ihnen gewählten Wert zu halten.

Für ElastiCache (Redis OSS) Auto Scaling sind IAM-Berechtigungen erforderlich

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

{ "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 Auto Scaling-Dienst ElastiCache (Redis OSS) benötigt außerdem die Erlaubnis, Ihre Cluster und CloudWatch Alarme zu beschreiben, sowie Berechtigungen, Ihre ElastiCache (Redis OSS) Zielkapazität in Ihrem Namen zu ändern. Wenn Sie Auto Scaling für Ihren ElastiCache (Redis OSS) -Cluster aktivieren, wird eine serviceverknüpfte Rolle mit dem Namen erstellt. AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG Diese serviceverknüpfte Rolle gewährt ElastiCache (Redis OSS) 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 (Redis OSS) Auto Scaling. Weitere Informationen finden Sie unter Serviceverknüpfte Rollen für ElastiCache (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 – 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) oder ElastiCacheReplicaEngineCPUUtilization (Replikatdimension)

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

    Wir empfehlen Ihnen, mehrere Richtlinien pro Dimension auf dem Cluster zu vermeiden. ElastiCache (Redis OSS) Auto Scaling skaliert das skalierbare Ziel, wenn Richtlinien zur Zielverfolgung bereit für die horizontale Skalierung sind. Die Skalierung erfolgt jedoch nur, 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 Redis OSS 7.0 oder höher verfügt und Ihre Anwendung Redis OSS-Funktionen 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.