Dimensionieren Ihres DAX-Clusters - Amazon-DynamoDB

Dimensionieren Ihres DAX-Clusters

Die Gesamtkapazität und Verfügbarkeit eines DAX-Clusters hängt vom Knotentyp und der Anzahl der Knoten ab. Mehr Knoten im Cluster erhöhen die Lesekapazität, nicht jedoch die Schreibkapazität. Größere Knotentypen (bis zu r5.8xlarge) können mehr Schreibvorgänge verarbeiten, aber zu wenige Knoten können die Verfügbarkeit beeinträchtigen, wenn ein Knoten ausfällt. Weitere Informationen zur Dimensionierung Ihres DAX-Clusters finden Sie im DAX-Clustergrößenleitfaden.

In den folgenden Abschnitten werden die verschiedenen Dimensionierungsaspekte erörtert, die Sie berücksichtigen sollten, um ein ausgewogenes Verhältnis zwischen Knotentyp und Knotenanzahl herzustellen und so einen skalierbaren und kostengünstigen Cluster zu erstellen.

Planen der Verfügbarkeit

Bei der Dimensionierung eines DAX-Clusters sollten Sie sich zunächst auf dessen angestrebte Verfügbarkeit konzentrieren. Die Verfügbarkeit eines geclusterten Service wie DAX ist eine Dimension der Gesamtzahl der Knoten im Cluster. Da ein Cluster mit einem Knoten keine Fehlertoleranz hat, entspricht seine Verfügbarkeit der eines Knotens. In einem Cluster mit 10 Knoten hat der Verlust eines einzelnen Knotens nur minimale Auswirkungen auf die Gesamtkapazität des Clusters. Dieser Verlust hat keine direkten Auswirkungen auf die Verfügbarkeit, da die verbleibenden Knoten weiterhin Leseanforderungen erfüllen können. Um Schreibvorgänge wieder aufzunehmen, nominiert DAX schnell einen neuen Primärknoten.

DAX ist VPC-basiert. Es verwendet eine Subnetzgruppe, um zu bestimmen, in welchen Availability Zones Knoten ausgeführt werden können und welche IP-Adressen aus den Subnetzen verwendet werden sollen. Für Produktions-Workloads empfehlen wir dringend, DAX mit mindestens drei Knoten in verschiedenen Availability Zones zu verwenden. Dadurch wird sichergestellt, dass dem Cluster mehr als ein Knoten zur Bearbeitung von Anforderungen zur Verfügung steht, selbst wenn ein einzelner Knoten oder eine Availability Zone ausfällt. Ein Cluster kann bis zu 11 Knoten haben, wobei einer ein Primärknoten und 10 Lesereplikate sind.

Planen des Schreibdurchsatzes

Alle DAX-Cluster verfügen über einen Primärknoten für Write-Through-Anforderungen. Die Größe des Knotentyps für den Cluster bestimmt dessen Schreibkapazität. Durch das Hinzufügen zusätzlicher Lesereplikate wird die Schreibkapazität des Clusters nicht erhöht. Daher sollten Sie die Schreibkapazität bei der Cluster-Erstellung berücksichtigen, da Sie den Knotentyp später nicht ändern können.

Wenn Ihre Anwendung einen Write-Through-Vorgang in DAX durchführen muss, um den Element-Cache zu aktualisieren, sollten Sie eine verstärkte Nutzung von Cluster-Ressourcen in Betracht ziehen, um das Schreiben zu erleichtern. Schreibvorgänge in DAX verbrauchen etwa 25-mal mehr Ressourcen als Cache-Trefferlesevorgänge. Dies erfordert möglicherweise einen größeren Knotentyp als für schreibgeschützte Cluster.

Weitere Hinweise zur Bestimmung, ob Write-Through oder Write-Around für Ihre Anwendung am besten geeignet ist, finden Sie unter Strategien für Schreibvorgänge.

Planen des Lesedurchsatzes

