Einheit 5.5: In-Memory Database (Cache-Ebene)

Einführung

Einheit 5.3 hat eine harte Plattformgrenze festgelegt: Verwaltete PostgreSQL- und MariaDB-Instanzen auf IONOS CLOUD verfügen über keine Lese-Replikate, keine verwaltete Replikation zu einem zweiten Cluster und keine Replikation über Regionen hinweg. Die synchronen und asynchronen Replikate innerhalb eines Clusters dienen dem Failover, nicht der Bereitstellung von Leseverkehr. Für jede leseintensive Arbeitslast stellt sich daher die naheliegende Frage: Woher stammt die Skalierung für Lesezugriffe? Die Antwort liefert diese Einheit. Die Cache-Ebene der In-Memory DB übernimmt die Lesebelastung, die ein relationales Lese-Replikat getragen hätte, und schließt damit die Lücke fehlender Lese-Replikate durch ein natives Muster, nicht durch eine fehlende Funktion.

Dasselbe Layer übernimmt eine zweite Aufgabe, die genauso wichtig ist. Einheit 4.3 hat gezeigt, dass VM Auto Scaling nur stateless Replikate sicher hinzufügen und entfernen kann. Jede Sitzung, jedes Lock oder jeder transienter Zustand, der im Arbeitsspeicher eines Compute-Knotens gespeichert ist, geht verloren, sobald dieser Knoten skaliert wird. Die Externalisierung dieses Zustands in eine geteilte In-Memory-Ebene macht die Anwendungsebene wirklich stateless und damit das Auto-Scaling sicher. Diese Einheit schließt mit dem Aufbau des Clusters im Data Center Designer und der Verbindung über das private Netzwerk vor der relationalen Ebene.

1. Die Ebene für Read-Skalierung und Externalisierung von Zuständen

In-Memory DB wird über IONOS CLOUD DBaaS als verwalteter, mit Redis OSS kompatibler Key-Value-Store angeboten und ist an die stabile Legacy-Version 7.2 von Redis OSS gebunden. Es handelt sich um einen Datenstrukturserver und nicht nur um einen flachen Cache: Er speichert Zeichenketten, Hashes, Listen, Mengen, sortierte Mengen, Bitmaps, Hyperloglogs, geospatiale Indizes und Streams. Diese Breite ermöglicht es einer einzigen Ebene, zwei architektonische Rollen gleichzeitig zu erfüllen.

Warum sie Read-Replikate ersetzt. Ein relationales Read-Replikat skaliert Lesevorgänge, indem es den Datensatz auf einen anderen Knoten dupliziert, der SELECT-Anfragen beantwortet; IONOS CLOUD DBaaS bietet dies nicht an. Stattdessen liest die Anwendung über einen Cache: Die erste Anfrage nach einem Wert verfehlt den Cache und trifft auf PostgreSQL oder MariaDB, das Ergebnis wird in In-Memory DB geschrieben, und jede nachfolgende Anfrage wird aus dem Arbeitsspeicher mit einer Latenz von unter einem Millisekunde bedient, ohne die Datenbank zu belasten. Die Nutzung des Caches minimiert Datenbankabfragen, reduziert den Datenverkehr und den benötigten Ressourcenbedarf erheblich und ermöglicht eine schnelle und kosteneffiziente Skalierungsebene. Das relationale Primärsystem bleibt klein, da es nur Verfehlungen und Schreibvorgänge sieht, während die Leseleistung mit dem Cache-Arbeitsspeicher und nicht mit Datenbankkernen skaliert. Dies ist die in Einheit 2.4 als cache-basierte Skalierung nach außen gekennzeichnete Designentscheidung: Man kauft RAM in der Cache-Ebene, anstatt die Datenbank vertikal zu skalieren.

