Otto-von-Guericke-Universität Magdeburg. Fakultät für Informatik Institut für Technische und Betriebliche Informationssysteme.

Transkript

1 Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Technische und Betriebliche Informationssysteme Masterarbeit Adaptionsstrategien für kosteneffizientes Complex Event Processing Verfasser: Andreas Meister 15. September 2013 Betreuer: Prof. Dr. rer. nat. habil. Gunter Saake, M.Sc. Sebastian Breß Universität Magdeburg Fakultät für Informatik Postfach 4120, D Magdeburg Germany Dr.-Ing. Zbigniew Jerzak Dipl. Inf. Thomas Heinze SAP Dresden Chemnitzer Strasse 48, D Dresden Germany

2 Meister, Andreas: Adaptionsstrategien für kosteneffizientes Complex Event Processing Masterarbeit, Otto-von-Guericke-Universität Magdeburg, 2013.

3 INHALTSVERZEICHNIS i Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Abkürzungen i v ix xi 1 Einführung Hintergrund Motivation Ziele der Arbeit Methodik der Arbeit Aufbau der Arbeit Grundlagen Complex Event Processing Cloud Computing Optimierung Adaptive Anfragebearbeitung Optimaler Optimierungsprozess Aufbau des Prototyps Multi Query Optimierung Platzierung von Operatoren Kostenmodell Systemoptimierung Zusammenfassung Anforderungsanalyse Problemstellung Kosten der Änderung der Systemkonfiguration

4 ii INHALTSVERZEICHNIS Faktoren zur Kostenberechnung Bestimmung eines geeigneten Zeitpunkts der Optimierung Anforderungen Zusammenfassung Konzeption Modellierung der Migrationskosten Direkte Migrationskosten Indirekte Migrationskosten Berechnung der Migrationszeit Berechnung der indirekten Migrationskosten Schätzung der Dauer einer Konfiguration des Systems Bestimmung eines geeigneten Optimierungszeitpunkts Zusammenfassung Systemintegration Bestehender Optimierungsprozess Erweiterter Optimierungsprozess Evaluation Auswirkungen der Migration von Operatoren Entwurf Variablen der Analyse Ergebnisse des Experiments Diskussion Bedrohung der Validität Vergleich der unterschiedlichen Optimierungsprozesse Entwurf Variablen der Analyse Ergebnisse des Experiments Diskussion Bedrohung der Validität Performanz der Berechnung der Migrationskosten Entwurf Variablen der Analyse Ergebnisse des Experiments Diskussion

5 INHALTSVERZEICHNIS iii Bedrohung der Validität Zusammenfassung Abschluss Zusammenfassung Ausblick A Multi Query Optimierung 83 Literaturverzeichnis 85

6 iv INHALTSVERZEICHNIS

7 ABBILDUNGSVERZEICHNIS v Abbildungsverzeichnis 2.1 Zeitbasierte Fenster zur Verarbeitung von Ereignissen Problem der Unter- und Überversorgung Architektur der Optimierung der Anfragebearbeitung Übersicht über laufende Anfragen Zusätzliche Informationen einer Anfrage Visualisierung zum Hinzufügen neuer Anfragen Systemkosten in Abhängigkeit von plc und gran Verlauf der Migration eines Operators Verlauf der Verzögerung der Anfragebearbeitung Optimierungsprozess ohne Berücksichtigung der Migrationskosten Optimierungsprozess mit Berücksichtigung der Migrationskosten Steigerung des CPU-Verbrauchs bei der Erstellung und Wiedereinspielung des Zustands eines zustandsbehafteten Operators Steigerung des Speicherverbrauchs bei der Erstellung und Wiedereinspielung des Zustands eines zustandsbehafteten Operators Benötigte Zeit zur Extraktion und Wiedereinspielung des Zustands eines zustandsbehafteten Operators Steigerung des CPU-Verbrauchs bei der Migration eines zustandslosen Operators Steigerung des Speicherverbrauchs bei der Migration eines zustandslosen Operators Zu übertragende Datenmenge bei der Migration eines zustandslosen Operators Zeit zur Migration eines zustandslosen Operators Durchschnittliche, maximale und minimale Latenz der Anfragen (Anfragemuster: linear, Ereignisrate: variabel)

