Einheit 5.5: In-Memory-Datenbank (Cache-Tier)

Einführung

Einheit 5.3 hat eine harte Plattformgrenze festgelegt: Managed PostgreSQL und MariaDB auf IONOS haben keine Lese-Replikate, keine gemanagte Replikation zu einer zweiten Cluster und keine Replikation zwischen Regionen. Die synchronen und asynchronen Replikate innerhalb einer Cluster dienen dem Failover und nicht dem Servieren von Leseverkehr. Das hinterlässt eine offensichtliche Frage für jede leseintensive Workload: Woher kommt die Skalierbarkeit für Lesevorgänge? Die Antwort findet sich in dieser Einheit. Die In-Memory DB-Cacheschicht absorbiert die Lesebelastung, die ein relationales Lese-Replikat getragen hätte, und schließt damit die Lücke ohne Lese-Replikat mit einem nativen Muster anstelle einer fehlenden Funktion.

Die gleiche Schicht erfüllt eine zweite Aufgabe, die ebenso wichtig ist. Einheit 4.3 hat gezeigt, dass VM Auto Scaling nur Zustandslose-Replikate sicher hinzufügen und entfernen kann. Jede Sitzung, Sperre oder vorübergehende Zustand, die im Arbeitsspeicher eines Compute-Node lebt, geht verloren, sobald dieser Node skaliert wird. Die Externalisierung dieses Zustands in eine gemeinsame In-Memory-Schicht ist es, was die Anwendungsschicht tatsächlich zustandslos macht und somit das Auto-Scaling sicher macht. Diese Einheit endet mit dem Aufbau der Cluster in der Data Center Designer und verbindet sie im privaten Netzwerk vor der relationalen Schicht.

1. Die Read-Scaling- und State-Externalisierungsebene

In-Memory DB wird über IONOS DBaaS als gemanagte, Redis-OSS-kompatible Key-Value-Speicherlösung angeboten, die an die Legacy-Redis-OSS-Stable-Version 7.2 gekoppelt ist. Es handelt sich um einen Datenstruktur-Server und nicht nur um einen flachen Cache: Er speichert Zeichenfolgen, Hashes, Listen, Sets, sortierte Sets, Bitmaps, Hyperloglogs, geospatialen Indexe und Streams. Diese Breite ermöglicht es einer Ebene, zwei architektonische Rollen auf einmal zu übernehmen.

Warum es sich um eine Alternative für Read-Replikate handelt. Ein relationales Read-Replikat skaliert Lesevorgänge, indem es das Dataset auf einen anderen Node dupliziert, der SELECT-Anfragen beantwortet; IONOS DBaaS bietet dies nicht. Stattdessen liest die Anwendung durch einen Cache: Die erste Anfrage für einen Wert verfehlt und trifft PostgreSQL oder MariaDB, das Ergebnis wird in In-Memory DB geschrieben, und jede nachfolgende Anfrage wird aus dem Arbeitsspeicher mit einer Latenz von unter einer Millisekunde bedient, ohne die Datenbank zu berühren. Durch die Nutzung des Caches werden Datenbankabfragen minimiert, was den Datenverkehr und die benötigten Ressourcen erheblich reduziert und ermöglicht eine schnelle und kosteneffiziente Skalierungsebene. Die relationale Primärinstanz bleibt klein, da sie nur Lesevorgänge und Schreibvorgänge sieht, während die Leseleistung mit dem Cache-Arbeitsspeicher und nicht mit den Datenbankkernen skaliert. Dies ist die in Einheit 2.4 als cache-basierte Skalierung gekennzeichnete Designentscheidung: Sie kaufen RAM in der Cache-Ebene anstelle einer vertikalen Skalierung der Datenbank.

Warum es die Voraussetzung für die automatische Skalierung ist. Wenn die Anwendungsebene den Sitzungszustand im lokalen Prozessspeicher hält, werden bei jedem Skalierungsereignis die Sitzungen, die an den entfernten Node geknüpft sind, zerstört, und bei jedem Skalierungsereignis wird ein kalter Node gestartet, der andere Anfragen nicht sehen kann. Durch die Verlagerung des Sitzungs- und transienten Zustands in die gemeinsame In-Memory DB-Ebene kann jede Rechenreplika jede Anfrage bedienen, was genau die zustandslose Voraussetzung ist, die in Einheit 4.3 erforderlich ist, bevor eine metrikbasierte automatische Skalierungsgruppe Dedicated Core-Knoten hinzufügen oder entfernen kann, ohne Benutzer zu stören. Die Cache-Ebene ist daher die Lese-Hälfte des no-read-replica-Musters (5.3) und die State-Externalisierungshälfte der sicheren automatischen Skalierung (4.3).

