WIXLIB

und Arbeitsweisen oft nur separat betrachtet und nicht ganzheitlich integriert (Brunnert et al.2014). Als Folge gibt es sowohl für das SPE als auch für APM eigene Klassen an SoftwareWerkzeugen und Modellierungssprachen.Beispielhafte Werkzeuge des SPE bauen oft auf sogenannten Performance-Modelltypen auf.Das Palladio Component Model (PCM) (Becker/Koziolek/Reussner 2009), SPE ED(Smith/Williams 1997) oder das Queueing Petrinet Modeling Environment (QPME)(Kounev/Dutz 2009) sind Beispiele solcher Werkzeuge, die den Nutzer bei der Modellierungauf Basis eines Modelltypens unterstützen. Anhand verschiedener Eingabe-Parameter wie derSoftwarearchitektur, Hardwareinfrastruktur oder dem Nutzerverhalten können so Modellegeneriert werden, die mittels analytischer Lösung oder Simulation eine Vorhersage bezüglichder Performance-Metriken des AwS treffen können.Im Bereich APM existieren eine Reihe von (kommerziellen) Software-Werkzeugen (Gartner2013) wie zum Beispiel Dynatrace (Compuware 2015b), SteelCentral (Riverbed2015), AppDynamics (AppDynamics 2015), New Relic APM (New Relict 2015) oder das ausdem Universitätsumfeld stammende Kieker (van Hoorn/Waller/Hasselbring 2012c, 2012a).Die APM-Werkzeuge unterstützen den IT-Betrieb dadurch, dass mithilfe eines detailliertenAwS-Monitorings während des Zugriffs durch Endnutzer die Messdatengrundlage geschaffenwird, um das Wissen über das Auftreten und die Ursachen von Performance-Problemen imAwS zu gewinnen (Gartner 2013).Obwohl die Performance ein gemeinsames Ziel des SPE und APM ist, sind Werkzeuge fürintegrierte PMW-Aktivitäten derzeit selten und bieten ein Potenzial für zukünftige Entwicklungen (Brunnert et al. 2014). Ein Ansatz findet sich in Brunnert/Vögele/Krcmar (2013), welcher unter dem Namen Performance Management Work Tools (PMWT, fortiss (2015))weiterentwickelt wird. Eine Eigenentwicklung ermöglicht hierbei das Erheben von Messdateneiner laufenden Java-EE-Applikation. Auf Basis dieser Messdaten können dann automatisiertmit einem Generator PCM-Performance-Modell der Applikation generiert werden. Jedochsetzt die Datenerhebung nicht auf ein Standard-Werkzeug im Bereich APM auf. Aufgrundihrer Verbreitung, des besseren Supports und der umfangreicheren Testbasis wäre eine Messdaten-Erzeugung über APM-Werkzeuge aus Unternehmenssicht mit Vorteilen verbundengegenüber einer Eigenentwicklung.1.2 Ziele der ArbeitDas erste Ziel der Masterarbeit ist es, die aus dem ersten Kapitel motivierte Fragestellungnach einer Verknüpfung von APM- und SPE-Werkzeugen als aktuelle Forschungslücke wissenschaftlich darzulegen. Hierfür müssen die existierenden Ansätze in der Literatur für diePerformance-Modellgenerierung auf Basis von Messdaten evaluiert werden.Aktuelle Publikationen wie Brunnert et al. (2014) geben bereits Hinweise darauf, dass umfassende Modellgenerierungsansätze mit Messdaten aus Standardsoftware selten sind. Der bestehende Modellgenerator der PMWT soll deshalb um eine APM-Schnittstelle erweitert werden,um diese Lücke zu schließen. Hiermit sollen generierte Messdaten von APM-Werkzeugenverwendet werden können, um automatisiert PCM-Performance-Modelle zu erzeugen. Bei2

