KOSTENEFFIZIENTES CLOUD - BASIERTES COMPLEX EVENT PROCESSING

Transkript

1 Fakultät Informatik Institut für Systemarchitektur, Lehrstuhl Rechnernetze Diplomarbeit KOSTENEFFIZIENTES CLOUD - BASIERTES COMPLEX EVENT PROCESSING Lars Rödiger Matrikel - Nr.: Betreut durch: Dr.-Ing. Groß (TU Dresden), Prof. Dr. Schill (TU Dresden) und: Dipl.-Inf. Thomas Heinze (SAP Research Dresden) Eingereicht am 14. August 2012

2 2

3 ERKLÄRUNG Ich erkläre, dass ich die vorliegende Arbeit selbständig, unter Angabe aller Zitate und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe. Dresden, 14. August

4 4

5 DANKSAGUNG An dieser Stelle möchte ich mich bei allen Personen bedanken, die mich bei der Erstellung dieser Arbeit unterstützt haben. Mein erster Dank geht an Prof. Dr. Schill für die Möglichkeit meine Diplomarbeit am Lehrstuhl für Rechnernetze zu schreiben. Ein besonderer Dank gilt meinen zwei Betreuern Thomas Heinze (SAP Research Dresden) sowie Dr. Groß (TU Dresden), die mit sehr viel Engagement, guten Ideen und unermüdlichem Einsatz meine Diplomarbeit betreuten. Des Weiteren danke ich meinen Kollegen bei SAP Research Dresden für das angenehme Arbeitsklima und die gute Zusammenarbeit. Nicht zuletzt danke ich meinen Freunden, meiner Familie und im Besonderen meiner Freundin,die mir in den Monaten der Entstehung meiner Diplomarbeit immer wieder Mut zugesprochen haben und eine große Stütze für mich waren. 5

6 6

7 INHALTSVERZEICHNIS

8 1 Einleitung Motivation Rahmen und Zielstellung Aufbau der Arbeit Hintergrund Complex Event Processing Cloud - basiertes Complex Event Processing Cloud Computing Cloud - basiertes Complex Event Processing Prototyp Überblick Anfrage - Optimierung Operator - Platzierung Kostenmodell Kosteneffizienz Verwandte Arbeiten 33 4 Analyse und Entwurf Entwurf der Adaption Adaption der Initialen Platzierung Adaption der Laufzeitplatzierung Identifikation und Analyse der Parameter Parameter für die Initiale Platzierung Parameter für die Laufzeitplatzierung Suchalgorithmen Genetic Algorithm Recursive Random Search Inhaltsverzeichnis

9 5 Implementierung Adaption CostAdaption InitialCostAdaption RuntimeCostAdaption Suchalgorithmen Evaluation Evaluationskonzept Einflussanalyse Parameter: plc, gran Parameter: llb, lub Skalierbarkeit Laufzeitverhalten Kostenkonvergenz mit variierender Anzahl an Anfragen Allgemeines Konvergenzverhalten Kostenkonvergenz mit variierender Größe des Suchraums Kosteneffizienz Fazit Zusammenfassung Ausblick Inhaltsverzeichnis 9

10 10 Inhaltsverzeichnis

11 1 EINLEITUNG