Was die Skalierung des Caches bewirkt und nicht bewirkt. Ein In-Memory DB-Cluster skaliert auf zwei Arten, und der Unterschied ist leicht zu verwechseln. Eine vertikale Skalierung ändert die Kerne und RAM pro Node und ist die Möglichkeit, die Durchsatzleistung zu erhöhen; Knoten werden nach dem Herunterfahren geändert, sodass Multi-Node-Cluster die Störung minimieren, indem sie zuerst die Sekundärknoten und dann den Primärknoten ändern. Eine horizontale Skalierung ändert die Anzahl der Knoten, aber die Dokumentation ist ausdrücklich, dass dies nur eine hohe Verfügbarkeit bietet und die Leistung nicht erhöht: Der Primärknoten akzeptiert alle Lese- und Schreibvorgänge, und die Sekundärknoten sind Reservekapazitäten für das automatische Failover und keine zusätzlichen Leseendpunkte. Der Cache skaliert also die Lesevorgänge durch die Größe des Arbeitsspeichers und nicht durch die Verteilung von Lesevorgängen auf Replikate, was der Realität der relationären Ebene ohne Read-Replikate in einer Ebene entspricht.

1.1 FinCorp: Schließung der Read-Scaling-Lücke

Der Lese-Pfad des Kundenportals von FinCorp war das offene Problem, das in Einheit 5.3 übrig blieb. Die Ansichten für Kontoubersichten und Transaktionsverläufe werden viel häufiger gelesen als geschrieben, und die regulierte PostgreSQL-Cluster auf der privaten Datenebene kann nicht durch Hinzufügen von Read-Replikaten skaliert werden. FinCorp platziert ein In-Memory DB-Cluster auf der gleichen privaten LAN, vor der PostgreSQL-Cluster, und leitet die Portal-Lesevorgänge durch es. Heiße Kontoubersichten werden aus dem Arbeitsspeicher bedient; die Datenbank wird nur bei einem Cache-Verfehlen oder einem Schreibvorgang berührt. Das gleiche Cluster hält den Portal-Sitzungszustand, sodass die öffentlich zugängliche zustandslose Web-Ebene unter die Dedicated Core-Automatikskalierungsgruppe gestellt werden kann, die in Einheit 4.3 entworfen wurde, ohne Sitzungen zu verlieren, wenn Knoten skaliert werden. Eine gemanagte Ebene löst beide Einschränkungen, und sie verlässt nie das private Netzwerk.

2. Cache-Aside vs Write-Through

Der Cache hilft nur, wenn die Anwendung ihn mit einer bewussten Lese- und Schreibstrategie integriert. Zwei Muster dominieren, und die Wahl ist eine Entscheidung der Anwendungsarchitektur, die die Plattform nicht für Sie trifft.

Die folgende Tabelle vergleicht die beiden Integrationsmuster:

Cache-Aside ist der Standard für eine Lese-Skalierungsebene, da es nur Daten im Cache speichert, die tatsächlich angefordert wurden, und den Cache-Speicher auf den Arbeitsbereich konzentriert. Sein Nachteil ist der kalte Vermissen beim ersten Zugriff und die Disziplin, einen Schlüssel bei jedem Schreibvorgang zu invalidieren oder zu aktualisieren, damit der Cache keinen veralteten Wert nach einer Änderung in der Datenbank liefert. Für das Portal von FinCorp, bei dem ein kleiner Satz von Konten ständig gelesen wird und die meisten selten gelesen werden, hält Cache-Aside den heißen Arbeitsbereich im Cache und überlässt den langen Schwanz der Datenbank.

Write-through hält den Cache sofort nach einem Schreibvorgang autoritativ, indem es beide Speicher gemeinsam schreibt, was für Daten geeignet ist, die sehr bald nach dem Schreiben gelesen werden. Es zahlt für diese Frische mit Schreiblatenz, da jeder Schreibvorgang nun auf beiden Speichern wartet, und es kann den Cache mit Einträgen füllen, die nie nachfolgend gelesen werden.

