Magento Hosting Architektur-Modelle

Eingehender Traffic wie echte Kunden, Suchmaschinen-Bots, Security-Scanner, Brute-Force-Versuche, böse IPs, Spam-Bots und sonstiges Hintergrundrauschen aus dem Internet. Aktuell sind über 30% aller HTTP-Requests weltweit Bot-Traffic — bis 2027 wird Bot-Traffic den menschlichen überholen!

Diese Schicht hält den unerwünschten Traffic von den nachfolgenden Schichten fern, schont so Ressourcen und sorgt vor allem für ein ungestörtes Einkaufserlebnis. OPNsense, SafeLine und PARC Security ergänzen sich gegenseitig: Die OPNsense Firewall blockt auf Layer 3/4 (Ports, IP-Bereiche, ungewollte Verbindungen). Die SafeLine Web Application Firewall mit semantischer Angriffs-Erkennung filtert auf Layer 7 (SQL-Injection, XSS, Bot-Traffic, Credential-Stuffing). Das PARC Security-Modul versorgt OPNsense und SafeLine mit aktuellen Blacklists und stellt IP-Gruppen für gute wie böse Bots bereit, auf denen viele WAF-Regeln basieren. Interessant zu wissen: Klassische CDN-WAFs wie Cloudflare, Akamai oder AWS CloudFront terminieren TLS auf ihrer Edge — der Traffic wird dort zur Inspektion entschlüsselt und ist dadurch technisch einsehbar. SafeLine terminiert TLS und entschlüsselt auf eurer eigenen Infrastruktur!

Varnish liefert Anfragen direkt aus dem Cache (Full-Page-Cache, FPC), ohne dass die nachfolgenden Schichten — Nginx, PHP-FPM, Datenbank — aktiv werden müssen. Das spart nicht nur Ressourcen, sondern hat als Konsequenz erheblichen Einfluss auf die Ausliefergeschwindigkeit der Seiten. Produkt- und Kategorieseiten werden beispielsweise blitzschnell ausgeliefert.

In unserer Architektur sind Frontend und Backend standardmäßig getrennt. Der Kunde wird durch Indexer, längere Crons oder große Import-/Export-Vorgänge nicht bei seinem Einkaufserlebnis gestört. Aber auch die Sicherheit wird durch die Trennung verbessert: Das Magento-Backend (Admin-Interface) ist beispielsweise nur über VPN oder IP-Restriktionen erreichbar. Außerdem ermöglicht die Trennung die horizontale Skalierung des Frontends — bei wachsendem Traffic werden mehrere Frontend-Nodes parallel betrieben, während Backend, Cron und Indexer zentral bleiben. RabbitMQ verteilt asynchrone Magento-Aufgaben (Massen-Attribut-Updates, Bilder-Generierung, Exports, ERP-Sync) auf einen oder mehrere Worker, damit der Server nicht überlastet wird — und macht eine horizontale Frontend-Skalierung erst sauber möglich.

Die Hauptdatenbank ist MariaDB — bewusst statt MySQL, weil sie sich bei Bedarf direkt in einen Galera-Cluster (mit ProxySQL als Router) umwandeln lässt. OpenSearch übernimmt die Produktsuche und lässt sich analog durch eine Coordination-Node und weitere Such-Instanzen horizontal skalieren. Redis hält die Frontend- und Backend-Sessions.

Bei der Infrastruktur setzen wir grundsätzlich auf dedizierte Server auf Basis von Proxmox VE. Jeder Dienst läuft gekapselt in einer eigenen VM — Optimierung, Skalierung und Updates passieren gezielt dort, wo es nötig ist. Das Setup ist von Anfang an so ausgelegt, dass es sich jederzeit um weitere Cloud- oder dedizierte Server erweitern lässt, um mehr Ausfallsicherheit und Performance zu erreichen.

Die SafeLine WAF hat jeweils einen Upstream pro Standort. Fällt ein Standort weg, schwenkt die WAF automatisch auf den verbleibenden Varnish um.

Magento Open Source kann nur einen DB-, einen Redis- bzw. einen OpenSearch-Server adressieren — Lastverteilung und Failover sind nicht eingebaut. Deshalb übernehmen ProxySQL (DB), HAProxy (Redis) und der OpenSearch Coordinator (Suche) das Routing. Pro Standort ein Nginx Frontend — für mehr Last und mehr Ausfallsicherheit. Backend Admin-Panel und Backend CLI/Index sind auf einzelne Standorte verteilt.

Der Galera-Cluster repliziert die Datenbank synchron über beide Standorte und die Cloud. OpenSearch läuft analog als 3-Knoten-Cluster. Redis ist auf jedem Standort vorhanden.

Zwei dedizierte Server statt einem — geografisch auf zwei Standorte verteilt. Die Cloud-Schicht wird um Routing- und Quorum-VMs erweitert.