12 1.1 MOTIVATION Die Auswertung von Informationen hat mit der Entwicklung der Informationstechnik, in unterschiedlichen Bereichen stetig an Bedeutung gewonnen. John Naisbitt prägte bereits 1982 in [Nai82] den Satz we are drowning in information, but we are starved for knowledge. Mit dem in den letzten Jahren zu beobachtenden rapiden Anstieg der Informationsmenge in Unternehmen gewinnt diese Aussage mehr und mehr an Gewicht. Die Menge der Daten, aus denen relevante Erkenntnisse gewonnen werden können ist dabei nicht die einzige Herausforderung. Kontinuierlich eintreffende Daten machen eine effiziente Verarbeitung erforderlich [Gar]. Ein typisches Beispiel sind Marktdaten, wie Aktien- oder Rohstoffpreise, welche fortlaufend in Form von Ereignissen eintreffen. Diese müssen zeitnah ausgewertet werden, um Chancen und Risiken frühzeitig zu erkennen und ggf. automatisch folgerichtige Entscheidungen zu treffen. Complex Event Processing (CEP) bildet die technologische Grundlage um eine Vielzahl konkurrierender Anfragen über einer Menge kontinuierlich eintreffender Ereignisse in Echtzeit zu verarbeiten. Die zunehmenden Anforderungen hinsichtlich des Durchsatzes, geringer Latenzzeiten und der Menge der Anfragen erfordern eine skalierbare Lösung in Form eines verteilten CEP - Systems [Sto05]. Mit Cloud Computing findet sich ein praktikabler Ansatz, welcher in dem der Arbeit zugrundeliegenden Prototypen eingesetzt wird. Hinsichtlich der Charakteristika von CEP - Anwendungen stellen sich einer Reihe neuer Herausforderungen. Zum Einen ist eine geeignete Abbildung der Anfragen innerhalb der Cloud zu finden. Zum Anderen muss diese entsprechend variierender Anforderungen angepasst werden. Im Zusammenhang mit der für Cloud Computing typischen Pay - per - Use - Philosophie ist auch die wirtschaftliche Effizienz des Systems gefordert. Im Rahmen dieser Arbeit wird untersucht, wie sich diese durch eine geeignete Adaption des vorhandenen Prototypen steigern lässt. Dabei geht es zum Einen um die Analyse von Systemparametern, welche einen Einfluss auf die Kosteneffizienz haben, zum Anderen um den Entwurf einer Adaptionsstrategie. Diese Strategie nimmt eine Parametrisierung des Prototypen zur Laufzeit vor mit dem Ziel die monetären Kosten zu minimieren. Die Wahl eines geeigneten Parameters erfordert dabei die effiziente Suche in einem potentiell sehr großen Suchraum. Des Weiteren ist eine Integration und Wiederverwendung des bestehenden Prototypen erforderlich. Im Nachfolgenden soll mit der Aufdeckung von Kreditkartenbetrug ein motivierendes Anwendungsszenario für Complex Event Processing beschrieben werden. Anwendungsszenario Die Motivation für den Einsatz von Complex Event Processing lässt sich anhand eines typischen Anwendungsszenarios, der Aufdeckung von EC- und Kreditkartenbetrug, beschreiben. Als Betrug wird an dieser Stelle die unberechtigte Verwendung eines Zahlungsmittels (EC- oder Kreditkarte) verstanden, z. B. infolge eines nicht gemeldeten Diebstahls. Die Aufdeckung eines solchen Betrugs ist mittels automatischer Analyse von Transaktionen (Überweisungen, Abhebungen etc.) hinsichtlich verdächtiger Muster möglich. Abb. 1.1 skizziert einen potentiellen Ablauf von Transaktionsereignissen, welcher auf einen Betrug schließen lässt. Die Ereignisse sind von oben nach unten zeitlich jünger werdend geordnet. Es sind zwei Abhebungen vom Konto hervorgehoben. Das erste Ereignis beschreibt eine Abhebung in London am 2. Juni 2012 um 12:00 UTC 1, das zweite Ereignis eine Abhebung vom gleichem Konto eine halbe Stunde später in Berlin. In Anbetracht des zeitlichen und räumlichen Zusammenhangs der beiden Ereignisse erscheint die Abfolge nicht plausibel. Der Ortswechsel London - Berlin ist in einer Zeitspanne von 30 Minuten praktisch nicht durchführbar. Der Verdacht, dass zumindest eine der beiden Abhebungen einen Betrug darstellt liegt nahe. Ein solches Szenario lässt sich allgemein durch ein Muster formulieren. In Falle des angegebenen Beispiels beschreibt ein Muster den verdächtigen Ablauf, indem sämtliche Transaktionsereignisse 1 Universal Time Coordinated, koordinierte Weltzeit 12 Kapitel 1 Einleitung