Eine praktische Regel: Wählen Sie eine Zeit bis zum Ablauf (Time To Live) für die im Cache gespeicherten Schlüssel, die der maximalen Veraltungszeit eines Wertes entspricht, und behandeln Sie die Löschung als eine Absicherung und nicht als primäres Ablaufmechanismus. Da der Cache den Lese-Skalierungsebene dient und kein System der Aufzeichnungen ist, muss die Anwendung immer in der Lage sein, jeden Wert aus der relationalen Ebene bei einem Vermissen zu rekonstruieren. Die Persistenzoptionen unten stärken den Cache gegen Neustarts, aber die relationale Cluster bleibt die Quelle der Wahrheit.

3. Platzierung, Größe und Entfernung

3.1 Private-Netzwerk-Platzierung

In-Memory DB bindet an genau eine Netzwerkverbindung: eine einzelne private LAN-Verbindung pro Cluster, definiert durch ein Rechenzentrum, eine LAN-ID und eine IP in diesem LAN-Subnetz. Es gibt keinen öffentlichen Endpunkt und keine IP-Adressenverwaltung für den Cluster, sodass Sie eine IP innerhalb Ihres Subnetzes wählen (oder die Subnetz-IP verwenden, die die Plattform unter DHCP zuweist) und der Cluster nach der Bereitstellung über diese Adresse erreichbar ist. Dies ist dieselbe private-Daten-Tier-Platzierung, die für die relationalen und Dokumentendatenbanken in diesem Modul verwendet wird: der Cache sitzt auf der privaten LAN vor der relationalen Cluster, die nur von der Anwendungsebene und der Datenbankebene, aber nie von dem Internet, erreichbar ist. Clients verbinden sich über TLS nur, wenn der Cluster explizit konfiguriert wurde, um es zu verwenden (TLS ist standardmäßig nicht aktiviert), wobei das Serverzertifikat von Let's Encrypt ausgestellt wird, wenn es aktiviert ist, sodass der Architekt entscheiden muss, TLS zu aktivieren und dann den Client mit der TLS-Option und dem entsprechenden CA-Zertifikat verbinden.

Die folgenden IP-Bereiche sind von der Plattform reserviert und können nicht für In-Memory DB-Verbindungen verwendet werden:

3.2 Größenanpassung von RAM und Persistenz

Sie stellen die Festplatte des Caches nicht direkt bereit. Sie wählen die Anzahl der CPU-Kerne und die RAM pro Node, und die Plattform leitet die bereitgestellte Block Storage aus der konfigurierten RAM und dem gewählten Persistenzmodus ab, wobei ein Mindestwert von 10 GB pro Node für jeden Modus angewendet wird. Die Beziehung ist fest:

Der Persistenzmodus ist der Größenhebel, der am meisten zählt. Der Standardwert ist "Keine", was bedeutet, dass das Dataset nur im Arbeitsspeicher existiert und bei einem Neustart verloren geht; für einen reinen Read-Through-Cache, der immer vom relationalen Tier aufgebaut werden kann, ist "Keine" oft die richtige und günstigste Wahl. RDB schreibt periodische Momentaufnahmen; AOF protokolliert jeden Schreibvorgang und kann das Dataset bei einem Neustart rekonstruieren; RDB_AOF kombiniert beides für die belastbarste und speicherhungrigste Konfiguration. Der Kompromiss ist direkt: mehr Belastbarkeit multipliziert den bereitgestellten Speicher gegen RAM, sodass ein 32 GB-Node, das mit dem Maximum dimensioniert ist, 32 GB Festplattenplatz unter "Keine" aber 256 GB unter RDB und AOF kostet. Dimensionieren Sie die RAM auf Ihren Arbeitsbereich plus Puffer für die Entfernung, und wählen Sie dann den niedrigsten Persistenzmodus, den die Wiederherstellungsanforderungen des Workload zulassen.