Warum sie die Voraussetzung für Auto-Scaling ist. Wenn die Anwendungsebene den Sitzungszustand im lokalen Prozessspeicher hält, zerstört jedes Scale-in-Ereignis die an den entfernten Knoten gebundenen Sitzungen, und jedes Scale-out startet einen kalten Knoten, den andere Anfragen nicht sehen können. Die Verlagerung von Sitzungszustand und transientem Zustand in die gemeinsame In-Memory DB-Ebene bedeutet, dass jeder Compute-Replikat jede Anfrage bedienen kann, was genau die zustandslose Voraussetzung ist, die Einheit 4.3 erfordert, bevor eine metrikgesteuerte Auto-Scaling-Gruppe Dedicated Core-Knoten hinzufügen oder entfernen kann, ohne Benutzer zu beeinträchtigen. Die Cache-Ebene ist daher die Lesehälfte des Musters ohne Read-Replikat (5.3) und die Zustands-Externalisierungs-Hälfte des sicheren Auto-Scalings (4.3).

Was die Skalierung des Caches leistet und was nicht. Ein In-Memory DB-Cluster skaliert auf zwei Arten, und die Unterscheidung ist leicht falsch zu verstehen. Vertikale Skalierung ändert die Kerne und den RAM pro Knoten und ist der Weg, um die Durchsatzleistung zu erhöhen; Knoten werden nach dem Abschalten geändert, sodass Mehrknoten-Cluster die Störung minimieren, indem sie zuerst die Sekundärknoten und dann den Primärknoten ändern. Horizontale Skalierung ändert die Anzahl der Knoten, aber die Dokumentation stellt ausdrücklich klar, dass dies nur Hochverfügbarkeit bereitstellt und die Leistung nicht erhöht: Der Primärknoten akzeptiert alle Lese- und Schreibvorgänge, und die Sekundärknoten sind Standby-Kapazität für automatisches Failover, keine zusätzlichen Leseendpunkte. Der Cache skaliert Lesevorgalso also durch die Speichergröße, nicht durch die Verteilung von Lesevorgängen auf Replikate, was die Realität der relationale Ebene ohne Read-Replikate eine Ebene darüber widerspiegelt.

1.1 FinCorp: Schließen der Lücke bei der Read-Skalierung

Der Lese-Pfad des Kundenportals von FinCorp war das offene Problem, das von Einheit 5.3 hinterlassen wurde. Ansichts für Kontozusammenfassungen und Transaktionsverläufe werden viel häufiger gelesen als geschrieben, und der regulierte PostgreSQL-Cluster auf der privaten Datenebene kann nicht durch Hinzufügen von Read-Replikaten skaliert werden. FinCorp platziert einen In-Memory DB-Cluster im selben privaten LAN, vor dem PostgreSQL-Cluster, und leitet Portal-Lesevorgänge durch ihn. Heiße Kontozusammenfassungen werden aus dem Arbeitsspeicher bedient; die Datenbank wird nur bei einem Cache-Verfehlen oder einem Schreibvorgang angesprochen. Der gleiche Cluster hält den Sitzungszustand des Portals, sodass die öffentlich zugängliche zustandslose Web-Ebene in die in Einheit 4.3 konzipierte Dedicated Core-Auto-Scaling-Gruppe aufgenommen werden kann, ohne dass Sitzungen verloren gehen, wenn Knoten skaliert werden. Eine verwaltete Ebene löst beide Einschränkungen, und sie verlässt niemals das private Netzwerk.

2. Cache-Aside vs. Write-Through

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

Die folgende Tabelle stellt die beiden Integrationsmuster gegenüber:

Cache-Aside ist die Standardlösung für eine Read-Scaling-Ebene, da sie nur Daten cacht, die tatsächlich angefordert wurden, und den Cache-Arbeitsspeicher auf den Arbeitsbereich konzentriert. Der Preis dafür ist der Cold-Miss beim ersten Zugriff und die Disziplin, bei jedem Schreibvorgang einen Schlüssel zu invalidieren oder zu aktualisieren, damit der Cache nach einer Änderung in der Datenbank keinen veralteten Wert liefert. Für das Portal von FinCorp, bei dem eine kleine Gruppe von Konten ständig gelesen wird und die meisten nur selten, hält Cache-Aside den heißen Arbeitsbereich resident und überlässt den langen Schwanz der Datenbank.

