Redis-Cluster-Setup fuer skalierende Magento-Shops

1. Wann eine einzelne Redis-Instanz nicht mehr reicht

Die meisten Magento-Shops laufen jahrelang problemlos mit einer einzelnen Redis-Instanz fuer Cache und Session. Das aendert sich, sobald bestimmte Schwellen erreicht werden: der Arbeitsspeicher der Instanz naehert sich dem konfigurierten maxmemory-Limit, die Latenz einzelner Befehle steigt spuerbar an, oder die CPU-Auslastung des einzelnen Redis-Prozesses erreicht dauerhaft ueber 70 Prozent. Da Redis intern single-threaded arbeitet, kann ein einzelner Prozess nur einen CPU-Kern fuer die eigentliche Befehlsverarbeitung nutzen, egal wie viele Kerne der Server insgesamt hat. Ab einem gewissen Traffic-Volumen wird dieser eine Kern zum Flaschenhals, unabhaengig davon, wie viel RAM noch frei ist.

Ein zweites Warnsignal ist die Vermischung unterschiedlicher Datentypen in derselben Instanz. Wenn Session-Daten, Objektcache und Full-Page-Cache alle in derselben Redis-Instanz liegen, konkurrieren sie um denselben Arbeitsspeicher und denselben Verarbeitungsthread. Ein Cache-Flush oder eine grosse KEYS-Operation im Objektcache kann dann kurzzeitig auch die Session-Verarbeitung blockieren, weil Redis Befehle sequenziell abarbeitet. In der Praxis zeigt sich das durch sporadische Login-Probleme oder abgebrochene Checkouts genau dann, wenn im Hintergrund ein Cache-Clear laeuft.

Bevor man ueber ein echtes Redis-Cluster nachdenkt, lohnt sich ein Blick auf INFO memory und INFO commandstats der bestehenden Instanz. Steigt used_memory kontinuierlich Richtung maxmemory, obwohl die TTLs korrekt gesetzt sind, deutet das auf echtes Datenwachstum hin, das durch mehr RAM oder Sharding geloest werden muss. Steigt dagegen instantaneous_ops_per_sec stark an, ist eher die CPU-Verarbeitung der Engpass, den man durch Aufteilung auf mehrere Prozesse loesen kann, nicht zwingend durch mehr Speicher.

2. Der erste Schritt: Rollenaufteilung statt Cluster

Bevor ein echtes Redis-Cluster mit Sharding zum Einsatz kommt, sollte in fast jedem Magento-Setup zuerst die Rollenaufteilung auf dedizierte Instanzen erfolgen. Magento nutzt Redis fuer drei unterschiedliche Zwecke: den Objektcache (cache), den Full-Page-Cache (page_cache) und optional die Session-Speicherung. Diese drei Rollen haben komplett unterschiedliche Zugriffsmuster: Sessions sind kleine, haeufig geschriebene Objekte mit kurzer Lebensdauer, der Objektcache besteht aus vielen kleinen bis mittelgrossen Eintraegen mit mittlerer TTL, und der Full-Page-Cache enthaelt wenige, aber grosse HTML-Bloecke.

Der einfachste Skalierungsschritt ist daher, drei separate Redis-Prozesse auf demselben oder auf unterschiedlichen Hosts zu betreiben, jeweils mit eigenem maxmemory-Limit und eigener maxmemory-policy. Da jeder Redis-Prozess seinen eigenen Thread fuer die Kommandoverarbeitung nutzt, verteilt sich die CPU-Last automatisch auf mehrere Kerne, sobald die Instanzen auf unterschiedlichen Ports oder Hosts laufen. Ein Cache-Flush im Objektcache kann dann die Session-Instanz nicht mehr blockieren, weil es sich um komplett getrennte Prozesse handelt.

In der Praxis reicht diese Rollenaufteilung bei einem grossen Teil der Magento-Installationen aus, um die naechsten ein bis zwei Jahre Wachstum abzufedern, ohne die Komplexitaet eines echten Clusters einzugehen. Erst wenn eine einzelne Rolle, meist der Objektcache bei sehr grossen Katalogen, selbst wieder an die Grenzen einer einzelnen Instanz stoesst, wird ein Redis-Cluster mit Sharding innerhalb dieser einen Rolle relevant.

; /etc/redis/redis-cache.conf
port 6379
maxmemory 4gb
maxmemory-policy allkeys-lru
save ""
appendonly no
databases 1