Die harten Obergrenzen, gegen Ihr Vertragskontingent, sind ein Maximum von 16 CPU-Kernen, 32 GB RAM und 2 TB Speicher pro Cluster, bis zu 5 Knoten pro Cluster. Der zugrunde liegende Valkey-Motor verwendet standardmäßig ein Maximum von 10.000 Client-Verbindungen (maxclients), was ein technischer Standardwert und kein veröffentlichter IONOS-Limit ist.

3.3 Entfernung

Wenn ein Cache-Node seine Arbeitsspeicher-Grenze für eingehende Daten erreicht, entscheidet die Entfernungsrichtlinie, was entfernt wird. Die Standardrichtlinie ist allkeys-lru, die den am wenigsten kürzlich verwendeten Schlüssel über alle Schlüssel entfernt, das richtige Verhalten für einen allgemeinen Read-Through-Cache, bei dem jeder Schlüssel ein Kandidat für die Entfernung ist. Die vollständige Menge der unterstützten Richtlinien umfasst noeviction, allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random und volatile-ttl. Die volatile-*-Richtlinien entfernen nur Schlüssel, die ein Ablaufdatum haben, was angemessen ist, wenn einige Schlüssel nie entfernt werden dürfen; noeviction lehnt neue Schreibvorgänge ab, sobald der Arbeitsspeicher voll ist, was den Cache in einen harten Fehlerpunkt verwandelt und selten für eine Skalierungsebene korrekt ist. Für eine Cache-Aside-Lese-Ebene behalten Sie die Standard-allkeys-lru-Richtlinie (oder allkeys-lfu, wenn die Zugriffshäufigkeit ein besserer Signal als die Kürze ist) bei, sodass der Cache immer Platz für den aktuellen Arbeitsbereich schafft.

DCD Implementierung Schritt-für-Schritt

Diese Implementierung bereitstellt eine einzelne In-Memory DB Cluster und platziert sie auf FinCorps privater Datenebene, sodass die Anwendung sie als Read-Through-Cache vor dem PostgreSQL Cluster aus Einheit 5.3 verwenden kann. Die Voraussetzung ist ein bestehendes VDC mit mindestens einem Server auf einer privaten LAN: Die Cluster muss einer bestehenden privaten LAN beitreten, und Sie müssen eine IP in dem Subnetz dieser LAN haben, um sie zuweisen zu können. Verwenden Sie das FinCorp-VDC und die private Datenebene-LAN, die in Modul 3 erstellt wurde.

Ziel: Bereitstellen des Caches und ihn als Read-Through-Schicht verbinden.

Schritte (in der Data Center Designer):

1. In der DCD, gehen Sie zu Menü > Datenbanken > In-Memory DB. Die Übersicht über die In-Memory DB Cluster öffnet sich und zeigt die für Ihren Vertrag bereitgestellten Ressourcen an.
2. Klicken Sie auf Cluster erstellen.
3. Definieren Sie die Eigenschaften der Cluster. Geben Sie einen Namen für die Cluster ein; lassen Sie die Version auf den Standardwert 7.2. Setzen Sie Instanzen auf die Anzahl der Knoten: Wählen Sie 1 für einen einzelnen-Node-Cache oder bis zu 5 für eine hohe Verfügbarkeit. Denken Sie daran, dass zusätzliche Knoten Failover und nicht Read-Durchsatz bieten. Wenn Sie mehr als einen Node festlegen, erscheint eine Option Replikationstyp; sie ist standardmäßig asynchron für In-Memory DB.
4. Wählen Sie die erforderliche Anzahl an Ressourcen aus. Verwenden Sie die Schieberegler, um die Anzahl der CPUs und die RAM-Größe pro Instanz festzulegen. Die RAM-Größe ist die eigentliche Größenentscheidung: Größen Sie sie auf die Arbeitsmenge, da der Persistenzmultiplikator und die pro-Node-Festplatte davon abhängen. Bleiben Sie innerhalb der 16-Kern- und 32-GB-pro-Cluster-Obergrenzen.
5. Verbinden Sie die Cluster mit einem VDC. Wählen Sie das Rechenzentrum, die private LAN und eine IP-Adresse (mit CIDR) innerhalb des Subnetzes dieser LAN aus. Es ist nur eine Verbindung pro Cluster erlaubt, und sie muss privat sein. Wählen Sie eine Adresse, die nicht mit bestehenden Hosts kollidiert und nicht innerhalb eines reservierten Bereichs liegt.
6. Planen Sie die Wartung der Cluster. Legen Sie den Wochentag und die Startzeit für das wöchentliche Wartungsfenster fest. Wählen Sie ein echtes Niedrigverkehrsfenster, anstatt es ungeplant zu lassen, da Versionen und Neustarts hier erfolgen und möglicherweise vorübergehend Verbindungen unterbrechen.
7. Definieren Sie Benutzer. Geben Sie einen Benutzernamen und ein Passwort für die Cluster ein. Diese Anmeldedaten können nur bei der Erstellung festgelegt werden und nicht später geändert werden, also speichern Sie sie sofort in Ihrem Geheimnis-Speicher.
8. Überprüfen Sie die geschätzten Kosten, die für die Konfiguration angezeigt werden, und klicken Sie dann auf Speichern. Der Zustand der Cluster zeigt "Beschäftigt" während der Erstellung und "Verfügbar", wenn sie bereit ist; die Plattform benachrichtigt Sie nicht, also überprüfen Sie, bis der Zustand "Verfügbar" ist.