8 vi ABBILDUNGSVERZEICHNIS 6.9 Durchschnittliche, maximale und minimale CPU-Auslastung der Rechnerknoten (Anfragemuster: linear, Ereignisrate: variabel) Anzahl an Operatormigrationen und durchschnittliche genutzte Rechnerknotenanzahl (Anfragemuster: linear, Ereignisrate: variabel) Anzahl und gesamte Ausführungszeit der Optimierungen (Anfragemuster: linear, Ereignisrate: variabel) Ausführungszeit und Kosten des Experiments (Anfragemuster: linear, Ereignisrate: variabel) Durchschnittliche, maximale und minimale Latenz der Anfragen (Anfragemuster: real, Ereignisrate: konstant) Durchschnittliche, maximale und minimale CPU-Auslastung der Rechnerknoten (Anfragemuster: real, Ereignisrate: konstant) Anzahl an Operatormigrationen und durchschnittliche genutzte Rechnerknotenanzahl (Anfragemuster: real, Ereignisrate: konstant) Anzahl und gesamte Ausführungszeit der Optimierungen (Anfragemuster: real, Ereignisrate: konstant) Ausführungszeit und Kosten des Experiments (Anfragemuster: real, Ereignisrate: konstant) Durchschnittliche, maximale und minimale Latenz der Anfragen (Anfragemuster: real, Ereignisrate: variabel) Durchschnittliche, maximale und minimale CPU-Auslastung der Rechnerknoten (Anfragemuster: real, Ereignisrate: variabel) Anzahl an Operatormigrationen und durchschnittliche genutzte Rechnerknotenanzahl (Anfragemuster: real, Ereignisrate: variabel) Anzahl und gesamte Ausführungszeit der Optimierungen (Anfragemuster: real, Ereignisrate: variabel) Ausführungszeit und Kosten des Experiments (Anfragemuster: real, Ereignisrate: variabel) Ausführungszeit der Kostenberechnung mit Berücksichtigung der Migrationskosten Ausführungszeit der Zielfunktion 1 mit Berücksichtigung der Migrationskosten Ausführungszeit der Zielfunktion 1 ohne Berücksichtigung der Migrationskosten Ausführungszeit der Zielfunktion 2 mit Berücksichtigung der Migrationskosten

9 ABBILDUNGSVERZEICHNIS vii 6.27 Ausführungszeit der Zielfunktion 2 ohne Berücksichtigung der Migrationskosten A.1 Prozess zum Vergleich von Operatoren

10 viii ABBILDUNGSVERZEICHNIS

11 TABELLENVERZEICHNIS ix Tabellenverzeichnis 3.1 Variablen zur Bestimmung des Optimierungszeitpunkts Variablen zur Modellierung der Migrationskosten Variablen zur Berechnung der Migrationszeit Variablen zur Berechnung der indirekten Migrationskosten Variablen zur Abschätzung der Dauer einer Systemkonfiguration Variablen zur Bestimmung eines Optimierungszeitpunkts Rechnerkonfigurationen Zielfunktionen der Optimierung Anfragemuster des Anfragegenerators Ereignisraten der Ereignisquellen

12 x TABELLENVERZEICHNIS

13 xi Verzeichnis der Abkürzungen SLA CEP GA RRS DBMS CQL MQO CCL Service Level Agreement Complex Event Processing genetische Algorithmen Recursive Random Search Datenbankmanagementsystem Continuous Query Language Multi Query Optimierung Continuous Computation Language

14 xii

15 Kapitel 1. Einführung 1 Kapitel 1 Einführung In diesem Kapitel wird eine kurze Einführung in diese Arbeit gegeben. Hierbei wird sowohl der Hintergrund, als auch die Motivation dieser Arbeit erläutert. Zusätzlich werden die Ziele der Arbeit definiert sowie die Methodik zum Erreichen der Ziele erklärt. Als letzter Abschnitt dieses Kapitels wird der Aufbau dieser Arbeit beschrieben. 1.1 Hintergrund Die Problemstellung der zeitnahen Verarbeitung von Ereignissen von Ereignisströmen gewann in den letzten Jahren an Bedeutung [CJ09]. Ein Beispiel für die zeitnahe Verarbeitung von Ereignissen ist die Auswertung von An- und Verkäufen von Aktien zur Ermittlung des Aktienwerts an einem Aktienmarkt [BDG07]. Die Ereignisse der unterschiedlichen Ereignisströme können in einem logischen oder temporalen Zusammenhang stehen, der durch eine geeignete Analyse genutzt werden kann, um Informationen und komplexe Zusammenhänge 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ührt werden soll, werden Anfragen definiert, die unterschiedliche Typen und eine variierende Anzahl von Operationen besitzen können. 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öme und damit die Ereignis- bzw. Datenmenge, die verarbeitet werden, potentiell unendlich ist, da Ereignisse, z.b. Aktienkäufe, kontinuierlich erzeugt werden. Anfragen, z.b. die Ermittlung eines Aktienkurses, werden hierbei über einen längeren Zeitraum ausgeführt, weshalb die Verarbeitung der Ereignisse durch die Operationen einer Anfrage kontinuierlich durchgeführt 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 Wahrscheinlichkeit groß, dass sich Anforderungen, z.b. die Anzahl an Ereignissen je Zeiteinheit, zur Laufzeit ändern [MSHR02].

