Large-Scale Magento. Aspekte, Probleme, Strategien. Dr. Utz Westermann. Technischer Architekt, Optaros

Transkript

1 Large-Scale Magento Aspekte, Probleme, Strategien Dr. Utz Westermann Technischer Architekt, Optaros Meet Magento, Leipzig,

2 Einige Körner Wahrheit Magento wurde für kleine Händler gebaut; es nichts für große Jungs wie uns Magento ist gut, um schnell einen netten Shop hochzuziehen, skaliert dann aber nicht Die Architektur von Magento ist toll, aber overengineered und damit ineffizient Magento ist nicht Enterprise-Ready: wir wickeln unsere Produkt-, Bestands- und Rechungsverwaltung komplett in unserem BIG-ERP ab Magento ist nicht Enterprise-Ready: keine Dokumentation 2

3 gleichzeitig aber nutzt Optaros Magento in Großprojekten namhafte Kunden TelKo Fernsehsender hohe Last viele Order (Beispiel: Import von 10 Mio Alt-Ordern) viele Nutzer (Beispiel: /h, Order/h) hoher Integrationsgrad vielzahl von Backoffice-Anbindungen (Beispiel: > 30 Systeme) 3

4 Warum tun wir uns das an? Magento hat viele Vorteile modernes e-commerce-system zeitgemäßes Arsenal an Verkaufsmitteln und Funktionen hohe Modularität Quelloffenheit hohe Anpassbarkeit an Kundenanforderungen Daten Funktion Nutzerschnittstelle Marktplatz für Erweiterungen Dynamische Entwicklergemeinde Vielzahl an Erweiterungen von Drittanbietern 4

5 Ziele der Präsentation Überblick verschaffen über relevante Aspekte der Magento-Architektur, daraus entstehende Probleme und Ansätze zu deren Lösung bei der Skalierung von Magento nicht nur Performanz / Lastskalierung Integration mit Unternehmensprozessen operative Skalierung Kernaussage Large-Scale-Magento ist möglich wenn auch nicht trivial zu erreichen und Kreativität bedürfend 5

6 Aspekt Magento ist eine PHP-Web-Anwendung auf MySQL-Datenbank einfacher Ansatz wohlverstanden und oft implementiert grosses Reservoir an Entwicklern Vielzahl von Bibliotheken interpretierte Sprache schneller Roundtrip während Entwicklung dynamisch getypte Sprache Flexibilität und Ausdrucksmächtigkeit Beispiel: Automatische Getter / Setter- Generierung zur Laufzeit in Magento Vielzahl an Hosting-Optionen 6

7 Resultierende Skalierungsprobleme Niedrigere Ausführungsgeschwindigkeit im Vergleich zu JIT-basierenden oder nativen Alternativen durch Parsen und Interpretieraufwand Höhere Prozessorlast durch Parsen der Quelldateien durch Interpretation im Vergleich zur Maschinencodeausführung Höhere IO-Last pro Request Quelldateien zu laden requestabhängig weitere nachzuladen Magento-Code > 6000 PHP-Dateien Einsatz von Compilern a la HipHop schwierig dynamischer Code dynamisches Laden von Erweiterungsmoduln 7

8 Lösungsstrategien Load-Balancing IO-/Prozessorlastverteilung Content-Delivery-Network Zugriff auf statische Inhalte von PHP- Servern fernhalten separate Web-Server-Infrastruktur orts- oder lastbasierte Verteilung Byte-Code Cache Aufbewahrung der interpretierten Zwischenrepräsentation der PHP-Dateien Vermeidung von IO durch Quellcodezugriff Vermeidung von Parsing-Last verteilter Cache im Load-Balancing-Fall (memcached) 8

9 Aspekt Modulares Template-System erweitertes MVC-Konzept Controller deligieren Seitenaufbau an Template-System Layout-Definitionen Blocks Block-Templates Layout: XML-Dateien Templates: PHP-Dateien Paketierung / Fallback- Mechanismus UI-Package-Verzeichnis Delta zu Standard-Templates + Layout-Dateien Wiederverwendung von Blocks Modularisierung der UI hohe Anpassbarkeit der UI 9