13 Transaktionsereignisse Zeit Transaktion: Abhebung am Geldautomaten Zeit: :00 UTC Ort: London Kto: Betrag: $ Transaktion: Abhebung am Geldautomaten $ Bank Zeit: :30 UTC Ort: Berlin Kto: Betrag: $ Abbildung 1.1: Anwendungsszenario: Aufdeckung von EC- und Kreditkartenbetrug der gleichen Kontonummer vereint werden und anschließend zeitlich und räumlich korreliert einer Plausibilitätsprüfung unterworfen werden. Dieses Muster beschreibt einen von vielen möglichen Fällen, welche auf EC- bzw. Kreditkartenbetrug hinweisen können. Als Reaktion auf das Erkennen eines verdächtigen Musters sollten umgehend entsprechende Maßnahmen eingeleitet werden, um weiteren Schaden zu vermeiden. Z. B. könnte eine konkrete Maßnahme die sofortige Sperrung des Zahlungsmittels sowie die Benachrichtigung des betreffenden Kontoinhabers umfassen. Ein weiterer Anwendungsfall ist mit Financial Monitoring gegeben. Bei diesem ist eine Menge an Benutzern an der Auswertung von Börsenereignissen interessiert. In den kontinuierlich eintreffenden Ereignissen wird nach einer Vielzahl von Mustern gesucht, welche durch die Benutzer in Form von Anfragen beschrieben sind. Dieser Anwendungsfall erfordert eine zeitnahe, schnelle Auswertung im Sinne einer Analyse bzw. Überwachung. Die riesige Menge an Ereignissen muss in Echtzeit verarbeitet, aufbereitet und in geeigneter Form dargestellt werden. Diese Forderung nach geringen Latenzzeiten, hohen Durchsatzraten sowie der Verarbeitung einer variierenden Menge konkurrierender Anfragen, ist charakteristisch für CEP - Anwendungen im Allgemeinen und für den Anwendungsfall Financial Monitoring im Besonderen. 1.1 Motivation 13

14 1.2 RAHMEN UND ZIELSTELLUNG Die vorliegende Arbeit soll einen bestehenden Prototyp hinsichtlich der Steigerung der Kosteneffizienz untersuchen. Der Prototyp implementiert ein CEP - System auf Basis von Cloud Computing und wurde im Rahmen des europäischen Forschungsprojekts SRT-15 entwickelt. Die Arbeiten [Ji11][Mey12][Hei11] untersuchen verschiedene Fragestellungen im Zusammenhang mit dem Prototypen, insbesondere die Verteilung von Anfragen innerhalb der Cloud und die Berechnung von monetären Kosten. Im Ergebnis bilden diese die Grundlage für die vorliegende Untersuchung. Zielstellung der vorliegenden Arbeit ist die Wiederverwendung, Anpassung und Erweiterung des bestehenden Prototypen um eine kosteneffiziente Ereignisverarbeitung zu erreichen. Die Arbeit gliedert sich in folgende Aufgaben. Identifikation von Parametern Der bestehende Prototyp verwendet Heuristiken, welche durch Reihe von Parametern angepasst werden können. Ein Teil der vorliegenden Arbeit ist die Identifikation solcher Parameter und eine anschließende Analyse hinsichtlich des Einflusses auf die Kosteneffizienz. Der Prototyp soll des Weiteren erweitert werden, so dass einer Parametrisierung zur Laufzeit sowie die Berechnung der Kosten auf Basis einer Parameterkonfiguration möglich wird. Umsetzung eines geeigneten Suchverfahrens Die zu untersuchenden Parameter haben komplexe Abhängigkeiten und ergeben einen potentiell sehr großen Suchraum, für welchen eine erschöpfende bzw. vollständige Suche keine Lösung darstellt. Aus diesem Grund soll ein passendes Suchverfahren ermittelt und umgesetzt werden. Eine effektive und effiziente Suche soll erzielt werden. Entwurf und Umsetzung einer Adaptionsstrategie Schwerpunkt der Arbeit liegt in der Ausarbeitung einer geeigneten Adaptionsstrategie. Die Adaption soll zur Laufzeit mit Hilfe des gewählten Suchalgorithmus eine Parameterkonfiguration ermitteln und untersuchen ob mit dieser eine Kostenreduktion erzielt werden kann. Des Weiteren soll die Fragestellung untersucht werden, wann eine Adaption zu untersuchen und wann diese durch Rekonfiguration des Systems umzusetzen ist. Als Ergebnis soll eine prototypische Implementierung entstehen, welche Teile des bestehenden Prototypen wiederverwendet und diesen um die Adaption erweitert. Evaluation In der Evaluation sollen die Ergebnisse der Ausarbeitung anhand geeigneter Evaluationsszenarien gezeigt werden. Dies betrifft insbesondere den Einfluss der Parameter, die Skalierbarkeit sowie die Kosteneffizienz. Des Weiteren sollen Grenzen und Verbesserungen des ausgearbeiteten Ansatzes diskutiert werden. 14 Kapitel 1 Einleitung