16 Motivation 1.2 Motivation Durch die variierenden Anforderungen, die durch die beschriebenen Eigenschaften des CEP eintreten können, ändert sich ebenfalls die Menge an Ressourcen, die zur Verarbeitung der Ereignisse benötigt wird. Es ist wichtig einem CEP System genug Ressourcen bereitzustellen, um eine zeitnahe Verarbeitung der Ereignisse zu gewährleisten. Werden nicht genug Ressourcen bereitgestellt, kann dies zu einer Verzögerung der Ereignisverarbeitung führen. Falls Ereignisse dabei schneller erzeugt werden, als die Ereignisse verarbeitet werden können, müssen gegebenenfalls Ereignisse vom System ohne Bearbeitung verworfen werden [BBD + 02]. Je nach vereinbarten Qualitätsmerkmalen in den Service Level Agreements (SLA), können dem Anbieter eines CEP Systems hierdurch zusätzliche 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ünschenswert, dass das CEP System und die verwendete Ressourcenmenge elastisch sind. Elastizität bedeutet hierbei, dass sowohl eine Abwärts-, als auch Aufwärtsskalierung des Systems durchgeführt werden kann. Die Verwendung von Cloud Computing kann hierbei genutzt werden, um die Ressourcen des Systems dynamisch an die aktuellen Anforderungen der Anfragebearbeitung anzupassen. Cloud Computing ermöglicht durch die Verwendung verschiedener Prinzipien und Mechanismen, z.b. Virtualisierung der Ressourcen, die Bereitstellung einer prinzipiell unendlichen Ressourcenmenge. Ressourcen werden in Form von Rechnerknoten bereitgestellt, die eine begrenzte Menge an CPU-Kapazität, Arbeitsspeicher und Netzwerkbandbreite besitzen. Die Anzahl an verwendeten Rechnerknoten kann hierbei dynamisch an die momentanen Anforderungen des Systems angepasst werden, wobei einzelne Rechnerknoten zeitnah bereitgestellt und freigegeben werden können. Beispielsweise dauert die Bereitstellung zusätzlicher 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öglichen, muss das System ständig optimiert werden, um das System auf geänderte Anforderungen der Anfragebearbeitung anzupassen. Eine Optimierung der Anfragebearbeitung kann hierbei z.b. durch die Minimierung der Anzahl an verwendeten Rechnerknoten durchgeführt 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öglichst minimiert werden sollen. Problematisch bei der Optimierung ist, dass die Änderung der Systemkonfiguration Auswirkungen auf die Ereignisverarbeitung haben kann. Durch die Verschiebung von Operatoren einer Anfrage ist es je nach verwendeten CEP System gegebenenfalls notwendig die Anfragebearbeitung zeitweise zu unterbrechen. Je nach Art der Konfigurationsänderung, die durch die Optimierung bestimmt wird, kann die Anfragebearbeitung durch verschiedene Auswirkungen beeinflusst werden. Es ist wichtig diese Auswirkungen abschätzen zu können, und in den Optimierungsprozess zu integrieren, da sonst die Kosten durch die Konfigurationsänderung höher sein können als die Kosteneinsparung durch die optimierte

