Lasttesten einer komplexen SOA in der Praxis

Das Lasttesten eines komplexen Softwaresystems ist seit jeher eine herausfordernde Aufgabe. Werden in einer großen IT-Landschaft, die primär aus eigenständigen Expertensystemen besteht, zudem integrative und geschäftsprozessorientierte Anwendungen auf Basis einer SOA eingeführt, so erhöht sich die Herausforderung in vielen Faktoren.

Die Einführung einer SOA beeinflusst zum einen die durch den Lasttest erreichbare Aussage: Das Verhalten von Partnersystemen – der Service-Provider – wirkt sich massiv auf das Performance-Verhalten einer untersuchten SOA-Anwendung aus. Eine singuläre Aussage zum System under Test ist nicht mehr möglich ist, ohne auch das Performance-Verhalten der Partner zu berücksichtigen.

Zum anderen führt die Einführung einer SOA zu einer deutlichen Steigerung der Komplexität der für den Lasttest notwendigen vorbereitenden Arbeiten. Die Komplexitätssteigerung betrifft sowohl technische als auch organisatorische Aspekte und umfasst die Testumgebungsbereitstellung ebenso wie das Testdatenmanagement und die Lasterzeugung.

Unser Vortrag beschäftigt sich mit diesen Aspekten und zeigt aus den Perspektiven eines strategischen SOA-Projekts sowie einer zentralen Testfactory die Herausforderungen und Lösungsansätze für den Lasttest einer geschäftsprozessorientierten SOA-Anwendung am Beispiel des Projekts ROBASO Stufe 1.

Das Projekt ROBASO Stufe 1 bildet im IT-Systemhaus der Bundesagentur für Arbeit das Pilotprojekt für die Einführung sowohl von geschäftsprozessorientierten Anwendungen als auch von intensiv auf Services basierenden SOA-Anwendungen. Die Anwendung ROBASO bildet nach dem Rollout zum Jahresende 2015 das Hauptarbeitsmittel für etwa 16.800 Mitarbeiter in Eingangszonen und Service Centern deutschlandweit. Insbesondere in den Service Centern ist eine gute Anwendungsperformance essentiell, da hier telefonisch eingereichte Anwendungen im Minutentakt bearbeitet werden. Zur Sicherstellung der Performance werden aus diesem Grund entwicklungsbegleitende Lasttests eingesetzt.

ROBASO selber bildet als Web-Anwendung die Geschäftsprozessabläufe ab und verfügt über keine eigene Fachlogik und Datenhaltung. Diese werden über Service-Aufrufe auf Fachanwendungen und Expertensystemen abgebildet. Hierzu bindet ROBASO 25 Service-Provider mit über 50 Services an, dabei kommen insgesamt rund 400 Service-Operationen zum Einsatz. Die Intensität der Service-Nutzung ist dabei stark variierend – von einzelnen Services mit einer Aufrufhäufigkeit von wenigen Malen pro Stunde, bis hin zu Services, die mehrere hundert Mal pro Sekunde genutzt werden.

Die Herausforderungen, mit denen wir im ROBASO-Lasttest konfrontiert wurden, lassen sich grob in drei Kategorien unterteilen: Testumgebungsbereitstellung, Testdatenauswahl und Abbildung des Lastverhaltens.

Durch die starke Fokussierung auf SOA besitzt ROBASO einen orchestrierenden Charakter und ist stark abhängig von den angebundenen Services. Für den Lasttest bedeutet dies, dass fast alle Service-Provider in der Testumgebung verfügbar sein müssen, in der richtigen Version und in einer Ausbaustufe, die der späteren Produktion entspricht. Gleichzeitig müssen diese Service-Provider, die ebenfalls kontinuierlich weiterentwickelt werden, in einer ausreichend stabilen Qualität bereitgestellt werden. Um die Ergebnisse nicht zu verfälschen dürfen die Service-Provider zum Testzeitpunkt nicht in anderen Tests verwendet werden – dasselbe gilt für die im Test verwendeten Middleware-Komponenten. Die Bereitstellung der Testumgebung ist damit komplex und insbesondere in frühen Entwicklungsphasen eine große Herausforderung. In unserem Vortrag stellen wir die von uns gewählten Wege vor, die mit der Testumgebungsbereitstellung verbundenen organisatorischen und technischen Hürden zu meistern. 

Auch die Auswahl oder Bereitstellung von Testdaten für den Lasttest verändert sich im Kontext einer SOA. Während Fachanwendungen primär auf ihren eigenen Daten operieren besitzt ROBASO keine eigene Datenhaltung. Testdaten für den Lasttest müssen vielmehr in den beteiligten Service-Providern bereitgestellt werden. Dabei ist es wichtig, dass die in den Providern gepflegten Testdaten synchronisiert und über die Provider hinweg konsistent sind. Im Laufe der Jahre haben wir Tests sowohl mit teilsynthetischen Testdaten als auch mit anonymisierten Produktionsdatenabzügen durchgeführt. Im Rahmen des Vortrags stellen wir diese beiden Ansätze vor und erläutern die jeweiligen Vor- und Nachteile sowie die Limitierungen und Möglichkeiten, die sich daraus ergeben.

Die Herausforderungen bei der Lasterzeugung ergeben sich aus der starken Abhängigkeit der Performance des Systems under Test von seinen Service-Providern. Im Fall von ROBASO sind nur wenige Service-Provider im Rahmen der SOA-Einführung vollständig neu implementiert worden. Vielmehr basieren die meisten Services auf Fachanwendungen, die nun zusätzlich Funktionalität über eine Service-Schnittstelle anbieten. Sind diese Fachverfahren korrekt dimensioniert, so verhalten sie sich nur dann der Real-Performance entsprechend, wenn sie zusätzlich zur Last durch ROBASO auch noch die zu erwartende Last über ihre Anwendungs-Clients sowie die erwartete Last durch andere Service-Consumer bearbeiten. Gleichzeitig nimmt die Einführung von ROBASO jedoch wieder Last von den Bestandsanwendungen, indem Prozesse über ROBASO und damit nicht mehr über die Bestandsanwendungen abgewickelt werden. Im Vortrag zeigen wir auf, wie wir diese Herausforderung angegangen sind, welche Limitierungen unser Vorgehen erzeugt und welche Ergebnisse wir damit erlangen konnten.

Ziel unseres Vortrags ist die Schaffung eines Überblicks über die Herausforderungen, die ein SOA-Lasttest mit sich bringt, sowie die von uns gewählten Wege, diese Herausforderungen zu meistern. Anhand realer Projektsituationen zeigen wir die Lessons Learned auf und vermitteln unsere Best Practices, um zu eine validen Aussage zur Performance einer komplexen SOA zu gelangen.

back to the program