10 Resultierende Skalierungsprobleme Nochmals erhöhter Aufwand bei der Request-Verarbeitung durchaus komplex wegen Fallback-Mechanismus parsen und verarbeiten der Layout-Dateien Zusammenfügung zu einer einheitlichen Layout-Definition pro Block i.d.r. eine Template-Datei Sowohl IO als auch CPU-Aufwand Upgrade auf neue Magento Version kann erschwert werden UI-Package ist oft Delta zur Standard UI Führt zu enger Abhängigkeit mit Struktur der Standard UI Problem bei Strukturänderung 10

11 Lösungsstrategien Layout-Definitionen cachen reduziert IO/und Prozessorlast vermeidet Kitten von Layout-XML-Dateien per Konfiguration Blocks cachen Blockausgaben aufbewahren sinnvoll bei Blocks, wo Inhalt sich wenig ändert erfordert Subclassing der Block-Klassen Fullpage-Cache aktivieren Teil der Enterprise-Edition gut für nutzerübergreifend einheitliche Seiten Homepage, Produkt- und Kategorieseiten nicht-statische Elemente durch AJAX nachladen Seiten schon im Reverse Proxy cachen z. B. Varnish Verkehr gar nicht erst zu PHP durchlassen 11

12 Lösungsstrategien Upgrade-Problematik von UI-Packages Ablage kompletter Themes nicht nur ein Delta zu Standard-Themes Nachteil: man profitiert nicht von Ergänzungen zu Standard-Themes 12

13 Aspekt EAV-Datenmodellierung Entity-Attribute-Value Metamodell auf rel. Modell Vorteile Entitäten und deren Attribute zur Laufzeit änderbar z. B. durch Admin-UI fixes Datenbankschema Zero-Code-ORM Performanzsteigerung durch Tabellen für unterschiedliche Entity-Types denormalisierte Indextabellen mit allen Entity-Attributwerten Hotspots mittlerweile ohne EAV Bestellungen und Rechnung 13

14 Resultierende Skalierungsprobleme Komplexität der Datenbankabfragen Joins zur Überbrückung der Indirektion in EAV Anfrageprogrammierung über Magento PHP ORM am bequemsten direktes SQL schwierig Aushebeln von Datenbankoptimierung Value-Tabellen fassen Werte unterschiedlicher Attribute zusammen mindert Effizienz von Datenbankindexen Erzeugung von Hotspots Anfragen auf unterschiedlichen Entity-Typen arbeiten auf gleichen Tabellen Sperrprobleme 14

15 Resultierende Skalierungsprobleme Indextabellen mindern Problematik führen aber zu starken Redundanzen erfordern Speicher und Rechenaufwand zur Erzeugung speichern eines Simple Products via ORM braucht 1-2 Sekunden SQL-Updates machbar aber nicht trivial Systemintegration Massendatentransport via Magento PHP-Stack schwierig z.b. täglicher Abgleich von Produktvarianten mit ERP-System Betrieb hohe Konfigurationsdatenmengen in DB Deployment via DB-Dump skaliert nicht 15

16 Lösungsstrategien Leistungsstarke DB-Server viel RAM RAID für parallele IO viele CPU-Kerne DB-Lastverteilung DB-Master-Server für Schreibzugriffe Slave-Server für Lesezugriffe asynchrone Logdateikopplung MySQL-Caches / Puffer hochsetzen Sort Buffer Read Buffer Experimentell DB-Logdateien der Slaves auf RAM- Disks Query Cache Table Cache 16

17 Aspekt Magento ist modular Funktionen in Extensions organisiert Extensions stellen bereit u.a.: Blocks Models Controller (Business) Event Handler Setup Skripte Extensions sind versioniert Extensions können neue Funktionalität hinzufügen existierende Funktionalität abändern (Patching) durch Subclassing 17

18 Resultierende Skalierungsprobleme Nochmals erhöhter IO-Aufwand bei der Request-Verarbeitung Nachladen der Extension Modules Generell hohe Zahl an PHP-Quelldateien Upgrade auf neue Magento Version kann erschwert werden Funktionsanpassung im wesentlichen via Subclassing Subclassing = enge Abhängigkeit zur Implementierung der Superklasse Problem bei Änderung der Superklasse Risiko der Inkompatibilität von Extension Modules Patching durch Subclassing geht nur einmal manche Module können deshalb nicht miteinander verwendet werden erhöhtes Risiko, je mehr Module miteinander verwendet werden sollen 18