17 Kapitel 1. Einführung 3 Anfragebearbeitung [BB05]. Ein weiteres Problem der Optimierung ist, dass die Optimierung selbst Ressourcen verbraucht. Da die Gesamtkosten des Systems abhängig von der Ressourcennutzung sind, sollte eine Optimierung nur dann ausgeführt werden, falls durch die Optimierung eine effizientere Ereignisverarbeitung erreicht wird, und hierdurch die Gesamtkosten des Systems reduziert werden. Durch die effizientere Ausführung müssen die Kosten, die durch die Optimierung und die Änderung der Konfiguration entstehen, zur Laufzeit der optimierten Konfiguration amortisiert werden. 1.3 Ziele der Arbeit Ziel dieser Arbeit ist es Möglichkeiten 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 überprüft werden, ob die Effizienz des bestehenden cloudbasierten CEP Systems gesteigert werden kann, indem die Auswirkungen der Änderung der Systemkonfiguration im Optimierungsprozess berücksichtigt werden. Zum anderen soll eine Möglichkeit erarbeitet werden, geeignete Optimierungszeitpunkte im vorhandenen Prototypen zu bestimmen. 1.4 Methodik der Arbeit Zum Erreichen des Ziels dieser Arbeit müssen verschiedene Schritte ausgeführt werden, die im Folgenden kurz erläutert werden. Erster Schritt ist die Analyse bestehender Verfahren zur Abschätzung der Auswirkungen einer Konfigurationsänderung in CEP bzw. cloudbasierten Systemen um mögliche Arten der Auswirkungen sowie Einflussfaktoren einer Optimierung bzw. Konfigurationsänderung zu bestimmen. Zusätzlich müssen bestehende Verfahren ermittelt und analysiert werden, die zur Bestimmung eines geeigneten Optimierungszeitpunkts verwendet werden können. Anhand der durchgeführten Analyse müssen im zweiten Schritt Modelle entwickelt werden, die die Auswirkungen einer Optimierung im vorhandenen cloudbasierten CEP System abschätzen bzw. geeignete Zeitpunkte für eine Optimierung ermitteln können. Die entwickelten Modelle müssen 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 Änderungen des Systems durchgeführt 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äutert. Hierbei werden die Begriffe CEP, Cloud Computing und adaptive Anfragebearbeitung erklärt. Außerdem wird das vorhandene cloudbasierte CEP System beschrieben. Im Anschluss wird in Kapitel 3 die Problemstellung dieser Arbeit angegeben sowie die möglichen Arten der Auswirkungen und Einflussfaktoren einer Konfigurationsänderung

18 Aufbau der Arbeit 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ätzt werden können. 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ührten Messungen, als auch die erhaltenen Ergebnisse erläutert und ausgewertet. In Kapitel 7 wird abschließend eine Zusammenfassung der Arbeit gegeben und mögliche Themen für zukünftige Arbeiten sowie zusätzliche Erweiterungen der entwickelten Modelle beschrieben.