15 1.3 AUFBAU DER ARBEIT Der Aufbau der vorliegenden Arbeit gestaltet sich wie folgt. Kapitel 2 stellt alle zum Verständnis notwendigen Begriffe, Konzepte, Methoden und Technologien vor. Das Kapitel 3 gibt einen Überblick über verwandte Arbeiten, diskutiert deren Ansätze und vergleicht diese mit der Zielstellung der vorliegenden Arbeit. Die Analyse, sowie das in dieser Arbeit entstandene Lösungskonzept werden ausführlich im Kapitel 4 behandelt. Anschließend beschreibt Kapitel 5 Details der Umsetzung des Entwurfs, sowie notwendige Anpassungen des bestehenden Prototypen. Das Kapitel 6 diskutiert die Ergebnisse unter den Aspekten: Einfluss der Parameter, Skalierbarkeit und Kosteneffizienz. Die Arbeit schließt mit dem Kapitel 7 ab, in welchem die Ergebnisse zusammengefasst werden und ein Ausblick auf weitere Fragestellungen gegeben wird. 1.3 Aufbau der Arbeit 15

16 16 Kapitel 1 Einleitung

17 2 HINTERGRUND

18 Das folgende Kapitel bildet den Hintergrund der vorliegenden Arbeit, definiert Begriffe und stellt Konzepte, Methoden sowie Technologien vor, mit dem Ziel ein einheitliches Vokabular und Verständnis zu schaffen. Abschnitt 2.1 gibt einen Überblick zur Thematik CEP und stellt diese als technologischen Ansatz zur Verarbeitung kontinuierlicher Ereignisströme dar. Im Abschnitt 2.2 wird Cloud Computing zunächst allgemein als Lösung für skalierbare elastische Anwendungen behandelt und anschließend unter dem Aspekt CEP diskutiert. Abschluss bildet der Abschnitt 2.3, indem der bestehende Prototyp hinsichtlich der Architektur, der Komponenten und deren Zusammenwirken vorgestellt wird. 2.1 COMPLEX EVENT PROCESSING Der Begriff Complex Event Processing (kurz CEP) wurde vor rund 10 Jahren durch David Luckham [Luc01] geprägt und beschreibt eine Softwaretechnologie, welche Operationen auf einer Menge von Ereignissen durchführt und diese schrittweise in komplexe Ereignisse überführt. Operationen, welche Verarbeitungsschritte auf Ereignissen definieren sind u. a. Konstruktion, Transformation und Abstraktion. Im Abschnitt 1.1 wurden mit der Aufdeckung von EC- bzw. Kreditkartenbetrug und Financial Monitoring bereits zwei konkrete Anwendungsfälle für CEP dargestellt. Weitere typische Anwendungsbereiche sind Business Activity Monitoring, Sensornetzwerke und Supply Chain Management. CEP ist dem Architekturstil Ereignis gesteuerte Architekturen zugeordnet, in dem Ereignisse das zentrale Konzept bilden. Die nachfolgende Ausführung lehnt sich vor Allem an den Arbeiten [BD10][Luc01] an. Ereignis Ein Ereignis beschreibt eine Beobachtung eines Zustandes bzw. einer Zustandsänderung eines Objektes. Ereignisse werden mit einem zeitlichen Bezug in Form eines Zeitpunktes (point in time) oder einer Zeitspanne (interval based) verknüpft. Typische Ereignisse im Zusammenhang mit CEP sind u. a. Signale von RFID Sensoren, der Eingang einer Bestellung und das Auftreten einer Börsenaktivität. Ereignisse lassen sich durch Schemata klassifizieren. Diese sind durch eine Menge von Attributen eindeutig definiert. Abb. 2.2 a) zeigt ein vereinfachtes Schema für eine Klasse von Börsenereignissen. Allgemein besteht ein CEP - System aus einem Netzwerk von Verarbeitungseinheiten, welches Ereignisquellen mit Ereignissenken verbindet. Die Verabeitungseinheiten werden im Folgenden als CEP - Komponenten 1 bezeichnet. Ereignisquellen erzeugen kontinuierlich Ereignisse, die u. a. durch Vorgänge, Aktivitäten oder Entscheidungen motiviert sein können. Diese zumeist einfachen Ereignisse werden durch CEP - Komponenten verarbeitet und führen letztendlich in Ereignissenken zu Reaktionen. Beispiele für solche Reaktionen sind u. a. Visualisierungen in Dashboards, die Steuerung von Geschäftsprozessen, Aktualisieren von Relationen in Datenbanken oder wie im Anwendungsfall im Abschnitt 1.1 beschrieben, das Sperren einer Kreditkarte. In Anlehnung an [BD10, S. 49f, 61ff] kann CEP durch drei aufeinanderfolgende Schritte beschrieben werden, welche sich in der Architektur als Schichten widerspiegeln. 1. Erkennen (Sense) Erkennen von Ereignissen aus der Umwelt und (unmittelbares) Generieren entsprechender Ereignisobjekte. Dieser Schritt entspricht der Schicht Ereignisquellen. 2. Verarbeiten (Process bzw. Analyze) Verarbeiten von Ereignissen, u. a. durch Abstraktion, Aggregation, Korrelation, Klassifikation und Filterung. Die Schicht Ereignisverarbeitung umfasst diesen Schritt. 18 Kapitel 2 Hintergrund