Die Lesekapazität eines DAX-Clusters hängt von der Cache-Trefferrate Ihres Workloads ab. Da DAX Daten aus DynamoDB liest, wenn ein Cache-Fehler auftritt, verbraucht es ungefähr zehnmal mehr Cluster-Ressourcen als ein Cache-Treffer. Um die Anzahl der Cache-Treffer zu erhöhen, erhöhen Sie die TTL-Einstellung des Caches, um den Zeitraum zu definieren, für den ein Element im Cache gespeichert wird. Eine höhere TTL-Dauer erhöht jedoch die Wahrscheinlichkeit, dass ältere Elementversionen gelesen werden, sofern Aktualisierungen nicht über DAX geschrieben werden.

Um sicherzustellen, dass der Cluster über ausreichende Lesekapazität verfügt, skalieren Sie den Cluster horizontal, wie unter Horizontale Skalierung eines Clusters beschrieben. Durch das Hinzufügen weiterer Knoten werden Lesereplikate zum Ressourcenpool hinzugefügt, während das Entfernen von Knoten die Lesekapazität reduziert. Wenn Sie die Anzahl der Knoten und deren Größe für einen Cluster auswählen, sollten Sie sowohl die minimale als auch die maximale benötigte Lesekapazität berücksichtigen. Wenn Sie einen Cluster mit kleineren Knotentypen nicht horizontal skalieren können, um Ihre Leseanforderungen zu erfüllen, verwenden Sie einen größeren Knotentyp.

Planen der Datensatzgröße

Jeder verfügbare Knotentyp hat eine festgelegte Speichergröße für DAX, um Daten zwischenzuspeichern. Wenn ein Knotentyp zu klein ist, passt der Arbeitsdatensatz, den eine Anwendung anfordert, nicht in den Speicher, was zu Cache-Fehlern führt. Da größere Knoten größere Caches unterstützen, sollten Sie einen Knotentyp verwenden, der größer ist als der geschätzte Datensatz, den Sie zwischenspeichern müssen. Ein größerer Cache verbessert auch die Cache-Trefferrate.

Sie erhalten möglicherweise abnehmende Ergebnisse, wenn Sie Elemente mit wenigen wiederholten Lesevorgängen zwischenspeichern. Berechnen Sie die Speichergröße für Elemente, auf die häufig zugegriffen wird, und stellen Sie sicher, dass der Cache groß genug ist, um diesen Datensatz zu speichern.

Berechnen der ungefähren Cluster-Kapazitätsanforderungen

Sie können den Gesamtkapazitätsbedarf Ihres Workloads abschätzen, um Ihnen bei der Auswahl der geeigneten Größe und Anzahl der Clusterknoten zu helfen. Für diese Schätzung berechnen Sie die Variable für die normalisierte Anforderung pro Sekunde (Normalized RPS). Diese Variable stellt die Gesamtzahl der Arbeitseinheiten dar, die der DAX-Cluster für Ihre Anwendung unterstützen muss, einschließlich Cache-Treffer, Cache-Fehler und Schreibvorgänge. Verwenden Sie die folgenden Eingaben, um die Variable Normalized RPS zu berechnen:

  • ReadRPS_CacheHit – Gibt die Anzahl der Lesevorgänge pro Sekunde an, die zu einem Cache-Treffer führen.

  • ReadRPS_CacheMiss – Gibt die Anzahl der Lesevorgänge pro Sekunde an, die zu einem Cache-Fehler führen.

  • WriteRPS – Gibt die Anzahl der Schreibvorgänge pro Sekunde an, die DAX durchlaufen.

  • DaxNodeCount – Gibt die Anzahl der Knoten im DAX-Cluster an.

  • Size – Gibt die Größe des zu schreibenden oder lesenden Elements in KB an, aufgerundet auf das nächste KB.

  • 10x_ReadMissFactor – Stellt einen Wert von 10 dar. Wenn ein Cache-Fehler auftritt, verwendet DAX ungefähr zehnmal mehr Ressourcen als bei Cache-Treffern.

  • 25x_WriteFactor – Stellt einen Wert von 25 dar, da ein DAX-Write-Through etwa 25-mal mehr Ressourcen verbraucht als Cache-Treffer.

Anhand der folgenden Formel können Sie die Variable Normalized RPS berechnen.

Normalized RPS = (ReadRPS_CacheHit * Size) + (ReadRPS_CacheMiss * Size * 10x_ReadMissFactor) + (WriteRequestRate * 25x_WriteFactor * Size * DaxNodeCount)