19 Kapitel 2. Grundlagen 5 Kapitel 2 Grundlagen Diese Arbeit beschäftigt sich mit der adaptiven Anpassung der Anfragebearbeitung eines cloudbasierten Complex Event Processing (CEP) Systems. Um die Aufgabenstellung dieser Arbeit besser verstehen zu können, werden im Folgenden die Grundlagen zu CEP, Cloud Computing und adaptiver Anfragebearbeitung erläutert. Da diese Arbeit auf einem bestehenden Prototypen aufbaut und das existierende System erweitern soll, werden ebenfalls relevante Informationen bezüglich des vorhandenen CEP Prototypen kurz beschrieben. 2.1 Complex Event Processing Complex Event Processing beschreibt die Erkennung von Mustern der Eigenschaften bzw. zeitlichen Zusammenhängen von Ereignissen innerhalb einem oder mehreren kontinuierlichen Ereignisströmen [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ührt werden [EB09]. Ereignisse sind erkennbare relevante Zustandsänderungen [MFP06], die für die weitere Verarbeitung von Bedeutung sind, z.b. An- und Verkäufe 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öme, die zur Musteranalyse verarbeitet werden, sind unabhängig, und können verschiedene Eigenschaften wie Ereignisformat oder Ereignisraten besitzen. Die gegebenenfalls unterschiedlichen Formate der Ereignisse der Ereignisströme sind jedoch zu Beginn bekannt, und ändern sich zur Laufzeit nicht. Obwohl die einzelnen Ereignisströme unabhängig voneinander sind, können zwischen den Ereignisströmen logische Verbindungen bestehen [LF98]. Entsprechend können die zugehörigen Ereignisse zu komplexen Ereignissen aggregiert werden, die höhere und wertvollere Informationen darstellen [EB09]. Diese Mustererkennung bzw. Analyse basiert auf formulierten, kontinuierlichen Anfragen. Zur Definition von kontinuierlichen Anfragen, können unter anderem graphische Interfaces [KS04] genutzt werden. Alternativ dazu können deklarative, SQL-basierte Anfragesprachen, z.b. Continuous Query Language (CQL) [ABW06] oder Continuous Computation Language (CCL) [Syb12] verwendet werden. Ausgangspunkt einer kontinuierlichen Anfrage sind ein oder mehrere Ereignisströme, die in der Anfrage durch Ereignisquellen

20 Complex Event Processing VerarbeitungsreihenfolgevdervEreignissev EreignisstromvA EreignisstromvB zukünftigevereignisse verworfenevereignisse Abbildung 2.1: Zeitbasierte Fenster zur Verarbeitung von Ereignissen repräsentiert werden. Die Ergebnisse einer Anfrage werden in Ereignissenken bereitgestellt. Zwischen den Ereignisquellen und Ereignissenken können 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ührung in Operatoren gekapselt, die neben den Informationen der Operationen, z.b. Bedingung einer Selektion, zusätzliche Informationen enthalten, z.b. Verbindungsinformationen zu anderen Operatoren. Die Operatoren werden hierbei zur Anfragebearbeitung bzw. Ereignisverarbeitung kontinuierlich ausgeführt. Zum anderen wird in einigen Operatoren, z.b. Aggregationen oder Joins, das Prinzip der Akkumulation verwendet. Akkumulation in Bezug auf CEP bedeutet, dass nur ein endlicher Ausschnitt der Ereignisströme gespeichert und weiterverarbeitet wird, da die Verarbeitung aller Ereignisse der potentiell unendlichen Ereignisströme nicht möglich ist [EB09]. Zur Umsetzung des Prinzips der Akkumulation werden in CEP Systemen zeitbasierte Fenster [BDM02], die nur einen gewissen Zeitraum betrachten, oder anzahlbasierte Fenster [GO03] verwendet, die die Anzahl der berücksichtigten Ereignisse beschränken. Abbildung 2.1 könnte die zeitbasierten Fenster eines Joins darstellen, der die Ereignisse zweier Ereignisströme A und B miteinander verbindet. Die Zahlen repräsentieren hierbei die Positionen der Ereignisse in den Ereignisströmen. 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öß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ührung 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ötigen, z.b. Selektionen, werden zustandslose Operatoren genannt. Zusätzlich muss bei der Ereignisverarbeitung in CEP berücksichtigt 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öme gewonnen Erkenntnisse dienen als Ausgangspunkt für Entscheidungen oder Aktionen, z.b. Aktienkauf, Starten eines neuen Prozesses usw. [EB09]. Anwendungsgebiete von CEP sind unter anderem Finanzanwendungen [ScZ05], z.b. Betrugserkennung durch Analyse von Kreditkartentransaktionen [SMMP09], Sensornetzwerke [CcC + 02] zur Verarbeitung von Sensordaten, Business

21 Kapitel 2. Grundlagen 7 Activity Monitoring [EB09] in dem z.b. Geschäftsprozesse überwacht werden, und die Überwachung von Netzwerken und Infrastrukturen [WDR06]. Bei der Auswertung von Ereignisströmen können sowohl bekannte Muster, oder durch Verwendung von Mechanismen des maschinellen Lernens unbekannte Muster gesucht werden [JHJ13]. In der Praxis, z.b. bei der Verarbeitung von Informationen aus Finanztransaktionen, müssen CEP Systeme die Ereignisse von verschiedenen Ereignisströmen verarbeiten, die Millionen von Ereignissen in der Sekunde erzeugen [Cor11]. Die Ereignisse müssen gegebenenfalls von einer hohen Anzahl von gleichzeitig laufenden Anfragen bearbeitet werden. Entsprechend können die Ressourcenanforderungen für einen einzelnen Rechnerknoten zu hoch sein. Um dennoch eine zeitnahe Ereignisverarbeitung zu ermöglichen, 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üssen die Eigenschaften von CEP Anfragen berücksichtigt werden. Im Gegensatz zur Problemstellung des Schedulings [BSBS13] können mehrere Operatoren gleichzeitig einem Rechnerknoten zugeordnet werden, und über einen längeren Zeitraum ausgeführt werden. Können trotz der Verwendung mehrerer Rechnerknoten nicht genügend Ressourcen zur Anfragebearbeitung bereitgestellt werden, müssen Ereignisse der Operatoren oder Ereignisströme ohne Bearbeitung verworfen werden (load shedding) [BBD + 02]. Um Qualitätsanforderungen, z.b. Antwortzeiten oder Ereignisdurchsatz, einhalten zu können, muss das CEP System kontinuierlich überwacht und an die aktuellen Anforderungen der Anfragebearbeitung angepasst werden. Problematisch hierbei ist, dass die Ereignisraten mit der Zeit variieren, oder Ereignisse stoßweise auftreten können [CJ09]. Entsprechend wichtig sind eine effiziente Anfragebearbeitung und -optimierung, gute Skalierbarkeit und hohe Verfügbarkeit des Systems [ScZ05]. Durch diese komplexen Anforderungen, die durch die zeitnahe Verarbeitung einer hohen Anzahl von Ereignissen (große Datenmenge) im Kontext von CEP auftreten können, stoßen bestehende Datenverarbeitungsinfrastrukturen, z.b. DBMS, an ihre Grenzen [ScZ05]. Um die hohen Anforderungen des CEP zu erfüllen, kann z.b. Cloud Computing verwendet werden, das unter anderem gute Eigenschaften bezüglich der Skalierbarkeit und Verfügbarkeit bietet. 2.2 Cloud Computing Die Ergebnisse dieser Arbeit werden innerhalb eines CEP Prototypen implementiert, der die Probleme bezüglich der hohen Effizienzanforderungen des CEP durch die Verwendung von Cloud Computing löst. Für 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) übernommen [MG09]: Cloud Computing ist ein Model, das jederzeit eine praktische Nutzung geteilter, konfigurierbarer Rechenressourcen (z.b. Netzwerke, Server, Speicher, Anwendungen und Dienste) auf Anfrage über ein Netzwerk erlaubt, wobei eine schnelle Bereitstellung und Freigabe mit minimalen Managementaufwand oder Serviceprovider-Interaktion ermöglicht wird.

