Fakult¨ at f¨ ur Informatik
Institut f¨ ur Technische und Betriebliche Informationssysteme
Masterarbeit
Adaptionsstrategien f¨ ur kosteneffizientes Complex Event Processing
Verfasser:
Andreas Meister
15. September 2013
Betreuer:
Prof. Dr. rer. nat. habil. Gunter Saake, M.Sc. Sebastian Breß
Universit¨at Magdeburg Fakult¨at f¨ur Informatik Postfach 4120, D–39016 Magdeburg
Germany
Dr.-Ing. Zbigniew Jerzak Dipl. Inf. Thomas Heinze
SAP Dresden
Chemnitzer Strasse 48, D-01187 Dresden Germany
Masterarbeit, Otto-von-Guericke-Universit¨at Magdeburg, 2013.
Inhaltsverzeichnis
Inhaltsverzeichnis i
Abbildungsverzeichnis v
Tabellenverzeichnis ix
Verzeichnis der Abk¨urzungen xi
1 Einf¨uhrung 1
1.1 Hintergrund . . . 1
1.2 Motivation . . . 2
1.3 Ziele der Arbeit . . . 3
1.4 Methodik der Arbeit . . . 3
1.5 Aufbau der Arbeit . . . 3
2 Grundlagen 5 2.1 Complex Event Processing . . . 5
2.2 Cloud Computing . . . 7
2.3 Optimierung . . . 9
2.3.1 Adaptive Anfragebearbeitung . . . 9
2.3.2 Optimaler Optimierungsprozess . . . 10
2.4 Aufbau des Prototyps . . . 12
2.4.1 Multi Query Optimierung . . . 12
2.4.2 Platzierung von Operatoren . . . 13
2.4.3 Kostenmodell . . . 16
2.4.4 Systemoptimierung . . . 18
2.5 Zusammenfassung . . . 19
3 Anforderungsanalyse 21 3.1 Problemstellung . . . 21
3.1.1 Kosten der ¨Anderung der Systemkonfiguration . . . 22
3.1.2 Faktoren zur Kostenberechnung . . . 25
3.1.3 Bestimmung eines geeigneten Zeitpunkts der Optimierung . . . . 27
3.2 Anforderungen . . . 28
3.3 Zusammenfassung . . . 30
4 Konzeption 31 4.1 Modellierung der Migrationskosten . . . 31
4.1.1 Direkte Migrationskosten . . . 32
4.1.2 Indirekte Migrationskosten . . . 34
4.2 Berechnung der Migrationszeit . . . 35
4.3 Berechnung der indirekten Migrationskosten . . . 37
4.4 Sch¨atzung der Dauer einer Konfiguration des Systems . . . 40
4.5 Bestimmung eines geeigneten Optimierungszeitpunkts . . . 41
4.6 Zusammenfassung . . . 42
5 Systemintegration 45 5.1 Bestehender Optimierungsprozess . . . 45
5.2 Erweiterter Optimierungsprozess . . . 47
6 Evaluation 51 6.1 Auswirkungen der Migration von Operatoren . . . 51
6.1.1 Entwurf . . . 52
6.1.2 Variablen der Analyse . . . 53
6.1.3 Ergebnisse des Experiments . . . 54
6.1.4 Diskussion . . . 57
6.1.5 Bedrohung der Validit¨at . . . 59
6.2 Vergleich der unterschiedlichen Optimierungsprozesse . . . 60
6.2.1 Entwurf . . . 60
6.2.2 Variablen der Analyse . . . 61
6.2.3 Ergebnisse des Experiments . . . 62
6.2.4 Diskussion . . . 69
6.2.5 Bedrohung der Validit¨at . . . 70
6.3 Performanz der Berechnung der Migrationskosten . . . 70
6.3.1 Entwurf . . . 71
6.3.2 Variablen der Analyse . . . 71
6.3.3 Ergebnisse des Experiments . . . 72
6.3.4 Diskussion . . . 74
6.3.5 Bedrohung der Validit¨at . . . 75 6.4 Zusammenfassung . . . 75
7 Abschluss 79
7.1 Zusammenfassung . . . 79 7.2 Ausblick . . . 80
A Multi Query Optimierung 83
Literaturverzeichnis 85
Abbildungsverzeichnis
2.1 Zeitbasierte Fenster zur Verarbeitung von Ereignissen . . . 6
2.2 Problem der Unter- und ¨Uberversorgung . . . 8
2.3 Architektur der Optimierung der Anfragebearbeitung . . . 13
2.4 Ubersicht ¨¨ uber laufende Anfragen . . . 17
2.5 Zus¨atzliche Informationen einer Anfrage . . . 17
2.6 Visualisierung zum Hinzuf¨ugen neuer Anfragen . . . 17
2.7 Systemkosten in Abh¨angigkeit von plc und gran . . . 19
4.1 Verlauf der Migration eines Operators . . . 33
4.2 Verlauf der Verz¨ogerung der Anfragebearbeitung . . . 38
5.1 Optimierungsprozess ohne Ber¨ucksichtigung der Migrationskosten . . . . 46
5.2 Optimierungsprozess mit Ber¨ucksichtigung der Migrationskosten . . . 48
6.1 Steigerung des CPU-Verbrauchs bei der Erstellung und Wiedereinspielung des Zustands eines zustandsbehafteten Operators . . . 55
6.2 Steigerung des Speicherverbrauchs bei der Erstellung und Wiedereinspie- lung des Zustands eines zustandsbehafteten Operators . . . 55
6.3 Ben¨otigte Zeit zur Extraktion und Wiedereinspielung des Zustands eines zustandsbehafteten Operators . . . 55
6.4 Steigerung des CPU-Verbrauchs bei der Migration eines zustandslosen Operators . . . 56
6.5 Steigerung des Speicherverbrauchs bei der Migration eines zustandslosen Operators . . . 56
6.6 Zu ¨ubertragende Datenmenge bei der Migration eines zustandslosen Ope- rators . . . 56
6.7 Zeit zur Migration eines zustandslosen Operators . . . 57
6.8 Durchschnittliche, maximale und minimale Latenz der Anfragen (Anfrage- muster: linear, Ereignisrate: variabel) . . . 63
6.9 Durchschnittliche, maximale und minimale CPU-Auslastung der Rechner- knoten (Anfragemuster: linear, Ereignisrate: variabel) . . . 63 6.10 Anzahl an Operatormigrationen und durchschnittliche genutzte Rechner-
knotenanzahl (Anfragemuster: linear, Ereignisrate: variabel) . . . 63 6.11 Anzahl und gesamte Ausf¨uhrungszeit der Optimierungen (Anfragemuster:
linear, Ereignisrate: variabel) . . . 64 6.12 Ausf¨uhrungszeit und Kosten des Experiments (Anfragemuster: linear,
Ereignisrate: variabel) . . . 64 6.13 Durchschnittliche, maximale und minimale Latenz der Anfragen (Anfrage-
muster: real, Ereignisrate: konstant) . . . 64 6.14 Durchschnittliche, maximale und minimale CPU-Auslastung der Rechner-
knoten (Anfragemuster: real, Ereignisrate: konstant) . . . 65 6.15 Anzahl an Operatormigrationen und durchschnittliche genutzte Rechner-
knotenanzahl (Anfragemuster: real, Ereignisrate: konstant) . . . 65 6.16 Anzahl und gesamte Ausf¨uhrungszeit der Optimierungen (Anfragemuster:
real, Ereignisrate: konstant) . . . 65 6.17 Ausf¨uhrungszeit und Kosten des Experiments (Anfragemuster: real, Ereig-
nisrate: konstant) . . . 66 6.18 Durchschnittliche, maximale und minimale Latenz der Anfragen (Anfrage-
muster: real, Ereignisrate: variabel) . . . 66 6.19 Durchschnittliche, maximale und minimale CPU-Auslastung der Rechner-
knoten (Anfragemuster: real, Ereignisrate: variabel) . . . 66 6.20 Anzahl an Operatormigrationen und durchschnittliche genutzte Rechner-
knotenanzahl (Anfragemuster: real, Ereignisrate: variabel) . . . 67 6.21 Anzahl und gesamte Ausf¨uhrungszeit der Optimierungen (Anfragemuster:
real, Ereignisrate: variabel) . . . 67 6.22 Ausf¨uhrungszeit und Kosten des Experiments (Anfragemuster: real, Ereig-
nisrate: variabel) . . . 67 6.23 Ausf¨uhrungszeit der Kostenberechnung mit Ber¨ucksichtigung der Migrati-
onskosten . . . 72 6.24 Ausf¨uhrungszeit der Zielfunktion 1 mit Ber¨ucksichtigung der Migrations-
kosten . . . 72 6.25 Ausf¨uhrungszeit der Zielfunktion 1 ohne Ber¨ucksichtigung der Migrations-
kosten . . . 73 6.26 Ausf¨uhrungszeit der Zielfunktion 2 mit Ber¨ucksichtigung der Migrations-
kosten . . . 73
6.27 Ausf¨uhrungszeit der Zielfunktion 2 ohne Ber¨ucksichtigung der Migrations- kosten . . . 73 A.1 Prozess zum Vergleich von Operatoren . . . 83
Tabellenverzeichnis
3.1 Variablen zur Bestimmung des Optimierungszeitpunkts . . . 27
4.1 Variablen zur Modellierung der Migrationskosten . . . 32
4.2 Variablen zur Berechnung der Migrationszeit . . . 35
4.3 Variablen zur Berechnung der indirekten Migrationskosten . . . 37
4.4 Variablen zur Absch¨atzung der Dauer einer Systemkonfiguration . . . 41
4.5 Variablen zur Bestimmung eines Optimierungszeitpunkts . . . 42
6.1 Rechnerkonfigurationen . . . 52
6.2 Zielfunktionen der Optimierung . . . 61
6.3 Anfragemuster des Anfragegenerators . . . 61
6.4 Ereignisraten der Ereignisquellen . . . 62
Verzeichnis der Abk¨ urzungen
SLA Service Level Agreement CEP Complex Event Processing GA genetische Algorithmen RRS Recursive Random Search DBMS Datenbankmanagementsystem CQL Continuous Query Language MQO Multi Query Optimierung
CCL Continuous Computation Language
Kapitel 1 Einf¨ uhrung
In diesem Kapitel wird eine kurze Einf¨uhrung in diese Arbeit gegeben. Hierbei wird sowohl der Hintergrund, als auch die Motivation dieser Arbeit erl¨autert. Zus¨atzlich werden die Ziele der Arbeit definiert sowie die Methodik zum Erreichen der Ziele erkl¨art. Als letzter Abschnitt dieses Kapitels wird der Aufbau dieser Arbeit beschrieben.
1.1 Hintergrund
Die Problemstellung der zeitnahen Verarbeitung von Ereignissen von Ereignisstr¨omen gewann in den letzten Jahren an Bedeutung [CJ09]. Ein Beispiel f¨ur die zeitnahe Ver- arbeitung von Ereignissen ist die Auswertung von An- und Verk¨aufen von Aktien zur Ermittlung des Aktienwerts an einem Aktienmarkt [BDG07]. Die Ereignisse der unter- schiedlichen Ereignisstr¨ome k¨onnen in einem logischen oder temporalen Zusammenhang stehen, der durch eine geeignete Analyse genutzt werden kann, um Informationen und komplexe Zusammenh¨ange aus den einzelnen Ereignissen zu gewinnen. Die Auswertung der einzelnen Ereignisse zur Gewinnung neuer Erkenntnisse bezeichnet man als Complex Event Processing (CEP). Um festzulegen wie die Analyse der Ereignisse ausgef¨uhrt werden soll, werden Anfragen definiert, die unterschiedliche Typen und eine variierende Anzahl von Operationen besitzen k¨onnen.
Die Operationen, die in Anfragen des CEP verwendet werden, sind aus dem Kontext von Datenbankmanagementsystemen (DBMS) bekannt, z.B. Selektionen, Aggregationen und Joins, wurden jedoch an die Anforderungen des CEP angepasst. Besonderheit des CEP ist, dass Ereignisstr¨ome und damit die Ereignis- bzw. Datenmenge, die verarbeitet werden, potentiell unendlich ist, da Ereignisse, z.B. Aktienk¨aufe, kontinuierlich erzeugt werden.
Anfragen, z.B. die Ermittlung eines Aktienkurses, werden hierbei ¨uber einen l¨angeren Zeitraum ausgef¨uhrt, weshalb die Verarbeitung der Ereignisse durch die Operationen einer Anfrage kontinuierlich durchgef¨uhrt werden muss. Eine effiziente Verarbeitung von Ereignissen ist hierbei notwendig, um Ergebnisse einer Anfrage zeitnah bereitzustellen.
Durch die langlaufenden Anfragen zur Bearbeitung der Ereignisse ist die Wahrschein- lichkeit groß, dass sich Anforderungen, z.B. die Anzahl an Ereignissen je Zeiteinheit, zur Laufzeit ¨andern [MSHR02].
1.2 Motivation
Durch die variierenden Anforderungen, die durch die beschriebenen Eigenschaften des CEP eintreten k¨onnen, ¨andert sich ebenfalls die Menge an Ressourcen, die zur Verarbei- tung der Ereignisse ben¨otigt wird. Es ist wichtig einem CEP System genug Ressourcen bereitzustellen, um eine zeitnahe Verarbeitung der Ereignisse zu gew¨ahrleisten. Werden nicht genug Ressourcen bereitgestellt, kann dies zu einer Verz¨ogerung der Ereignisver- arbeitung f¨uhren. Falls Ereignisse dabei schneller erzeugt werden, als die Ereignisse verarbeitet werden k¨onnen, m¨ussen gegebenenfalls Ereignisse vom System ohne Bear- beitung verworfen werden [BBD+02]. Je nach vereinbarten Qualit¨atsmerkmalen in den Service Level Agreements (SLA), k¨onnen dem Anbieter eines CEP Systems hierdurch zus¨atzliche Kosten in Form von Strafzahlungen entstehen. Auf der anderen Seite sorgt die Bereitstellung von zu vielen Ressourcen zu einer Ineffizienz des Systems. Es ist deshalb w¨unschenswert, dass das CEP System und die verwendete Ressourcenmenge elastisch sind. Elastizit¨at bedeutet hierbei, dass sowohl eine Abw¨arts-, als auch Aufw¨artsskalierung des Systems durchgef¨uhrt werden kann.
Die Verwendung von Cloud Computing kann hierbei genutzt werden, um die Ressourcen des Systems dynamisch an die aktuellen Anforderungen der Anfragebearbeitung anzupas- sen. Cloud Computing erm¨oglicht durch die Verwendung verschiedener Prinzipien und Mechanismen, z.B. Virtualisierung der Ressourcen, die Bereitstellung einer prinzipiell un- endlichen Ressourcenmenge. Ressourcen werden in Form von Rechnerknoten bereitgestellt, die eine begrenzte Menge an CPU-Kapazit¨at, Arbeitsspeicher und Netzwerkbandbreite besitzen. Die Anzahl an verwendeten Rechnerknoten kann hierbei dynamisch an die mo- mentanen Anforderungen des Systems angepasst werden, wobei einzelne Rechnerknoten zeitnah bereitgestellt und freigegeben werden k¨onnen. Beispielsweise dauert die Bereitstel- lung zus¨atzlicher Ressourcen bei dem Cloud-Anbieter Amazon EC2 [Ama] in der Regel nur 2 bis 5 Minuten [AFG+09]. Besonderheit bei der Verwendung von Cloud Computing ist, dass kaum Investitionen notwendig sind, sondern die verwendeten Ressourcen auf Basis der Nutzung bezahlt werden. Ziel bei der Verwendung von Cloud Computing ist die Gesamtbetriebskosten durch die geringeren Investitions- und Wartungskosten zu reduzieren.
Um eine kosteneffiziente Anfragebearbeitung zu erm¨oglichen, muss das System st¨andig optimiert werden, um das System auf ge¨anderte Anforderungen der Anfragebearbeitung anzupassen. Eine Optimierung der Anfragebearbeitung kann hierbei z.B. durch die Mi- nimierung der Anzahl an verwendeten Rechnerknoten durchgef¨uhrt werden. Durch die Optimierung soll zum einen sichergestellt werden, dass dem System genug Ressourcen zur Bearbeitung aller Anfragen bereitgestellt werden. Zum anderen soll durch die Optimierung eine effiziente Konfiguration des Systems bestimmt werden, wodurch die Gesamtkosten des Systems m¨oglichst minimiert werden sollen.
Problematisch bei der Optimierung ist, dass die ¨Anderung der Systemkonfiguration Auswirkungen auf die Ereignisverarbeitung haben kann. Durch die Verschiebung von Ope- ratoren einer Anfrage ist es je nach verwendeten CEP System gegebenenfalls notwendig die Anfragebearbeitung zeitweise zu unterbrechen. Je nach Art der Konfigurations¨anderung, die durch die Optimierung bestimmt wird, kann die Anfragebearbeitung durch verschie- dene Auswirkungen beeinflusst werden. Es ist wichtig diese Auswirkungen absch¨atzen zu k¨onnen, und in den Optimierungsprozess zu integrieren, da sonst die Kosten durch die Konfigurations¨anderung h¨oher sein k¨onnen als die Kosteneinsparung durch die optimierte
Anfragebearbeitung [BB05]. Ein weiteres Problem der Optimierung ist, dass die Optimie- rung selbst Ressourcen verbraucht. Da die Gesamtkosten des Systems abh¨angig von der Ressourcennutzung sind, sollte eine Optimierung nur dann ausgef¨uhrt werden, falls durch die Optimierung eine effizientere Ereignisverarbeitung erreicht wird, und hierdurch die Gesamtkosten des Systems reduziert werden. Durch die effizientere Ausf¨uhrung m¨ussen die Kosten, die durch die Optimierung und die ¨Anderung der Konfiguration entstehen, zur Laufzeit der optimierten Konfiguration amortisiert werden.
1.3 Ziele der Arbeit
Ziel dieser Arbeit ist es M¨oglichkeiten zur Steigerung der Effizienz bzw. zur Minimierung der Kosten des vorhandenen cloudbasierten CEP Systems zu bestimmen. Hierbei sollen zwei unterschiedliche Aspekte untersucht werden. Zum einen soll ¨uberpr¨uft werden, ob die Effizienz des bestehenden cloudbasierten CEP Systems gesteigert werden kann, indem die Auswirkungen der ¨Anderung der Systemkonfiguration im Optimierungsprozess ber¨ucksichtigt werden. Zum anderen soll eine M¨oglichkeit erarbeitet werden, geeignete Optimierungszeitpunkte im vorhandenen Prototypen zu bestimmen.
1.4 Methodik der Arbeit
Zum Erreichen des Ziels dieser Arbeit m¨ussen verschiedene Schritte ausgef¨uhrt werden, die im Folgenden kurz erl¨autert werden.
Erster Schritt ist die Analyse bestehender Verfahren zur Absch¨atzung der Auswirkungen einer Konfigurations¨anderung in CEP bzw. cloudbasierten Systemen um m¨ogliche Arten der Auswirkungen sowie Einflussfaktoren einer Optimierung bzw. Konfigurations¨anderung zu bestimmen. Zus¨atzlich m¨ussen bestehende Verfahren ermittelt und analysiert werden, die zur Bestimmung eines geeigneten Optimierungszeitpunkts verwendet werden k¨onnen.
Anhand der durchgef¨uhrten Analyse m¨ussen im zweiten Schritt Modelle entwickelt werden, die die Auswirkungen einer Optimierung im vorhandenen cloudbasierten CEP System absch¨atzen bzw. geeignete Zeitpunkte f¨ur eine Optimierung ermitteln k¨onnen.
Die entwickelten Modelle m¨ussen im Anschluss im dritten Schritt in den existierenden Prototypen integriert werden, um den aktuellen Optimierungsprozess zu erweitern.
Im vierten Schritt muss eine geeignete Evaluation der vorgenommen ¨Anderungen des Systems durchgef¨uhrt werden, in der die Auswirkungen bestimmt werden, die durch die Verwendung der entwickelten Modelle entstehen.
1.5 Aufbau der Arbeit
Um einen genaueren Einblick in die Problemstellung und Ziele dieser Arbeit zu geben, werden in Kapitel 2 die Grundlagen dieser Arbeit erl¨autert. Hierbei werden die Begriffe CEP, Cloud Computing und adaptive Anfragebearbeitung erkl¨art. Außerdem wird das vorhandene cloudbasierte CEP System beschrieben.
Im Anschluss wird in Kapitel 3 die Problemstellung dieser Arbeit angegeben sowie die m¨oglichen Arten der Auswirkungen und Einflussfaktoren einer Konfigurations¨anderung
dargestellt, die in bestehenden Arbeiten verwendet werden. Außerdem werden in diesem Kapitel die Anforderungen dieser Arbeit analysiert.
In Kapitel 4 wird im Anschluss beschrieben, wie die verschiedenen Arten der Auswirkungen einer Optimierung im bestehenden cloudbasierten CEP System anhand der verschiedenen Einflussfaktoren im System gesch¨atzt werden k¨onnen.
Sowohl der bestehende Prozess der Optimierung, als auch die Integration der entwickelten Modelle in den vorhandenen Optimierungsprozess wird in Kapitel 5 beschrieben.
Die notwendige Evaluation zur Bewertung der Umsetzung der entwickelten Modelle wird in Kapitel 6 dargestellt. Hierbei werden sowohl die durchgef¨uhrten Messungen, als auch die erhaltenen Ergebnisse erl¨autert und ausgewertet.
In Kapitel 7 wird abschließend eine Zusammenfassung der Arbeit gegeben und m¨ogliche Themen f¨ur zuk¨unftige Arbeiten sowie zus¨atzliche Erweiterungen der entwickelten Modelle beschrieben.
Kapitel 2 Grundlagen
Diese Arbeit besch¨aftigt sich mit der adaptiven Anpassung der Anfragebearbeitung eines cloudbasierten Complex Event Processing (CEP) Systems. Um die Aufgabenstellung dieser Arbeit besser verstehen zu k¨onnen, werden im Folgenden die Grundlagen zu CEP, Cloud Computing und adaptiver Anfragebearbeitung erl¨autert. Da diese Arbeit auf einem bestehenden Prototypen aufbaut und das existierende System erweitern soll, werden ebenfalls relevante Informationen bez¨uglich des vorhandenen CEP Prototypen kurz beschrieben.
2.1 Complex Event Processing
Complex Event Processing beschreibt die Erkennung von Mustern der Eigenschaften bzw.
zeitlichen Zusammenh¨angen von Ereignissen innerhalb einem oder mehreren kontinuierli- chen Ereignisstr¨omen [Luc01]. Die Verarbeitung der Ereignisse erfolgt hierbei nach dem Eintreffen des Ereignisses kontinuierlich und zeitnah, im Gegensatz zu Datenbankanfragen, die einmalig gegen eine endliche Datenmenge ausgef¨uhrt werden [EB09]. Ereignisse sind erkennbare relevante Zustands¨anderungen [MFP06], die f¨ur die weitere Verarbeitung von Bedeutung sind, z.B. An- und Verk¨aufe von Aktien. Zu beachten ist, dass die einzelnen Ereignisse, im Gegensatz zu Datenbankmanagementsystemen (DBMS), im Allgemeinen nicht persistent gespeichert, sondern direkt verarbeitet werden.
Die einzelnen Ereignisstr¨ome, die zur Musteranalyse verarbeitet werden, sind unabh¨angig, und k¨onnen verschiedene Eigenschaften wie Ereignisformat oder Ereignisraten besitzen.
Die gegebenenfalls unterschiedlichen Formate der Ereignisse der Ereignisstr¨ome sind jedoch zu Beginn bekannt, und ¨andern sich zur Laufzeit nicht. Obwohl die einzelnen Ereignisstr¨ome unabh¨angig voneinander sind, k¨onnen zwischen den Ereignisstr¨omen logische Verbindungen bestehen [LF98]. Entsprechend k¨onnen die zugeh¨origen Ereignisse zu komplexen Ereignissen aggregiert werden, die h¨ohere und wertvollere Informationen darstellen [EB09]. Diese Mustererkennung bzw. Analyse basiert auf formulierten, konti- nuierlichen Anfragen.
Zur Definition von kontinuierlichen Anfragen, k¨onnen unter anderem graphische Interfa- ces [KS04] genutzt werden. Alternativ dazu k¨onnen deklarative, SQL-basierte Anfragespra- chen, z.B. Continuous Query Language (CQL) [ABW06] oder Continuous Computation Language (CCL) [Syb12] verwendet werden. Ausgangspunkt einer kontinuierlichen An- frage sind ein oder mehrere Ereignisstr¨ome, die in der Anfrage durch Ereignisquellen
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
EreignisstromvA EreignisstromvB VerarbeitungsreihenfolgevdervEreignissev
verworfenevEreignisse zukünftigevEreignisse
Abbildung 2.1: Zeitbasierte Fenster zur Verarbeitung von Ereignissen
repr¨asentiert werden. Die Ergebnisse einer Anfrage werden in Ereignissenken bereitge- stellt. Zwischen den Ereignisquellen und Ereignissenken k¨onnen sich eine beliebige Anzahl unterschiedlicher Operationen befinden, z.B. Selektionen, Aggregationen, Joins usw.
Obwohl die genannten Operationen aus dem Kontext von DBMS bekannt sind, gibt es dennoch Unterschiede. Zum einen werden Operationen zur Ausf¨uhrung in Operatoren gekapselt, die neben den Informationen der Operationen, z.B. Bedingung einer Selektion, zus¨atzliche Informationen enthalten, z.B. Verbindungsinformationen zu anderen Operato- ren. Die Operatoren werden hierbei zur Anfragebearbeitung bzw. Ereignisverarbeitung kontinuierlich ausgef¨uhrt. Zum anderen wird in einigen Operatoren, z.B. Aggregatio- nen oder Joins, das Prinzip der Akkumulation verwendet. Akkumulation in Bezug auf CEP bedeutet, dass nur ein endlicher Ausschnitt der Ereignisstr¨ome gespeichert und weiterverarbeitet wird, da die Verarbeitung aller Ereignisse der potentiell unendlichen Ereignisstr¨ome nicht m¨oglich ist [EB09].
Zur Umsetzung des Prinzips der Akkumulation werden in CEP Systemen zeitbasier- te Fenster [BDM02], die nur einen gewissen Zeitraum betrachten, oder anzahlbasierte Fenster [GO03] verwendet, die die Anzahl der ber¨ucksichtigten Ereignisse beschr¨anken.
Abbildung 2.1 k¨onnte die zeitbasierten Fenster eines Joins darstellen, der die Ereignisse zweier Ereignisstr¨omeA und B miteinander verbindet. Die Zahlen repr¨asentieren hier- bei die Positionen der Ereignisse in den Ereignisstr¨omen. Die Ereignisse innerhalb der Rechtecke werden zur Anfragebearbeitung zwischengespeichert. Die Ereignisse, die sich außerhalb der Rechtecke befinden, wurden entweder noch nicht verarbeitet, oder wurden bereits verworfen. Zu beachten ist, dass die Gr¨oße der Fenster selbst innerhalb eines Operators variieren kann, z.B. wenn zeitliche Bedingungen verwendet werden, um zu entscheiden wann ein Ereignis des Fensters verworfen werden kann. Operatoren, die zur Ausf¨uhrung zeit- oder anzahlbasierte Fenster verwenden, werden als zustandsbehaftete Operatoren bezeichnet, wobei die Ereignisse, die in den Fenstern gespeichert werden, unter anderem den Zustand der entsprechenden Operatoren bilden. Operatoren, die keine zeit- oder anzahlbasierten Fenster zur Ereignisverarbeitung ben¨otigen, z.B. Selektionen, werden zustandslose Operatoren genannt.
Zus¨atzlich muss bei der Ereignisverarbeitung in CEP ber¨ucksichtigt werden, dass das Ergebnis eines Operators bzw. einer kontinuierlichen Anfrage kein einmaliges Ergebnis wie in DBMS ist, sondern erneut ein kontinuierlicher Ereignisstrom ist.
Die durch die Analyse der Ereignisstr¨ome gewonnen Erkenntnisse dienen als Aus- gangspunkt f¨ur Entscheidungen oder Aktionen, z.B. Aktienkauf, Starten eines neuen Prozesses usw. [EB09]. Anwendungsgebiete von CEP sind unter anderem Finanzan- wendungen [ScZ05], z.B. Betrugserkennung durch Analyse von Kreditkartentransaktio- nen [SMMP09], Sensornetzwerke [CcC+02] zur Verarbeitung von Sensordaten, Business
Activity Monitoring [EB09] in dem z.B. Gesch¨aftsprozesse ¨uberwacht werden, und die Uberwachung von Netzwerken und Infrastrukturen [WDR06]. Bei der Auswertung von¨ Ereignisstr¨omen k¨onnen sowohl bekannte Muster, oder durch Verwendung von Mechanis- men des maschinellen Lernens unbekannte Muster gesucht werden [JHJ13].
In der Praxis, z.B. bei der Verarbeitung von Informationen aus Finanztransaktionen, m¨ussen CEP Systeme die Ereignisse von verschiedenen Ereignisstr¨omen verarbeiten, die Millionen von Ereignissen in der Sekunde erzeugen [Cor11]. Die Ereignisse m¨ussen gege- benenfalls von einer hohen Anzahl von gleichzeitig laufenden Anfragen bearbeitet werden.
Entsprechend k¨onnen die Ressourcenanforderungen f¨ur einen einzelnen Rechnerknoten zu hoch sein. Um dennoch eine zeitnahe Ereignisverarbeitung zu erm¨oglichen, kann ein verteiltes System zur Ereignisverarbeitung verwendet werden. Hierbei entstehen jedoch neue Problemstellungen, z.B. wie die Operatoren der kontinuierlichen Anfragen auf die vorhandenen Rechnerknoten des verteilten CEP Systems platziert werden [LLS08]. Bei der Platzierung der Operatoren m¨ussen die Eigenschaften von CEP Anfragen ber¨uck- sichtigt werden. Im Gegensatz zur Problemstellung des Schedulings [BSBS13] k¨onnen mehrere Operatoren gleichzeitig einem Rechnerknoten zugeordnet werden, und ¨uber einen l¨angeren Zeitraum ausgef¨uhrt werden. K¨onnen trotz der Verwendung mehrerer Rechner- knoten nicht gen¨ugend Ressourcen zur Anfragebearbeitung bereitgestellt werden, m¨ussen Ereignisse der Operatoren oder Ereignisstr¨ome ohne Bearbeitung verworfen werden (load shedding) [BBD+02].
Um Qualit¨atsanforderungen, z.B. Antwortzeiten oder Ereignisdurchsatz, einhalten zu k¨onnen, muss das CEP System kontinuierlich ¨uberwacht und an die aktuellen Anforde- rungen der Anfragebearbeitung angepasst werden. Problematisch hierbei ist, dass die Ereignisraten mit der Zeit variieren, oder Ereignisse stoßweise auftreten k¨onnen [CJ09].
Entsprechend wichtig sind eine effiziente Anfragebearbeitung und -optimierung, gute Skalierbarkeit und hohe Verf¨ugbarkeit des Systems [ScZ05]. Durch diese komplexen Anfor- derungen, die durch die zeitnahe Verarbeitung einer hohen Anzahl von Ereignissen (große Datenmenge) im Kontext von CEP auftreten k¨onnen, stoßen bestehende Datenverarbei- tungsinfrastrukturen, z.B. DBMS, an ihre Grenzen [ScZ05]. Um die hohen Anforderungen des CEP zu erf¨ullen, kann z.B. Cloud Computing verwendet werden, das unter anderem gute Eigenschaften bez¨uglich der Skalierbarkeit und Verf¨ugbarkeit bietet.
2.2 Cloud Computing
Die Ergebnisse dieser Arbeit werden innerhalb eines CEP Prototypen implementiert, der die Probleme bez¨uglich der hohen Effizienzanforderungen des CEP durch die Verwendung von Cloud Computing l¨ost.
F¨ur Cloud Computing gibt es eine Vielzahl von unterschiedlichen Definitionen [VRMCL08].
Die folgende Definition von Cloud Computing wird hierbei vom National Institute of Standards and Technology (NIST) ¨ubernommen [MG09]:
”Cloud Computing ist ein Model, das jederzeit eine praktische Nutzung geteilter, konfigurierbarer Rechenressourcen (z.B. Netzwerke, Server, Speicher, Anwendungen und Dienste) auf Anfrage ¨uber ein Netzwerk erlaubt, wobei eine schnelle Bereitstellung und Freigabe mit minimalen Managementaufwand oder Serviceprovider-Interaktion erm¨oglicht wird.“
Systemlast Statische Ressourcenbereitstellung Elastische Ressourcenbereitstellung
Ressourcenmenge
Zeit Überversorgung
Unterversorgung
Abbildung 2.2: Problem der Unter- und ¨Uberversorgung
Die wesentlichen Neuerungen, die durch Cloud Computing eingef¨uhrt werden, sind hierbei folgende Merkmale [AFG+09]:
1. Illusion einer unendlichen verf¨ugbaren Ressourcenmenge 2. Keine Investitionskosten
3. Bezahlung der Ressourcen auf Basis der Nutzung 4. Schnelle Bereitstellung bzw. Freigabe von Ressourcen
Außerdem bietet Cloud Computing die M¨oglichkeit Anwendungen durch ¨Anderungen des Rechnerknotens zu verschieben sowie eine automatische Ressourcenverwaltung [ZCB10].
Obwohl die meisten Anwendungen vorhersagbaren, periodischen oder saisonalen Schwan- kungen unterliegen, treten oft unvorhersehbare Spitzenlasten auf [AFG+09]. Um diese Spitzenlasten abzufangen, und gen¨ugend Ressourcen bereitzustellen, k¨onnen Cloud- Technologien verwendet werden. Die genutzten Anwendungen m¨ussen hierbei elastisch sein, um sich entsprechend schnell an ge¨anderte Anforderungen durch eine Aufw¨arts- oder Abw¨artsskalierung anpassen zu k¨onnen [AFG+09]. Die Anforderungen bez¨uglich der Elastizit¨at werden von modernen Cloud-Anbietern wie Amazon EC2 [Ama] un- terst¨utzt, indem z.B. zus¨atzliche Ressourcen innerhalb von 2 bis 5 Minuten angeboten werden k¨onnen [AFG+09]. Diese schnelle Bereitstellung neuer Ressourcen ist ein enormer Vorteil im Vergleich zur traditioneller Ressourcenbeschaffung in der von der Finanzie- rung, Kauf, Lieferung und Installation neuer Hardware mehrere Monate verstreichen k¨onnen [KHSS10].
Durch die schnelle Ressourcenbereitstellung bzw. -freigabe bei der Verwendung von Cloud-Technologien ist es m¨oglich die Kosten f¨ur die ¨Uberversorgung (Over Provisioning) bzw. das Risiko der Unterversorgung (Under Provisioning) zu reduzieren [AFG+09]. Die Probleme der ¨Uberversorgung bzw. Unterversorgung werden in Abbildung 2.2 dargestellt.
Uberversorgung bezeichnet hierbei die Bereitstellung von zu vielen Ressourcen f¨¨ ur die ak- tuellen Anforderungen, was zu einer ineffizienten Hardwarenutzung f¨uhrt, da nur ein Teil der vorhandenen Hardware genutzt wird. Bei einer Unterversorgung hingegen werden zu wenig Ressourcen f¨ur die aktuellen Anforderungen bereitgestellt, wodurch gegebenenfalls Laufzeitanforderungen der Anwendungen bez¨uglich Antwortzeit oder Durchsatz nicht mehr gew¨ahrleistet werden k¨onnen. K¨onnen die Kosten f¨ur die ¨Uberversorgung konkret bestimmt werden, ist dies f¨ur eine Unterversorgung nur schwer m¨oglich [AFG+09]. Eine
Unterversorgung kann zu einem Verlust von Kunden f¨uhren, falls eine Anfragebearbeitung zu lange dauert, oder zu Strafzahlungen, falls vereinbarte Service Level Agreements (SLA) nicht eingehalten werden [AFG+09].
Um die Elastizit¨at von cloudbasierten Systemen zu erm¨oglichen, werden unter ande- rem Prinzipien der Virtualisierung und Skalierbarkeit im Bereich der Hardware einge- setzt [VRMCL08]. Anwender haben den Vorteil, dass zur Bereitstellung von Anwendungen bzw. Diensten kaum Hardware ben¨otigt wird, weshalb nur ein geringer Installations- und Wartungsaufwand existiert. Die Hardware kann hierbei entsprechend den aktuellen Anforderungen gemietet bzw. angefordert werden [Hay08].
Es gibt eine Vielzahl unterschiedlicher Dienste, die per Cloud Computing genutzt werden k¨onnen. Hierbei reicht das Angebot von Software, z.B. Google Docs [Goo], ¨uber Plattform, z.B. Microsoft Azure [Win], bis hin zur reinen Infrastruktur, z.B. Amazon EC2 [WAB+09].
Die anfallenden Kosten bei der Verwendung von Cloud-Technologien sind abh¨angig von den genutzten Ressourcen, entsprechend ist bei der Benutzung von Cloud Computing neben der Ber¨ucksichtigung von Qualit¨atseigenschaften der Anwendungen, wie Antwort- zeit oder Durchsatz, ebenfalls eine effiziente Nutzung der Ressourcen notwendig. Im Vergleich zur Verwendung von herk¨ommlicher Hardware erfordert der Einsatz von Cloud- Technologien oft eine Architektur¨anderung existierender Systeme, um eine kosteneffiziente Ausf¨uhrung zu erm¨oglichen [FK09]. Um die Effizienz eines Systems zur Laufzeit, auch unter sich ¨andernden Bedingungen, zu gew¨ahrleisten, ist eine st¨andige Optimierung des Systems notwendig.
2.3 Optimierung
Ziel des vorhandenen CEP Systems ist eine kosteneffiziente, elastische Anfragebearbeitung unter Verwendung von Cloud-Technologien zu erm¨oglichen. Um die Ziele der Kosteneffizi- enz und Elastizit¨at zu erf¨ullen, ist eine kontinuierliche Adaption der Anfragebearbeitung des CEP Systems an die aktuellen Anforderungen, z.B. Qualit¨atsanforderungen der Anfragebearbeitung, notwendig.
2.3.1 Adaptive Anfragebearbeitung
Die traditionelle Anfragebearbeitung innerhalb eines DBMS verwendet den Plan First Execute Next Ansatz, in dem eine Anfrage einmalig optimiert wird, und nach der Optimie- rung ausgef¨uhrt wird [BB05]. Um mit dem Plan First Execute Next Ansatz ein optimales Ergebnis zu erhalten, m¨ussen Informationen, z.B. Laufzeitverhalten, Dateneigenschaften usw., zum Optimierungszeitpunkt, also vor der Ausf¨uhrung der Anfrage, vorhanden sein [DIR07]. Gerade in CEP Systemen ist aufgrund der lang laufenden Anfragen die Wahrscheinlichkeit jedoch groß, dass sich Ereignis- oder Systemeigenschaften zur Laufzeit
¨andern [MSHR02]. Entsprechend schwierig ist es, einen effizienten Ausf¨uhrungsplan vor der Bearbeitung einer Anfrage zu bestimmen, weshalb eine adaptive Anfragebearbeitung verwendet werden muss, um eine hohe Effizienz zu gew¨ahrleisten [CG13].
Adaptive Anfragebearbeitung bedeutet hierbei, dass die Optimierung der Anfragebear- beitung zur Laufzeit gegebenenfalls mehrmals durchgef¨uhrt wird, um eine optimale An- fragebearbeitung bei variierenden Bedingungen zur Laufzeit zu gew¨ahrleisten [BB05]. Bei l¨angerer Laufzeit, oder mehrmaliger Ausf¨uhrung kann eine adaptive Anfragebearbeitung
genutzt werden, um Fehler des Optimierers, unbekannte oder ge¨anderte Statistiken, ¨Ande- rungen der Dateneigenschaften und Systembedingungen zu ber¨ucksichtigen [BBR+12].
Weitere Anwendungsbeispiele neben CEP f¨ur adaptive Anfragebearbeitung sind Anwen- dungen zur Datenintegration [BFMV00] und gegebenenfalls auch relationale Anfragen in DBMS [NWMN99].
Da bei der Optimierung eine hohe Zahl von Faktoren ber¨ucksichtigt werden muss, z.B.
Systemkonfiguration, Eigenschaften der Ereignisstr¨ome usw., ist es kaum m¨oglich die An- fragebearbeitung effizient manuell zu optimieren, weshalb eine automatische Optimierung erfolgen sollte [KCS05].
2.3.2 Optimaler Optimierungsprozess
Eine Optimierung erfolgt in der Regel in drei Schritten [BB05]:
1. Bestimmung des Optimierungszeitpunkts 2. Berechnung der Optimierungsm¨oglichkeiten 3. Umsetzung der besten Optimierungsm¨oglichkeit
Teilweise wird die Optimierung auch in vier Phasen getrennt, dem MAPE (Monitor, Analyse, Process, Execute) Zyklus [DIR07]:
Monitor Um eine Optimierung durchf¨uhren zu k¨onnen, ist es notwendig vorhandene In- formation zu verwenden, um eine Effizienzsteigerung zu erreichen. Um Informationen zu nutzen, m¨ussen relevante Eigenschaften, z.B. Ereignisraten der Ereignisquel- len, ¨uberwacht werden. Diese ¨Uberwachung muss kontinuierlich erfolgen, da sich Eigenschaften zur Laufzeit des Systems ¨andern k¨onnen.
Analyse Informationen, die durch die ¨Uberwachung der Systemeigenschaften gewonnen wurden, m¨ussen analysiert werden, um z.B. zeitliche Zusammenh¨ange erkennen zu k¨onnen.
Process Auf Grundlage der analysierten Informationen kann durch geeignete Opti- mierungsverfahren verschiedene M¨oglichkeiten zur Steigerung der Effizienz des Systems ermittelt werden. Die unterschiedlichen M¨oglichkeiten m¨ussen miteinan- der verglichen, und die beste M¨oglichkeit ausgew¨ahlt werden. Je nach Ziel der Optimierung m¨ussen unterschiedliche Aspekte, z.B. Ausf¨uhrungszeit, Kosten oder Ressourcenverbrauch, bei der Auswahl der Optimierungsm¨oglichkeit ber¨ucksichtigt werden.
Execute Die ermittelte M¨oglichkeit zur Optimierung muss in der letzten Phase im System umgesetzt werden. Zur Umsetzung k¨onnen dabei mehrere Schritte notwendig sein, z.B. ¨Anderung der Systemkonfiguration, Berechnung einer optimierten Platzierung der Operatoren oder Verschiebung von Operatoren.
Innerhalb der drei bzw. vier Phasen m¨ussen verschiedene Faktoren der Optimierung festgelegt werden. Es m¨ussen Art, Ziel und Zeitpunkt der Optimierung bestimmt wer- den [BCM+12]. Zum besseren Verst¨andnis werden die genannten Punkte im Folgenden kurz erl¨autert:
Arten der Optimierung Prinzipiell k¨onnen verschiedene Verfahren zur Optimierung verwendet werden. Hierbei k¨onnen zwei Arten von Verfahren unterschieden wer- den, deterministische und heuristische Verfahren. Der Unterschied zwischen den beiden Arten ist, dass deterministische Verfahren mit der gleichen Eingabe im-
mer das gleiche Ergebnis liefern. Heuristische Verfahren, z.B. genetische Algorith- men (GA) [VKP11], k¨onnen bei der selben Eingabe unterschiedliche Ergebnisse liefern. Im Gegensatz zu heuristischen Verfahren k¨onnen deterministische Verfah- ren eine optimale L¨osung finden. Der Grund, warum h¨aufig dennoch heuristische Verfahren eingesetzt werden, ist, dass heuristische Verfahren teilweise ausreichend gute Ergebnisse finden, und dabei eine geringere Laufzeit oder geringeren Ressour- cenverbrauch im Vergleich zu deterministischen Verfahren haben.
Optimierungsziel In einem System gibt es prinzipiell verschiedene Ansatzpunkte f¨ur eine Optimierung. Ein m¨ogliches Ziel einer Optimierung kann die Minimierung der Kosten bzw. des Ressourcenverbrauchs des Systems sein. Hierzu k¨onnen verschie- dene Systemeigenschaften, z.B. Anzahl und Konfiguration der Rechnerknoten, bei der Optimierung ber¨ucksichtigt werden. Innerhalb eines verteilten Systems muss ebenfalls entschieden werden, ob das gesamte System optimiert werden soll, oder nur einzelne Rechnerknoten. Neben der Optimierung der Rechnerknoten ist ebenfalls eine Optimierung des CEP Systems m¨oglich. Hierbei k¨onnen unter anderem die Strategie zur Platzierung der Operatoren einer Anfrage bestimmt werden, oder die Anzahl an Ereignissen angepasst werden, die zwischengespeichert werden, falls ein Rechnerknoten die erzeugten Ereignisse nicht direkt verarbeiten kann.
Zeitpunkt der Optimierung Problematisch bez¨uglich der Optimierung ist, dass zum einen die Optimierungsalgorithmen Ressourcen und Zeit ben¨otigen. Zum anderen ben¨otigt die Umsetzung der bestimmten ¨Anderungen der Optimierung ebenfalls Ressourcen und Zeit [VBVB09] bzw. hat gegebenenfalls negative Auswirkung auf das System, z.B. h¨ohere Antwortzeiten oder geringerer Durchsatz der Anfragen.
Entsprechend wichtig ist die Bestimmung eines geeigneten Optimierungszeitpunkts.
Die Eignung eines Zeitpunkts zur Optimierung kann je nach Ziel der Optimierung variieren, entsprechend m¨ussen die Ziele bei der Auswahl des Optimierungszeit- punkts ber¨ucksichtigt werden.
Hierbei k¨onnen zwei Zeitpunkte der Entscheidungsfindung der Optimierung unter- schieden werden, Start und Umsetzung (Migration) der bestimmten ¨Anderungen der Optimierung. Eine Optimierung zu starten ist sinnvoll, falls neue Informationen vorhanden sind [ZZSB13], z.B. aktuellere Statistiken, oder ge¨anderte Systemanfor- derungen, da bei der Optimierung sonst die selben (deterministische Verfahren) oder ¨ahnliche (heuristische Verfahren) Ergebnisse zu erwarten sind. Entsprechend wichtig ist es abzusch¨atzen, wie gravierend sich die aktuellen ¨Anderungen auf die Effizienz des Systems auswirken. Eine Optimierung sollte nur ausgef¨uhrt werden, falls eine relevanten Steigerung der Effizienz erwartet wird [KD98].
Wurde eine Optimierung gestartet und ¨Anderungen zur Effizienzsteigerung ermit- telt, muss ebenfalls ¨uberpr¨uft werden, ob die bestimmten ¨Anderungen sinnvoll sind und durchgef¨uhrt werden sollen [LXJ+11]. Die Kosten, die durch die ¨Anderungen des Systems entstehen, m¨ussen sich zur Laufzeit durch die Effizienzsteigerung des Systems amortisieren [JJH+09].
Problematisch in CEP Systemen ist, dass die exakte Laufzeit einer Konfiguration im voraus nicht berechnet werden kann, entsprechend muss eine Absch¨atzung der Laufzeit durchgef¨uhrt werden, und entschieden werden, ob eine ¨Anderung der Sy- stemkonfiguration sinnvoll ist [JJH+09]. Bei einer bestimmten Effizienzsteigerung
des Systems gilt, je l¨anger die erwartete Laufzeit einer Konfiguration ist, desto h¨oher k¨onnen die Migrationskosten sein, um dennoch eine Kostenreduktion zu bewirken.
Sowohl Art [Ji11], als auch Ziel [R¨od12] der Optimierung der Anfragebearbeitung wurden bereits in vorherigen Arbeiten f¨ur den vorhandenen CEP Prototypen erarbeitet und integriert. Ziel dieser Arbeit ist es den Optimierungsprozess des bestehenden cloudba- sierten CEP Systems zu erweitern, und so die Kosteneffizienz des Prototyps weiter zu verbessern. Hierbei sollen Mechanismen entwickelt werden, die zum einen geeignete Opti- mierungszeitpunkte bestimmen k¨onnen, und zum anderen die Auswirkungen absch¨atzen k¨onnen, die durch ¨Anderung des Systems w¨ahrend der Optimierung im bestehenden System entstehen. Um mehr Verst¨andnis f¨ur die Problemstellung dieser Arbeit zu erhalten, werden im n¨achsten Abschnitt die relevanten Verfahren des bestehenden Prototypen erl¨autert.
2.4 Aufbau des Prototyps
Ziel des bestehenden Prototyps ist es ein kosteneffizientes CEP System auf Basis von Cloud- Technologien bereitzustellen. Um dieses Ziel umzusetzen, wurden bereits mehrere System- komponenten entwickelt. Es wurden unter anderem verschiedene Strategien zur Platzie- rung von Operatoren und ein Verfahren zur Multi Query Optimierung (MQO) [Ji11], ein Kostenmodell [Mey12] und Verfahren zur Systemoptimierung [R¨od12] umgesetzt, die im Folgenden erl¨autert werden.
2.4.1 Multi Query Optimierung
Kern der Optimierung des existierenden CEP Systems ist das Verfahren zur MQO und verschiedene Strategien zur Platzierung der Operatoren [Ji11]. Sobald Nutzer des CEP Sy- stems neue Anfragen formulieren, werden diese durch die MQO Komponente verarbeitet, siehe Abbildung 2.3. Hierbei wird durch die MQO versucht, (Teil-)Ergebnisse von beste- henden Anfragen wiederzuverwenden, um eine h¨ohere Effizienz der Anfragebearbeitung zu erreichen. Wichtig ist hierbei, dass der verwendete Ansatz ein inkrementelles Hinzuf¨ugen bzw. Entfernen von Anfragen erm¨oglicht. Hierdurch ist es m¨oglich Anfragen zur Laufzeit hinzuzuf¨ugen bzw. zu entfernen, ohne einen zu großen Mehraufwand zu verursachen, da gegebenenfalls nur bestehende Anfragen, deren (Teil-)Ergebnisse wiederverwendet werden, durch die MQO beeintr¨achtigt werden. Anfragen, deren Ergebnisse nicht wiederverwendet werden, werden bei dem Hinzuf¨ugen bzw. Entfernen von Anfragen nicht beeinflusst.
Zur Wiederverwendung bestehender (Teil-)Ergebnisse werden neue Anfragen mit ei- nem globalen Anfragegraphen verglichen. Der globale Anfragegraph enth¨alt hierbei alle aktiven Operatoren der aktuell bearbeiteten Anfragen und entsprechend die Verbindun- gen zwischen den Operatoren. Der Suchraum zur Bestimmung einer ¨Aquivalenz von (Teil-)Anfragen ist groß, da es z.B. unterschiedliche semantisch-¨aquivalente Anfragepl¨ane f¨ur eine Anfrage gibt. Grund hierf¨ur ist, dass die M¨oglichkeit besteht eine semantisch-
¨aquivalente Umformung einer Anfrage durchzuf¨uhren, z.B. auf Basis der Kommutativit¨at von Selektionen. Um dennoch eine effiziente MQO zu erm¨oglichen wurde ein geeignetes Verfahren [Ji11] entwickelt, welches in Anhang A genauer beschrieben wird.
Kann das Ergebnis einer neuen Anfrage nicht durch die Wiederverwendung der Ergebnisse
neueQAnfragen
GlobalerQAnfragegraph
Platzierungskomponente initialeQPlatzierung
Platzierungsentscheidung Laufzeitinformationen
Laufzeitplatzierung
verteiltesQCEPQSystem MultiQQueryQOptimierungskomponente
Systemoptimierungskomponente
Abbildung 2.3: Architektur der Optimierung der Anfragebearbeitung
vorhandener Operatoren bereitgestellt werden, m¨ussen neue Operatoren im System er- zeugt werden. Das bestehende CEP System ist ein verteiltes System, weshalb entschieden werden muss, auf welchem Rechnerknoten des Systems die ben¨otigten Operatoren erzeugt bzw. platziert werden sollen. Zur Platzierung der Operatoren k¨onnen im vorhandenen Pro- totypen verschiedene Verfahren genutzt werden, die im n¨achsten Abschnitt beschrieben werden.
2.4.2 Platzierung von Operatoren
Alle Operatoren von neuen Anfragen, deren Ergebnisse nicht durch die Wiederverwen- dung bestehender Operatoren bereitgestellt werden k¨onnen, m¨ussen entsprechend im System erzeugt bzw. platziert werden. Hierbei m¨ussen unterschiedliche Problemstellungen ber¨ucksichtigt werden.
Da das vorhandene CEP System cloudbasiert ist, k¨onnen prinzipiell unendlich viele Ressourcen zur Bearbeitung der Anfragen im CEP genutzt werden. Da die verwendeten Ressourcen jedoch auf Basis der Nutzung bezahlt werden m¨ussen, ist eine effiziente Nutzung der Ressourcen notwendig. Ziel der Komponente zur Platzierung der Operatoren ist es eine minimale Ressourcenmenge bei der Platzierung von Operatoren zu verwenden, ohne dabei das gesamte oder Teile des Systems zu ¨uberlasten. Die verf¨ugbaren Ressourcen
stehen hierbei in Form von Rechnerknoten zur Verf¨ugung, die entsprechend begrenzte Ressourcenkapazit¨aten, z.B. CPU-Kapazit¨at und Netzwerkbandbreite, besitzen.
Zur Parallelisierung der Anfragebearbeitung k¨onnen (logische) Operatoren mehrere un- abh¨angige Instanzen besitzen, die parallel Ereignisse verarbeiten k¨onnen [SHCF03]. Durch die Parallelisierung kann zum einen die Verarbeitungszeit der Ereignisse reduziert werden, zum anderen kann die Last auf die unterschiedlichen Instanzen eines Operators verteilt werden, wodurch ein besserer Lastenausgleich im bestehenden Prototypen erreicht werden kann. Um sicherzustellen, dass kein Rechnerknoten des Systems bei der Anfragebearbei- tung ¨uberlastet ist, muss bei der Platzierung der Operatoren der Ressourcenverbrauch der Operatoren ber¨ucksichtigt werden.
Bei der Ausf¨uhrung der Operatoren wird der Ressourcenverbrauch kontinuierlich ¨uber- wacht und ausgewertet, um sicherzustellen, dass gen¨ugend Ressourcen bereitgestellt werden k¨onnen. Beim Hinzuf¨ugen einer Anfrage kann dieses Verfahren jedoch noch keine Informationen bereitstellen. Zur Ermittlung des Ressourcenverbrauchs der Operatoren neuer Anfragen wurde deshalb ein Verfahren implementiert, das eine Kombination aus einem stichproben- und sch¨atzungsbasierten Verfahren ist. Durch eine Sch¨atzung wird hierbei der Ressourcenaufwand f¨ur die Verarbeitung eines Ereignisses innerhalb eines Operators gesch¨atzt und mit den Ereignisraten der genutzten Ereignisquellen multipliziert.
Zur Bestimmung der Ereignisraten werden Messungen des Systems verwendet. Anhand des ermittelten Ressourcenverbrauchs der einzelnen Operatoren kann die Anzahl an Rechnerknoten bestimmt werden, die ben¨otigt werden, um die vorhandenen Anfragen zu bearbeiten ohne einzelne Rechnerknoten zu ¨uberlasten. Wurde die Anzahl an Rech- nerknoten bestimmt, die das System zur Bearbeitung der Anfragen ben¨otigt, muss die eigentliche Platzierung der Operatoren durchgef¨uhrt werden. Hierbei m¨ussen zwei Teil- probleme ber¨ucksichtigt werden, die initiale Platzierung sowie die Laufzeitplatzierung der Operatoren. Beide Problemstellungen, initiale und Laufzeitplatzierung der Operatoren, werden in den n¨achsten Abschnitten beschrieben.
Initiale Platzierung der Operatoren
Zur L¨osung der Problemstellung der Platzierung der Operatoren wurden unterschiedliche heuristische Verfahren in das System integriert, die im Kontext des Bin Packing Problems entwickelt wurden.
Das Bin Packing Problem [MT90] beschreibt allgemein das Problem der Aufteilung von unterschiedlich großen Elementen auf vorhandene Beh¨alter. Im vorhandenen CEP System sind die Operatoren ¨aquivalent mit den Elementen und die Rechnerknoten entsprechen den Beh¨altern. Innerhalb des Prototypen wurden sechs verschiedene Verfahren zur Platzierung der Operatoren implementiert [Ji11].
Innerhalb des First Fit Verfahren werden die Beh¨alter beliebig geordnet und ein Element wird auf den ersten Beh¨alter platziert, der genug freie Ressourcen besitzt, wobei die Beh¨alter auf Basis der Ordnung ¨uberpr¨uft werden. Das Best Fit Verfahren sucht einen gef¨ullten Beh¨alter, der noch genug Ressourcen hat, um das Element zu beherbergen.
Finden die entsprechenden Verfahren keinen Beh¨alter, der gen¨ugend freie Ressourcen besitzt, m¨ussen neue Beh¨alter hinzugef¨ugt werden. Zus¨atzlich wurden zwei Erweiterungen der First Fit und Best Fit Verfahren implementiert. Bei der Erweiterung Decreasing werden die Elemente vor der Zuordnung durch das entsprechende Verfahren nach Gr¨oße geordnet, wobei die Zuordnung mit dem gr¨oßten Element beginnt. Bei der anderen Erweiterung
With Prioritized Host werden die Beh¨alter in Abh¨angigkeit des Elements geordnet.
Innerhalb von Anfragen stehen Operatoren in einer Beziehung zu anderen Operatoren.
Operatoren k¨onnen eine beliebige Anzahl von Vorg¨angern und Nachfolgern besitzen.
Zwischen den benachbarten Operatoren m¨ussen Daten bzw. Ereignisse ¨ubertragen werden, diese Beziehung wird entsprechend bei der Ordnung der Beh¨alter ber¨ucksichtigt.
Die unterschiedlichen Verfahren haben unterschiedliche Vor- bzw. Nachteile. Je nach gew¨ahlten Verfahren kann z.B. die Netzwerklast oder Knotenanzahl minimiert werden.
Bei der initialen Platzierung der Operatoren findet im Gegensatz zur Laufzeitplatzierung keine Bearbeitung von Anfragen statt. Da sich zur Laufzeit die Anforderungen ¨andern k¨onnen, ist es teilweise notwendig die initiale Platzierung der Operatoren zu ¨andern.
Diese ¨Anderung der Platzierung erfolgt durch die Laufzeitplatzierung der Operatoren.
Laufzeitplatzierung der Operatoren
Aufgabe der Laufzeitplatzierung der Operatoren ist es, das System auf ge¨anderte Anfor- derungen anzupassen. Mit der Zeit k¨onnen z.B. neue Anfragen gestartet oder bestehende Anfragen beendet werden. Zus¨atzlich kann sich die Last des Systems ¨andern, indem sich z.B. Eigenschaften der Ereignisse oder Ereignisraten der Ereignisquellen ¨andern. Die ¨Ande- rung von Anforderungen zur Laufzeit k¨onnen zu einer ¨Uberlastung (zu wenig Ressourcen) oder Ineffizienz (zu viele Ressourcen) des Systems f¨uhren, weshalb die aktuelle Last der Rechnerknoten ¨uberwacht wird. Anhand der Daten, die w¨ahrend der ¨Uberwachung ermittelt werden, z.B. CPU- oder Netzwerk-Auslastung, wird entschieden, ob und auf welche Rechnerknoten Operatoren migriert werden sollen. Die Entscheidung auf welchen Rechnerknoten ein Operator migriert werden soll, erfolgt hierbei erneut mit den bereits vorgestellten L¨osungsverfahren f¨ur das Bin Packing Problem, siehe Abschnitt 2.4.2.
Um zu entscheiden wann ein Rechnerknoten ¨uberlastet ist, oder aufgrund einer zu gerin- gen Auslastung freigegeben werden kann, wird die sogenannte Elasticity Policy [HJJF13]
genutzt. Hierbei k¨onnen sowohl grenzwert- also auch tendenzbasierte Regeln verwendet werden. Bei beiden Regeln k¨onnen spezifische Eigenschaften der Rechnerknoten oder globale Eigenschaften verwendet und ¨uberwacht werden. F¨ur grenzwertbasierte Regeln wird der entsprechend definierte Grenzwert ¨uberwacht und bei Eintreten der Regel, die vorgegebene Aktion durchgef¨uhrt. Ein Beispiel f¨ur grenzwertbasierte Regeln ist das Freigeben eines Rechnerknotens, sobald die Last unter eine definierte Auslastungsgrenze f¨allt. Tendenzbasierte Regeln versuchen das ¨Uber- bzw. Unterschreiten eines Grenzwerts noch vor dem Eintritt abzusch¨atzen. Hierzu nutzen tendenzbasierte Regeln lineare Ap- proximationen der letzten Messungen. Ein Beispiel f¨ur eine tendenzbasierte Regel ist z.B.
falls die Last steigt und der Grenzwert innerhalb der n¨achsten 5 Sekunden ¨uberschritten wird, ist der Rechnerknoten ¨uberlastet. Um eine effiziente Ausf¨uhrung des Systems zu erm¨oglichen, m¨ussen geeignete Regeln definiert werden.
Wie bereits in Abschnitt 2.3.1 beschrieben, m¨ussen zur Definition der Regeln der Elasticity Policy jedoch viele unterschiedliche Aspekte und anwendungsspezifische Anforderungen beachtet werden. F¨ur einen Nutzer ist es kaum m¨oglich alle Anforderungen zu ber¨uck- sichtigen. Zur Unterst¨utzung des Nutzers k¨onnen durch die Verwendung der Systemopti- mierung, siehe Abschnitt 2.4.4, diese Regeln teilweise automatisch ermittelt werden, bzw.
an ge¨anderte Anforderungen angepasst werden. Ein Beispiel f¨ur einen Parameter, der automatisch durch die Systemoptimierung bestimmt werden kann, ist LOAD LOWER BOUND, die die untere Auslastungsgrenze eines Rechnerknotens definiert. Unterschreitet
ein Rechnerknoten, diese Grenze f¨ur eine gewisse Zeit, werden die Operatoren des Rech- nerknotens migriert und der Knoten entsprechend freigegeben.
Andere Faktoren, die sich zur Laufzeit kaum oder gar nicht ¨andern, bzw. leicht durch den Nutzer selbst ermittelt werden k¨onnen, werden bei der Optimierung nicht betrachtet.
Diese Faktoren m¨ussen entsprechend vom Nutzer beim Start des Systems selbst festge- legt werden. Die maximale bzw. minimale Anzahl an Rechnerknoten, die vom System verwendet werden kann, sind Beispiele f¨ur vom Nutzer festgelegte Parameter.
Je nach Nutzung der bestehenden Rechnerknoten des cloudbasierten CEP Systems ent- stehen Kosten. Um diese Kosten bestimmen zu k¨onnen, wurde ein Kostenmodell erstellt, das unter anderem im n¨achsten Abschnitt beschrieben wird.
2.4.3 Kostenmodell
Um die Kosten des Systems zu bestimmen, wurde ein Kostenmodell [Mey12] entwickelt und in den vorhandenen Prototypen integriert. Zur Entwicklung des Kostenmodells wurden bestehende Kostenmodelle im Bereich Cloud Computing [TD10] sowie vorhandene Angebots- und Preismodelle von Cloud-Anbietern analysiert, z.B. Amazon EC2 [Ama], Microsoft Azure [Win] usw. Ergebnis der Arbeit war unter anderem ein generisches Kostenmodell, das bei beliebigen Cloud-Anbietern eingesetzt werden kann und die Kosten einer Anfrage auf Basis der folgenden Faktoren berechnet:
• Reservierte und genutzte CPU-Kapazit¨at
• Reservierter und genutzter Arbeitsspeicher
• Zahl der reservierten Rechnerknoten
• Ein- und ausgehender Netzwerkverkehr
• Fixkosten und Zeitraum zur Verrechnung der Fixkosten
Zur Verwendung des generischen Kostenmodells m¨ussen die entsprechenden Kosten des genutzten Cloud-Anbieters hinterlegt werden, und eine gew¨unschte Systemkonfiguration eingestellt werden, z.B. Festlegung der Anzahl an reservierten Rechnerknoten.
Die Kosten einer Anfrage werden zum einen durch die Kosten der genutzten Ressourcen, zum anderen durch Fixkosten bestimmt, die z.B. durch die Reservierung oder die Konfi- guration von Rechnerknoten entstehen. Um die Kosten der genutzten Ressourcen einer Anfrage zu bestimmen, werden hierbei die Kosten der einzelnen Operatoren auf Basis des Ressourcenverbrauchs bestimmt und die einzelnen Kosten der Operatoren summiert.
Werden Ergebnisse eines Operators von mehreren Anfragen wiederverwendet, werden die Kosten eines Operators auf die entsprechenden Anfragen aufgeteilt.
Neben der Entwicklung und Integration des Kostenmodells wurden weitere Funktiona- lit¨aten in den CEP Prototypen integriert. Durch die integrierte Komponenten [Mey12]
ist es m¨oglich die Kosten einer Anfrage zu sch¨atzen und zu ¨uberwachen. Die Sch¨atzung der erwarteten Kosten einer Anfrage wird hierbei durch Simulation der Anfragen im CEP System bestimmt. Die ¨Uberwachung der Kosten wird durch Kontrolle des Systems erreicht, indem zum einen der Ressourcenverbrauch der einzelnen Operatoren kontinuier- lich ¨uberpr¨uft wird, und zum anderen entsprechende Ergebnisse anhand des verwendeten Kostenmodells ausgewertet werden. Neben der ¨Uberwachung der Kosten k¨onnen ebenfalls Qualit¨atseigenschaften definiert und kontrolliert werden, z.B. Latenz oder Durchsatz von Anfragen.
Um die Benutzerfreundlichkeit zu erh¨ohen, wurde ebenfalls eine Visualisierung integriert,
Abbildung 2.4: ¨Ubersicht ¨uber laufende Anfragen
Abbildung 2.5: Zus¨atzliche Informationen einer Anfrage
Abbildung 2.6: Visualisierung zum Hinzuf¨ugen neuer Anfragen
die dem Nutzer sowohl Informationen ¨uber alle laufende Anfragen darstellt, als auch die M¨oglichkeit bietet laufende Anfragen zu l¨oschen, siehe Abbildung 2.4. Zus¨atzlich ist es m¨oglich Detailinformationen einer Anfragen anzeigen zu lassen, z.B. den zeitlichen Verlauf der Kosten der einzelnen Operatoren einer Anfrage, siehe Abbildung 2.5. Des Weiteren ist es in der Visualisierung m¨oglich neue Anfragen zu starten, siehe Abbildung 2.6.
Die berechneten bzw. gesch¨atzten Kosten der Anfragen bzw. des Systems werden im bestehenden CEP System zur Optimierung der Anfragebearbeitung genutzt. Der Optimie- rungsprozess des existierenden Prototyps wird hierbei im n¨achsten Abschnitt beschrieben.
2.4.4 Systemoptimierung
In Abschnitt 2.4.2 wurden bereits die verschiedenen Platzierungsstrategien der Operatoren erl¨autert. Neben den verschiedenen Strategien existieren noch weitere Parameter des Systems, die die Effizienz der Anfragebearbeitung im CEP System beeinflussen [R¨od12].
In der aktuellen Version des Prototyps k¨onnen bis zu 15 verschiedene Faktoren automa- tisch optimiert werden, die die Ausf¨uhrung beeinflussen. Durch diese 15 Faktoren und die entsprechenden Wertebereiche sind insgesamt 3,9·1017 unterschiedliche Konfigurationen des Systems m¨oglich.
Es wurde festgestellt, dass keine eindeutige Tendenz zwischen den einzelnen Faktoren und der Effizienz des Systems besteht, siehe Abbildung 2.7. In dem durchgef¨uhrten Experiment wurden zwei Konfigurationsparameter variiert und die entsprechenden Sy- stemkosten ermittelt. Der Parameter plc steht hierbei f¨ur die Platzierungsstrategien der Operatoren. gran definiert die Granularit¨at der Operatoren, wodurch die maximale Anzahl an Instanzen f¨ur die (logischen) Operatoren bestimmt wird.
Durch die hohe Zahl an Konfigurationen und den nicht linearen Zusammenhang der einzelnen Parameter ist es schwierig eine Konfiguration des Systems f¨ur die aktuellen Anforderungen zu finden, die die Kosten des Systems minimiert. Da der Aufwand zur Suche einer effizienten Konfiguration bei deterministischen Verfahren aufgrund der Gr¨oße des Suchraums zu hoch ist, wurden zwei heuristische Verfahren, Recursive Random Search (RRS) [YK03] und GA [Hol92] zur Suche einer Systemkonfiguration implemen- tiert [R¨od12].
RRS versucht durch zufallsbasierte Stichproben relevante Teilsuchr¨aume im globalen Suchraum zu finden (Exploration). Innerhalb der bestimmten Teilsuchr¨aume wird eine lokale Suche (Exploitation) durchgef¨uhrt. Bei GA werden zufallsbasiert initiale Konfigu- rationen erzeugt. Ausgehend von den initialen Konfigurationen werden durch Austausch von Merkmalen zwischen zwei beliebigen existierenden Konfigurationen (Crossover) oder zufallsbasierten ¨Anderungen einzelner Merkmale einer Konfiguration (Mutation) inkremen- tell neue Konfigurationen erzeugt. Auf Basis einer Fitnessfunktion (Kostenberechnung), und einer Selektionsstrategie werden Konfigurationen ausgew¨ahlt bzw. verworfen. Beide Verfahren k¨onnen durch eine zeitliche Grenze bzw. eine maximale Iterationsstufe begrenzt werden. Wurde die Suche beendet bzw. abgebrochen, wird in beiden Strategien die gefun- dene Konfiguration zur¨uckgeliefert, die die geringsten Kosten verursacht.
Die Kosten der Konfiguration, die durch die Suche bestimmt wurde, werden im Anschluss mit den Kosten der aktuellen Konfiguration des Systems verglichen. Wird durch die ¨Ande- rung der Konfiguration eine Kostenreduktion erreicht, wird die aktuelle Konfiguration in die neue Konfiguration ¨uberf¨uhrt, wodurch die Anfragebearbeitung des CEP Systems (z.B. Platzierung der Operatoren) gegebenenfalls adaptiert wird. Die Kosten, die durch
FF FFD
FFP FFDP
BF BFD
BFP BFDP plc
1 3
5 7
9 11
13 15
17 19
gran 14.00
14.50 15.00 15.50 16.00 16.50 17.00 17.50 18.00 18.50
Kosten [Euro/h]
14 14.5 15 15.5 16 16.5 17 17.5 18 18.5
Abbildung 2.7: Systemkosten in Abh¨angigkeit der Platzierungsstrategie plc und der maximalen Anzahl an Instanzen pro Operator gran (5000 EreignisseSekunde ) [R¨od12]
die ¨Anderung der Konfiguration bzw. Anpassung der Anfragebearbeitung entstehen, werden in dem aktuellen Optimierungsprozess nicht ber¨ucksichtigt. Die Optimierung erfolgt periodisch, entsprechend kann die Konfiguration ebenfalls nur periodisch angepasst werden, falls die Kosten des Systems durch die ¨Anderung der Konfiguration gesenkt werden k¨onnen.
2.5 Zusammenfassung
In diesem Kapitel wurden die Grundlagen dieser Arbeit erl¨autert. Es wurde das Konzept von CEP eingef¨uhrt, dass die zeitnahe Bearbeitung von kontinuierlichen Anfragen ¨uber Ereignisstr¨ome definiert. Da innerhalb der Ereignisstr¨ome potentiell unendlich viele Er- eignisse erzeugt werden und durch die Anfragebearbeitung verarbeitet werden m¨ussen, stellen CEP Systeme hohe Anforderungen bez¨uglich der Performanz. Des Weiteren k¨onnen sich Eigenschaften des Systems, z.B. Ereignisraten der Ereignisstr¨ome zur Laufzeit ¨andern, wodurch eine h¨ohere oder geringere Last des Systems erzeugt wird. Durch diese variie- renden Anforderungen ist es notwendig, dass sich das CEP System elastisch (Auf- und Abw¨artsskalierung) an die aktuellen Anforderungen anpassen kann, um eine effiziente Ausf¨uhrung der Anfragebearbeitung zu gew¨ahrleisten.
Der existierende CEP Prototyp nutzt Cloud Computing, um die Anforderungen der Elastizit¨at zu erf¨ullen. Cloud Computing verwendet Prinzipien der Virtualisierung und Skalierbarkeit, um prinzipiell unendlich viele Ressourcen auf Anfrage ¨uber ein Netzwerk bereitzustellen. Besonderheit von Cloud Computing ist, dass kaum Investitionskosten entstehen, sondern die Ressourcen auf Basis der Nutzung bezahlt werden. Da die Kosten des Systems abh¨angig von der Nutzung der Ressourcen sind, ist eine effiziente Ressourcen- verwendung notwendig. Entsprechend ist eine adaptive Anfragebearbeitung notwendig, die die Ausf¨uhrung der Anfragen kontinuierlich optimiert, um das System auf ge¨anderte Anforderungen, Lasten und aktualisierte Statistiken anzupassen und die Effizienz des CEP Systems zu gew¨ahrleisten.
Der bestehende CEP Prototyp besitzt mehrere Mechanismen zur Anpassung der Anfra- gebearbeitung an die aktuellen Anforderungen des Systems. Zum einen ist eine MQO vorhanden, die f¨ur neue Anfragen ¨uberpr¨uft, ob (Teil-)Ergebnisse bestehender Anfragen in neuen Anfragen wiederverwendet werden k¨onnen. K¨onnen Ergebnisse neuer Anfragen nicht durch die Wiederverwendung bestehender Ergebnisse bereitgestellt werden, werden neue Operatoren im verteilen CEP System erzeugt bzw. platziert. Zur Platzierung der Operatoren im verteilten CEP System wurden verschiedene Strategien implementiert, die unterschiedliche Vor- und Nachteile mit sich bringen. Da die Effizienz von einer Vielzahl von Faktoren abh¨angig ist, wurden Suchstrategien implementiert, die auf Basis des vorhandenen Kostenmodells f¨ur die aktuellen Anforderungen und Last eine effiziente Konfiguration des Systems ermitteln.
Problematisch an dem aktuellen Optimierungsprozess ist, dass die Optimierung periodisch ausgef¨uhrt wird. Sowohl die Optimierung als auch die ¨Anderung (Migration) der Kon- figuration verbrauchen Ressourcen bzw. beeinflussen die Anfragebearbeitung, wodurch zus¨atzliche Kosten entstehen k¨onnen. Da das bestehende CEP System cloudbasiert ist, m¨ussen z.B. die durch die Optimierung verbrauchten Ressourcen gegebenenfalls zus¨atzlich bezahlt werden. Es ist deshalb zum einen notwendig die Optimierung nur an geeigneten Zeitpunkten auszuf¨uhren. Zum anderen sollten die Kosten der Optimierung im Optimie- rungsprozess ber¨ucksichtigt werden, da sonst die Effizienz des Systems beeinflusst werden kann.
Diese Arbeit besch¨aftigt sich hierbei sowohl mit der Problemstellung einen geeigneten Zeitpunkt f¨ur die Optimierung des existierenden Prototyps zu bestimmen, als auch mit den Fragen welche Kosten durch die Migration der Konfiguration entstehen und wie die Migrationskosten in dem vorhandenen Optimierungsprozess ber¨ucksichtigt werden k¨onnen. Welche Aspekte bei den entsprechenden Problemstellungen ber¨ucksichtigt werden m¨ussen, werden im n¨achsten Kapitel n¨aher erl¨autert.
Kapitel 3
Anforderungsanalyse
Ziel des vorhandenen cloudbasierten Complex Event Processing (CEP) Systems ist es eine kosteneffiziente Anfragebearbeitung durchzuf¨uhren. Um die Probleme der sich
¨andernden Anforderung bez¨uglich der Auslastung der Ressourcen zu l¨osen, werden Cloud- Technologien verwendet, siehe Abschnitt 2.2. Um die Kosteneffizienz zu gew¨ahrleisten, ist eine kontinuierliche Optimierung notwendig, die die Anfragebearbeitung an die aktuellen Anforderungen anpasst, siehe Abschnitt 2.3. Zur Optimierung der Anfragebearbeitung wurden bereits verschiedene Verfahren implementiert, die auf Grundlage der bestehenden Anfragen und Anforderungen eine kosteneffiziente Systemkonfiguration ermitteln, siehe Abschnitt 2.4. Da die Optimierung und die ¨Anderung einer Konfiguration jedoch selbst Kosten verursachen, z.B. durch den Ressourcenverbrauch der Optimierungsverfahren, ist es notwendig einen geeigneten Zeitpunkt zur Durchf¨uhrung der Optimierung zu bestimmen, und die Kosten der Optimierung im Optimierungsprozess zu ber¨ucksichtigen.
Ziel dieser Arbeit ist die Effizienz des bestehenden Prototypen zu steigern, indem der Optimierungsprozess erweitert wird, so dass die Kosten, die durch die Optimierung entstehen, bei der Optimierung ber¨ucksichtigt werden. Zus¨atzlich soll ein Verfahren umgesetzt werden, das geeignete Zeitpunkte zur Optimierung bestimmen kann. In diesem Kapitel werden die genaue Problemstellung und Anforderungen dieser Arbeit erl¨autert.
3.1 Problemstellung
Kontinuierliche Anfragen eines CEP Systems werden ¨uber einen l¨angeren Zeitraum be- arbeitet. Die Wahrscheinlichkeit, dass sich w¨ahrend der Bearbeitungszeit einer Anfrage Systemeigenschaften, wie Ereignisraten, Eigenschaften der Ereignisse (z.B. Verteilung der Attribute), oder Anforderungen ¨andern ist hoch [MSHR02]. Entsprechend wichtig ist eine geeignete Optimierung, die die Anfragebearbeitung an die aktuellen Anforderungen anpasst.
Wird durch die Optimierung eine effizientere Systemkonfiguration ermittelt, muss die ak- tuelle in die effizientere Konfiguration ¨uberf¨uhrt werden. Die ¨Anderung der Konfiguration des Systems kann jedoch Auswirkungen auf die Anfragebearbeitung haben und zus¨atzliche Kosten im System verursachen. Durch die kontinuierliche, periodische Optimierung ist die Anzahl an Migrationen der Systemkonfiguration groß, weshalb die Kosten, die durch eine Migration der Konfiguration des Systems verursacht werden, bei der Optimierung ber¨ucksichtigt werden sollten [VAN08].
Im Kontext der Migration von virtuellen Maschinen konnte gezeigt werden, dass falls die Auswirkungen einer Migration ber¨ucksichtigt werden, die Effizienz des Systems gesteigert werden kann. Faktoren, die hierbei ber¨ucksichtigt werden k¨onnen sind z.B.
Energieverbrauch [GSF11], Antwortzeit [QZW+12], Kosten [SSSS10] bzw. Einnahmever- lust [ZZSB13]. Es wurde ebenfalls im Kontext der Migration von virtuellen Maschinen gezeigt, dass der Aufwand, der durch eine Migration entsteht, zwar akzeptabel ist, jedoch nicht vernachl¨assigt werden sollte [SD13], insbesondere in Umgebungen, die Service Level Agreements (SLA) erf¨ullen m¨ussen [VBVB09]. Im ung¨unstigsten Fall ¨ubersteigen die Migrationskosten die durch die Optimierung eingesparten Kosten [BB05].
Die Problemstellung der Migration von virtuellen Maschinen ist hierbei ¨ahnlich zur Problemstellung der Verschiebung der Operatoren in einem CEP System, die als Folge einer Konfigurations¨anderung des Systems auftreten kann. Bei beiden Problemstellungen werden Objekte (virtuelle Maschinen bzw. Operatoren) verschoben, die Ressourcen eines Rechnerknotens ben¨otigen (z.B. CPU-Kapazit¨at). Ziel ist hierbei die Anzahl der ben¨otig- ten Rechnerknoten zu minimieren bzw. die Auslastung der genutzten Rechnerknoten zu maximieren und somit die Effizienz des Systems zu steigern. Jedoch unterscheiden sich die beiden Problemstellungen, z.B. sind virtuelle Maschinen im Allgemeinen un- abh¨angig von anderen virtuellen Maschinen. Operatoren eines CEP Systems hingegen bilden zur Anfragebearbeitung ein Netzwerk aus Operatoren, wodurch Abh¨angigkeiten zwischen einzelnen Operatoren entstehen. Des Weiteren unterscheiden sich die beiden Problemstellungen bez¨uglich der genutzten Ressourcen und Anforderungen. Da bei virtu- ellen Maschinen auch Festplattenspeicher genutzt werden, m¨ussen andere Betrachtungen durchgef¨uhrt werden im Vergleich zur Migration von Operatoren eines CEP Systems, bei dem lediglich CPU und Arbeitsspeicher genutzt werden. Trotz der Unterschiede der beiden Problemstellungen werden innerhalb des vorhandenen cloudbasierten CEP Systems ¨ahnliche Ergebnisse erwartet wie in den Arbeiten, die im Kontext der Migration von virtuellen Maschinen durchgef¨uhrt wurden.
Ein Ziel dieser Arbeit ist deshalb die Effizienz des Systems durch ein Modell zu steigern, das die Auswirkungen der ¨Anderung einer Systemkonfiguration bei einer Optimierung absch¨atzt, und die Absch¨atzung der Migrationskosten entsprechend in den Optimierungs- prozess zu integrieren. Hierdurch soll erreicht werden, dass eine Migration nur dann ausgef¨uhrt wird, wenn ein signifikanter Nutzen erwartet wird. Um ein geeignetes Modell zur Bestimmung der Migrationskosten entwickeln zu k¨onnen, werden im Folgenden sowohl die Auswirkungen der Migration der Konfiguration erl¨autert, als auch m¨ogliche Faktoren bestimmt, die zur Kostenberechnung der Auswirkungen dienen k¨onnen.
3.1.1 Kosten der ¨ Anderung der Systemkonfiguration
Wird eine Optimierung und eine ¨Anderung der Konfiguration des Systems durchgef¨uhrt, wirkt sich dies auf die Anfragebearbeitung aus. Der Grund hierf¨ur ist, dass viele Para- meter, die zur Platzierung der Operatoren verwendet werden, durch die Optimierung des Systems bestimmt werden. Beispielsweise wird durch die Optimierung entschieden welche der Platzierungsstrategien (siehe Abschnitt 2.4.2) verwendet werden sollen. Je nach ¨Anderung der Systemkonfiguration, die durch die Optimierung bestimmt wurde, m¨ussen unterschiedliche Faktoren ber¨ucksichtigt werden.
Zur Kostenberechnung bez¨uglich der Migration von Operatoren kontinuierlicher Anfragen in Ereignisstr¨omen wurden bereits ¨Uberlegungen durchgef¨uhrt, z.B. von Zu et al. [ZRH04].