Betrachten wir beispielsweise folgende Eingabewerte:

  • ReadRPS_CacheHit = 50 000

  • ReadRPS_CacheMiss = 1 000

  • ReadMissFactor = 1

  • Size = 2 KB

  • WriteRPS = 100

  • WriteFactor = 1

  • DaxNodeCount = 3

Wenn Sie diese Werte in die Formel einsetzen, können Sie die Variable Normalized RPS wie folgt berechnen.

Normalized RPS = (50,000 Cache Hits/Sec * 2KB) + (1,000 Cache Misses/Sec * 2KB * 10) + (100 Writes/Sec * 25 * 2KB * 3)

In diesem Beispiel beträgt der berechnete Wert für Normalized RPS 135 000. Dieser Normalized RPS-Wert berücksichtigt jedoch nicht die Tatsache, dass die Cluster-Auslastung unter 100 % bleibt oder dass Knoten verloren gehen. Wir empfehlen, zusätzliche Kapazität zu berücksichtigen. Ermitteln Sie dazu den größeren von zwei Multiplikationsfaktoren: Zielauslastung oder Knotenverlusttoleranz. Multiplizieren Sie dann den Normalized RPS-Wert mit dem größeren Faktor, um eine Zielanforderung pro Sekunde (Target RPS) zu erhalten.

  • Zielauslastung

    Da Leistungseinbußen die Anzahl der Cache-Fehler erhöhen, empfehlen wir, den DAX-Cluster nicht mit einer Auslastung von 100 % auszuführen. Idealerweise sollten Sie die Cluster-Auslastung bei oder unter 70 % halten. Um dies zu erreichen, multiplizieren Sie den Normalized RPS-Wert mit 1,43.

  • Toleranz gegenüber Knotenverlusten

    Wenn ein Knoten ausfällt, muss Ihre Anwendung in der Lage sein, ihre Anforderungen auf die verbleibenden Knoten zu verteilen. Um sicherzustellen, dass die Knoten unter einer Auslastung von 100 % bleiben, wählen Sie einen Knotentyp aus, der groß genug ist, um zusätzlichen Datenverkehr aufzunehmen, bis der ausgefallene Knoten wieder online ist. Bei einem Cluster mit weniger Knoten muss jeder Knoten einen größeren Anstieg des Datenverkehrs tolerieren, wenn ein Knoten ausfällt.

    Beim Ausfall eines Primärknotens, führt DAX automatisch einen Failover auf ein Lesereplikat durch und bestimmt dieses zum neuen Primärknoten. Wenn ein Replikatknoten ausfällt, können andere Nodes im DAX-Cluster nach wie vor Anforderungen verarbeiten, bis der ausgefallene Knoten wiederhergestellt ist.

    Beispielsweise erfordert ein DAX-Cluster mit 3 Knoten und einem Knotenausfall zusätzliche Kapazität von 50 % auf den verbleibenden zwei Knoten. Dafür ist ein Multiplikationsfaktor von 1,5 erforderlich. Umgekehrt erfordert ein Cluster mit 11 Knoten und einem ausgefallenen Knoten zusätzliche Kapazität von 10 % auf den verbleibenden Knoten oder einen Multiplikationsfaktor von 1,1.

Anhand der folgenden Formel können Sie die Variable Target RPS berechnen.

Target RPS = Normalized RPS * CEILING(TargetUtilization, NodeLossTolerance)

Gehen Sie als Beispiel von den folgenden Werten für die Berechnung von Target RPS aus:

  • Normalized RPS= 135 000

  • TargetUtilization= 1,43

    Da wir eine maximale Cluster-Auslastung von 70 % anstreben, setzen wir TargetUtilization auf 1,43.

  • NodeLossTolerance = 1,5

    Nehmen wir an, wir verwenden einen Cluster mit 3 Knoten und legen daher NodeLossTolerance auf eine Kapazität von 50 % fest.

Wenn Sie diese Werte in die Formel einsetzen, können Sie die Variable Target RPS wie folgt berechnen.

Target RPS = 135,000 * CEILING(1.43, 1.5)

