Catch up: die ersten Tage von alpha.otto.de

Donnerstag, 28.2.2013: Livegang alpha.otto.de

Um 12:00 wurden die ersten paar tausend Einladungen an Kunden versendet, die ersten „echten“ Kunden trudeln ein: alpha.otto.de, ist live! Eine vollständig neu entwickelte Shop-Plattform, die ab Herbst die Grundlage für otto.de bilden wird.

Mit der Alpha Version wollen wir erste Erfahrungen in der freien Wildbahn sammeln, den Betrieb der Plattform üben und – vor allem – Feedback von Kunden für die Weiterentwicklung erhalten.

Die technischen Grundlagen:

  • vertikal geschnittenes, verteiltes, lose gekoppeltes System
  • Integration über Edge-Side Includes
  • Varnish als Reverse Proxy und LoadBalancer
  • F5 Server für das HTTPS offloading
  • REST-Schnittstellen in den einzelnen Systemen
  • Dedizierte MongoDB-Cluster pro Vertikale.
  • Fredhopper Search Engine
  • Prudsys RDE für automatische Produktempfehlungen
  • Alle Anwendungen laufen auf virtuellen Maschinen.

Wir erwartet sehen wir im Laufe des Tages ca. 2500 verschiedene Kunden. Bestellungen kommen herein, gute Performance, alles prima.

Freitag, 1.3.2013: Erste Schwierigkeiten

Gegen 12:15 gibt es Probleme mit dem Tracking: wir sehen keine Daten mehr im Reporting. Für den Betrieb ist das zwar nicht schlimm, wir sehen allerdings nicht mehr ohne weiteres, wie viele Kunden im Shop unterwegs sind.

Um 16:00 bekommen wir Alarmmeldungen: Die Festplatten der MongoDB Server laufen langsam voll. Wir wussten, dass der Platz knapp ist, dachten aber, dass es über das Wochenende reichen würde.

Lhtose SPoCDie SPOCs („Single Point of Contact“ aka First-Level Support) fahren nacheinander die Knoten des Replica-Set herunter, konfiguriert die VMs mit mehr Plattenspeicher, startet neu und wartet jeweils auf die Synchronisation der einzelnen DB Instanzen. Das funktioniert reibungslos und anscheinend ohne Ausfall. Virtualisierung hat schon den einen oder anderen Vorteil…

Das System läuft weiterhin stabil – was sich allerdings kurz nach Feierabend ändert – war ja klar :-/

18:30: Ich bin mittlerweile zu Hause und checke das System. P13N hat Probleme, einzelne Instanzen werden vom LoadBalancer aus der Verteilung genommen, die Einstiegsseiten – das sind die ersten Ebenen in der Navigationsstruktur – haben teilweise keinen Content mehr. Vermutung nach erster Analyse: Der Hauptspeicher der VMs ist zu knapp, bzw die Tomcats sind mit zu viel Speicher konfiguriert.

Ich erwische Markus (Ops). Er startet die Server nacheinander durch und rekonfiguriert dann die VMs mit 6GB anstelle von 4GB. In der Lasttest-Umgebung hat das schon einmal geholfen; eigentlich sollte es auch reichen, die Tomcats mit weniger Speicher zu konfigurieren, das haben wir aber noch nicht ausprobiert.

Die Varnish Instanzen mussten danach ebenfalls durchgestartet werden, da sie die mittlerweile neu gestarteten Server anscheinend nicht gefunden haben.

Anscheinend haben wir einen wichtigen Test unterlassen: einen über mehrere Tage laufenden Lasttest.

Das Search and Navigation System (SAN) hat ebenfalls Probleme: einzelne Kacheln der Suchergebnisliste bleiben leer, die Seite sieht nicht gut aus. Später stellt sich heraus, dass die Ursache dafür inkonsistente Produktdaten sind: Das SAN System findet Produkte, die das Product-System nicht mehr kennt. Das gleiche Problem sehen wir im Personalization (P13N) System: es werden Produkte empfohlen, die nicht mehr vorhanden sind.

Samstag, 2.3.2013: Ruhe

Die Systeme haben sich wieder synchronisiert und laufen stabil. Alles prima.

Sonntag, 3.3.2013: Datenbankprobleme

12:00 Systeme geprüft, mit Ausnahme des noch immer keine Daten liefernden Tracking-Servers läuft alles rund.

Unsere Einstiegsseiten (bzw. die „ContentAreas“ auf den Seiten) sind serverseitig ausgesprochen schnell: die 90%-Linie liegt bei 60ms, die 99%-Linie bei 150ms. Selbst die Top-Werte sind anscheinend vollkommen in Ordnung. Die Last ist natürlich gering, 2000 Kunden pro Tag bringen das System nicht gerade an den Anschlag. Tatsächlich macht es mich kurz stutzig, dass ich auf der Storefront einen konstanten Traffic mit ca. 50 Aufrufen der Storefront pro Minute sehe. Das ist viel zu konstant um real zu sein. Die konstante Linie passt auch nicht mit den Aufrufen der Artikeldetailseiten zusammen – die schwankt nämlich und ist deutlich niedriger. Nach Rückfrage stellt sich heraus, dass das Tasseo Dashboard regelmässig die Storefront prüft.

Wir sollten eine „bekannte“ visitorId für diese Art Monitoring verwenden, damit wir echte (von Kunden kommende) von künstlichen Requests unterscheiden können.

Um viertel nach drei ist P13N für ca. zehn Minuten down. Der Varnish hat alle Instanzen aus der Verteilung genommen. Die Graphen der AppServer sehen in Ordnung aus, dieses mal liegt es nicht an den Speichereinstellungen.

