Shopware hochverfügbar: Strategien für 99,9 % Erreichbarkeit

Für einen Onlineshop im Mittelstand oder im D2C-Bereich ist Downtime weit mehr als ein technisches Ärgernis. Jede Minute Unerreichbarkeit bedeutet direkten Umsatzverlust, sinkendes Vertrauen bei den Kunden und verschwendetes Budget für laufende Marketing-Kampagnen.

Wer als Agentur wachsen und größere Marken betreuen möchte, kommt an der Forderung nach Service Level Agreements (SLAs) von 99,9 % nicht vorbei. Doch diese Verfügbarkeit lässt sich mit einem klassischen Single-Server-Setup physikalisch nicht garantieren. Ein Hardware-Defekt, ein hängender Datenbank-Prozess oder eine einfache Kernel-Panik am Host-System führen sofort zum Stillstand. Hochverfügbarkeit erfordert ein Umdenken in der Architektur: Weg vom Einzelserver, hin zum verteilten System.

1. Die Applikationsschicht: Redundanz durch Pod-Orchestrierung

Der erste Schritt zur Hochverfügbarkeit in einer Kubernetes-Umgebung ist die horizontale Verteilung der Shopware-Instanz. Anstatt den Shop als einen großen Prozess laufen zu lassen, wird er in mehrere kleine, identische Einheiten (Pods) aufgeteilt.

• Multi-Node-Betrieb: Die Pods werden durch den Scheduler automatisch auf verschiedene physische Server (Nodes) im Cluster verteilt. Fällt ein Server komplett aus, bemerkt Kubernetes dies sofort und startet die fehlenden Pods auf den verbleibenden gesunden Servern neu.
• Health Checks: Kubernetes prüft kontinuierlich den Zustand jedes Pods (Liveness- und Readiness-Probes). Antwortet ein Shopware-Prozess nicht mehr korrekt – etwa wegen eines PHP-Memory-Errors - wird dieser spezifische Pod isoliert und neu gestartet, während die anderen Pods den Traffic unterbrechungsfrei weiterverarbeiten.

2. Die Datenbankschicht: Keine Kompromisse beim State

Die Datenbank ist oft das Nadelöhr und der kritischste “Single Point of Failure”. Für 99,9 % Verfügbarkeit setzen wir auf hochverfügbare Datenbank-Cluster (z. B. MariaDB oder MySQL mit Galera oder Group Replication):

• Automatisches Failover: Ein Cluster besteht aus mindestens drei Knoten. Fällt der primäre Schreib-Knoten aus, wählen die verbleibenden Knoten in Sekundenbruchteilen einen neuen “Leader”. Die Anwendung schreibt ohne manuellen Eingriff einfach weiter.
• Point-in-Time-Recovery (PITR): Neben täglichen Backups werden kontinuierlich Transaktionslogs (Binary Logs) gesichert. Das erlaubt es, den Shop im Ernstfall auf jede beliebige Sekunde in der Vergangenheit zurückzusetzen - ein entscheidender Schutz gegen menschliche Fehler oder korrupte Datenimporte.

3. Shared Resources: Redis und Dateisystem

Damit mehrere Shop-Pods gleichzeitig arbeiten können, müssen sie sich Informationen teilen, ohne sich gegenseitig zu blockieren:

• Zentrales Session-Management: Sessions werden nicht lokal im Dateisystem des Servers gespeichert, sondern in einem hochverfügbaren Redis-Cluster. So kann ein Nutzer während seines Einkaufs nahtlos von einem Pod zum nächsten geleitet werden (z. B. bei einem Update oder Skalierungsvorgang), ohne seinen Warenkorb zu verlieren.
• Repliziertes Dateisystem: Produktbilder und Dokumente liegen auf einem verteilten Storage-System, auf das alle Pods gleichzeitig Lese- und Schreibzugriff haben. Das verhindert Inkonsistenzen zwischen den Instanzen.

Fazit: Stabilität als Standard

Echte Hochverfügbarkeit für Shopware ist kein “Feature”, das man einfach zuschaltet, sondern das Ergebnis einer konsequent zu Ende gedachten Infrastruktur. Durch die Kombination aus orchestraler Verteilung, Datenbank-Clustering und zentralem Session-Management eliminieren wir den Single Point of Failure.

Für die Agentur bedeutet das: Man muss keine Angst mehr vor Hardware-Ausfällen beim Hoster haben. Für den Shopbetreiber bedeutet es: Absolute Verlässlichkeit, auch wenn der Traffic massiv ansteigt oder im Hintergrund Wartungsarbeiten laufen.

FAQ

Warum reicht ein Backup für Hochverfügbarkeit nicht aus? Ein Backup sichert die Daten, aber nicht den Betrieb. Ein Restore nach einem Serverausfall dauert oft Stunden. Hochverfügbarkeit zielt darauf ab, den Ausfall durch Redundanz gar nicht erst spürbar werden zu lassen.

Was ist der Unterschied zwischen vertikaler und horizontaler Skalierung? Vertikal (Scale-up) bedeutet, einem vorhandenen Server mehr CPU oder RAM zu geben – das hat physikalische Grenzen und erfordert oft einen Neustart. Horizontal (Scale-out) bedeutet, weitere Instanzen (Pods) hinzuzufügen. Das geschieht im laufenden Betrieb und bietet echte Redundanz.

Macht eine hochverfügbare Architektur den Shop langsamer? Im Gegenteil. Durch die Verteilung der Last auf mehrere Instanzen und die Nutzung von schnellen In-Memory-Datenbanken für Caching (Redis) verbessert sich die Antwortzeit meist spürbar, besonders unter Last.

Wie wird der Traffic auf die verschiedenen Pods verteilt? Ein Loadbalancer (Ingress-Controller) im Kubernetes-Cluster nimmt alle Anfragen entgegen und verteilt sie intelligent auf die gesunden Pods. Er erkennt automatisch, wenn ein Pod nicht bereit ist, und nimmt ihn aus der Verteilung.

Kosten hochverfügbare Setups deutlich mehr? Die Infrastrukturkosten steigen leicht an, da mehr Instanzen laufen. Dieser Aufwand steht jedoch in keinem Verhältnis zu den Kosten eines mehrstündigen Totalausfalls während einer umsatzstarken Phase wie dem Black Friday. Zudem optimiert Kubernetes die Ressourcenauslastung effizienter als klassische VMs.