Elasticsearch-Cluster-Sizing für Magento-Shops mit sehr großen Katalogen

1. Warum Standard-Sizing-Empfehlungen bei Magento oft nicht passen

Allgemeine Sizing-Leitfäden gehen meist von relativ schlanken Dokumenten mit wenigen Feldern aus, etwa Log-Einträgen oder einfachen Content-Datensätzen. Ein Magento-Produktdokument enthält dagegen häufig mehrere Dutzend indexierte Attribute, dazu Preisdaten pro Kundengruppe und Website sowie Kategoriezuordnungen, wodurch ein einzelnes Dokument deutlich größer ausfällt als bei den meisten generischen Sizing-Beispielen angenommen.

Erschwerend kommt hinzu, dass Magento für jede Store View mit eigener Sprache oder eigenem Preiskontext einen separaten Index anlegt, sodass die effektive Gesamtdokumentanzahl nicht der Produktanzahl im Katalog entspricht, sondern sich ungefähr aus Produktanzahl multipliziert mit der Anzahl relevanter Store Views ergibt. Ein Katalog mit 500.000 Produkten und sechs Store Views erzeugt damit potenziell drei Millionen indexierte Dokumente über alle Indizes hinweg.

2. Kennzahlen zur Kapazitätsplanung: Dokumentanzahl und Dokumentgröße ermitteln

Der erste Planungsschritt ist eine realistische Schätzung der Gesamtdokumentanzahl über alle Store Views hinweg, nicht nur der reinen Produktanzahl im Magento-Adminbereich. Dazu zählt auch, ob konfigurierbare Produkte zusätzlich zu ihren einfachen Varianten indexiert werden und ob deaktivierte oder nicht sichtbare Produkte im Index verbleiben, was die tatsächliche Zahl leicht unterschätzen lässt, wenn nur aktive Storefront-Produkte gezählt werden.

Die durchschnittliche Dokumentgröße lässt sich am zuverlässigsten direkt am bestehenden Index messen, indem die Gesamtgröße des Index durch die Dokumentanzahl geteilt wird, statt sie theoretisch aus der Attributanzahl herzuleiten. Bei Katalogen mit vielen mehrsprachigen Textattributen und langen Beschreibungen liegt die durchschnittliche Dokumentgröße in der Praxis häufig zwischen zwei und acht Kilobyte, kann bei sehr attributreichen B2B-Katalogen aber deutlich höher ausfallen.

# Durchschnittliche Dokumentgröße am bestehenden Index ermitteln
curl -s "https://search.example.com/catalogsearch_fulltext_de/_stats/store" \
  | jq '.indices[]._all.total.store.size_in_bytes as $size
        | .indices[]._all.total.docs.count as $docs
        | ($size / $docs)'

3. Shard-Sizing: Zielgröße und Anzahl der Primary Shards

Als allgemeine Richtgröße gilt ein einzelner Shard sollte zwischen zehn und fünfzig Gigabyte groß sein, weil zu kleine Shards unnötigen Verwaltungsoverhead erzeugen, während zu große Shards Recovery-Zeiten nach einem Node-Ausfall unnötig verlängern und einzelne Suchanfragen langsamer machen, weil jede Anfrage innerhalb eines Shards weiterhin sequenziell durch dessen Segmente laufen muss.

Die Anzahl der Primary Shards für einen Magento-Katalogindex ergibt sich damit direkt aus der erwarteten Indexgröße geteilt durch die Zielshardgröße, wobei ein gewisser Wachstumspuffer eingeplant werden sollte, weil sich die Shard-Anzahl eines bestehenden Index nachträglich nicht ändern lässt, ohne den Index per Reindex oder Split-Operation neu aufzubauen.

PUT /_index_template/magento_catalog_shards
{
  "index_patterns": ["catalogsearch_fulltext_*"],
  "template": {
    "settings": {
      "number_of_shards": 4,
      "number_of_replicas": 1
    }
  }
}

4. Replica-Konfiguration: Verfügbarkeit gegenüber Suchdurchsatz

Jede Replica erhöht sowohl die Ausfallsicherheit als auch den möglichen Lesedurchsatz, weil Suchanfragen über alle verfügbaren Kopien eines Shards, Primary und Replicas, verteilt werden können, kostet aber zusätzlichen Speicherplatz und zusätzliche Indexierungslast, weil jede Schreiboperation auf allen Kopien ausgeführt werden muss. Für Magento-Storefront-Traffic mit hohem Lesevolumen und vergleichsweise seltenen Reindex-Vorgängen ist eine Replica-Anzahl von eins bis zwei in der Regel ein guter Ausgangspunkt.

Bei Shops mit sehr hohem Suchvolumen zu Spitzenzeiten, etwa während saisonaler Verkaufsaktionen, lohnt sich eine temporäre Erhöhung der Replica-Anzahl vor dem erwarteten Traffic-Anstieg, weil zusätzliche Replicas als dynamisches Index-Setting ohne Neuaufbau des Index angepasst werden können und den Lesedurchsatz direkt proportional erhöhen, solange genügend Data Nodes für die Verteilung der zusätzlichen Kopien vorhanden sind.

5. Node-Anzahl und Hardware-Dimensionierung

Die Heap-Größe eines jeden Data Node sollte maximal fünfzig Prozent des verfügbaren Arbeitsspeichers betragen und dreißig bis zweiunddreißig Gigabyte grundsätzlich nicht überschreiten, weil oberhalb dieser Grenze die Java-Pointer-Kompression deaktiviert wird und der effektiv nutzbare Heap trotz mehr zugewiesenem Speicher paradoxerweise sinkt. Der verbleibende Arbeitsspeicher steht dem Betriebssystem für das Filesystem-Caching zur Verfügung, das für die Lesegeschwindigkeit von Segmenten mindestens ebenso wichtig ist wie der Heap selbst.

