DevOpsCon: Last- und Performancetests in der Cloud?! [DE]

Auf der DevOpsCon 2016 in Berlin habe ich einen Vortrag zu der Frage gehalten, was es mit Last- und Performancetests in der Cloud auf sich hat und warum diese Themen auch im Zeitalter der Cloud noch relevant sind.

Abstract:
Die Cloud ist unendlich und skalierbar. Punkt. Warum ist es dann noch wichtig, die Performance und Skalierbarkeit von Cloud-basierten Systemen zu testen? Skaliert nicht mein Anbieter mein System, solange ich mir das leisten kann? Ja, aber … Cloud-Anbieter skalieren in erster Linie Ressourcen. Sie sorgen nicht automatisch dafür, dass Anwendungen schnell, stabil und – viel wichtiger – skalierbar sind. Performancetests sind ein wichtiges Instrument, um ein System und dessen Laufzeitumgebung zu verstehen.

https://devopsconference.de/session/last-und-performancetests-in-der-cloud/

Transcript

1. Sebastian Cohnen, StormForger GmbH Last- und Performancetests in der Cloud?!
2. ELLO! • Sebastian Cohnen (@tisba) • 7+ Jahre Beratung und Entwicklung • Fokus auf Performance und Architektur • Gründer & CTO StormForger.com
3. Performance
4. Performance • Fähigkeit eines Systems eine Aufgabe in einer definierten Dimension zu erledigen • Effizienz eines Systems
 • "1 Server schafft 250 tps mit p99 50ms"
5. Skalierbarkeit
6. ≠ Performance Skalierbarkeit
7. Skalierbarkeit • Effektivität, mit der die Kapazität durch Ressourcen gesteigert werden kann
 • "1 Server schafft 250 tps mit p99 50ms"
 und
 "10 Server schaffen 2500 tps mit p99 50ms"
8. Woran erkenne ich, dass ich ein Performance-Problem habe? http://www.slideshare.net/jboner/scalability-availability-stability-patterns/15-How_do_I_know_if Wenn dein System langsam für einen einzelnen Benutzer ist.
9. Woran erkenne ich, dass ich ein Skalierungs-Problem habe? Wenn dein System schnell für einzelne Benutzer ist, aber langsam unter Last.
10. Performance ⚡ Skalierbarkeit "Scaling usually hurts efficiency…" 
 "…Efficiency projects rarely give you enough improvement to have a big effect on scaling." Robert Johnson – https://www.facebook.com/note.php?note_id=409881258919 – Robert Johnson
11. Performance Testing
12. “In software engineering, performance testing is in general, a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload." – Wikipedia https://en.wikipedia.org/wiki/Software_performance_testing
13. Performance Tests • Sammlung nicht-funktionaler Testmethoden • System anregen mit einer definierten Last • Verhalten beobachten • Eigenschaften verifizieren • Verhalten verstehen
14. Performance Tests Load Testing, Stress Testing, Spike Testing, Soak Testing, Endurance Testing, Resilience Testing, Configuration Testing Scalability Testing, … • Nicht ganz trennscharf zu definieren • Unterschiedliche Ziele und Perspektiven
16. Die Cloud • IaaS, PaaS, … • APIs und Automatisierung • on-demand • kosteneffektiv • skalierbar
17. Performance-Tests in der Cloud
18. Ja und warum?
19. Die Cloud™ skaliert doch für uns! "
20. Ressourcen skalieren
 ≠ Anwendungen skalieren
21. Ressourcen vs Anwendungen skalieren Elastic Load Balancing Amazon EC2 MySQL DB instance Auto Scaling group
22. Und managed Services? • Provider kümmert sich um alles! • AWS Lambda, GC Functions, … • AWS DynamoDB, GC Datastore, … • AWS Kinesis/SQS, GC Pub/Sub, …
23. "Komplexe Systeme sind Systeme mit hoher Wechselwirkung." – sagen Physiker
24. Komplexität • Komplexität ist nicht verschwunden • {S,P,I}aaS & Co verstecken sie teilweise • Auswirkung auf Performance ist nicht-trivial
25. Verständnis aufbauen • Eigene Anwendung • System & Softwarearchitektur • Cloud/Laufzeit-Umgebung • Verwendete Dienste und deren Verhalten
26. Performance-Tests (auch) in der Cloud!
27. Load Testing • Tests mit normaler, zu erwartender Last • Ermittlung von Latenzen, Durchsatz, Fehlerraten, … • Verifikation nicht-funktionaler Anforderungen (SLA)
28. Stress Testing • Tests mit gesteigerter bis extremer Last • Systemverhalten unter (Über)last verstehen • Grenzen und Kapazitäten ermitteln
29. Stress Testing Vorgehen • Qualitätskriterien festlegen (OK / KO) • Last stufenweise steigern 0 20 40 60 80 100 120 140 160 50 100 150 200 250 300 350 400 450 500 0 20 40 60 80 100 120 Latency (ms) Request Rate (1/s) time (s)
30. Stress Testing Vorgehen • Systemverhalten überwachen • Bottlenecks identifizieren • Kapazität pro Ressource ermitteln
31. Scalability Testing • Wie effektiv werden weitere Ressourcen in Kapazität umgesetzt? • Grundlage für Kapazitätsplanung und Kostenabschätzung
32. Scalability Testing capacity 0 175 350 525 700 resources 5 10 15 20 25
33. Spike Testing • Wie verhält sich das System, bei (extremen) Lastspitzen? • Reagieren wir schnell genug? • Anlässe: Marketing #, Reddit, Hacker News, …
34. Soak Testing • Wie verhält sich das System unter Last über einen langen Zeitraum? • (sehr) langer Load Test • Gibt es Langzeiteffekte? Memory Leaks?
35. Configuration Testing
36. Configuration Testing • Wie ändert sich das Verhalten, wenn sich die Konfiguration ändert? • Serie von Testdurchführungen • Auswirkung der Umgebung auf das eigene System untersuchen
37. …in der Cloud • Instanztypen • Auto Scaling Einstellung • Throughput Provisioning • Optimale Nutzung von Diensten?
38. …und überhaupt… • Hypervisor • Betriebssystem • Web & Application Server • Softwarekonfiguration • Softwareabhängigkeiten
39. Availability & Resilience Testing
40. Availability & Resilience Testing • (Zero-Downtime) Deployments unter Last • Änderungen an Infrastruktur • Fehler Szenarien • Failover Testing • => Chaos Engineering
41. Ist das anders als früher?
42. Jain… • Notwendigkeit und Methoden unverändert • ABER, neue Möglichkeiten der Durchführung durch die Cloud
43. Testumgebungen in der Cloud • einfach(ere), Bereitstellung von Testumgebungen • Infrastruktur, Services, Server, Code, … • viel kostengünstiger und flexibler
44. Herausforderung: Reproduzierbarkeit • Testdaten und "State" im Allgemeinen sind auch in der Cloud ein komplexes Problem • Wie versetzt man Datenbanken, Caches und Dateisysteme in einen definierten Zustand? • Verwaltung von Testdaten? • Automatisierung des ganzen?
45. Fazit
46. Fazit • Ressourcen ≠ Anwendungen skalieren • Komplexität ist immer noch da • Verständnis ist enorm wichtig • Benutzt die Cloud, um das Testen einfacher zu machen!
47. • Design • Implementierung • Messen und Validieren • Repeat! Fazit
48. Danke! Fragen? Sebastian Cohnen (@tisba) https://stormforger.com