Write-Through hält den Cache unmittelbar nach einem Schreibvorgang für autoritativ, indem er beide Speicher gemeinsam beschreibt, was für Daten geeignet ist, die kurz nach dem Schreiben gelesen werden. Er zahlt für diese Aktualität mit Schreiblatenz, da jeder Schreibvorgang nun auf beide Speicher wartet, und er kann den Cache mit Einträgen füllen, die anschließend nie gelesen werden.

Eine praktische Regel: Wählen Sie eine Time To Life für gecachte Schlüssel, die dem zulässigen Alter eines Werts entspricht, und behandeln Sie Eviction als Sicherheitsnetz, nicht als primären Ablaufmechanismus. Da der Cache die Read-Scaling-Ebene ersetzt und kein System of Record ist, muss die Anwendung in der Lage sein, jeden Wert bei einem Miss aus der relationalen Ebene neu aufzubauen. Die unten aufgeführten Persistenzoptionen härten den Cache gegen Neustarts ab, aber der relationale Cluster bleibt die Wahrheitquelle.

3. Platzierung, Dimensionierung und Eviction

3.1 Platzierung im privaten Netzwerk

In-Memory DB wird genau einer Netzwerkverbindung zugewiesen: einer einzelnen privaten LAN-Verbindung pro Cluster, definiert durch ein Rechenzentrum, eine LAN-ID und eine IP in dem Subnetz dieses LANs. Es gibt keinen öffentlichen Endpunkt und keine IP-Adressverwaltung für das Cluster. Daher wählen Sie eine IP innerhalb Ihres Subnetzes (oder verwenden die vom Plattform-DHCP zugewiesene Subnetz-IP), und das Cluster wird nach der Bereitstellung unter dieser Adresse erreichbar. Dies ist dieselbe Platzierung in der privaten Daten-Ebene, die für die relationalen und Dokumenten-Datenbanken in diesem Modul verwendet wird: Der Cache befindet sich auf dem privaten LAN vor dem relationalen Cluster und ist nur von der Anwendungsebene und der Datenbankebene erreichbar, niemals vom Internet aus. Clients verbinden sich über TLS nur dann, wenn das Cluster ausdrücklich so konfiguriert wurde (TLS ist standardmäßig nicht aktiviert). Wenn TLS aktiviert ist, wird das Serverzertifikat von Let's Encrypt ausgestellt. Der Architekt muss daher entscheiden, TLS zu aktivieren, und anschließend muss der Client mit der TLS-Option und dem entsprechenden CA-Zertifikat verbinden.

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

3.2 Dimensionierung anhand von RAM und Persistenz

Sie provisionieren die Festplatte des Caches nicht direkt. Sie wählen die Anzahl der CPU-Kerne und den RAM pro Knoten, und die Plattform leitet den provisionierten Block Storage aus dem konfigurierten RAM und dem gewählten Persistenzmodus ab, wobei für jeden Modus ein Minimum von 10 GB pro Knoten gilt. Die Beziehung ist festgelegt:

Der Persistenzmodus ist der wichtigste Hebel für die Dimensionierung. Der Standardwert ist None, was bedeutet, dass der Datensatz nur im Arbeitsspeicher vorhanden ist und bei einem Neustart verloren geht. Für einen reinen Read-Through-Cache, der sich immer aus der relationalen Ebene neu aufbauen kann, ist None oft die richtige und günstigste Wahl. RDB schreibt periodische Punkt-in-Time-Snapshots; AOF protokolliert jede Schreiboperation und kann den Datensatz bei einem Neustart rekonstruieren; RDB_AOF kombiniert beide für die langlebigste und speicherintensivste Konfiguration. Der Trade-off ist direkt: Höhere Langlebigkeit multipliziert den provisionierten Speicher im Verhältnis zum RAM. So kostet ein auf das Maximum dimensionierter Knoten mit 32 GB unter None 32 GB Festplattenspeicher, aber unter RDB und AOF 256 GB. Dimensionieren Sie den RAM entsprechend Ihrem Arbeitsdatensatz plus Puffer für Eviction, und wählen Sie dann den niedrigsten Persistenzmodus, den die Wiederherstellungsanforderungen der Arbeitslast zulassen.