Für produktive Magento-Cluster ab einer gewissen Größe empfiehlt sich zudem die Trennung von Master-Nodes und Data-Nodes: Dedizierte Master-Nodes ohne Datenhaltung reagieren zuverlässiger auf Cluster-Zustandsänderungen, weil sie nicht gleichzeitig durch Indexierungs- oder Suchlast ausgelastet sind, was besonders während eines vollständigen Magento-Reindex mit hoher Bulk-Indexierungslast den Unterschied zwischen einem stabilen und einem instabilen Cluster-Zustand ausmachen kann.

6. Magento-spezifische Besonderheiten beim Sizing

Ein vollständiger Magento-Reindex erzeugt kurzzeitig eine deutlich höhere Schreiblast als der normale Betrieb, weil sämtliche Produktdokumente neu indexiert werden, während gleichzeitig der alte Index für die Storefront-Suche weiterhin bedient wird, sofern die Blue-Green-Reindex-Strategie von Magento genutzt wird. Diese Lastspitze muss beim Sizing explizit eingeplant werden, weil ein Cluster, der nur für den Normalbetrieb dimensioniert ist, während des Reindex an seine Grenzen stoßen kann.

Zusätzlich summiert sich bei vielen Store Views die Gesamtzahl gleichzeitig aktiver Indizes schnell, weshalb neben der reinen Datenmenge auch die absolute Anzahl der Indizes und Shards im Cluster im Blick behalten werden muss, da jeder Shard unabhängig von seiner Größe einen gewissen Grundoverhead an Cluster-State-Verwaltung verursacht, der sich bei mehreren Hundert Shards spürbar auf die Cluster-Stabilität auswirken kann.

7. Skalierungsschritte bei wachsendem Katalog

In der ersten Ausbaustufe reicht für kleinere Kataloge oft ein einzelner Node mit kombinierten Master- und Data-Rollen, solange die Gesamtindexgröße deutlich unter der verfügbaren Speicherkapazität bleibt und ein kurzzeitiger Ausfall geschäftlich verkraftbar ist. Sobald Ausfallsicherheit produktiv relevant wird, folgt die zweite Stufe mit mindestens drei Nodes, damit ein stabiles Quorum für die Master-Wahl auch bei einem einzelnen Node-Ausfall erhalten bleibt.

Bei weiterem Wachstum werden dedizierte Master-Nodes von den Data-Nodes getrennt, gefolgt von einer horizontalen Skalierung der Data-Nodes entsprechend der wachsenden Indexgröße. Auf der letzten, für sehr große Magento-Installationen relevanten Stufe lohnt sich eine Hot-Warm-Architektur, bei der neu geschriebene oder häufig durchsuchte Indizes auf performanter Hot-Hardware liegen, während selten genutzte, historische Daten auf günstigerer Warm-Hardware verbleiben.

8. Kapazitätstest und Benchmark-Methodik

Theoretische Sizing-Berechnungen sollten vor einem produktiven Rollout immer durch einen realistischen Lasttest validiert werden, weil sich reale Query-Muster einer Magento-Storefront, gemischt aus Volltextsuche, Layered-Navigation-Aggregationen und Sortierungen, nur bedingt aus abstrakten Kennzahlen ableiten lassen. Werkzeuge wie Rally erlauben es, einen realistischen Anfragemix nachzubilden, der die tatsächliche Query-Verteilung eines produktiven Magento-Shops widerspiegelt statt einer synthetischen Gleichverteilung einfacher Suchbegriffe.

Ein aussagekräftiger Benchmark simuliert dabei nicht nur Normal-Traffic, sondern auch die Lastspitze eines laufenden Reindex parallel zu aktivem Storefront-Traffic, weil genau diese Kombination in der Praxis am häufigsten zu Performance-Problemen führt. Ergebnis des Benchmarks sollte eine belastbare Aussage sein, bei welcher Node- und Shard-Konfiguration die Antwortzeitverteilung innerhalb der geschäftlich akzeptablen Grenzen bleibt.

9. Monitoring-Kennzahlen zur laufenden Validierung des Sizings

Nach dem produktiven Rollout ersetzt kontinuierliches Monitoring die einmalige Sizing-Entscheidung nicht, sondern validiert sie fortlaufend anhand realer Kennzahlen: JVM-Heap-Auslastung nahe der konfigurierten Obergrenze deutet auf zu knapp dimensionierten Speicher hin, während eine dauerhaft hohe Anzahl an Rejected Threads im Such- oder Indexierungs-Thread-Pool auf eine unzureichende Node-Anzahl für die aktuelle Last hindeutet.

Ebenso wichtig sind Latenz-Perzentile, insbesondere das 95. und 99. Perzentil statt reiner Durchschnittswerte, weil einzelne langsame Ausreißer bei Magento-Storefront-Anfragen direkte Auswirkung auf die wahrgenommene Nutzererfahrung haben, auch wenn der Durchschnitt weiterhin unauffällig aussieht. Ein regelmäßiger Abgleich dieser Kennzahlen mit den ursprünglichen Sizing-Annahmen zeigt frühzeitig, wann die nächste Skalierungsstufe fällig wird.

10. Zusammenfassung

11. FAQ: Cluster-Sizing für große Kataloge