; /etc/redis/redis-session.conf
port 6380
maxmemory 2gb
maxmemory-policy noeviction
save ""
appendonly yes
appendfsync everysec
databases 1

; /etc/redis/redis-fpc.conf
port 6381
maxmemory 6gb
maxmemory-policy allkeys-lru
save ""
appendonly no
databases 1

3. Redis-Cluster: Sharding und Hash-Slots verstehen

Ein echtes Redis-Cluster teilt den Datenraum in 16384 Hash-Slots auf, die auf mehrere Master-Knoten verteilt werden. Jeder Schluessel wird per CRC16-Hash einem Slot zugeordnet, und jeder Knoten im Cluster ist fuer einen Teilbereich dieser Slots zustaendig. Das bedeutet: Schreib- und Lesezugriffe verteilen sich automatisch auf mehrere Prozesse und damit auf mehrere CPU-Kerne und im Idealfall auch auf mehrere physische Server. Anders als bei der reinen Rollenaufteilung wird hier eine einzelne logische Datenmenge, etwa der komplette Objektcache, horizontal auf mehrere Knoten verteilt.

Der entscheidende Unterschied zu einer einfachen Multi-Instanz-Loesung ist, dass ein Redis-Cluster Multi-Key-Operationen einschraenkt. Befehle, die mehrere Schluessel gleichzeitig betreffen, wie MGET oder Transaktionen mit mehreren Keys, funktionieren nur, wenn alle beteiligten Schluessel im selben Hash-Slot liegen. Magento nutzt intern haeufig Tag-basierte Invalidierung mit Cache-Tags, die ueber Sets mehrere Schluessel referenzieren. Wenn diese Tags und die zugehoerigen Cache-Eintraege in unterschiedlichen Slots landen, schlagen bestimmte Invalidierungsoperationen fehl oder muessen umgeschrieben werden, damit sie Hash-Tags nutzen.

Um verwandte Schluessel im selben Slot zu halten, unterstuetzt Redis Hash-Tags in geschweiften Klammern: ein Schluessel wie cache:{tag123}:entity_42 wird nur anhand des Teils in den geschweiften Klammern gehasht. Das erlaubt es, gezielt zu steuern, welche Schluessel gemeinsam auf einem Knoten landen. Die Cinnamon- beziehungsweise Colinmollenhour-Cache-Backends, die Magento fuer Redis nutzt, unterstuetzen dieses Hash-Tagging nicht automatisch, weshalb ein Redis-Cluster fuer den Magento-Objektcache in der Praxis zusaetzliche Konfiguration oder ein cluster-faehiges Cache-Backend erfordert.

4. Ein Redis-Cluster fuer Magento aufbauen

Fuer ein minimal produktionstaugliches Redis-Cluster sind mindestens drei Master-Knoten und drei Replica-Knoten noetig, damit bei Ausfall eines Masters automatisches Failover moeglich bleibt, ohne dass Slots verloren gehen. Jeder Knoten benoetigt zusaetzlich zum normalen Client-Port einen zweiten Port fuer die Cluster-Bus-Kommunikation, standardmaessig Client-Port plus 10000. Diese Ports muessen zwischen allen Cluster-Knoten offen sein, aber nicht von aussen erreichbar.

# Six Redis nodes: 3 masters, 3 replicas, minimal production cluster
for port in 7000 7001 7002 7003 7004 7005; do
  mkdir -p /etc/redis/cluster/${port}
  cat > /etc/redis/cluster/${port}/redis.conf <<EOF
port ${port}
cluster-enabled yes
cluster-config-file nodes-${port}.conf
cluster-node-timeout 5000
appendonly yes
dir /etc/redis/cluster/${port}
maxmemory 2gb
maxmemory-policy allkeys-lru
EOF
  redis-server /etc/redis/cluster/${port}/redis.conf --daemonize yes
done

# Create the cluster: first three nodes as masters, last three as replicas
redis-cli --cluster create \
  127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1

# Verify slot distribution across masters
redis-cli -p 7000 cluster slots
redis-cli -p 7000 cluster nodes

Nach der Erstellung verteilt redis-cli --cluster create die 16384 Slots automatisch zu gleichen Teilen auf die drei Master-Knoten. Jeder Replica wird einem Master zugeordnet und uebernimmt bei dessen Ausfall automatisch die Rolle des Masters, sofern eine Mehrheit der verbleibenden Master-Knoten dem Failover zustimmt. Dieser Konsens-Mechanismus verhindert Split-Brain-Situationen, setzt aber voraus, dass immer eine ungerade Gesamtzahl an Master-Knoten existiert, damit Mehrheitsentscheidungen eindeutig sind.

