Auswahl der Knotengröße - 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.

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 OSS Redis)

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-Implementierung benötigen: OSS

  • Erwarten Sie durchsatzgebundene Workloads mit mehreren Client-Verbindungen?

    Wenn dies der Fall ist und Sie Redis OSS Version 5.0.6 oder höher verwenden, können Sie mit unserer erweiterten I/O-Funktion, die, sofern verfügbar, für die Entlastung der Client-Verbindungen im Namen der Redis-Engine CPUs verwendet wird, einen besseren Durchsatz und eine bessere Latenz erzielen. OSS Wenn Sie Redis OSS Version 7.0.4 oder höher verwenden, erhalten Sie zusätzlich zur erweiterten I/O zusätzliche Beschleunigung durch erweitertes I/O-Multiplexing, bei dem jeder dedizierte Netzwerk-I/O-Thread Befehle von mehreren Clients an die OSS Redis-Engine weiterleitet und so die Fähigkeit von Redis OSS nutzt, Befehle effizient stapelweise zu verarbeiten. In ElastiCache (RedisOSS) 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 Darstellungsschicht meinen wir, dass erweiterte I/O-Threads jetzt nicht nur die Client-Eingaben lesen, sondern die Eingabe auch im OSS Redis-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 OSS Redis-Engine Version 6.2 oder höher verwenden, können Sie das Data-Tiering nutzen, indem Sie den Knotentyp r6gd wählen. Beim Data-Tiering werden Daten, die zuletzt verwendet wurden, in gespeichert. SSD 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 OSS Redis verwenden Sie?

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

    OSSRedis-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:

  • 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 hierfür sind das Erstellen eines Snapshots, das Synchronisieren eines primären Clusters mit einem Replikat in einem Cluster und das Aktivieren der Funktion „Nur Datei anhängen“ (). 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 Speicherplatz verfügen, um einen Valkey- oder OSS Redis-Snapshot zu erstellen.

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

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

    Wenn Sie einen Valkey- oder Redis-Cluster OSS (Cluster-Modus deaktiviert) implementieren, muss Ihr Knotentyp in der Lage sein, all Ihre Daten sowie den erforderlichen Overhead 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 (Cluster-Modus aktiviert) mit mehreren Shards

    Wenn Sie einen Valkey- oder Redis-Cluster OSS (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. In diesen Fällen können Sie eine andere Knotengröße mit größeren CPU und Speicherspezifikationen wählen.

Denken Sie bei der Überwachung der CPU Nutzung 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 ermitteln. Beispielsweise ist ein Vierkernprozessor, der eine Nutzungsrate von 20 Prozent CPU meldet, tatsächlich der Einkernprozessor, der bei einer Auslastung von 80 Prozent OSS 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 Ihres Clusters wird berechnet, indem die Anzahl der Knoten im Cluster mit der RAM Kapazität jedes Knotens nach Abzug des System-Overheads multipliziert wird. 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 wieder 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. Informationen zum Vergleich der Kosten Ihrer spezifischen Optionen finden Sie unter ElastiCache Amazon-Preise.

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 Speichernutzung, CPU Auslastung und 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 die R5-Knoten die beste Leistung und das beste RAM Preis-Leistungs-Verhältnis.

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 gebunden ist, CPU aber eine ausreichende Trefferquote aufweist, richten Sie einen neuen Cluster mit einem Knotentyp ein, der mehr Rechenleistung bietet.