Tom hat das Problem ebenfalls gefunden – wir analysieren…

  • Der Master-Node der Datenbank ist weg, der Cluster hat mittlerweile auf einen anderen Node umgeschaltet. Der bisherige Master ist nicht mehr erreichbar und muss durchgestartet werden.
  • Die Load auf dem Master war mit ca. 3 ungewöhnlich hoch, während die CPU nichts zu tun hatte. Eigentlich sollte die Datenbank sich furchtbar langweilen…

Unklar ist zunächst, warum die DB zehn Minuten für den automatischen switch des Master-Nodes auf einen anderen Master benötigt hat und weswegen das clientseitig zu Problemen geführt hat.

Nach etwas Recherche komme ich auf die MongoDB ReadPreferences: Die Standard-Einstellungen sehen vor, dass ausschließlich vom Master gelesen wird. Im Failover-Fall werden Zugriffe dann mit einer Exception beantwortet. Man kann jedoch auch auf PrimaryPreferred umschalten: Die Anwendung greift dann während eines Failovers lesend auf die Secondaries zu. Das erklärt zwar nicht den Ausfall des Masters, hilft uns aber möglicherweise, mit einem solchen Ausfall besser umgehen zu können.

Die Änderung ist eine Sache von Minuten, morgen werden wir ein Deployment durchführen.

Montag, 04.03.2013: Nochmal DB

Die Server liefen im laufe des Tages stabil, allerdings sehen wir wieder eine Load von 3 bei verhältnismässig geringer Last auf den Systemen. Da wir gleichzeitig IOWaits auf den DB-Servern beobachten, vermuten wir eine zu knappte Konfiguration des Hauptspeichers der MongoDB:

Die VM der MongoDB ist mit 8GB konfiguriert - zu wenig für 20GB Daten.

Die VM der MongoDB ist mit 8GB konfiguriert – zu wenig für 20GB Daten.

Die Server sind mit 8GB konfiguriert, wobei wir ca. 15GB Daten und 4,5GB Index haben. Das ist nicht gut: Das Working-Set der Daten und der Index sollten bei der MongoDB in den Hauptspeicher passen.

Die SPOCs fahren nacheinander die DB-Nodes herunter, konfigurieren mehr Memory, fahren hoch, warten die Synchronisation ab – usw, bis alle DBs mit 20GB laufen. So langsam bekommen sie darin Übung.

Während des switches sieht die Load der P13N so aus:

Load der P13N VMs während eines DB-Failovers

Wir nutzen die Chance und analysieren die Auswirkungen des DB-Failovers. In den Logfiles finden wir während des Switches ca. 1000 Fehlermeldungen:

  • Die Delta-Importe der Datenversorgung etc. brechen mit einem Fehler ab, da sie nicht schreiben können. Das ist aber ok, die (regelmässig laufenden) Jobs versuchen es dann einfach später noch mal an der selben Stelle.
  • Einzelne Requests (drei Requests – aber es war auch nicht viel los…) von Kunden können nicht personalisiert ausgespielt werden, da das Pseudonym nicht aktualisiert werden kann. Die Exceptions werden dabei sauber gefangen und die Kunden bekommen das, was auch ein Anonymus User (oder Google Bot) sieht. Keine für den Kunden erkennbaren Fehler.

Donnerstag, 07.03. Blog über alpha.otto.de

Der erste Blog-Eintrag über alpha.otto.de wird veröffentlicht: http://www.drivenbydata.org/2013/03/alpha-otto-neuer-shop.html

Freitag, 08.03. Speicher auf den Live-VMs

Pünktlich zum Wochenende läuft auf den Live-Servern der Speicher voll. Nichts, was wir nicht die letzten Tage schon hätten sehen können – aber immerhin eine gute Chance, sein Monitoring und Alarming zu justieren.

 Memory-Leak

Die Kurve zeigt den Speicherverbrauch eines P13N AppServers im Verlauf der Woche. Nachdem wir den Speicher der VMs von 4 auf 6GB erhöht haben, stand zunächst ausreichend zur Verfügung. Im Laufe der Tage stieg der Verbrauch aber in kleinen Sprüngen (grüne Kurve) an, bis er nicht mehr ausreichte und das System ins swappen (roter Bereich) kam.

Parallel mit dem Anstieg des Speicherverbrauchs steigt auch die Anzahl der laufenden Threads auf dem System:

Threads

Die VMs geraten ins swappen, obwohl der JVM Heap ziemlich konstant ist:

JVM Heap

Wie man sieht, ist der Heap sogar deutlich zu großzügig bemessen. In einem Lasttest haben wir bereits mit niedrigeren Einstellungen experimentiert; im nächsten Schritt werden wir daher den Max Heap der JVM schrittweise reduzieren.

Schließlich findet sich die Lösung in einem fehlerhaften Init-Skript: durch Puppet-Änderungen werden neue Logstash-Prozesse neu gestartet. Im Laufe der Tage sammelt sich so einiges an, bis der zur Verfügung stehende Speicher irgendwann zur Neige geht.

Guido Steinacker, Jahrgang 1969, Diplom-Informatiker. Nach mehreren Stationen in der Software-Entwicklung verschiedener mittelständischer Unternehmen stieß er 2009 zu OTTO. 2010 entwickelte er im Rahmen von Prototypen die Grundlagen für die neue Shop-Architektur von otto.de und ist mittlerweile als Executive Software-Architekt im Bereich E-Commerce tätig.

Veröffentlicht in Grundlagen, Operations

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: