Auswahl der Knotengröße

Die Knotengröße, die Sie für Ihren ElastiCache Cluster auswählen, wirkt sich auf Kosten, Leistung und Fehlertoleranz aus.

Knotengröße (Valkey und Redis OSS)

Informationen zu den Vorteilen von Graviton-Prozessoren finden Sie unter AWS -Graviton-Prozessor.

Die Beantwortung der folgenden Fragen kann Ihnen helfen, den minimalen Knotentyp zu ermitteln, den Sie für Ihre Valkey- oder Redis OSS-Implementierung benötigen:

• Erwarten Sie durchsatzgebundene Workloads mit mehreren Client-Verbindungen?

  Wenn dies der Fall ist und Sie Redis OSS Version 5.0.6 oder höher ausführen, können Sie mit unserer erweiterten I/O-Funktion, die, sofern verfügbarCPUs , für die Entlastung der Client-Verbindungen im Namen der Redis OSS-Engine verwendet wird, einen besseren Durchsatz und eine bessere Latenz erzielen. Wenn Sie Redis OSS Version 7.0.4 oder höher ausführen, erhalten Sie zusätzlich zu erweiterter I/O zusätzliche Beschleunigung durch erweitertes I/O-Multiplexing, bei dem jeder dedizierte Netzwerk-I/O-Thread Befehle von mehreren Clients an die Redis OSS-Engine weiterleitet, wodurch die Fähigkeit von Redis OS genutzt wird, Befehle effizient stapelweise zu verarbeiten. In ElastiCache Redis OSS v7.1 und höher haben wir die erweiterte I/O-Thread-Funktionalität erweitert, um auch die Logik der Präsentationsebene zu handhaben. Mit Presentation Layer meinen wir, dass Enhanced I/O-Threads jetzt nicht nur Client-Eingaben lesen, sondern die Eingabe auch im Redis OSS-Binärbefehlsformat parsen, die dann zur Ausführung an den Haupt-Thread weitergeleitet werden, was zu einer Leistungssteigerung führt. Weitere Informationen finden Sie im Blogbeitrag und auf der Seite mit den unterstützten Versionen.

• Haben Sie Workloads, die regelmäßig auf einen kleinen Prozentsatz ihrer Daten zugreifen?

  Wenn dies der Fall ist und Sie die Redis OSS-Engine Version 6.2 oder höher verwenden, können Sie das Data-Tiering nutzen, indem Sie den Knotentyp r6gd wählen. Bei Verwendung von Daten-Tiering werden zuletzt verwendete Daten auf dem SSD gespeichert. Beim Abruf entsteht eine geringe Latenzzeit, die jedoch durch Kosteneinsparungen ausgeglichen wird. Weitere Informationen finden Sie unter Daten-Tiering ElastiCache.

  Weitere Informationen finden Sie unter Unterstützte Knotentypen.

• Wie viel Gesamtspeicher benötigen Sie für Ihre Daten?

  Um eine allgemeine Schätzung zu erhalten, nehmen Sie die Größe der Objekte, die Sie zwischenspeichern möchten. Multiplizieren Sie diese Größe mit der Anzahl der Objekte, die Sie gleichzeitig im Cache halten wollen. Um eine vernünftige Schätzung der Elementgröße zu erhalten, serialisieren Sie zunächst Ihre Cache-Elemente und zählen dann die Zeichen. Teilen Sie diese Zahl dann durch die Anzahl der Shards in Ihrem Cluster.

  Weitere Informationen finden Sie unter Unterstützte Knotentypen.

• Welche Version von Redis OSS verwenden Sie?

  Bei Redis OSS-Versionen vor 2.8.22 müssen Sie mehr Speicher für Failover, Snapshots, Synchronisation und das Heraufstufen eines Replikats auf den primären Betrieb reservieren. Diese Anforderung besteht, weil ausreichend Speicher für alle Schreibvorgänge während des Prozesses zur Verfügung stehen muss.

  Redis OSS Version 2.8.22 und höher verwenden einen forkless-Speicherprozess, der weniger verfügbaren Speicher benötigt als der vorherige Prozess.

  Weitere Informationen finden Sie hier:

  • So werden Synchronisation und Backup implementiert

  • Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen

• Wie hoch ist der Anteil der Schreibvorgänge Ihrer Anwendung?

  Anwendungen mit vielen Schreibvorgängen können deutlich mehr verfügbaren Speicher, d. h. Speicher, der nicht von Daten belegt wird, beim Erstellen von Snapshots oder beim Failover erfordern. Wenn der BGSAVE-Prozess ausgeführt wird, müssen Sie über genügend Speicher verfügen, der nicht durch Daten belegt ist, um alle Schreibvorgänge, die während des BGSAVE-Prozesses stattfinden, unterzubringen. Beispiele sind die Erstellung eines Snapshots, die Synchronisierung eines primären Clusters mit einem Replikat in einem Cluster und die Aktivierung der Append-Only-Datei-Funktion (AOF). Ein weiteres ist das Heraufstufen eines Replikats zum primären Knoten (wenn Sie Multi-AZ aktiviert haben). Im schlimmsten Fall werden alle Ihre Daten während des Prozesses neu geschrieben. In diesem Fall benötigen Sie eine Knoten-Instance-Größe mit doppelt so viel Speicher wie für die Daten allein benötigt wird.

  Detailliertere Informationen erhalten Sie unter Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen.