19 Ereignisströme (eing.) Ereignisquellen Ereignisverarbeitung Ereignisbehandlung Ereignisströme (ausg.) CEP-Komponenten Ereignisstrom eing.-eingehend ausg.-ausgehend Abbildung 2.1: Schichten in einem CEP - System 3. Reagieren (Respond) Veranlassen von definierten Reaktionen in der Schicht Ereignisbehandlung/Ereignissenken. Reaktionen können auch die Rückkopplung zur Schicht Ereignisquellen beinhalten. Abb. 2.1 stellt die Schichtenarchitektur eines CEP - Systems mit den Schichten Ereignisquellen, Ereignisverarbeitung und Ereignisbehandlung dar. Die softwaretechnische Basis für die Ausführung von CEP - Anwendungen bilden so genannte CEP - Engines. In einem CEP - System erfolgt die Kommunikation grundlegend asynchron durch Publish-Subsribe 2. Daten, welche über Kanäle zwischen CEP - Komponenten ausgetauscht werden, haben im Allgemeinen die Form von Ereignisströmen. Ereignisstrom Ein Ereignisstrom ist eine linear geordnete Sequenz von Ereignissen. Das Ordnungskriterium ist in der Regel der Zeitstempel der Ereignisse. Ereignisströme können entweder endlich, durch ein Zeitfenster oder ein anderes Kriterium begrenzt oder unendlich bzw. unbegrenzt sein. Technisch gesehen ist die Verarbeitung unbegrenzter Ereignisströme nicht möglich. Intern erfolgt aus diesem Grund eine Abbildung auf einen endlichen Strom durch ein zeitlich oder mengenmäßig beschränktes Fenster (engl. Sliding Window). Die Verarbeitung von Ereignisströmen wird als Event Stream Processing (ESP) bezeichnet. Der Unterschied zwischen ESP und CEP ist nach [BD10, S. 57] konzeptionell. In der vorliegenden Arbeit wird CEP ausschließlich unter dem Aspekt von Ereignisströmen behandelt. Unter dieser Betrachtung kann CEP, wie im Abschnitt 1.1 bereits dargestellt, als Mustersuche über den eingehenden Ereignisströmen verstanden werden. Die Muster sind dabei im Vorfeld bekannt 3 und können in Form von Ereignismustern spezifiziert werden. Ereignismuster Ereignismuster beschreiben Beziehungen zwischen Ereignissen, welche in einem festgelegten (fachlichen) Kontext relevant sind. [LSA + 08] definiert Ereignismuster formal als Menge von Schablonen (Templates), welche mit relationalen Operatoren verknüpft werden. Templates beschreiben mittels Variablen eine Menge von Ereignissen. 1 [Luc01] bezeichnet diese als Event Processing Agents und das Netzwerk als Event Processing Network 2 Eine Besonderheit diesbezüglich ist, dass die Vernetzung der Komponenten als lose gekoppelt angesehen werden kann. Der Zeitpunkt der Verarbeitung ist jedoch durch Kohäsion gekennzeichnet, da eine zeitnahe Verarbeitung der Ereignisse gefordert wird. 3 In [EB09] wird darauf verwiesen, dass CEP auch dazu verwendet wird unbekannte Muster zu erkennen, z. B. in Form von Data Mining oder maschinellem Lernen. 2.1 Complex Event Processing 19

