View a markdown version of this page

Auswahl der Knotengröße - Amazon ElastiCache
Knotengröße (Valkey und Redis OSS)Knotengröße (Memcached)

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 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 Valkey oder Redis OSS Version 5.0.6 bis 7.1 verwenden, können Sie mit der erweiterten Funktion einen besseren Durchsatz und eine bessere Latenz erzielen. I/O Verfügbare CPUs entlasten die Engine von den Client-Verbindungen. Wenn Sie Valkey oder Redis OSS Version 7.0.4 bis 7.1 verwenden, erhalten Sie zusätzlich zu Enhanced zusätzliche Beschleunigung durch verbessertes I/O Multiplexing I/O, bei dem jeder dedizierte I/O Netzwerk-Thread Befehle von mehreren Clients an die Engine weiterleitet und dabei deren Fähigkeit nutzt, Befehle stapelweise effizient zu verarbeiten. Ab Redis OSS v7.1 und Valkey 7.2 übernimmt die erweiterte Threads-Funktionalität auch die Logik der Präsentationsebene. ElastiCache I/O Das bedeutet, dass erweiterte I/O Threads nicht nur Client-Eingaben lesen, sondern die Eingabe auch in das binäre Befehlsformat der Engine analysieren, das dann zur Ausführung an den Haupt-Thread weitergeleitet wird, 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 Daten-Tiering nutzen, indem Sie den R6gd-Knotentyp 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.

  • Valkey und Redis OSS verwenden einen forklesslosen Speichervorgang für Failover, Snapshots, Synchronisieren und Heraufstufen eines Replikats in den Primärbetrieb. Für diesen Vorgang ist weniger Arbeitsspeicher erforderlich, da Schreibvorgänge verwaltet werden, ohne dass der Prozess unterbrochen wird.

    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 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). Eine andere Möglichkeit besteht darin, ein Replikat auf ein primäres Replikat heraufzustufen (sofern Sie Multi-AZ es 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 Speicher 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 (Clustermodus deaktiviert) oder um einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit mehreren Shards?

    Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert)

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

    Nehmen Sie zum Beispiel an, dass die Gesamtgröße aller Ihrer Objekte 12 GB beträgt. In diesem Fall können Sie einen cache.m5.xlarge Knoten mit 12,93 GB Arbeitsspeicher oder einen cache.r5.large Knoten mit 13,07 GB Arbeitsspeicher 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 a cache.m5.2xlarge mit 26,04 GB Speicher oder a cache.r5.xlarge mit 26,32 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 in der Lage sein, Datenbytes aufzunehmen. 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.m5.large Knoten mit 6,38 GB Arbeitsspeicher (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 a cache.m5.xlarge mit 12,93 GB Speicher oder a cache.r5.large mit 13,07 GB Speicher.

  • Verwenden Sie Local Zones?

    Lokale Zonen 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 ausgeführt wird, können Sie die Messwerte für Speichernutzung, Prozessorauslastung, Cache-Treffer und Cache-Fehlschläge überwachen, die unter 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, in Wirklichkeit die Ein-Core-Redis OSS, 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. In einem solchen Fall wird ein Ersatz ElastiCache für einen ausgefallenen Knoten bereitgestellt 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. 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 Speicherauslastung, die CPU-Auslastung und die Cache-Trefferquote ElastiCache anhand der bei Amazon veröffentlichten 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.