Die harten Obergrenzen, gemessen an Ihrer Vertragsquote, betragen maximal 16 CPU-Kerne, 32 GB RAM und 2 TB Speicher pro Cluster, mit bis zu 5 Knoten pro Cluster. Die zugrunde liegende Valkey-Engine standardmäßig auf maximal 10.000 Client-Verbindungen (maxclients), was ein Technologie-Standardwert und keine veröffentlichte IONOS CLOUD-Grenze ist.

3.3 Eviction

Wenn ein Cache-Knoten sein Arbeitsspeicherlimit für eingehende Daten erreicht, entscheidet die Eviction-Richtlinie, was entfernt wird. Die Standardrichtlinie ist allkeys-lru, die den zuletzt am wenigsten genutzten Schlüssel über alle Schlüssel hinweg evictet. Dies ist das richtige Verhalten für einen allgemeinen Read-Through-Cache, bei dem jeder Schlüssel ein Kandidat für die Entfernung ist. Der vollständige Satz der unterstützten Richtlinien umfasst noeviction, allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random und volatile-ttl. Die volatile-*-Richtlinien evicten nur Schlüssel, die eine Ablaufzeit haben, was angemessen ist, wenn bestimmte Schlüssel niemals evictet werden dürfen; noeviction lehnt neue Schreibvorgänge ab, sobald der Speicher voll ist, was einen Cache zu einem harten Fehlerpunkt macht und für eine skalierende Ebene selten richtig ist. Für eine Cache-Aside-Read-Ebene behalten Sie die Standardrichtlinie allkeys-lru bei (oder allkeys-lfu, wenn die Zugriffsfrequenz ein besseres Signal ist als die Neuigkeit), damit der Cache immer Platz für den aktuellen Arbeitsdatensatz schafft.

DCD-Implementierungsanleitung

In dieser Anleitung wird ein einzelner In-Memory DB-Cluster bereitgestellt und auf der privaten Datenebene von FinCorp platziert, damit die Anwendung ihn als Read-Through-Cache vor dem PostgreSQL-Cluster aus Einheit 5.3 nutzen kann. Voraussetzung ist ein vorhandenes VDC mit mindestens einem Server in einem privaten LAN: Der Cluster muss einem vorhandenen privaten LAN beitreten, und es muss eine IP in dem Subnetz dieses LANs vorhanden sein, die zugewiesen werden kann. Wiederverwenden Sie das in Modul 3 erstellte FinCorp-VDC und das private LAN der Datenebene.

Ziel der Implementierung: Bereitstellen des Caches und dessen Anbindung als Read-Through-Ebene.

Schritte (im Data Center Designer):

1. Gehen Sie im DCD zu Menü > Datenbanken > In-Memory DB. Die Übersicht des In-Memory DB-Clusters öffnet sich und zeigt die Ihrem Vertrag zugewiesenen Ressourcen.
2. Klicken Sie auf Cluster erstellen.
3. Cluster-Eigenschaften definieren. Geben Sie einen Namen für den Cluster ein; lassen Sie die Version auf dem Standardwert 7.2. Setzen Sie Instanzen auf die Anzahl der Knoten: Wählen Sie 1 für einen Ein-Knoten-Cache oder bis zu 5 für Hochverfügbarkeit. Beachten Sie, dass zusätzliche Knoten Failover bereitstellen, nicht jedoch höhere Lese-Leistung. Wenn Sie mehr als einen Knoten festlegen, erscheint die Option Replikatortyp; sie ist für In-Memory DB standardmäßig Asynchron.
4. Erforderliche Anzahl an Ressourcen auswählen. Verwenden Sie die Regler, um die Anzahl der CPUs und die RAM-Größe pro Instanz festzulegen. RAM ist die eigentliche Dimensionierungsentscheidung: Passen Sie die Größe an den Arbeitssatz an, da der Persistenzmultiplikator und die Platte pro Knoten davon abgeleitet werden. Halten Sie sich innerhalb der Obergrenzen von 16 Kernen und 32 GB pro Cluster.
5. Cluster mit einem VDC verbinden. Wählen Sie das Rechenzentrum, das private LAN und eine IP-Adresse (mit CIDR) innerhalb des Subnetzes dieses LANs aus. Pro Cluster ist nur eine Verbindung erlaubt, und sie muss privat sein. Wählen Sie eine Adresse, die nicht mit vorhandenen Hosts kollidiert und sich nicht in einem reservierten Bereich befindet.
6. Wartung des Clusters planen. Legen Sie den Wochentag und die Startzeit für das wöchentliche Wartungsfenster fest. Wählen Sie ein echtes Zeitfenster mit geringem Verkehr, anstatt die Planung offenzulassen, da Versionserweiterungen und Neustarts hier stattfinden und Verbindungen kurzzeitig unterbrechen können.
7. Benutzer definieren. Geben Sie einen Benutzernamen und ein Passwort für den Cluster ein. Diese Zugangsdaten können nur bei der Erstellung festgelegt und danach nicht geändert werden; speichern Sie sie daher sofort in Ihrem Secret Store.
8. Prüfen Sie die für die Konfiguration angezeigte geschätzete Kosten, und klicken Sie dann auf Speichern. Der Cluster-STATUS zeigt während der Erstellung „Busy" und „Available", wenn er bereit ist; die Plattform benachrichtigt Sie nicht, daher müssen Sie den Status abfragen, bis er „Available" ist.