20 Ereignismuster sind ein wesentliches Konzept von CEP und bilden in der Summe einen wichtigen Teil der Fachlogik im Gesamtsystem ab. Die Muster werden in einer speziellen Beschreibungssprache formuliert. [EB09] unterscheidet Kompositionsoperatoren, Produktionsregeln und Datenstrom - Anfragesprachen 4. Für die vorliegende Arbeit sind letztere von Interesse, speziell die deklarative Beschreibung durch die Continous Computing Language (CCL) [Syb]. Im Zusammenhang dieser, werden die zu suchenden Ereignismuster durch kontinuierliche Anfragen (engl. Continous Queries) gekapselt. Anfrage (Query) Eine Anfrage im Sinne von CEP beschreibt die Suche nach einem Ereignismuster über einem oder mehreren Ereignisströmen, welche im Vorfeld offline oder zur Laufzeit ad - hoc durch einen Anwender formuliert wird. Die Ausführung einer Anfrage kann einmalig für einen festgelegten Zeitpunkt oder kontinuierlich über einen gewissen Zeitraum stattfinden. Letzteres ist typisch für CEP. CCL orientiert sich an Konzepten von SQL und erweitert diese insbesondere um die Darstellung von Datenströmen sowie um eine temporale und sequentielle Semantik. Im Unterschied zu SQL oder anderen klassischen Datenbankanfragesprachen arbeitet CCL auf einem kontinuierlichen, flüchtigen Datenstrom. Die in CCL formulierten Anfragen sind des Weiteren überwiegend langlaufend statt einmalig. Zur Laufzeit verarbeiten CEP - Systeme häufig eine Vielzahl von Anfragen gleichzeitig, wobei die Menge der Anfragen im System dynamisch ist. D. h. Anwender können zur Laufzeit neue Anfragen hinzufügen und entfernen. Abb. 2.2 zeigt eine CCL - Anfrage zur Berechnung einer Candlestick - Darstellung für Börsenereignisse. Die Anfrage berechnet den minimalen und maximalen, sowie den ältesten und aktuellsten Preis innerhalb der letzten 60 Sekunden des Symbols DE über dem Ereignisstrom In. Die Ergebnisse sind werden wiederum in Form von Ereignissen in den Ereignisstrom Out eingefügt. a) Ereignisschema b) CCL-Anfrage String comp; double tick; long time; Insert into Out Select min(price), max(price), first(price), last(price) From In Within 60 seconds Where symbol = DE ; c) Anfragegraph Strom In Strom Out Quelle Q1 Filter F1 Aggregation A1 Selektion Sel2 Senke S1 Ereignisstrom Operator Abbildung 2.2: Anfrage zur Berechnung einer Candlestick - Darstellung 4 Eine verbreitete Datenstrom - Anfragesprache ist CQL, Continous Query Language[AB06]. 20 Kapitel 2 Hintergrund

