Oporty - stock.adobe.com
Sechs Best Practices für Microservices-Lasttests
Lasttests in Microservices-Umgebungen sind keine leichte Aufgabe. Diese sechs Best Practices unterstützen dabei, gleichmäßige Workloads zu gewährleisten.
Während Lasttests zu den grundlegenden Routinen gehören, die Softwareteams durchführen, sind Lasttests für Microservices mit einem gewissen Schwierigkeitsgrad verbunden. verteilte Anwendungen unterliegen sprunghaften Änderungen in Bezug auf Umfang und Ressourcenverbrauch, was die Anwendungen anfällig für Leistungsprobleme macht und eine kontinuierliche Überwachung erschwert.
Eine Microservices-spezifische Strategie für Lasttests kann dazu beitragen, dieses Risiko zu minimieren, aber die Testteams werden wahrscheinlich auf einige Herausforderungen stoßen, wenn sie einen praktischen Plan erstellen müssen.
Es gibt keine Abkürzungen für die Durchführung von Lasttests für Microservices. Entwickler können nicht nur einzelne, risikoreiche Anwendungskomponenten testen, da die gemeinsamen Beziehungen dieser Komponenten in der Regel zu Leistungs- und Stabilitätsproblemen führen.
Der richtige Weg, um dies zu beheben, ist die Berücksichtigung von Lasttests während der Planungsphase einer Microservices-basierten Anwendung und die kontinuierliche Durchführung von Lasttests während des gesamten Lebenszyklus der Anwendung. Durch Befolgung der folgenden Prinzipien können Entwicklungs- und Testteams eine umfassende Lastteststrategie für Microservices-basierte Anwendungen erstellen.
1. Beginnen Sie mit APM
Microservices-Lasttests sollten nicht mit simulierten Datenlasttests beginnen. Eine solche Qualitätssicherung sollte mit der Überwachung der Anwendungsleistung (Application Performance Monitoring, APM) beginnen.
Software mit vielen Komponenten, wie zum Beispiel Microservices-Anwendungen, sind notorisch schwer zu analysieren. Selbst mit umfassenden Lasttests kann es schwierig sein, die Gesamtleistung zu bestimmen oder die Ursache von Leistungsproblemen zu ermitteln. Eine APM-Strategie stellt sicher, dass die Teams wissen, was während eines Lasttests zu beobachten ist, und ermöglicht es ihnen außerdem, die Testergebnisse mit dem Produktionsverhalten zu korrelieren.
2. Fokus auf Observability
Observability ist der Schlüssel für effektive Lasttests während des Designs von Microservices. IT-Teams legen in der Regel Leistungs- und Skalierbarkeitsparameter für Microservices fest. Wenn die zur Überwachung dieser Parameter erforderlichen Daten nicht verfügbar sind, ist es an der Zeit, sich nach neuen APM-Tools umzusehen. Andernfalls müssen die Entwickler automatisierte Überwachungsprozesse in den Code einbauen.
Kubernetes bietet leistungsstarke Überwachungs-Tools, die es den Entwicklern nicht abverlangen, Überwachungsroutinen manuell hinzuzufügen. Darüber hinaus bietet ein Service-Mesh, wie zum Beispiel Istio oder Linkerd, ein komplettes Spektrum an Lasttest-Parametern und Observability-Möglichkeiten.
3. Behalten Sie eine ganzheitliche Sicht bei
Teams sollten sich bei Lasttests für Microservices nicht auf Teil- oder Unit-Tests verlassen. Microservices lassen sich leicht skalieren und neu bereitstellen, und die Logik in einem einzelnen Service ist selten die Ursache für Leistungsprobleme. Was wirklich zählt, sind der gesamte Arbeitsablauf und die Skalierbarkeitseigenschaften der Anwendung.
Es ist zwar in Ordnung, Unit- und Section-Tests für die Logik einer Anwendung durchzuführen, doch die Ergebnisse geben keinen Aufschluss über die Leistung unter Last. Führen Sie die Arbeit in die normalen Workflow-Kanäle der Anwendung ein und bewerten Sie die Antworten von dort aus.
Wenn die Gesamtleistung unter Last – gemessen an der Durchlaufzeit für die Verarbeitung – nicht zufriedenstellend ist, können Sie beginnen, die einzelnen Komponenten, die das Problem verursachen, zu ermitteln.
Sie können zum Beispiel Orchestrierungsdaten aus dem Service-Mesh betrachten, um Workflows und Bereitstellungspunkte zu verfolgen. Diese Verfolgung sollte aufzeigen, welche Komponenten unter Last skalieren und wie sich diese Skalierungsprozesse auf die Leistung auswirken. Grafana und JMeter sind Tool-Beispiele, die dabei helfen, diese Art von zentraler Ansicht zu liefern.
4. Analysieren Sie Skalierungsmuster
Beim Testen von Microservices ist es wichtig, die Zeit zu bewerten, die benötigt wird, um Workloads zu verbinden, einen Lastausgleich zwischen den Instanzen durchzuführen, neue Instanzen aufzusetzen und die Skalierung zu verringern, wenn das Workload-Volumen abnimmt. Der Einblick in diese Betriebsmuster sowie in das Gesamtverhalten der Anwendung unter bestimmten Skalierungsbedingungen ist entscheidend.
Um Lasttests für eine Microservices-Anwendung mit simulierten Szenarien durchzuführen, sollten Sie nicht einfach die Arbeitslast erhöhen und die Auswirkungen der zusätzlichen Belastung isoliert messen. Führen Sie stattdessen die gleiche Art von sporadischer Nachfrage und schwankenden Arbeitsabläufen ein, die auch in einer Produktionsumgebung auftreten.
5. Testen Sie über Hosting-Domänen hinweg
In hybriden und Multi-Cloud-Umgebungen kann sich der Datenverkehr von Microservices über verschiedene Funktionsgrenzen und Hosting-Domänen hinweg bewegen. Diese Bewegung kann zu Überlastung und Netzwerklatenz führen, was längere Bereitstellungszeiten für Anwendungskomponenten in einer anderen Domäne zur Folge hat.
Auch wenn sich nicht alle Anwendungen über mehrere Hosting-Domänen erstrecken, werden Dinge wie Cloud Bursting oder Failover zwischen Domänen unweigerlich zu einem Crossover führen. Daher wird es sehr schwierig sein, die Ergebnisse von Lasttests zu messen, wenn keine zentrale Überwachung über alle Hosting-Domänen hinweg erfolgt, die die Microservices möglicherweise nutzen.
6. Ein geeignetes Framework für die Arbeitsverteilung finden
Der letzte Grundsatz beim Lasttest von Microservices ist die Auswahl eines Frameworks, das den Arbeitsablauf und die Lastverteilung sorgfältig steuert. Beispiele für Arbeitsverteilungs-Frameworks sind API-Gateways und Service-Mesh-Implementierungen, da sie beide eine zentrale Rolle bei Skalierungs- und Lastausgleichsverfahren spielen.
Bevor sich Teams für ein bestimmtes Framework entscheiden, müssen sie feststellen, ob sie die Arbeitsverteilung zwischen den Microservices, aus denen eine Anwendung besteht, unnötig komplex machen.
Service-Mesh ist beispielsweise nützlich, wenn es darum geht, mit großen, hochgradig verteilten Umgebungen in einer Weise umzugehen, die für einen einfachen API-Broker zu viel sind. Service-Mesh-Implementierungen sind jedoch oft mit einer Reihe von ausgefeilten Funktionen ausgestattet, wie zum Beispiel verteilten Überwachungs- und Verfolgungsfunktionen. Wenn die Umgebung einfach und relativ überschaubar ist, ist es unter Umständen besser, einen einfachen API-Broker zu verwenden.