Da in diesem Beispiel der Wert von NodeLossTolerance größer als TargetUtilization ist, berechnen wir den Wert von Target RPS mit NodeLossTolerance. Dies ergibt einen Target RPS-Wert von 202 500, was der Gesamtkapazität entspricht, die der DAX-Cluster unterstützen muss. Um die Anzahl der Knoten zu ermitteln, die Sie in einem Cluster benötigen, ordnen Sie den Target RPS-Wert einer entsprechenden Spalte in der folgenden Tabelle zu. Für dieses Beispiel eines Target RPS-Werts von 202 500 benötigen Sie den Knotentyp dax.r5.large mit drei Knoten.

Ungefähre Cluster-Durchsatzkapazität nach Knotentyp

Mit der Target RPS formula können Sie die Cluster-Kapazität für verschiedene Knotentypen schätzen. Die folgende Tabelle zeigt ungefähre Kapazitäten für Cluster mit 1, 3, 5 und 11 Knotentypen. Diese Kapazitäten ersetzen nicht die Notwendigkeit, Lasttests für DAX mit Ihren eigenen Daten und Anforderungsmustern durchzuführen. Darüber hinaus beinhalten diese Kapazitäten keine Instances vom Typ T, da diese nicht über eine feste CPU-Kapazität verfügen. Die Einheit für alle Werte in der folgenden Tabelle ist Normalized RPS.

Knotentyp (Speicher) 1 Knoten 3 Knoten 5 Knoten 11 Knoten
dax.r5.24xlarge (768 GB) 1 Mio. 3 Mio. 5 Mio. 11 Mio.
dax.r5.16xlarge (512 GB) 1 Mio. 3 Mio. 5 Mio. 11 Mio.
dax.r5.12xlarge (384 GB) 1 Mio. 3 Mio. 5 Mio. 11 Mio.
dax.r5.8xlarge (256 GB) 1 Mio. 3 Mio. 5 Mio. 11 Mio.
dax.r5.4xlarge (128 GB) 600 000 1,8 Mio. 3 Mio. 6,6 Mio.
dax.r5.2xlarge (64 GB) 300 000 900 000 1,5 Mio. 3,3 Mio.
dax.r5.xlarge (32 GB) 150 000 450 000 750 000 1,65 Mio.
dax.r5.xlarge (16 GB) 75 000 225 000 375 000 825 000

Aufgrund der Höchstgrenze von 1 Million NPS (Netzwerkoperationen pro Sekunde) für jeden Knoten tragen Knoten des Typs dax.r5.8xlarge oder größer nicht zur zusätzlichen Cluster-Kapazität bei. Knotentypen, die größer als 8xlarge sind, tragen möglicherweise nicht zur Gesamtdurchsatzkapazität des Clusters bei. Solche Knotentypen können jedoch hilfreich sein, um einen größeren Arbeitsdatensatz im Speicher zu speichern.

Skalieren der Schreibkapazität in DAX-Clustern

Jeder Schreibvorgang in DAX verbraucht 25 normalisierte Anforderungen auf jedem Knoten. Da es für jeden Knoten ein Limit von 1 Million RPS gibt, ist ein DAX-Cluster auf 40 000 Schreibvorgänge pro Sekunde begrenzt, wobei die Lesenutzung nicht berücksichtigt wird.

Wenn Ihr Anwendungsfall mehr als 40 000 Schreibvorgänge pro Sekunde im Cache erfordert, müssen Sie separate DAX-Cluster verwenden und die Schreibvorgänge als Shard auf diese verteilen. Ähnlich wie bei DynamoDB können Sie den Partitionsschlüssel für die Daten, die Sie in den Cache schreiben, hashen. Verwenden Sie dann den Modulo, um zu bestimmen, auf welchen Shard die Daten geschrieben werden sollen.

Im folgenden Beispiel wird der Hash einer Eingabezeichenfolge berechnet. Anschließend wird der Modulo des Hashwerts mit 10 berechnet.

def hash_modulo(input_string): # Compute the hash of the input string hash_value = hash(input_string) # Compute the modulus of the hash value with 10 bucket_number = hash_value % 10 return bucket_number #Example usage if _name_ == "_main_": input_string = input("Enter a string: ") result = hash_modulo(input_string) print(f"The hash modulo 10 of '{input_string}' is: {result}.")