5. Magento auf Cluster-Betrieb konfigurieren

Magento unterstuetzt Redis-Cluster-Betrieb ueber das Colinmollenhour-Cache-Backend, das in der env.php mit dem Parameter cluster aktiviert wird. Dabei werden nicht mehr einzelne Server, sondern eine Liste aller Cluster-Seed-Knoten angegeben, ueber die Magento die vollstaendige Cluster-Topologie automatisch ermittelt. Wichtig ist, dass fuer den Full-Page-Cache und den Objektcache jeweils eigene Cluster oder zumindest eigene Slot-Bereiche verwendet werden sollten, um weiterhin eine klare Rollentrennung zu behalten.

// app/etc/env.php: Redis Cluster configuration for Magento object cache
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'seed' => '10.0.1.10:7000,10.0.1.11:7001,10.0.1.12:7002',
                'load_from_slave' => '10.0.1.10:7000',
                'read_timeout' => 10,
                'automatic_cluster' => true,
                'persistent' => 1,
                'compress_data' => 1,
            ],
        ],
        'page_cache' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'seed' => '10.0.1.20:7100,10.0.1.21:7101,10.0.1.22:7102',
                'automatic_cluster' => true,
                'compress_data' => 1,
                'compression_lib' => 'l4z',
            ],
        ],
    ],
],

Nach jeder Aenderung an der env.php muessen Cache und Konfiguration neu generiert werden, damit Magento die neue Cluster-Topologie uebernimmt. Ein Testlauf mit bin/magento cache:status zeigt, ob Magento die konfigurierten Redis-Backends korrekt erreicht. Zusaetzlich empfiehlt es sich, nach der Umstellung gezielt bin/magento cache:flush auszufuehren und im Anschluss die Slot-Verteilung mit redis-cli --cluster check zu pruefen, um sicherzustellen, dass keine Slots unzugewiesen geblieben sind.

6. Redis Sentinel als Alternative fuer Hochverfuegbarkeit

Nicht jedes Skalierungsproblem erfordert Sharding. Wenn die Datenmenge pro Rolle problemlos in eine einzelne Redis-Instanz passt, aber Hochverfuegbarkeit gefragt ist, ist Redis Sentinel oft die einfachere Loesung als ein vollstaendiges Cluster. Sentinel ueberwacht einen Master und mehrere Replicas, erkennt einen Ausfall des Masters automatisch und foerdert eine Replica zum neuen Master, ohne dass die Daten auf mehrere Slots aufgeteilt werden muessen.

Der wesentliche Vorteil von Sentinel gegenueber einem echten Cluster ist die Kompatibilitaet: alle Multi-Key-Operationen funktionieren weiterhin uneingeschraenkt, weil die gesamte Datenmenge auf einem einzigen Master liegt. Der Nachteil ist, dass Sentinel keine horizontale Skalierung der Schreiblast bietet, sondern ausschliesslich Ausfallsicherheit. Fuer Magento-Shops, die primaer Wert auf Verfuegbarkeit legen und deren Datenmenge auch in Zukunft in eine Instanz passt, ist Sentinel oft die pragmatischere Wahl als ein Cluster mit den zusaetzlichen Einschraenkungen bei Cache-Tags.

; /etc/redis/sentinel.conf: three Sentinel processes watch one master
port 26379
sentinel monitor mymaster 10.0.1.30 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 10000

# env.php pointing Magento at the Sentinel-managed master
# 'backend_options' => [
#     'server' => 'tcp://10.0.1.30:6379',
#     'persistent' => 1,
# ],

7. Sessions im Cluster: Stolperfallen vermeiden

Session-Daten sollten in der Praxis nie Teil eines gesharded Redis-Clusters sein, sondern immer in einer eigenen, dedizierten Instanz oder einem Sentinel-Setup liegen. Der Grund: PHP-Sessions in Magento werden ueber den Cm_Cache_Backend_Redis-Sessionhandler mit Locking-Mechanismen abgesichert, um parallele Requests desselben Nutzers korrekt zu serialisieren. Dieses Locking basiert auf einzelnen Schluesseln, deren Konsistenz in einem Cluster mit Failover-Fenstern schwerer zu garantieren ist als in einer einzelnen Instanz mit synchroner Replikation.