Sobald die Cluster verfügbar ist, zeigen Sie den Cache-Client der Anwendung auf die zugewiesene private IP auf dem Standardport 6379 (über TLS, wenn Sie es bei der Instanzkonfiguration aktiviert haben) und implementieren den Cache-Aside-Lese-Pfad aus Abschnitt 2: Überprüfen Sie den Cache, fallen Sie auf PostgreSQL bei einem Fehlschlag zurück und füllen Sie den Cache auf dem Rückweg.

Häufige Fehler:

• Die Behandlung von zusätzlichen Knoten als Read-Skalierung. Das Hinzufügen von Knoten bietet nur eine hohe Verfügbarkeit und erhöht nicht die Leistung; skalieren Sie die Lesevorgänge mit mehr RAM und einer vertikalen Größenänderung, nicht mit mehr Replikaten.
• Das Vergessen, dass Anmeldedaten nur bei der Erstellung festgelegt werden. Der Benutzername und das Passwort können später nicht geändert werden, also speichern Sie sie bei der Erstellung; die Wiederherstellung von einem verlorenen Passwort bedeutet, die Cluster neu zu erstellen.
• Das Vergessen, dass die Persistenz auf der falschen Ebene für die Kosten liegt. Keine verliert alle Daten bei einem Neustart, aber stellt die wenigste Festplatte bereit; RDB und AOF zusammen stellen 8-mal die RAM als Festplatte bereit. Für einen reinen Read-Through-Cache, der aus der Datenbank neu erstellt wird, ist normalerweise "Keine" die richtige Einstellung.
• Die Auswahl von noeviction für einen Skalier-Cache. Wenn der Speicher voll ist, lehnt noeviction neue Schreibvorgänge ab und wandelt den Cache in einen Fehlerpunkt; behalten Sie die allkeys-lru-Standard-Einstellung, es sei denn, ein bestimmter Schlüssel darf nie entfernt werden.
• Die Zuweisung einer IP in einem reservierten Bereich oder die Erwartung einer zweiten Verbindung. Eine Cluster nimmt genau eine private LAN-Verbindung an, und die plattformreservierten Bereiche (z. B. 10.233.0.0/18) können nicht verwendet werden.
• Das Nicht-Planen eines echten Wartungsfensters. Upgrades und Neustarts laufen im wöchentlichen Fenster und können vorübergehend Verbindungen unterbrechen, also legen Sie es absichtlich in einer ruhigen Periode und lassen Sie die Clients neu verbinden.

Eine kurze Client-Verbindung verdeutlicht die TLS-und-Private-Endpunkt-Beschränkung, die die Beschreibung festlegt:

redis-cli -h 192.168.1.100 -p 6379 --tls --cacert ca.crt -a "$PASSWORD" ping

