Autoskaleriung: Performancetests noch nötig?

Share this post by e-mail
You can enter up to five recipients. Seperate them with a comma.





The provided data in this form is only used to send the e-mail in your name. They will not be stored and not be distributed to any third party or used for marketing purposes.

Vor ein paar Tagen saß ich in einem Meeting, in dem es um Monitoring von Web-Anwendungen ging. Dabei ging es um Ende zu Ende Monitoring, also vom Backend bis zum Frontend. Genauer um das Überwachen auf Server-Ebene, Application-Ebene, Netzwerk-Ebene und Enduser-Ebene, also volle Transparenz von der First zur Last Mile, was nicht nur eine gute Sache, sondern in meinen Augen Pflicht ist. Dabei kamen wir auf das Thema Load Testing zu sprechen, da jemand in die Runde einwarf, ob es noch sinnvoll ist Performance- und Last-Tests durch zuführen, wenn man eine automatisch skalierende Infrastruktur betreibt. D.h. also je mehr Last auf das System kommt, desto mehr Ressourcen automatisch bereit gestellt werden. Mit heutigen Cloud und SaaS Technologien ist das durchaus möglich.

Als erstes habe ich eingeworfen, dass es nur professionell ist, (neu-) entwickelte Systeme zu testen. Und zwar mit allen erdenklichen Möglichkeiten, wie z.B. funktionale Tests, Acceptance Tests, X-Browser Tests, Crowd-Tests und eben auch Performance Tests. Es würde nie jemand auf die Ideen kommen, seine Anwendung nicht funktional zu testen, oder? Welche Entwickler würden auf Unit Tests verzichten, gerade im agilen Umfeld? Allerdings klingt dieses Argument nach „Haben wir schon immer so gemacht.„… Eine Aussage, die ich als Leid geplagter Performance Engineer oft gehört habe, wenn es darum geht Performance mehr Beachtung zu schenken.

An dieser Stelle möchte ich aber wieder mein Mantra heraus kramen: Der Endnutzer steht im Mittelpunkt.

Nehmen wir als Beispiel eine Marketing Kampagne, in der der Traffic auf einen Zielpunkt gelenkt wird, z.B. bei einer kurzfristig angesetzten Newsletter Kampagne auf ein nur kurzzeitig verfügbares Angebot eines Webshops. Solche Flash-Sales werden immer beliebter und werden häufig im Social Media angekündigt. Ob das angekündigte Angebot seine Zielgruppe findet, ist eine Frage des Marketings und des Angebots. Aber wenn es eine Anziehungskraft generiert, wird durch den Traffic auch die Last auf die System größer, da ist natürlich eine autoskalierende Infrastruktur von Vorteil.

Aber was bedeutet das wirklich „autoskalierend“? Mit dem Aufkommen der Cloud Services – wie z.B. IaaS – ist das dynamische Hinzufügen und Entfernen von Ressourcen, wie Servern, sehr einfach und mächtig geworden, so kann man z.B. mit AWS flexibel und weitreichend skalieren. Vom Hinzufügen von CPUs, Speicher, Bandbreite bis hin zur Inbetriebnahme ganzer Infrastrukturen ist der Anwendungsbereich groß, aber auch komplex, da viele Abhängigkeiten beachten werden müssen, wie Sessions, Loadbalancing, Datenzugriff,etc.. Aber auch das Hochfahren von Cloud Instanzen kostet selbst bei Amazon etwas Zeit bevor diese im Einsatz sind. Bei einer Marketing Kampagne wie im Beispiel kann das Kind schon nach ein paar Minuten in den Brunnen gefallen sein. Die Skalierungsmechanismen reagieren nicht schnell oder früh genug und ich habe hunderte oder tausende Nutzer, die eine schlechte Endnutzer Erfahrung erleiden. Die direkte Konsequenz daraus ist Umsatzverlust und Markenschäden: „Hier kauf ich nie wieder ein!“. Weitere Beispiele sind Sportereignisse wie Champions-League Spiele oder Relaunches von Webshops.

Auch an dieser Stelle sieht man wieder: Performance ist UX. Setze ich eine autoskalierende Infrastruktur ein, muss ich testen, wie gut und schnell kann sie reagieren. Dies ist zum Einen wichtig, um die die geeigneten Grenzwerte für die Autoskalierung zu setzen, z.B. ab 80% CPU Auslastung auf 50% der Instanzen. Zum Anderen ist es wichtig, dass ich weiß, ab wann ich aktiv werden muss, wenn das System doch an seine Grenzen kommt. Jede Infrastruktur stellt ein Risiko dar, um die Größe des Risikos zu bestimmen, muss man sie testen.

Der vermehrte Einsatz von 3rd Party Services kommt als entscheidender Faktor zum Risiko Management hinzu. Ich habe zwar die Kontrolle über meine eigene Infrastruktur, aber nicht über die der 3rd Party Provider. Dieses können Frontend Services sein, wie Web Analytics oder Ad-Provider die ins HTML integriert werden. Aber auch Backend Provider, wie sie z.B. Recommendation oder Rating Services anbieten. Können diese der Last standhalten? Diese Frage kann nur ein Test klären. Und aus Erfahrung: Auch der Name Google ist nicht immer Garant für eine Top-Performance.

Allerdings hat alles Testen und jede Autoskalierung Grenzen, bei letzterem ist es der Einsatz der gewählten Cloud Architektur und des Providers. Vor allem aber kostet alles Zeit und Geld und davon hat man (leider) nicht unendlich, also muss immer im Rahmen des Budget getestet werden. Dieser definiert sich über mehrere Metriken, sicherlich über das Budget, was dem Projekt zur Verfügung steht, vor allem aber über den zu erwartenden Traffic und die daraus resultierende Konvertierungsrate (Conversationrate). Um diese Metriken abzuschätzen kann man auf die Daten von Webanalytics Tools zurückgreifen. Sicherlich kann man nicht Wissen, ob der Traffic über diese Größe hinaus geht, aber bis zu einem historischen Wert plus Puffer sollte man sicherstellen, dass die Infrastruktur in den gewünschten Grenzwerten stabil läuft. Kontrolle und Transparenz über die Enduser Erfahrung während der Kampagne bekommt man über Real User Monitoring (RUM).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.