19 Lösungsstrategien Upgrade auf neue Magento Version bzw. Modulinkompatibilität Vermeidung von Subclass-Patching von Core-Klassen Alternative: Delegation von Logik an separate Klassen über Event-Handler Nutzung der Setup-Skripte Automatisierung manueller Administrationsarbeiten nicht: Nutzung der Admin-UI mit nachfolgenden unhandlichen DB-Dumps stattdessen: Manipulation der Konfigurationseinstellungen in Setup-Skripten dediziertes Extension Module für Setup-Arbeiten kann sinnvoll sein Deployment-Strategien Deployment von Magento-Code via SVN / FTP oft problematisch schwieriges Konfigurationsmanagement Sicherheitsproblem (Zugriff auf Quellcodeverwaltung in Produktionssystem) Rollenverständnis: Entwickler vs. Administrator erstellen von Installationspackages a la RPM oder PEAR kann sinnvoll sein 19

20 Aspekt Integration: Magento bietet Web- Service-Schnittstelle Core-API setzt auf internen Magento API-Stack auf protokollunabhängig generischer SOAP-Wrapper generischer XMLRPC-Wrapper erlaubt Batching von Aufrufen (multicall) erlaubt Kommunikation externer Applikationen mit Magento Abdeckung Kundendaten Produkte und Kategorien Bestellungen, Rechnungen, Versand Bestand lesen und schreiben 20

21 Resultierende Skalierungsprobleme Performanz Core-API-Implementierung setzt auf Magento-Stack auf insbesondere bei Updates: RPC-Overhead + EAV-/Index-Overhead zeitkritischer Massendatentransport schwierig zu realisieren Systemintegration SOAP nur über generischen Wrapper unterstützt keine Funktion: createorder() stattdessen: call( createorder ) erschwert Anbindung mittels Enterprise-Middleware BizTalk, TIBCO Business Works & Co. grafische XML-Mapping-Werkzeuge Dokumentation Core-API nur mäßig dokumentiert Ermitteln des genauen Methodenverhaltens oft über Trial & Error 21

22 Lösungsstrategien Regelmässiger Massendatentransfer direkter Zugriff auf DB Umgehung der Web-Service-Schnittstelle Beispiele stündliche Aktualisierung des Warenbestandes aus ERP-System mit großem Produktkatalog tägliche Aktualisierung von Preisen aus ERP- System bei großem Produktkatalog Initialtransfer von vielen Altbestellungen aus Altsystem bei Replatforming 22

23 Aspekt Magento ist ein synchrones System komplette Verarbeitung eines Nutzer-Request von vorne bis hinten Beispiel: Checkout und Bestellerzeugung Event Hooks: nicht nebenläufig verarbeitet sondern sequentiell 23

24 Resultierende Skalierungsprobleme Lastskalierung nur über mehr Hardware möglich nicht über Zeit z. B. keine asynchrone, nachgelagerte Bestellverarbeitung Systemintegration Datentransfer mit externen Systemen über Event Hooks möglich jedoch verlangsamt dies Request-Verarbeitung Beispiel: Bestellübermittlung an ERP-System Event Hook: checkout_type_onepage_save_order Hook ruft Web-Service des ERP-System Nutzer spürt Kommunikationslatenz bei Klicken auf Kaufen-Button 24

25 Lösungsstrategien Entkopplung von Integration über Message Queues Nutzung von Event Hooks einzige Aktion: lege Nachricht auf Message Queue Nachrichtenabarbeitung von Queue durch externen Prozess Kommunikation mit externer Anwendung asynchron 25

26 Lösungsstrategien Entkopplung von Integration durch Polling externer Prozess fragt Magento in regelmäßigen Intervallen nach Änderungen Datenbankzugriff oder Web-Service-Aufruf Änderungen werden gesammelt an externe Anwendung übermittelt 26

27 Zusammenfassung Vielzahl von Aspekten beeinflussen Skalierbarkeit von Magento Generelle PHP-Eigenschaften Template-System Extension Modul-System Web-Service-API Synchonität bei jedem Aspekt gibt es Skalierungsprobleme aber eben auch Strategien zur Überwindung der Probleme viele der Strategien sind nicht unbedingt Magento-spezifisch ebenfalls sinnvoll bei Skalierung anderer Web-Anwendungen 27

28 Vielen Dank für Ihre Aufmerksamkeit Large-Scale Magento mag oftmals so wirken mitnichten aber so 28