Sobald der Cluster „Available" ist, richten Sie den Cache-Client der Anwendung auf die zugewiesene private IP auf dem Standardport 6379 ein (über TLS, falls Sie ihn bei der Instanzkonfiguration aktiviert haben), und implementieren Sie den Cache-Aside-Lese-Pfad aus Abschnitt 2: Prüfen Sie den Cache, fallen Sie bei einem Miss auf PostgreSQL zurück und befüllen Sie den Cache auf dem Rückweg.

Häufige Fehler:

• Zusätzliche Knoten als Read-Skalierung zu betrachten. Das Hinzufügen von Knoten bietet nur Hochverfügbarkeit und erhöht nicht die Leistung; skalieren Sie Lesevorgaben mit mehr RAM und einer vertikalen Größenanpassung, nicht mit mehr Replikaten.
• Zu vergessen, dass Zugangsdaten nur bei der Erstellung festgelegt werden. Benutzername und Passwort können später nicht aktualisiert werden; speichern Sie sie daher zum Zeitpunkt der Erstellung. Die Wiederherstellung nach einem verlorenen Passwort bedeutet den Neuaufbau des Clusters.
• Die Persistenz auf der falschen Ebene für die Kosten zu belassen. „None" verliert alle Daten beim Neustart, provisioniert aber die geringste Platte; „RDB" und „AOF" zusammen provisionieren 8x das RAM als Platte. Für einen reinen Read-Through-Cache, der aus der Datenbank neu aufgebaut wird, ist „None" in der Regel richtig.
• noeviction für einen skalierenden Cache zu wählen. Wenn der Speicher gefüllt ist, lehnt noeviction neue Schreibvorgänge ab und macht den Cache zu einem Ausfallpunkt; behalten Sie den allkeys-lru-Standard bei, es sei denn, ein bestimmter Schlüssel darf niemals verdrängt werden.
• Eine IP in einem reservierten Bereich zuzuweisen oder eine zweite Verbindung zu erwarten. Ein Cluster nimmt genau eine private LAN-Verbindung an, und die von der Plattform reservierten Bereiche (zum Beispiel 10.233.0.0/18) können nicht verwendet werden.
• Kein echtes Wartungsfenster zu planen. Erweiterungen und Neustarts laufen im wöchentlichen Fenster ab und können Verbindungen kurzzeitig trennen; legen Sie es daher bewusst in eine ruhige Periode und sorgen Sie dafür, dass Clients neu verbinden.

Eine kurze Client-Verbindung illustriert die TLS- und Private-Endpunkt-Beschränkung, die der Text festlegt:

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

