Container based hosting: sicher nicht ohne LPT!

Ob AWS, GCP, Azure Cloud oder doch selbst gehostet mit Kubernetes oder OpenShift: Container based Hosting ist mittlerweile sehr etabliert oder ein Umstieg darauf zu meist bereits geplant.

CBH: Virtualization on Steroids

CBH bietet die Möglichkeit, Application Container (meist auf Docker Basis) zu hosten und darüber hinaus viele Enterprise Features wie z.B. das Zusammenfassen von mehreren Applikations-Instanzen zu logischen Services oder die Aufteilung dieser Instanzen auf verschiedene physische Nodes, automatische Restarts im Fehlerfall oder Skalieren dieser Instanzen aufgrund bestimmter Kennzahlen wie CPU Load: wertvolle Features, die moderne und robuste Infrastrukturen ermöglichen.

Ein großer und stark unterschätzter Unterschied zu Standard Virtualisierung ist die „Größe“ der virtuellen Maschinen bzw. Container: wurde früher das ganze Betriebssystem inkl. Web- und Applicationserver virtualisiert, teilt man die Applikation bei CBH in viele kleine(re) Komponenten (Container): da gibt es Container für die Datenbank, einen für das Backend der Hauptanwendung, einen für das Admin-Interface, einen für das Customer-Interface... Das bringt Flexibilität, aber auch Komplexität mit sich.

Damit einher verändert sich die Art der Skalierung: bei klassischer Virtualisierung hat man eher auf starke virtuelle Maschine gesetzt und bei Bedarf noch mehr RAM oder CPU zugewiesen, horizontale Skalierung war eher die Ausnahme und fast immer mit zusätzlicher (und zum Teil aufwendiger) Konfiguration verbunden. Mit CBH wird vorwiegend horizontal skaliert: sind zu viele Anfragen am Backend der Hauptanwendung? Man startet einfach eine zweite Instanz derselben Komponente, die wird automatisch in den Service integriert und die Anfragen auf beide Instanzen verteilt.

^{Abbildung: (Quelle: klemens loschy - SEQIS GmbH)}

Der Umstieg: Ein steiniger Weg

Auch wenn CBH eine Vielzahl von Vorteilen mit sich bringt, birgt der Umstieg auch viele Risiken: Die korrekte Funktionsweise der Konfiguration muss getestet werden! Das ist an sich nichts Neues und darauf habe ich schon in älteren Blog-Beiträgen hingewiesen (immer wieder sind und waren Performance Probleme auf falsche Konfiguration zurückzuführen, auch lange vor CBH), nur mit CBH erreicht der Konfigurationsaufwand bzw. die Menge an Konfigurationsmöglichkeiten und deren Komplexität ein ganz neues Level. Zusätzlich sollte die Applikation in kleine Komponenten zerlegt werden, was oft mit einer nicht trivialen Anpassung der ganzen Applikation einhergeht. Zu diesem Zeitpunkt muss verstärkt durch fachliche Tests die korrekte Funktionsweise sichergestellt werden, aber schon jetzt kann man mit Hilfe von punktuellen und gezielten Lasttests erste aussagekräftige Ergebnisse erzielen. Im Normalfall ist man hierbei noch weit weg von einer produktionsnahen Simulation und die Ergebnisse sind somit nicht 1:1 auf den Produktivbetrieb anwendbar, dafür ist der eigentliche Aufwand für den Lasttest viel geringer und man bekommt schon sehr frühe erste belastbare Ergebnisse.

LPT for the win!

Ein Last- und Performancetest hilft dabei, diverse Fragestellungen im simulierten Produktionsbetrieb zu beantworten: werden die Instanzen bei hoher Last automatisch skaliert? Wie sehr profitiert meine Applikation von mehreren Instanzen? Werden diese Instanzen bei geringer Last auch wieder entfernt? Funktioniert das Skalieren unterbrechungsfrei oder kann das doch zu unerwarteten Fehlern führen?

Aber auch betriebsrelevante Fragen können geklärt werden: Was passiert, wenn während des Betriebs eine physische Node einfach wegbricht? Wie kurz (oder lange) dauert es, bis alle Instanzen auf anderen Nodes wieder gestartet und in die Services integriert und damit betriebsbereit sind? Oder aber welche Schritte sind notwendig, um eine Node plangemäß zu servicieren? Kann man das gefahrlos unter Tags machen oder muss es dafür eigene kommunizierte Wartungsfenster spät Abends, am Wochenende oder mit Downtime geben? Last- und Performancetests helfen dabei, das Operations-Team sich mit der neuen Infrastruktur vertraut zu machen, das Monitoring zu testen und die Arbeitsschritte in Ausnahmesituationen zu proben.

Die Empfehlung ist aber ganz klar, bereits den eigentlichen Umstieg von klassischer Virtualisierung auf CBH mit einem LPT zu begleiten, denn die neue Infrastruktur soll ja auch im besten Fall die Performance steigern und keinesfalls negative Auswirkungen haben. Dafür ist es notwendig, eine Baseline noch vor dem Umstieg zu machen, der dann als Vergleichsgrundlage dient. Selten wird nach einem Umstieg auf Anhieb dieselbe Performance wie davor erreicht und eine Reihe an Tests ist notwendig, um die Root Cause zu finden und die Probleme zu lösen. Ein produktiver Einsatz ohne vorherige Lasttests hätte zu massiven Problemen und Ausfällen geführt!

Vertrauen ist gut, Gewissheit ist besser!

Cloud Anbieter wie AWS, GCP oder Azure Cloud bieten für viele der genannten Features einfache Konfigurationsmöglichkeiten. Auch die Notwendigkeiten, den Master und alle Nodes von 0 auf bereitzustellen und zu servicieren fällt mit dem Einsatz eines Cloud Dienstes weg und damit verringert sich automatisch die Anzahl an Fehlerquellen. Auch die Möglichkeit der Skalierung ist in der Cloud einfacher: Zum Teil ist es gar nicht notwendig, sich mit einzelnen Nodes auseinanderzusetzen, die Cloud bietet auf Knopfdruck so gesehen „unendliche“ Ressourcen (gegen Einwurf von kleinen oder großen Münzen versteht sich). Unternehmen tendieren dann dazu, den Versprechungen und theoretischen Möglichkeiten dieser Cloud Anbieter blind zu vertrauen. Letztendlich ist aber immer noch die richtige Verwendung der Features und das Zusammenspiel der Cloud Ressourcen mit der Applikation ausschlaggebend für den Gesamterfolg, Gewissheit erlangt man also im besten Fall durch Last- und Performancetests, oder aber durch Probleme im Produktivbetrieb.

Container based hosting ist aus der heutigen IT Landschaft nicht mehr wegzudenken und mehr und mehr Unternehmen setzen zu Recht darauf, denn die Vorteile gegenüber klassischer Virtualisierung sind deutlich. Komplexität bedeutet aber immer gleichzeitig erhöhte Risiko und höhere Fehlerwahrscheinlichkeit und damit höheren Testaufwand. Mit Hilfe von Last- und Performancetests wird das Risiko minimiert und der Aufwand insgesamt reduziert, denn sobald ein Problem in Produktion auftritt, sind die Folgekosten jedenfalls höher als jeder Last- und Performancetest.