Seite 5 - Redis

Redis ist standardmaessig fuer maximale Performance, nicht fuer maximale Sicherheit konfiguriert. Ohne Authentifizierung, mit offenem Netzwerk-Bind und aktivierten gefaehrlichen Befehlen wird eine produktive Redis-Instanz zum Einfallstor. Dieser Artikel zeigt die vollstaendige Haertung fuer Magento-Umgebungen, von Passwoertern und ACLs bis zu TLS.

Redis-Knoten in einer einzigen Availability Zone sind gegen den Ausfall genau dieser Zone machtlos, egal wie gut die interne Replikation konfiguriert ist. Eine durchdachte Verteilung von Mastern und Replicas ueber mehrere Zonen erhoeht die Ausfallsicherheit erheblich, erfordert aber bewusste Entscheidungen ueber Latenz, Netzwerkkosten und die Grenzen von Cloud-Managed-Redis-Angeboten.

Redis überträgt Verbindungsdaten standardmäßig unverschlüsselt, ein Zustand, der in vielen internen Netzwerken jahrelang toleriert wurde, weil die Instanzen meist hinter einer Firewall liefen. Sobald jedoch Cloud-Umgebungen, Container-Orchestrierung oder Compliance-Vorgaben ins Spiel kommen, reicht reines Vertrauen auf Netzwerksegmentierung nicht mehr aus. Seit Redis 6 lässt sich TLS nativ konfigurieren, inklusive gegenseitiger Authentifizierung zwischen Client und Server. Dieser Artikel zeigt, wie eine End-to-End-Verschlüsselung server- und clientseitig sauber aufgesetzt wird, welchen Performance-Overhead die TLS-Terminierung tatsächlich verursacht, wie sich dieser Overhead durch Connection-Reuse und Session-Resumption spürbar reduzieren lässt, und wie eine Zertifikatsrotation im Produktivbetrieb gelingt, ohne die Verbindung zu unterbrechen.

Redis Lua-Scripting fuehrt komplette Skripte als einen einzigen atomaren Befehl aus, ohne dass ein anderer Client dazwischenfunken kann. Wer Increment-mit-Limit, bedingtes Loeschen oder andere Read-then-Write-Muster ohne echte Server-Logik umsetzt, riskiert Race-Conditions, die Lua-Skripte strukturell ausschliessen.

Ein Redis-Hash mit drei Feldern und ein Redis-Hash mit dreißigtausend Feldern werden intern völlig unterschiedlich gespeichert, obwohl beide über dieselben Befehle wie HSET und HGET angesprochen werden. Redis wählt automatisch zwischen einer kompakten, speicherplatzoptimierten Listpack-Kodierung für kleine Collections und einer klassischen Hashtable-Struktur für große, abhängig von konfigurierbaren Schwellenwerten. Wer diesen automatischen Umschaltpunkt kennt, kann seine Datenmodelle gezielt so gestalten, dass Redis möglichst lange in der speichereffizienten Listpack-Kodierung bleibt. Dieser Artikel zeigt, wie das Umschalten technisch funktioniert und welche praktischen Konsequenzen sich daraus für die Speicherplanung ergeben.

Session-Storage wirkt trivial, bis die Anwendung ueber mehrere Server skaliert und die erste Anmeldung nach einem Deploy verschwindet. Redis als zentraler Session-Store loest das Skalierungsproblem, bringt aber eigene Architekturentscheidungen mit sich, von Serialisierungsformat ueber TTL-Strategie bis zur Frage, ob Sticky Sessions ueberhaupt noch noetig sind.

Ein Magento-Docker-Stack besteht aus mindestens fünf Services: PHP-FPM, Nginx, MySQL, Redis und OpenSearch. Dazu kommen RabbitMQ für Message Queues und Varnish für Full-Page-Cache. Wie diese Services korrekt vernetzt, persistent gespeichert und in der richtigen Reihenfolge gestartet werden, entscheidet über Stabilität und Wartbarkeit.

used_memory sinkt nach dem Löschen tausender Keys nicht immer im gleichen Maß wie erwartet, weil der zugrunde liegende Speicher-Allocator fragmentiert. Active Defrag ist der Mechanismus, mit dem Redis diese Fragmentierung inkrementell und ohne spürbare Latenzspitzen im laufenden Betrieb wieder abbaut.

Memory-Fragmentation entsteht, wenn der Allokator jemalloc mehr physischen Speicher belegt, als Redis für die eigentlichen Daten tatsächlich braucht, und lässt sich präzise über mem_fragmentation_ratio messen. Wer versteht, wie jemalloc Speicherblöcke verwaltet, kann Active Defrag gezielt konfigurieren und weiß, wann ein kontrollierter Neustart die bessere Wahl gegenüber Defragmentierung im laufenden Betrieb ist.

Seit Redis 6 reicht ein einzelnes Passwort für den gesamten Server nicht mehr als einziges Sicherheitsmodell aus. Das ACL-System erlaubt es, für jeden Anwendungsdienst einen eigenen Benutzer mit exakt den Befehlen und Schlüsselmustern anzulegen, die dieser Dienst wirklich braucht. Vordefinierte Command-Kategorien wie @read, @write, @admin oder @dangerous machen dieses Least-Privilege-Modell praktisch handhabbar, statt jeden einzelnen der mehreren hundert Redis-Befehle manuell freizugeben oder zu sperren. Dieser Artikel zeigt, wie sich diese Kategorien sinnvoll kombinieren lassen, wie gefährliche Befehle wie FLUSHALL oder KEYS in Produktionsumgebungen kontrolliert werden und wie ein realistisches Multi-Service-Setup für einen Magento-Shop aussieht.