Web Service Lasttest mit simulierten Nutzern

Die Tickets für die diesjährige Feier wurden im März online und in den Ticketläden verkauft. Fast 100.000 Tickets für 19 Veranstaltungen waren innerhalb weniger Stunden ausverkauft. Wie viele vorhergesagt hatten, verlief der Ticketverkauf nicht wie geplant, da es viele technische Herausforderungen gab.

Wir entwickeln derzeit ein Tool zum Lasttest von Web Services, das die Last simulieren kann, die von Nutzern erzeugt wird. Dieser Blogbeitrag beschreibt unsere Erfahrungen bei der Entwicklung dieses Tools. Es gibt viele Dinge, die schiefgehen können, wenn die Belastung steigt, aber wir glauben, dass unser Tool Ihnen helfen kann, Probleme zu identifizieren, bevor sie zu realen Problemen werden.

Was kann schiefgehen?

Große Belastungen bringen in der Regel viele Herausforderungen mit sich, auf die Dienstleister vorbereitet sein müssen, beginnend mit der großen Nutzerlast bis hin zu Angriffen auf das System. Wenn man eine große Belastung erwartet, ist das absolute Minimum, das getestet werden sollte, ob die Server die gesamte Last bewältigen können. Große Belastungen können zu Wettlaufbedingungen führen, die unter normalen Bedingungen nicht beobachtet werden. Solche Wettlaufbedingungen können parallelen Datenbankzugriff, Netzwerkbandbreite oder Probleme mit gemeinsam genutzten Variablen umfassen, die nicht auftreten, wenn nur wenige Personen den Dienst gleichzeitig nutzen.

Eine weitere Herausforderung, auf die sich Dienstleister vorbereiten müssen, ist eine Denial-of-Service (DoS)-Attacke. Bei deutlich höheren Belastungen als üblich kann diese Belastung leicht zu einer unbeabsichtigten DoS werden, da die Server nicht in der Lage sind, so viel Last zu bewältigen. Besonders wenn die Netzwerkschnittstelle die zusätzliche Last nicht verarbeiten kann oder der erhöhte Verkehr unerwartet ist.

Es könnte auch jemand versuchen, einen verteilten DoS-Angriff zu starten, um das System weiter zu verlangsamen. In jedem Fall sollte es einen Mechanismus geben, der eine DoS verhindert, indem die Last auf mehrere Handler verteilt wird oder Anfragen aus einer einzigen Stelle begrenzt werden. Auch generelle Sicherheitsbedrohungen müssen berücksichtigt werden, z. B. Cross-Site-Scripting oder SQL-Injectionen - diese Angriffe könnten die Datenintegrität ernsthaft gefährden oder zu Datenlecks führen.

Unsere Lösung

Seit über einem Jahr entwickeln wir ein Framework, das helfen kann, potenzielle Probleme durch Lasttests zu identifizieren. Die Idee hinter diesem Framework ist es, so viele Nutzer wie möglich zu simulieren, ohne dabei Bedingungen zu opfern, z. B. browserbezogene Probleme. Das bedeutet, dass Sie ein sehr realistisches Setup erstellen können, um das Verhalten des Dienstes aus der Sicht des Endbenutzers zu überwachen.

Um realistische Szenarien für Lasttests zu simulieren und Skalierbarkeit aufrechtzuerhalten, mussten wir eine Reihe von Hauptmerkmalen entwickeln:

Alles in allem gibt es Hunderte von möglichen Konfigurationen, die Sie während erhöhter Lastsituationen testen können. Die Kombination all dieser Optionen mit einem automatisierten Setup für simulierte Benutzer ergibt ein großartiges und einfach einzurichtendes Lasttesttool.

Ein Beispiel

Angenommen, wir wollen einen Online-Video-Streaming-Dienst testen. In diesem Fall möchten wir die gleichzeitige Nutzung von Videos durch viele Benutzer sowie DoS testen - beide Szenarien sind mit unserem Framework testbar.

