Verteilte Softwaresysteme bringen ein sehr komplexes Verhalten unter echten Einsatzbedingungen mit sich, meist resultiert dies auch in sehr komplexen Fehlerzuständen, die durch den Betrieb unter widrigen Netzwerkbedingungen wie beispielsweise hohen Latenzen und zunehmenden Paketverlusten entstehen. Diese Fehlerzustände können mit herkömmlichen Softwaretestverfahren wie Unit- und Integrationstests nicht mehr hinreichend provoziert, getestet und verifiziert werden. Mit der Methode des Chaos-Engineerings werden komplexe Chaos-Szenarien entworfen, die es ermöglichen dieses unbekannte Verhalten der Software in Grenzfällen strukturiert zu entdecken. Am Beispiel einer verteilten Software, die bereits seit über 10 Jahren am Deutschen Zentrum für Luft- und Raumfahrt (DLR) entwickelt wird, werden Chaos-Engineering-Methoden angewandt und sowohl konzeptuell in existierende Softwaretestverfahren eingeordnet als auch praktisch in einer Experimental-Cloud-Umgebung erprobt. Innerhalb eines Experteninterviews mit den RCE-Entwicklern wird ein Chaos-Szenario entworfen, in der die Robustheit der Software mit Chaos-Experimenten auf die Probe gestellt wird. Aufbauend auf einem Softwareprojekt zur automatischen Erstellung von RCE-Testnetzwerken, wird eine Softwarelösung entwickelt, die eine automatische Ausführung von Chaos-Szenarien innerhalb der Experimental-Cloud-Umgebung ermöglicht. Anschließend wird das aus den Experteninterviews resultierende Chaos-Szenario in der Praxis durchgeführt. Abschließend werden die Erkenntnisse aus der Ausführung des Chaos-
Szenarios vorgestellt und weiterführende Fragestellungen und Arbeiten aufgezeigt:1 Einleitung
2 Grundlagen
2.1 Softwareentwicklung und Testverfahren
2.2 Verteilte Software
2.3 Containerorchestrierung
2.4 Chaos Engineering
3 Betrachtetes System
3.1 Remote Component Environment
3.2 Testing von RCE Releases
3.3 Methode Experteninterview
3.4 Fragestellungen entwerfen
3.5 Resultate aus Interview
3.6 Integration von Chaos-Engineering
4 Konzepte des Chaos-Engineering am Beispiel
4.1 Ausgangssituation
4.1.1 Systemumgebung
4.1.2 Automatisierte Erstellung von Testnetzwerken
4.1.3 Microservices
4.1.4 Systemarchitektur
4.1.5 Netzwerkbeschreibung
4.2 Anforderungen an die zu entwickelnde Software
4.3 Erweiterung des vorhandenen Gesamtsystems
4.3.1 Chaos Mesh
4.4 Chaos-Operator Microservice
4.4.1 Erweiterung der Systemarchitektur
4.4.2 Erweiterung der Schnittstellen
4.4.3 Beschreibung eines Chaos-Experiments
4.4.4 Probes
4.4.5 Ablaufsteuerung
5 Evaluierung und Diskussion
5.1 Geplantes Chaos-Szenario
5.1.1 JSON Beschreibung eines Chaos-Szenarios
5.2 Durchführung des entworfenen Chaos-Szenarios
5.2.1 Ausführung mit Chaos-Sequencer
5.2.2 Validierung
5.3 Resultate
6 Fazit
Literaturverzeichnis
Abbildungsverzeichnis
Listings
| Identifer | oai:union.ndltd.org:DRESDEN/oai:qucosa:de:qucosa:78842 |
| Date | 13 April 2022 |
| Creators | Hampel, Brian |
| Contributors | Deutsches Zentrum für Luft- und Raumfahrt, Hochschule für Technik, Wirtschaft und Kultur Leipzig |
| Source Sets | Hochschulschriftenserver (HSSS) der SLUB Dresden |
| Language | German |
| Detected Language | German |
| Type | info:eu-repo/semantics/acceptedVersion, doc-type:bachelorThesis, info:eu-repo/semantics/bachelorThesis, doc-type:Text |
| Rights | info:eu-repo/semantics/openAccess |
Page generated in 0.0044 seconds