Der Host ist der private LAN IP, der in Schritt 5 zugewiesen wurde, der Port ist der Standardport 6379 und das --tls --cacert-Paar ist nur erforderlich, wenn TLS bei der Instanzkonfiguration aktiviert wurde (der gemanagte Endpunkt beendet TLS mit einem Let's Encrypt-Zertifikat, wenn es aktiviert ist, aber TLS ist standardmäßig nicht aktiviert). Es gibt keine öffentliche Adresse, um eine Verbindung herzustellen, was der Zweck ist: der Cache ist nur von innerhalb des virtuellen Rechenzentrums aus erreichbar, wenn die Instanz mit einem der drei TLS-Server konfiguriert wurde.

Zusammenfassung

Die In-Memory DB-Cacheschicht ist die einzige Komponente, die gleichzeitig zwei Plattformgrenzen auflöst. Sie ist der native Ersatz für die Lese-Replikate, die Managed PostgreSQL und MariaDB nicht anbieten, und absorbiert die Lesebelastung durch den Arbeitsspeicher, so dass die relationale Hauptkomponente nur Schreibvorgänge und Cachefehler sieht, und sie ist der gemeinsame Zustandsspeicher, der die Anwendungsschicht wirklich zustandslos macht und daher sicher unter VM Auto Scaling platziert werden kann. Basierend auf der privaten Datenebene mit einem Cacheseitigen-Lesepfad, dimensioniert von RAM und dem Persistenzmodus, und mit seinem sinnvollen Standardverdrängungsverhalten, ermöglicht es FinCorp, Lesevorgänge und Rechenleistung zu skalieren, ohne jemals eine Datenbank-Lese-Replikate oder einen öffentlichen Endpunkt einzuführen.

Wichtige Punkte:

• Es gibt keine relationalen Lese-Replikate auf IONOS; der In-Memory DB-Cache ist die Möglichkeit, Lesevorgänge zu skalieren, indem die heiße Arbeitsmenge aus dem Arbeitsspeicher bedient wird und die Datenbank nur bei Fehlern und Schreibvorgängen berührt wird.
• Der Cache ist auch die Zustandsexternalisierungsebene, die die zustandslose Voraussetzung für die Autoskalierung (Einheit 4.3) real macht.
• Das Hinzufügen von Knoten zum Cluster bietet Hochverfügbarkeit, nicht Lese-Durchsatz; die Kapazität kann durch Hinzufügen von RAM und vertikales Skalieren erhöht werden.
• Der bereitgestellte Speicherplatz wird aus RAM mal dem Persistenzmultiplikator (Keiner 1x, RDB 2x, AOF 4x, RDB+AOF 8x) abgeleitet, mit einem 10-GB-pro-Node-Boden; wählen Sie die niedrigste Persistenz, die die Wiederherstellungsanforderung zulässt.
• Der Cluster nimmt genau eine private LAN-Verbindung, mit TLS verfügbar, wenn Sie es bei der Instanzkonfiguration aktivieren, hat keinen öffentlichen Endpunkt und seine Anmeldeinformationen sind bei der Erstellung festgelegt; die Standard-allkeys-lru-Verdrängung ist korrekt für einen Read-Through-Cache.

Wichtige Begriffe:

• Cacheseitig: Ein Lesemuster, bei dem die Anwendung den Cache liest, bei einem Fehlschlag auf die Datenbank zurückfällt und den Cache mit dem Ergebnis befüllt; Schreibvorgänge gehen an die Datenbank und invalidieren oder aktualisieren den zwischengespeicherten Schlüssel.
• Write-Through: Ein Muster, bei dem die Anwendung auf den Cache und die Datenbank zusammen schreibt, den Cache sofort nach einem Schreibvorgang autoritativ hält, aber mit der Kosten von Schreibverzögerung.
• Persistenzmodus: Die In-Memory DB-Einstellung (Keiner, RDB, AOF oder RDB_AOF), die steuert, ob Daten nach einem Neustart überleben und, durch einen festen Multiplikator auf RAM, wie viel Block Storage der Cluster bereitstellt.
• Verdrängungsrichtlinie: Die Regel (Standard-allkeys-lru), die entscheidet, welche Schlüssel entfernt werden, wenn ein Node sein Arbeitsspeicherlimit erreicht.

Weitere Lektüre

• Einheit 5.3: Relationale Datenbanken, für die no-read-replica-Grenze schließt diese Ebene
• Einheit 4.3: Elastizität und VM Auto Scaling, für die zustandslose Voraussetzung erfüllt diese Ebene
• Einheit 2.4: Kostenarchitektur und FinOps, für cache-basierte Skalierbarkeit versus vertikale Datenbank-Skalierung