Wir müssen mehrere Schritte unternehmen, um uns auf diese Anwendungsfälle vorzubereiten. Zuerst definieren wir die Anzahl der Nutzer, die wir simulieren möchten, und teilen diese Nutzer in logische Gruppen ein. Video-Streaming-Dienste bieten in der Regel viele Videos an, daher macht es Sinn, die Nutzer nach den Videos zu sortieren, die sie ansehen werden. Auf diese Weise können wir testen, ob viele Nutzer ein bestimmtes Video ansehen, während andere Nutzer etwas anderes ansehen. Wir nennen diese Gruppen „Räume“.

Nachdem wir unsere Gruppen definiert haben, müssen wir das Testskript schreiben. Keine Sorge, es ist einfach! Das Framework unterstützt das Selenium-Scripting mit der NightWatch JS-Syntax. Alles, was Sie tun müssen, ist Aktionen zu komponieren, die die simulierten Benutzer ausführen sollen, sowie einige Assertions während des Tests.

Dieser Beispielcode beschreibt ein Testskript zum Starten eines Videoanrufs zwischen zwei Teilnehmern auf Google's Appr.tc.

Sie können entscheiden, in welchem Tempo die Benutzer beitreten. Für gängige Anwendungsfälle würden die Benutzer zu einem bestimmten Zeitpunkt schnell beitreten und das Tempo kurz vor dem Ereignis verlangsamen. Dieser Graph veranschaulicht die potenzielle Gesamtzahl der Benutzer im Laufe der Zeit.

Um ein realistisches Szenario zu simulieren, wollen wir nicht, dass alle Benutzer gleichzeitig den Dienst nutzen. Daher müssen wir eine Anlaufzeit konfigurieren. Die Anlaufzeit definieren wir mit zwei Parametern: der Gesamtzeit, die alle Benutzer benötigen, um sich anzuschließen, und der Anschlussfunktion. In manchen Anwendungsfällen möchten Sie, dass Benutzer in einem konstanten Tempo beitreten, während in anderen Anwendungsfällen ein plötzlicher Anstieg nach einigen ruhigen Minuten erwünscht sein kann.

Sobald das Skript fertig ist, müssen wir die Benutzer konfigurieren. Dies geschieht in zwei Schritten:

Wir können Browser für diese Benutzer mischen und ihre Netzwerkbedingungen einstellen, um Hochgeschwindigkeitsverbindungen, 4G, 3G oder Verbindungen mit begrenzter Geschwindigkeit zu simulieren.

Der schwierigste Teil ist erledigt, und wir können die Tests starten und die Ergebnisse auswerten. Die Ergebnisse enthalten viele nützliche Daten, die dazu beitragen, das Geschehen auf der Clientseite zu verstehen. Beginnen wir mit den Grundlagen - der Erfolgsquote. Dies zeigt, ob die simulierten Benutzer ihre Aktionen erfolgreich abschließen konnten. Abgesehen von der allgemeinen Erfolgsquote können wir den Belastungsgrad zu jedem Zeitpunkt rekonstruieren, der gegen die Webanwendung gerichtet war. Darüber hinaus gibt es komplexe Kennzahlen wie Statistiken der Benutzermaschine (CPU-Auslastung, RAM-Auslastung usw.) oder WebRTC-Statistiken, falls dies für den Dienst relevant ist.

Die Kennzahlen können auf verschiedene Arten bewertet werden, z. B. nach Region, Browser oder einem anderen gemeinsamen Parameter. Beachten Sie: Für eine genauere Datenerfassung empfehlen wir, diese Kennzahlen zusammen mit den Kennzahlen zu betrachten, die von den Servern der Anwendung gesammelt wurden.

Unser hauseigenes Tool kann die Lasttestinfrastruktur mit minimalem Setup und konfigurierbaren einzelnen Benutzern bereitstellen. In Kombination mit der Expertise unserer Ingenieure sind die Möglichkeiten grenzenlos.

Dieses Framework eignet sich am besten für neue Produkte, die den Markt betreten wollen und sich nicht sicher sind, welche Leistungsfähigkeit ihre Server haben. Unternehmen mit bestehenden Produkten können dieses Tool nutzen, um ihre Infrastruktur auf erhöhte Belastungen zu testen oder neue Releases zu testen. Darüber hinaus kann jede WebRTC-Anwendung auch ihre Nicht-HTTP-Server testen.