spielhaft für diverse APM-Lösungen soll diese Erweiterung des Modellgenerators für daskonkrete Werkzeug Dynatrace technisch umgesetzt und getestet werden.Als Folge müssen anschließend die Vor- und Nachteile der APM-Erweiterung des Modellgenerators analysiert werden. Hierbei wird ein generiertes Performance-Modell mit DynatraceMessdaten den bestehenden Ansätzen gegenüber gestellt, um zu entscheiden, aus welcherArchitektur sich ein Modell mit einer höheren Genauigkeit oder Funktionalität ergibt. Diessoll anhand einer exemplarischen Java-EE-Anwendung geschehen, wie sie im betrieblichenKontext oft zu finden sind.1.3 ForschungsfragenAus den Zielen ergeben sich drei Forschungsfragen:Forschungsfrage 1: Welche automatischen und auf Messdatenbasierende PerformanceModell-Generierungsansätze existieren in Literatur und Praxis?Das Ziel bei der Beantwortung dieser Forschungsfrage ist es, themenverwandte Literatur aufzuzeigen. Die eigene Erweiterung des Modellgenerators soll somit als Forschungslücke eingeordnet werden können. Zudem soll der Literaturüberblick zeigen, in welchen Bereichen undfür welche Technologien Messdatenbasierende Modell-Generierungsansätze existieren, umweitere Anwendungsmöglichkeiten aufzuzeigen.Existierende (Teil-)Ansätze, aufbauend zum Beispiel auf dem Kieker-Framework von vanHoorn/Waller/Hasselbring (2012c), sollen für eine Anforderungsanalyse der eigenen Modellgeneratorerweiterung evaluiert werden, um hohe Flexibilität und Anpassbarkeit der zu entwickelnden Schnittstellen zu gewährleisten. Dies soll insgesamt dazu dienen, die PMWTModellgeneration unabhängig von der Datenerhebungsmethode zu konstruieren.Automatisierte Ansätze wie der von Brunnert/Vögele/Krcmar (2013) sind besonders in derPraxis den manuellen Ansätzen vorzuziehen, da der Aufwand einer manuellen Modellierungoft einem späteren Nutzen übersteigt (Koziolek 2010). Zudem lassen sich automatisierte Ansätze einfacher vergleichen und auf andere AwS übertragen, da hierbei keine zusätzliche Benutzereingabe notwendig ist. Es entsteht somit weniger Spielraum bei der Auswertung vonPerformance-Ergebnissen.Insgesamt gilt es somit folglich bei der Literaturrecherche darum, auf Folgende Fragen Antworten zu finden:-Welche Messdaten wurden in welcher Granularität erhoben?Welche Monitoring-Lösung wurde benutzt und welche Schnittstelle dabei verwendet?Welches Performance-Metamodell wurde in welchem Umfang (möglich sind auchTeilmodelle) verwendet?Wie hoch ist der Grad der Automatisierung bei der Modellgenerierung?Wie leicht sich das existierende Vorgehen zur Modellgenerierung aus der Literatur auf andereAPM-Werkzeuge und Performance-Modelle übertragen lässt, sollte ebenfalls analysiert werden. Dies dient dazu, die Flexibilität der eigenen APM-Erweiterung einzuordnen.3