Der Host ist die private LAN-IP, die in Schritt 5 zugewiesen wurde, der Port ist der Standardwert 6379, und das --tls --cacert-Paar wird nur benötigt, wenn TLS bei der Konfiguration der Instanz aktiviert wurde (der verwaltete Endpunkt beendet TLS mit einem Let's Encrypt-Zertifikat, wenn es aktiviert ist, TLS ist jedoch standardmäßig nicht aktiviert). Es gibt keine öffentliche Adresse, mit der eine Verbindung hergestellt werden kann, und genau das ist der Punkt: Der Cache ist nur von innerhalb des VDC aus erreichbar.

Zusammenfassung

Die Cache-Ebene der In-Memory DB ist die einzige Komponente, die zwei Plattformgrenzen gleichzeitig auflöst. Sie ist der native Ersatz für die Lese-Replikate, die verwaltete PostgreSQL und MariaDB nicht anbieten, und nimmt die Lesebelastung über den Arbeitsspeicher auf, sodass die relationale Primärinstanz nur Schreibvorgänge und Cache-Trefferverfehlungen sieht. Sie ist außerdem der gemeinsame Zustandspeicher, der die Anwendungsebene wirklich zustandslos macht und sie daher sicher unter VM Auto Scaling stellen lässt. Aufbauend auf der privaten Datenebene mit einem Cache-aside-Lesepfad, dimensioniert nach RAM und Persistenzmodus und mit dem sinnvollen Standard für die Verdrängung belassen, ermöglicht sie FinCorp, Lesezugriffe und Compute zu skalieren, ohne jemals ein Datenbank-Lese-Replikat oder einen öffentlichen Endpunkt einzuführen.

Wichtige Punkte:

• Auf IONOS CLOUD gibt es keine relationalen Lese-Replikate; die In-Memory DB-Cache-Ebene ist der Weg, Lesezugriffe zu skalieren, indem der heiße Arbeitsbereich aus dem Arbeitsspeicher bedient wird und die Datenbank nur bei Trefferverfehlungen und Schreibvorgängen angesprochen wird.
• Der Cache ist auch die Ebene zur Externalisierung von Zuständen, die die zustandslose Voraussetzung für das automatische Skalieren (Einheit 4.3) real macht.
• Das Hinzufügen von Knoten zum Cluster bietet Hochverfügbarkeit, nicht Lese-Durchsatz; Kapazität wird durch Hinzufügen von RAM und vertikales Vergrößern erhöht.
• Der provisionierte Speicherplatz wird aus RAM multipliziert mit dem Persistenzfaktor abgeleitet (None 1x, RDB 2x, AOF 4x, RDB+AOF 8x), mit einer Untergrenze von 10 GB pro Knoten; wählen Sie die niedrigste Persistenz, die die Wiederherstellungsanforderung zulässt.
• Der Cluster nimmt genau eine private LAN-Verbindung an, mit TLS verfügbar, wenn Sie es bei der Instanzkonfiguration aktivieren, hat keinen öffentlichen Endpunkt, und seine Zugangsdaten sind bei der Erstellung festgelegt; die Standard-Verdrängung allkeys-lru ist für einen Read-Through-Cache korrekt.

Wichtige Begriffe:

• Cache-aside: Ein Read-Through-Muster, bei dem die Anwendung den Cache liest, bei einer Trefferverfehlung auf die Datenbank zurückgreift 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 gleichzeitig in den Cache und in die Datenbank schreibt, wodurch der Cache unmittelbar nach einem Schreibvorgang autoritativ ist, auf Kosten der Schreiblatenz.
• Persistenzmodus: Die In-Memory DB-Einstellung (None, RDB, AOF oder RDB_AOF), die steuert, ob Daten nach einem Neustart erhalten bleiben und, über einen festen Multiplikator auf den RAM, wie viel Block Storage der Cluster provisioniert.
• Verdrängungsrichtlinie: Die Regel (Standard allkeys-lru), die bestimmt, welche Schlüssel entfernt werden, wenn ein Knoten sein Speicherlimit erreicht.

Weitere Lektüre

• Einheit 5.3: Relationale Datenbanken, für die Grenze der no-read-replica-Ebene, die diese Ebene schließt
• Einheit 4.3: Elastizität und VM Auto Scaling, für die zustandslose Voraussetzung, die diese Ebene erfüllt
• Einheit 2.4: Kostenarchitektur und FinOps, für die Wirtschaftlichkeit des cache-basierten Scale-out im Vergleich zur vertikalen Datenbank- Skalierung