Ein weiteres Risiko ist die Slot-Migration waehrend eines laufenden Cluster-Rebalancings. Wenn ein Slot, in dem gerade eine aktive Session liegt, mitten im Checkout-Prozess auf einen anderen Knoten verschoben wird, kann es zu kurzzeitigen Lesefehlern kommen, die Magento als Session-Verlust interpretiert. Bei Sessions in einer dedizierten Nicht-Cluster-Instanz mit Sentinel-Failover tritt dieses Problem nicht auf, weil kein Rebalancing stattfindet, sondern nur ein klar definierter Failover-Wechsel im Fehlerfall.

8. Monitoring und Kapazitaetsplanung

Ein Redis-Cluster oder eine Multi-Instanz-Landschaft ohne kontinuierliches Monitoring ist ein Blindflug. Die wichtigsten Kennzahlen pro Knoten sind used_memory im Verhaeltnis zu maxmemory, die evicted_keys-Rate als Indikator fuer zu knapp bemessenen Speicher, und connected_clients im Verhaeltnis zum konfigurierten maxclients-Limit. Bei einem Cluster kommt zusaetzlich die Ueberwachung der Slot-Verteilung hinzu, um zu erkennen, ob einzelne Knoten durch ungleichmaessige Hash-Tag-Nutzung staerker belastet werden als andere.

Fuer die Kapazitaetsplanung empfiehlt sich ein einfaches Vorgehen: den durchschnittlichen Speicherbedarf pro aktivem Nutzer beziehungsweise pro Kategorie- und Produktseite messen, und daraus die erwartete Gesamtlast bei Traffic-Spitzen wie Black Friday hochrechnen. Ein Redis-Cluster sollte immer mit ausreichend Puffer dimensioniert sein, damit ein einzelner Knotenausfall nicht sofort zu Memory-Pressure auf den verbleibenden Knoten fuehrt, waehrend das Failover laeuft.

# Key metrics per node, run against each Redis instance in the cluster
redis-cli -p 7000 info memory | grep -E "used_memory:|maxmemory:"
redis-cli -p 7000 info stats  | grep -E "evicted_keys:|instantaneous_ops_per_sec:"
redis-cli -p 7000 info clients | grep "connected_clients:"

# Cluster-wide slot and node health check
redis-cli --cluster check 127.0.0.1:7000

# Simple capacity forecast: memory per active session times expected peak users
redis-cli -p 6380 info keyspace
# db0:keys=48213,expires=48213,avg_ttl=1780000

9. Cluster vs. dedizierte Instanzen im Vergleich

Die Entscheidung zwischen echtem Redis-Cluster und einfacher Rollenaufteilung auf dedizierte Instanzen haengt vom konkreten Engpass ab. Die folgende Tabelle fasst die wichtigsten Unterschiede fuer den Magento-Kontext zusammen.

In der Praxis zeigt sich: die meisten Magento-Shops erreichen mit sauberer Rollenaufteilung auf dedizierte Instanzen bereits eine sehr solide Skalierungsstufe. Ein echtes Redis-Cluster lohnt sich erst, wenn eine einzelne Rolle, meist der Objektcache bei mehreren Millionen Katalogeintraegen, selbst wieder an ihre Kapazitaetsgrenze stoesst und die zusaetzliche Komplexitaet des Slot-Managements gerechtfertigt ist.

10. Zusammenfassung

Der Skalierungspfad fuer Redis in Magento folgt in der Praxis fast immer derselben Reihenfolge: zuerst die Rollenaufteilung von Cache, Session und Full-Page-Cache auf dedizierte Instanzen, danach bei Bedarf Redis Sentinel fuer Hochverfuegbarkeit, und erst als letzter Schritt ein echtes Redis-Cluster mit Sharding fuer einzelne Rollen, die selbst zu gross fuer eine Instanz werden. Sessions sollten dabei nie Teil eines gesharded Clusters sein, weil das Locking-Verhalten und Slot-Migrationen mit dem Session-Handling kollidieren koennen.

Wer diesen Pfad einhaelt, vermeidet vorzeitige Komplexitaet und behaelt die Kontrolle ueber Cache-Invalidierung und Multi-Key-Operationen, die Magento intern nutzt. Monitoring von Speicherauslastung, Eviction-Rate und Slot-Verteilung ist in jeder Ausbaustufe Pflicht, damit ein Engpass erkannt wird, bevor er zu Ausfaellen im Checkout fuehrt.

11. FAQ: Redis-Cluster-Setup fuer Magento