Forschungsfrage 2: Welche Anpassungen an das bestehende Performance-ModellGenerierungs-Framework (PMWT) sind notwendig, um Standard-APM-Werkzeuge als Messdatenquelle zu nutzen?Das Ziel dieser Forschungsfrage ist es herauszufinden, wie der bestehende Modellgeneratorbasierend auf der eigenen Erhebung von Messdaten angepasst werden muss, damit auchextrahierte Messdaten aus anderen APM-Werkzeugen für die Generierung von PerformanceModelle benutzt werden können. Hierfür muss die Konzeption und Implementierung umgesetzt werden. Abbildung 1 zeigt eine solche Erweiterung schematisch.Der Generator greift für die Modellgenerierung auf Daten zu, die mittels einer PersistenceService-Schnittstelle bereitgestellt werden. Während der erste Ansatz vonBrunnert/Vögele/Krcmar (2013) die Messdaten für diese Schnittstelle über CSV-Dateien1aggregiert und in einer Datenbank bereitstellt, existiert auch eine Alternative, die Messdatenfür die Modellgenerierung direkt als MBeans überträgt (Brunnert/Neubig/Krcmar 2014;Oracle 2015c). Extrahierte Messdaten aus Dynatrace müssen also auf die Persistence-ServiceSchnittstelle transformiert werden. Die Orientierung an einem der vorhandenen Ansätze überCSV-Dateien oder MBeans muss bewertet werden.Da diese Arbeit - stellvertretend für allgemeine APM-Standardlösungen - eine Messdatenerhebung mit Dynatrace implementiert, müssen die von Dynatrace bereitgestellten Möglichkeiten einer Daten-Extraktion analysiert werden. Die von Dynatrace zur Verfügung stehendenSchnittstellen wie REST Interfaces (Fielding 2000; Compuware 2015j) müssen verglichenAbbildung 1: Schema des PMWT-Frameworks mit Dynatrace-SchnittstelleQuelle: Willnecker et al. (2015)1Comma-separated values4

werden, um an den PMWT-Modellgenerator anknüpfen zu können.Forschungsfrage 3: Welche Unterschiede in Genauigkeit und Funktionalität ergeben sichdurch den Einsatz einer Standard-APM-Lösung gegenüber selbstentwickelten Werkzeugen zurMessdatenerhebung?Die bestehende Ansätze aus Brunnert/Vögele/Krcmar (2013) mit der eigenen Methode für dieMessdatenerhebung generieren bereits Performance-Modelle mit einem Fehler von nur 1-20%in der Antwortzeit und weniger als 10% in der CPU-Auslastung bei Nutzung einer exemplarischen Java-EE-Applikation.Das Ziel dieser Forschungsfrage ist die Beantwortung, wie exakt die Performance-Modellemithilfe der Messdaten eines Standard-APM-Werkzeugs werden. Zum einen handelt es sichhierbei in der Regel um lizenzpflichtige Industrie-Lösungen, was technisch auf sehrausgereifte Produkte deuten könnte, die einen Zugewinn in der Genauigkeit der PerformanceModelle bringen könnten. Zum anderen muss jedoch auch bedacht werden, dass es sich imVergleich zu der PMWT-Messdatenerhebungsmethode um sehr viel umfangreichereWerkzeuge und keine Speziallösung zur Modellgenerierung handelt, was zu schlechtenPerformance-Vorhersagen führen könnte.1.4 Aufbau der ArbeitDie Masterarbeit ist in mehrere Kapitel eingeteilt. Eine Struktur basierend auf den definiertenForschungsfragen wird im Folgenden gegeben:Zu Beginn der Arbeit müssen alle relevanten Fachbegriffe definiert und erläutert werden.Hierzu gehören Definitionen bezüglich der zu untersuchenden Anwendungssysteme, derPerformance-Modellierung und Metriken sowie der in dieser Arbeit verwendetenTechnologien. Diese Grundlagen werden in Kapitel 2 beschrieben.Um die erste Forschungsfrage bezüglich der wissenschaftlichen Einordnung dieser Arbeitbeantworten zu können, bietet sich eine Literaturrecherche angelehnt nach Webster/Watson(2002) an. Dieser Literaturüberblick der vorhandenen Ansätze ist in Abschnitt 2.4 zu finden.Hauptbestandteile einer Klassifizierung bezüglich Messdaten-basierter PerformanceModellgenerierung leiten sich direkt aus der Forschungsfrage ab (vgl. Abschnitt 1.3).Für die Beantwortung der zweiten Forschungsfrage, bei der es um die Integration der Dynatrace-Messdaten in das PMWT-Modellgenerierungsframework geht, wird zuerst geprüft, welche für die Performance-Modellierung-relevanten Daten man wie mit Dynatrace (alsFallbeispiel für APM-Werkzeuge) extrahieren kann (Abschnitt 2.3). Danach sollten die vorhandenen Schnittstellen oder Datenstrukturen im PMWT-Framework ausgewählt bzw. adaptiert werden, damit die extrahierten Messdaten aus Dynatrace verwendet werden können(Kapitel 3).Um die dritte Frage zu beantworten und die Unterschiede in Genauigkeit und Funktionalitätzu vergleichen, sollte ein an Hevner et al. (2004) angelehntes „Controlled Experiment“durchgeführt werden. Der Test sollte zudem ein typisches betriebliches Anwendungssystemsimulieren, da APM-Werkzeuge dort primär eingesetzt werden. Als Ausgangspunkt zum5