• Handelt es sich bei Ihrer Implementierung um einen eigenständigen Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) oder um einen Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) mit mehreren Shards?

  Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert)

  Wenn Sie einen Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) implementieren, muss Ihr Knotentyp in der Lage sein, all Ihre Daten zuzüglich des erforderlichen Overheads aufzunehmen, wie im vorherigen Punkt bullet.

  Nehmen Sie zum Beispiel an, dass die Gesamtgröße aller Ihrer Objekte 12 GB beträgt. In diesem Fall können Sie einen cache.m3.xlarge-Knoten mit 13,3 GB Speicher oder einen cache.r3.large-Knoten mit 13,5 GB Speicher verwenden. Sie benötigen jedoch möglicherweise mehr Speicher für BGSAVE-Operationen. Wenn Ihre Anwendung sehr schreibintensiv ist, sollten Sie den Speicherbedarf auf mindestens 24 GB verdoppeln. Verwenden Sie also entweder eine cache.m3.2xlarge mit 27,9 GB Speicher oder eine cache.r3.xlarge mit 30,5 GB Speicher.

  Valkey oder Redis OSS (Clustermodus aktiviert) mit mehreren Shards

  Wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit mehreren Shards implementieren, muss der Knotentyp Datenbytes aufnehmen können. bytes-for-data-and-overhead / number-of-shards

  Angenommen, Sie schätzen die Gesamtgröße aller Ihrer Objekte auf 12 GB und Sie haben zwei Shards. In diesem Fall können Sie einen cache.m3.large-Knoten mit 6,05 GB Speicher (12 GB / 2) verwenden. Sie benötigen jedoch möglicherweise mehr Speicher für BGSAVE-Operationen. Wenn Ihre Anwendung schreibintensiv ist, verdoppeln Sie die Speicheranforderungen auf mindestens 12 GB pro Shard. Verwenden Sie also entweder eine cache.m3.xlarge mit 13,3 GB Speicher oder eine cache.r3.large mit 13,5 GB Speicher.

• Verwenden Sie Local Zones?

  Local Zones ermöglichen es Ihnen, Ressourcen wie einen ElastiCache Cluster an mehreren Standorten in der Nähe Ihrer Benutzer zu platzieren. Bei der Auswahl der Knotengröße sollten Sie jedoch beachten, dass die verfügbaren Knotengrößen unabhängig von den Kapazitätsanforderungen derzeit auf die folgenden beschränkt sind:

  • Aktuelle Generation:

    M5-Knotentypen: cache.m5.large, cache.m5.xlarge, cache.m5.2xlarge, cache.m5.4xlarge, cache.m5.12xlarge, cache.m5.24xlarge

    R5-Knotentypen: cache.r5.large, cache.r5.xlarge, cache.r5.2xlarge, cache.r5.4xlarge, cache.r5.12xlarge, cache.r5.24xlarge

    T3-Knotentypen: cache.t3.micro, cache.t3.small, cache.t3.medium

Während Ihr Cluster läuft, können Sie die Messwerte für Speicherverbrauch, Prozessorauslastung, Cache-Treffer und Cache-Fehlschläge überwachen, die veröffentlicht werden CloudWatch. Sie werden vielleicht feststellen, dass Ihr Cluster nicht die gewünschte Trefferquote hat oder dass die Schlüssel zu oft entfernt werden. Sie können in diesen Fällen eine andere Knotengröße mit größeren CPU- und Speicherspezifikationen wählen.

Denken Sie bei der Überwachung der CPU-Auslastung daran, dass Valkey und Redis OSS Single-Threading verwenden. Multiplizieren Sie also die gemeldete CPU-Nutzung mit der Anzahl der CPU-Kerne, um die tatsächliche Nutzung zu erhalten. Beispielsweise ist eine Vierkern-CPU, die eine Nutzungsrate von 20 Prozent meldet, tatsächlich die Einkern-CPU von Redis, die mit einer Auslastung von 80 Prozent läuft.

Knotengröße (Memcached)

Memcached-Cluster enthalten gegebenenfalls mehrere Knoten mit über die Knoten partitionierten Cluster-Daten. Aus diesem Grund sind die Speicheranforderungen des Clusters und die eines Knotens zwar ähnlich, jedoch nicht identisch. Sie können Ihre erforderliche Cluster-Speicherkapazität mit wenigen großen Knoten oder mit vielen kleineren Knoten abdecken. Mit wechselnden Anforderungen können Sie Knoten zum Cluster hinzufügen oder aus diesem entfernen und zahlen so nur für die Knoten, die Sie tatsächlich brauchen.