22 Cloud Computing Statische Ressourcenbereitstellung Elastische Ressourcenbereitstellung Unterversorgung Systemlast Ressourcenmenge Überversorgung Zeit Abbildung 2.2: Problem der Unter- und Überversorgung Die wesentlichen Neuerungen, die durch Cloud Computing eingeführt werden, sind hierbei folgende Merkmale [AFG + 09]: 1. Illusion einer unendlichen verfügbaren 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öglichkeit Anwendungen durch Änderungen des Rechnerknotens zu verschieben sowie eine automatische Ressourcenverwaltung [ZCB10]. Obwohl die meisten Anwendungen vorhersagbaren, periodischen oder saisonalen Schwankungen unterliegen, treten oft unvorhersehbare Spitzenlasten auf [AFG + 09]. Um diese Spitzenlasten abzufangen, und genügend Ressourcen bereitzustellen, können Cloud- Technologien verwendet werden. Die genutzten Anwendungen müssen hierbei elastisch sein, um sich entsprechend schnell an geänderte Anforderungen durch eine Aufwärtsoder Abwärtsskalierung anpassen zu können [AFG + 09]. Die Anforderungen bezüglich der Elastizität werden von modernen Cloud-Anbietern wie Amazon EC2 [Ama] unterstützt, indem z.b. zusätzliche Ressourcen innerhalb von 2 bis 5 Minuten angeboten werden können [AFG + 09]. Diese schnelle Bereitstellung neuer Ressourcen ist ein enormer Vorteil im Vergleich zur traditioneller Ressourcenbeschaffung in der von der Finanzierung, Kauf, Lieferung und Installation neuer Hardware mehrere Monate verstreichen können [KHSS10]. Durch die schnelle Ressourcenbereitstellung bzw. -freigabe bei der Verwendung von Cloud-Technologien ist es möglich die Kosten für die Überversorgung (Over Provisioning) bzw. das Risiko der Unterversorgung (Under Provisioning) zu reduzieren [AFG + 09]. Die Probleme der Überversorgung bzw. Unterversorgung werden in Abbildung 2.2 dargestellt. Überversorgung bezeichnet hierbei die Bereitstellung von zu vielen Ressourcen für die aktuellen Anforderungen, was zu einer ineffizienten Hardwarenutzung führt, da nur ein Teil der vorhandenen Hardware genutzt wird. Bei einer Unterversorgung hingegen werden zu wenig Ressourcen für die aktuellen Anforderungen bereitgestellt, wodurch gegebenenfalls Laufzeitanforderungen der Anwendungen bezüglich Antwortzeit oder Durchsatz nicht mehr gewährleistet werden können. Können die Kosten für die Überversorgung konkret bestimmt werden, ist dies für eine Unterversorgung nur schwer möglich [AFG + 09]. Eine