Plausibilisieren der Ergebnisse mit vorhandenen Messungen wird die für die Eigenentwicklung von Brunnert/Vögele/Krcmar (2013) bereits verwendete Java-EE-ApplikationSPECjEnterprise2010 verwendet. Die Evaluation der Ergebnisse findet in Kapitel 3.3 statt.Ferner wird die Arbeit in Abschnitt 5 zusammengefasst und ein Ausblick gegeben, an waszukünftig weitergeforscht werden kann.6

2 Grundlagen2.1 Allgemeine Begriffe und DefinitionenAnwendungssystem und AnwendungssoftwareDer Begriff Anwendungssystem (oder Informationssystem) bezeichnet ein System, welchesfür bestimmte Anwendungsgebiete erstellt wurde und umfasst die hierfür nötige Gesamtheitan Hard- und Software. Schwarzer/Krcmar (2010) trennen hiervon den Begriff der Anwendungssoftware, welche das eigentliche Programm beschreibt und auf der Hardware eingesetztwird, die dem Anwendungssystem zur Verfügung steht. Anwendungssoftware wird oft auchals Anwendung, Applikation oder kurz als App bezeichnet.Eine Anwendungssoftware besteht ferner wiederum aus vielen einzelnen Operationen (in derSystementwicklung oft „Methode“ genannt), die kleine Funktionalitäten implementieren undsich gegenseitig (verschachtelt) aufrufen können. Logisch oder programmatisch zusammenhängende Operationen können zu einer sogenannten (Geschäfts-) Transaktion zusammengefasst werden, welche die gesamte Abfolge an Operationsaufrufen (den Kontrollfluss) voneiner Anfrage bis zur Antwort beschreibt. Eine oder auch mehrere Transaktionen sind hierbeiimmer für die Ausführung der von der Anwendungssoftware bereitgestellten Funktionalitätnötig (Smith 2007b, S. 294).Anwendungssysteme im betrieblichen Kontext sind heutzutage oft verteilte webbasierte Anwendungen, die parallel von Endnutzer genutzt werden können und mittels Netzwerkverbindungen untereinander kommunizieren bzw. Daten austauschen können. Unterteilt werdenhierbei in der Regel drei Schichten (Leff/Rayfield 2001): Die Präsentations-, die Geschäftslogik/Business- und die Datenhaltungsschicht (vgl. Abbildung 2).Abbildung 2: Typische Architektur eines betrieblichen AnwendungssystemsQuelle: Wischer (2014)7

Das Ziel der Datenhaltungsschicht ist die (langfristige) Speicherung von Daten (Persistierung). Hierfür werden in der Praxis oft Datenbanksysteme eingesetzt. Aufbauend auf der Datenhaltungsschicht arbeitet die Businessschicht, welche sich um die Anwendungslogik unddie Prozessierung von Informationen kümmert. Die Präsentationsschicht hingegen beinhaltetkeine Geschäftslogik aber baut auf der Businessschicht auf. Die Schicht ist ausschließlich fürdie (grafische) Aufbereitung der prozessierten Daten zuständig. Sie die

FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master's Thesis in Informatik Performance-Modellgenerierung für Java-Enterprise-Edition-Anwendungen auf Basis von