Die Gesamtspeicherkapazität des Clusters wird durch Multiplizieren der Anzahl von Knoten im Cluster mit der RAM-Kapazität der einzelnen Knoten (nach Abzug der für die Systemverwaltung erforderlichen Kapazität) berechnet. Die Kapazität jedes Knotens basiert auf dem Knotentyp.

cluster_capacity = number_of_nodes * (node_capacity - system_overhead)

Die Anzahl von Knoten im Cluster ist ein Schlüsselfaktor für die Verfügbarkeit Ihres Clusters, der Memcached ausführt. Der Ausfall eines einzelnen Knotens kann Auswirkungen auf die Verfügbarkeit Ihrer Anwendung und die Belastung Ihrer Backend-Datenbank haben. Stellt in einem solchen Fall einen Ersatz ElastiCache für einen ausgefallenen Knoten bereit und dieser wird erneut aufgefüllt. Um diese Auswirkungen auf die Verfügbarkeit zu verringern, sollten Sie die Speicher- und Rechenkapazität auf mehrere Knoten mit geringerer Kapazität verteilen, anstatt weniger Knoten mit hoher Kapazität zu verwenden.

In einem Szenario, in dem Sie 35 GB Cache-Speicher haben möchten, können Sie eine der folgenden Konfigurationen einrichten:

• 11 cache.t2.medium-Knoten mit 3,22 GB Speicher und jeweils 2 Threads = 35,42 GB und 22 Threads.

• 6 cache.m4.large-Knoten mit 6,42 GB Speicher und jeweils 2 Threads = 38,52 GB und 12 Threads.

• 3 cache.r4.large-Knoten mit 12,3 GB Speicher und jeweils 2 Threads = 36,90 GB und 6 Threads.

• 3 cache.m4.xlarge-Knoten mit 14,28 GB Speicher und jeweils 4 Threads = 42,84 GB und 12 Threads.

Vergleichen der Knotenoptionen

Knotentyp	Speicher (in GiB)	Kerne	Kosten pro Stunde*	Erforderliche Knoten	Gesamtspeicher (in GiB)	Kerne gesamt	Monatlicher Preis
cache.t2.medium	3.22	2	0,068 USD	11	35,42	22	538,56 USD
cache.m4.large	6,42	2	0,156 USD	6	38,52	12	673,92 USD
cache.m4.xlarge	14,28	4	0,311 USD	3	42,84	12	671,76 USD
cache.m5.xlarge	12,93	4	0,311 USD	3	38,81	12	671,76 USD
cache.m6g.large	6,85	2	$0,147	6	41,1	12	$635
cache.r4.large	12.3	2	0,228 USD	3	36,9	6	492,48 USD
cache.r5.large	13,07	2	0,216 USD	3	39,22	6	466,56 USD
cache.r6g.large	13,07	2	$0,205	3	42,12	6	$442
* Preis pro Stunde und Knoten ab 08. Oktober 2020.
† Kosten pro Monat bei 100 %-iger Auslastung für 30 Tage (720 Stunden).

Diese Optionen bieten jeweils ähnliche Speicherkapazität bei unterschiedlicher Rechenkapazität und Kosten. Um die Kosten Ihrer spezifischen Optionen zu vergleichen, sehen Sie sich die ElastiCache Amazon-Preise an.

Für Cluster, die Memcached ausführen, wird ein Teil des verfügbaren Speichers auf jedem Knoten für den Verbindungs-Overhead verwendet. Weitere Informationen finden Sie unter Overhead von Memcached-Verbindungen.

Bei der Verwendung mehrerer Knotenpunkte müssen die Schlüssel auf diese verteilt werden. Jeder Knoten besitzt einen eigenen Endpunkt. Für eine einfache Endpunktverwaltung können Sie ElastiCache die Auto Discovery-Funktion verwenden, mit der Client-Programme automatisch alle Knoten in einem Cluster identifizieren können. Weitere Informationen finden Sie unter Identifizieren Sie automatisch Knoten in Ihrem Cluster (Memcached).

In manchen Fällen sind Sie vielleicht unsicher, wie viel Kapazität Sie benötigen. Wenn das so ist, empfehlen wir, zu Testzwecken mit einem cache.m5.large-Knoten zu beginnen. Überwachen Sie dann die Speicherauslastung, die CPU-Auslastung und die Cache-Trefferquote anhand der auf Amazon veröffentlichten ElastiCache Metriken CloudWatch. Weitere Informationen zu CloudWatch Metriken für ElastiCache finden Sie unterÜberwachung der Nutzung mit CloudWatch Metrics. Für die Produktion und größere Workloads bieten R5-Knoten die beste Leistung und einen optimalen RAM-Einstandswert.

Wenn Ihr Cluster nicht die gewünschte Trefferquote aufweist, können Sie einfach weitere Knoten hinzufügen, um den gesamten verfügbaren Speicher in Ihrem Cluster zu erhöhen.

Wenn Ihr Cluster durch die CPU begrenzt ist, aber eine ausreichende Trefferquote aufweist, richten Sie einen neuen Cluster mit einem Knotentyp ein, der mehr Rechenleistung bietet.