21 Der eingehende Ereignisstrom StreamQ1 besteht aus den Attributen symbol, price und volume. Das zugehörige Schema ist unter 2.2 a) angegeben. Die Anfrage zur Berechnung der Candlestick - Darstellung in CCL zeigt Abb. 2.2 b). Wie in Abb. 2.2 c) dargestellt lassen sich Anfragen als gerichteter, zusammenhängender, azyklischer Graph verstehen. Sämtliche Kanten entsprechen Ereignisströmen und innere Knoten repräsentieren Operatoren aus denen die Anfrage zusammengesetzt ist. Wie am Beispiel dargestellt gibt es unterschiedliche Typen von Operatoren. U. a. Filter - Operatoren, mit denen Ereignisströme nach bestimmten Bedingungen gefiltert werden können und Aggregations - Operatoren, mit denen sich Informationen über einer Menge von Ereignissen zusammenfassen lassen. Sämtliche im System befindliche Anfragen können ebenfalls als gerichteter azyklischer (ggf. nicht zusammenhängender) Graph beschrieben werden. Dieser spezifiziert den Datenfluss im CEP - System und wird im Folgenden als globaler Anfragegraph bezeichnet. Hintergrund der vorliegenden Arbeit ist die Untersuchung eines elastischen CEP - Systems auf Basis von Cloud Computing. Der nachfolgende Abschnitt gibt einen kurzen Überblick zum Thema Cloud Computing. 2.2 CLOUD - BASIERTES COMPLEX EVENT PROCESSING CEP - Systeme verarbeiten eine Vielzahl nebenläufiger Anfragen auf einer Menge von Ereignisströmen. Die zunehmenden Anforderungen bezüglich geringer Latenzzeiten sowie hoher Durchsatzmengen erfordern eine parallele Ausführung in Form eines verteilten Systems [Sto05]. Der bestehende Prototyp verwendet Cloud Computing um das CEP - System auf mehrere Ressourcen zu verteilen. Bevor die Besonderheiten von Cloud basierenden CEP - Systemen diskutiert werden, wird Cloud Computing als Paradigma kurz vorgestellt Cloud Computing Für die Klärung des Begriffs Cloud Computing und die anschließende Darstellung der Eigenschaften und Konzepte soll die in Fachkreisen oft zitierte Definition [Mel11] des National Institute of Standards and Technology (NIST) als Einstieg dienen. Cloud Computing Cloud computing is a model for enabling ubiquitous, convienient, on - demand network access to a shared pool of configurable computing resources (e. g. networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Der Definition zufolge liegt der Fokus von Cloud Computing auf der einfachen, dem Bedarf angepassten, flexiblen Bereitstellung von (Rechner-) Ressourcen. Ressourcen sind dabei u. a. Netzwerk, Speicher, Anwendungen, Dienste und Server. [Mel11] charakterisiert Cloud Computing u. a. anhand folgender Eigenschaften. Es existiert einen Pool von Rechnerressourcen, welcher durch einen Provider verwaltet und bereitgestellt wird. Ressourcen können nach Bedarf über einen standardisierten Zugriffsmechanismus angefordert werden. Die Beschaffung sowie die Freigabe der Ressourcen kann elastisch und schnell erfolgen, um den Anforderungen der Anwendung gerecht zu werden. Weiterhin scheinen die zur Verfügung stehenden Ressourcen aus Sicht des Kunden unbegrenzt. Die Ressourcennutzung ist für die Kunden und den Anbieter in dem Sinne transparent, dass diese gemessen, überwacht und letztendlich gesteuert werden kann. Cloud Computing ermöglicht dabei nicht nur neue Ressourcen im Sinne einer Aufwärtsskalierung hinzuzufügen, sondern auch nicht mehr benötigte Ressourcen freizugeben (Abwärtsskalierung). 2.2 Cloud - basiertes Complex Event Processing 21

22 Last Variierende Last Under-Provisioning Statische Ressourcenbereitstellung Elastische Ressourcenbereitstellung Over-Provisioning Zeit Abbildung 2.3: Statische und Elastische Ressourcenbereitstellung Diese Eigenschaft wird als Elastizität bezeichnet. Abb. 2.3 veranschaulicht den Begriff beispielhaft für die Anpassung der Ressourcen an eine zeitlich variierende Last. Im Vergleich ist die, für konventionelle Rechenzentren typische, statische Bereitstellung von Ressourcen dargestellt. Diese kennt folgende Probleme. Die variierenden Lastanforderungen sind im Allgemeinen nicht bekannt und lassen sich nur schwer abschätzen. Dennoch muss eine Anzahl von Ressourcen festgelegt werden, welche diesen Anforderungen gerecht wird. Eine Unterschätzen (Under - Estimate) der aufkommenden Last kann zu Verletzungen zugesicherter Systemeigenschaften führen. Z. B. kann die Latenzzeit einen maximalen Wert überschreiten. In diesem Fall, in dem die verwendeten Ressourcen den Anforderungen nicht genügen, wird von Under - Provisioning gesprochen. Darüber hinaus kann eine Überschätzen (Over - Estimate) der notwendigen Ressourcen eine geringere Auslastung der Ressourcen zur Folge haben. Die zur Verfügung stehenden Ressourcen werden nicht effizient genutzt. Dies bezeichnet man mit Over - Provisioning. Aus wirtschaftlicher Sicht sollte Over - Provisioning vermieden werden, indem ungenutzte Ressourcen freigegeben werden. Ideal ist eine dynamische Anpassung der Ressourcen entsprechend dem tatsächlichen Bedarf, so dass einerseits genügend Ressourcen zur Verfügung stehen um den Anforderungen gerecht zu werden und andererseits die Ressourcen wirtschaftlich effizient eingesetzt werden. Diese Ziele werden durch Elastic Provisioning umgesetzt. Aus der Elastizität sowie, der für Cloud Computing charakteristischen Pay - per - Use - Philosophie ergeben sich gegenüber dem Einsatz konventioneller Rechenzentren eine Reihe von Vorteilen und Chancen. Auf der anderen Seite sind neue Herausforderungen und Probleme zu bewältigen. Für die vorliegende Arbeit spielt vor Allem der wirtschaftliche Aspekt, die Einsparung finanzieller Ausgaben eine Rolle. Im Folgenden Abschnitt wird Cloud Computing unter dem Aspekt CEP behandelt Cloud - basiertes Complex Event Processing Wirtschaftlichkeit sowie Elastizität sind treibende Faktoren für den Einsatz von Cloud Computing, so auch für CEP. Abb. 2.4 zeigt eine stark vereinfachte Darstellung eines Cloud - basierten CEP - Systems und damit des bestehenden Prototypen. Das System verwendet ein Netzwerk von Ressourcen innerhalb der Cloud um Anfragen der CEP - Anwendung auszuführen. Ereignisströme 22 Kapitel 2 Hintergrund

23 Anfragen CEP in der Cloud Ereignisströme (eing.) Ereignisströme (ausg.) Ereignisstrom eing.-eingehend ausg.-ausgehend Abbildung 2.4: Cloud - basiertes CEP - System (stark vereinfacht) unterschiedlicher Quellen dienen als Eingangdaten. Als Ergebnis liefert das System wiederum Ereignisströme. Die Last im CEP - System und folglich der Bedarf an Ressourcen sind im Wesentlichen durch zwei Faktoren bestimmt. Zum Einen entsteht durch die kontinuierlich eintreffenden Ereignisse eine Last, welche sich im CEP - System unterschiedlich verteilt. Zum Anderen schwankt die Anzahl der Anfragen im System mit den Anforderung der Benutzer, die diese formulieren. Im Folgenden wird diese Charakteristik als Dynamik des Systems bezeichnet. Elastizität befasst sich mit dieser Dynamik und kann im Zusammenhang mit CEP auf unterschiedlichen Ebenen verschiedener Granularität abgebildet werden. [Hei11] unterscheidet dabei mit abnehmender Granularität die Abbildung auf Engine-, Anfrage und Operator - Ebene. Für den bestehenden Prototypen wurde die Operator - Ebene gewählt, welche im Folgenden kurz erklärt wird. Beim Hinzufügen einer Anfrage wird den logischen Operatoren jeweils eine Menge von Operatorinstanzen zugeordnet. Der eingehende Ereignisstrom wird dabei partitioniert und auf die Instanzen aufgeteilt. Anschließend werden die Ergebnisse zusammengefasst und den Instanzen des bzw. der nachfolgenden logischen Operatoren bereitgestellt. In Abschnitt ist dies in der Abb. 2.7 dargestellt. Im Rahmen der elastischen Ressourcenbereitstellung wird über eine Zuordnung von Operatorinstanzen zu den Cloud - Ressourcen entschieden. Diese Zuordnung ändert sich aufgrund der Dynamik. Für die nachfolgenden Ausführungen wird der Begriff Momentaufnahme eingeführt. Dieser bezeichnet eine Aufnahme des Zustands des Systems zu einem festgelegten Zeitpunkt. Der Zustand umfasst dabei die Menge der im System laufenden Anfragen, deren Zuordnung und den Auslastungszustand sowie die Verteilung im CEP - System. Als Synonym wird z. T. auch Konstellation des Systems oder Systemzustand verwendet. Der nachfolgende Abschnitt beschreibt den Prototypen als Cloud - basiertes CEP - System mit den für die vorliegende Arbeit relevanten Details. 2.2 Cloud - basiertes Complex Event Processing 23