KOSTENEFFIZIENTES CLOUD - BASIERTES COMPLEX EVENT PROCESSING
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fakultät Informatik Institut für Systemarchitektur, Lehrstuhl Rechnernetze Diplomarbeit KOSTENEFFIZIENTES CLOUD - BASIERTES COMPLEX EVENT PROCESSING Lars Rödiger Matrikel - Nr.: 32 13 95 2 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
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 2012
34
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 Arbeits-
klima 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 Diplomar-
beit immer wieder Mut zugesprochen haben und eine große Stütze für mich waren.
56
INHALTSVERZEICHNIS
1 Einleitung 11
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Rahmen und Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Hintergrund 17
2.1 Complex Event Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Cloud - basiertes Complex Event Processing . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Cloud - basiertes Complex Event Processing . . . . . . . . . . . . . . . . . . 22
2.3 Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.2 Anfrage - Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.3 Operator - Platzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.4 Kostenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.5 Kosteneffizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Verwandte Arbeiten 33
4 Analyse und Entwurf 37
4.1 Entwurf der Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.1 Adaption der Initialen Platzierung . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.2 Adaption der Laufzeitplatzierung . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Identifikation und Analyse der Parameter . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Parameter für die Initiale Platzierung . . . . . . . . . . . . . . . . . . . . . . 41
4.2.2 Parameter für die Laufzeitplatzierung . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Suchalgorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Genetic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.2 Recursive Random Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8 Inhaltsverzeichnis5 Implementierung 55
5.1 Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.1 CostAdaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.2 InitialCostAdaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.3 RuntimeCostAdaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Suchalgorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6 Evaluation 59
6.1 Evaluationskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Einflussanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.1 Parameter: plc, gran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.2 Parameter: llb, lub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.1 Laufzeitverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.2 Kostenkonvergenz mit variierender Anzahl an Anfragen . . . . . . . . . . . 66
6.3.3 Allgemeines Konvergenzverhalten . . . . . . . . . . . . . . . . . . . . . . . 67
6.3.4 Kostenkonvergenz mit variierender Größe des Suchraums . . . . . . . . . . 71
6.4 Kosteneffizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7 Fazit 75
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Inhaltsverzeichnis 910 Inhaltsverzeichnis
1 EINLEITUNG
1.1 MOTIVATION
Die Auswertung von Informationen hat mit der Entwicklung der Informationstechnik, in unter-
schiedlichen 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 Unterneh-
men 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 typi-
sches 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 konkur-
rierender Anfragen über einer Menge kontinuierlich eintreffender Ereignisse in Echtzeit zu ver-
arbeiten. 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 vor-
handenen Prototypen steigern lässt. Dabei geht es zum Einen um die Analyse von Systempara-
metern, 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 erfor-
dert 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 Anwen-
dungsszenario 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 Be-
trugs 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 Be-
trug schließen lässt. Die Ereignisse sind von oben nach unten zeitlich jünger werdend geordnet.
Es sind zwei Abhebungen vom Konto 123 456 789 hervorgehoben. Das erste Ereignis beschreibt
eine Abhebung in London am 2. Juni 2012 um 12:00 UTC1 , das zweite Ereignis eine Abhe-
bung 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 EinleitungTransaktionsereignisse
Zeit
Transaktion: Abhebung am Geldautomaten
Zeit: 02.06.2012 12:00 UTC
Ort: London
Kto: 123456789
Betrag: 100.00$
$
Transaktion: Abhebung am Geldautomaten Bank
Zeit: 02.06.2012 12:30 UTC
Ort: Berlin
Kto: 123456789
Betrag: 400.00$
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 Sper-
rung 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 ein-
treffenden 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 131.2 RAHMEN UND ZIELSTELLUNG Die vorliegende Arbeit soll einen bestehenden Prototyp hinsichtlich der Steigerung der Kosteneffi- zienz 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 Pro- totypen, 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 Ad- aption soll zur Laufzeit mit Hilfe des gewählten Suchalgorithmus eine Parameterkonfiguration ermitteln und untersuchen ob mit dieser eine Kostenreduktion erzielt werden kann. Des Wei- teren 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 An- satzes diskutiert werden. 14 Kapitel 1 Einleitung
1.3 AUFBAU DER ARBEIT
Der Aufbau der vorliegenden Arbeit gestaltet sich wie folgt. Kapitel 2 stellt alle zum Verständ-
nis 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 Ziel-
stellung der vorliegenden Arbeit. Die Analyse, sowie das in dieser Arbeit entstandene Lösungs-
konzept 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, Skalierbar-
keit 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 1516 Kapitel 1 Einleitung
2 HINTERGRUND
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 Ver-
stä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. Operatio-
nen, welche Verarbeitungsschritte auf Ereignissen definieren sind u. a. Konstruktion, Transfor-
mation und Abstraktion. Im Abschnitt 1.1 wurden mit der Aufdeckung von EC- bzw. Kreditkar-
tenbetrug 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ände-
rung eines Objektes. Ereignisse werden mit einem zeitlichen Bezug in Form eines Zeit-
punktes (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 Be-
stellung 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 Ereignissen-
ken 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 beschrie-
ben 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 HintergrundEreignisverarbeitung
Ereignisströme (eing.) Ereignisströme (ausg.)
Ereignisbehandlung
Ereignisquellen
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üh-
rung von CEP - Anwendungen bilden so genannte CEP - Engines. In einem CEP - System erfolgt
die Kommunikation grundlegend asynchron durch Publish-Subsribe2 . Daten, welche über Kanäle
zwischen CEP - Komponenten ausgetauscht werden, haben im Allgemeinen die Form von Ereig-
nisströmen.
Ereignisstrom Ein Ereignisstrom ist eine linear geordnete Sequenz von Ereignissen. Das Ord-
nungskriterium 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 einge-
henden 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 ei-
nem festgelegten (fachlichen) Kontext relevant sind. [LSA+ 08] definiert Ereignismuster for-
mal 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 Ereig-
nisse 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 19Ereignismuster sind ein wesentliches Konzept von CEP und bilden in der Summe einen wichti-
gen Teil der Fachlogik im Gesamtsystem ab. Die Muster werden in einer speziellen Beschrei-
bungssprache 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 Zusam-
menhang 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 Ereignismu-
ster ü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 stattfin-
den. 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 lang-
laufend 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örsenereig-
nisse. Die Anfrage berechnet den minimalen und maximalen, sowie den ältesten und aktuellsten
Preis innerhalb der letzten 60 Sekunden des Symbols DE0007164600 ü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; Insert into Out
double tick; Select min(price), max(price), first(price), last(price)
long time; From In
Within 60 seconds
Where symbol = ‘DE0007164600‘;
c) Anfragegraph
Strom In Strom Out
Quelle Q1 Senke S1
Filter F1 Aggregation A1 Selektion Sel2
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 HintergrundDer 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 Candle-
stick - 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 zusam-
mengesetzt 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 Er-
eignissen 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 Ereignis-
strömen. Die zunehmenden Anforderungen bezüglich geringer Latenzzeiten sowie hoher Durch-
satzmengen erfordern eine parallele Ausführung in Form eines verteilten Systems [Sto05]. Der
bestehende Prototyp verwendet Cloud Computing um das CEP - System auf mehrere Ressour-
cen zu verteilen. Bevor die Besonderheiten von Cloud basierenden CEP - Systemen diskutiert
werden, wird Cloud Computing als Paradigma kurz vorgestellt.
2.2.1 Cloud Computing
Für die Klärung des Begriffs Cloud Computing und die anschließende Darstellung der Eigenschaf-
ten 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, ser-
vers, 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 an-
gepassten, flexiblen Bereitstellung von (Rechner-) Ressourcen. Ressourcen sind dabei u. a. Netz-
werk, 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 ge-
recht 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 21Last
Variierende Last
Statische Ressourcen-
bereitstellung
Under-Provisioning
Elastische Ressourcen-
bereitstellung
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 kon-
ventionelle 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 festge-
legt 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 verwen-
deten Ressourcen den Anforderungen nicht genügen, wird von Under - Provisioning gesprochen.
Darüber hinaus kann eine Überschätzen (Over - Estimate) der notwendigen Ressourcen eine ge-
ringere 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.
2.2.2 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 HintergrundAnfragen
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 die-
ser 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 Ope-
ratorinstanzen zugeordnet. Der eingehende Ereignisstrom wird dabei partitioniert und auf die
Instanzen aufgeteilt. Anschließend werden die Ergebnisse zusammengefasst und den Instan-
zen des bzw. der nachfolgenden logischen Operatoren bereitgestellt. In Abschnitt 2.3.3 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 Zuord-
nung ä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 232.3 PROTOTYP
2.3.1 Überblick
Der Prototyp, welcher im Rahmen dieser Arbeit angepasst und erweitert werden soll, realisiert
ein verteiltes Cloud - basierentes CEP - System, welches mit variierenden Anforderungen elastisch
skaliert. Im vorhergehenden Abschnitt wurde die grundlegende Idee hinter dem Prototypen be-
reits skizziert. In diesem Abschnitt werden Details des Prototypen vorgestellt, welche für die
vorliegende Arbeit von Interesse sind. Abb. 2.5 gibt einen Überblick über die Struktur des Proto-
typen. Die wesentlichen Komponenten sind Anfrage - Optimierung (MQO), Operator - Platzierung,
Cloud - basiertes CEP - System und Kostenberechnung (in der Abb. nicht dargestellt).
Parameter-
Anfrage hinzufügen/entfernen konfiguration
Anfrage-Optimierung Operator-Platzierung
x
(MQO)
Auslastungs-
Platzierung ereignisse
vornehmen
Ereignisströme (eing.) Ereignisströme (ausg.)
Cloud-basiertes CEP-System
Ereignisstrom eing.-eingehend ausg.-ausgehend
Abbildung 2.5: Struktur des Prototypen
Das Zusammenspiel der einzelnen Komponenten gestaltet sich wie folgt: Benutzer können zur
Laufzeit ad - hoc Anfragen hinzufügen bzw. entfernen. Diese Anfragen müssen in der Cloud ge-
schickt auf Rechnerknoten platziert werden. Die Komponente Anfrage - Optimierung, welche im
Abschnitt 2.3.2 näher beschrieben wird, versucht vor der Platzierung durch Wiederverwendung
von bestehenden Anfragen oder Teilen davon eine Optimierung zu erreichen. Für die mit der
neuen Anfrage hinzukommenden Operatoren wird anschließend die Zuordnung auf verfügbare
Ressourcen berechnet. Dies ist Aufgabe der Komponente Operator - Platzierung. Letztendlich
wird die berechnete Zuordnung in Form einer Platzierung in der Cloud vorgenommen. Die Plat-
zierung neuer Anfragen als Teil der Operator - Platzierung wird im Folgenden als Initiale Platzie-
rung bezeichnet. Durch variierende Lastanforderungen, welche sich im System unterschiedlich
verteilt, ist eine dynamische Anpassung der Platzierung erforderlich. Dabei soll nicht vorrangig
ein Lastausgleich erzielt werden, sondern eine effiziente Nutzung der Ressourcen im Sinne der
elastischen Skalierung. Für die Berechnung der Platzierung sind Laufzeitinformationen über den
aktuellen Zustand des Systems notwendig, insbesondere Informationen zur Auslastung der Rech-
nerknoten und der darauf platzierten Operatorinstanzen. Dieser Informationsfluss erfolgt über die
in Abb. 2.5 ersichtliche Rückkopplung durch Auslastungsereignisse. Die Komponente Operator -
Platzierung berechnet aus den Laufzeitinformationen eine neue Platzierung bzw. Zuordnung der
Operatorinstanzen. Im Nachfolgenden wird dieser Teil der Operator - Platzierung als Laufzeitplat-
zierung bezeichnet. In Abschnitt 2.3.3 werden die Konzepte der Berechnung einer Platzierung nä-
her besprochen. In Bezug auf die genannten Aufgaben sieht der Prototyp einen zentralen Ansatz
24 Kapitel 2 Hintergrundvor. D. h. es werden alle notwendigen Informationen gesammelt und an einer zentralen Stelle
verwaltet und ausgewertet. Mit Wirtschaftlichkeit und Kosteneffizienz ist neben der Elastizität
ein weiteres wichtiges Ziel gesetzt. Die Berechnung sowie die Überwachung der entstehenden
Kosten soll zum Einen Transparenz und zum Anderen eine potentielle Minimierung dieser ermög-
lichen. Grundlage bildet ein generisches Kostenmodell, welches in Abschnitt 2.3.4 beschrieben
wird. Im anschließenden Abschnitt 2.3.5 wird die Fragestellung zum Thema Kosteneffizienz dis-
kutiert, welche durch die vorliegende Arbeit beantwortet werden soll.
Zusammenfassend sind die wesentlichen Aspekte, welche durch den Prototypen abgedeckt wer-
den: Anfrage - Optimierung, Operator - Platzierung sowie die in dieser Arbeit zu untersuchende
Kosteneffizienz. Nachfolgend werden diese Aspekte vorgestellt und deren Relevanz für die vor-
liegende Arbeit besprochen.
2.3.2 Anfrage - Optimierung
Der Prototyp verwaltet eine Menge von Anfragen durch einen globalen Graphen (vgl. Abschnitt
2.1 ). Dieser Graph ist dynamisch und ändert sich durch Hinzufügen oder Entfernen von Anfragen
zur Laufzeit. Dabei stellt sich die Frage, wie Anfragen im System repräsentiert und speziell wie
neu hinzukommende Anfragen in den globalen Graphen eingefügt werden können. Letzteres
wird als Query Merging bezeichnet. Es ist wahrscheinlich, dass neu hinzukommende Anfragen
mit Teilen des bestehenden globalen Graphen überlappen und somit Teilergebnisse wiederver-
wendet werden können. Folglich werden Ressourcen effizienter genutzt. Diese Optimierung des
globalen Graphen wird in [Ji11] als Multi Query Optimization (MQO) bezeichnet.
[Ji11] stellt einen inkrementellen, konservativ erweiternden Ansatz vor und optimiert diesen hin-
sichtlich Effizienz und Skalierbarkeit. Abb. 2.6 verdeutlicht das Prinzip des inkrementellen Hin-
zufügens einer Anfrage. Im oberen Teil der Abbildung ist der globale Anfragegraph dargestellt,
welcher sämtliche im System laufenden Anfragen umfasst. Der untere Teil der Abbildung zeigt
die neu hinzukommende Anfrage ebenfalls als Graph. Der MQO - Algorithmus sucht im globalen
Graphen nach einer größtmöglichen Überlappung mit der neuen Anfrage. Im Beispiel besteht
der größtmögliche Teilgraph, welcher wiederverwendet werden kann, aus der Ereignisquelle Q3
sowie dem nachfolgendem Filter Operator F3. Die Suche basiert auf dem Vergleich der Eigen-
schaften der Ereignisströme. Z. B. ist eine Eigenschaft des ausgehenden Ereignisstroms eines
Filter - Operators, dass dieser lediglich Ereignisse enthält, welche dem Filter genügen.
Globaler Anfragegraph
Merge-Punkt
neue Anfrage
Ereignisstrom Operator
Abbildung 2.6: Beispiel für die Anfrage - Optimierung
2.3 Prototyp 25[Ji11] untersucht Ereignisströme dabei nicht nur auf Gleichheit, sondern auch auf eine etwaige
Teilmengenbeziehung (Subsumption). Dadurch lässt sich eine hohe Wiederverwendung errei-
chen, selbst dann, wenn sich die Ereignisströme nicht vollständig gleichen. Effizienz erreicht
[Ji11] durch verschiedene Strategien. So werden Ereignisströme auf die Menge der erzeugenden
Ströme (Basisströme) abgebildet. Die Idee dahinter ist, dass zwei Ereignisströme nur dann ver-
glichen werden müssen, wenn diese aus der selben Menge von Basisströmen gebildet wurden.
Dadurch wird der Suchraum wesentlich verkleinert. Weiterhin werden Indizes, Tabellenstrukturen
und Hash - Kodierung verwendet um die Geschwindigkeit der Suche zu erhöhen.
Der in [Ji11] ausgearbeitete MQO - Ansatz reduziert den Ressourcenverbrauch durch Wiederver-
wendung von Operatoren und minimiert somit die monetären Kosten. Der Nutzen erhöht sich
dabei mit zunehmender Laufzeit der Anfragen. Der MQO - Algorithmus wird vor der Initialen Plat-
zierung neuer Anfragen aufgerufen und spielt für die Laufzeitplatzierung keine unmittelbare Rolle.
In der vorliegenden Arbeit soll der bestehende Algorithmus wiederverwendet und ggf. angepasst
werden.
2.3.3 Operator - Platzierung
Generell unterscheidet die Operator - Platzierung zwei Szenarien. Zum Einen müssen neue An-
fragen, welche durch die Anfragen - Optimierung bereits im globalen Graphen eingefügt wurden,
auf verfügbare Ressourcen verteilt werden. Ggf. müssen neue Ressourcen allokiert werden.
Dies wird als Initiale Platzierung bezeichnet. Zum Anderen soll eine dynamische Platzierungs-
strategie (Laufzeitplatzierung) eine elastische Skalierung ermöglichen. Wie bereits unter dem
Punkt Elastizität in 2.2 beschrieben, ist eine Abbildung auf unterschiedlichen Ebenen möglich.
Der bestehende Prototyp setzt eine feingranulare Skalierung auf Operator - Ebene um. Es erfolgt
eine Zuordnung von Operatorinstanzen auf Rechnerknoten in der Cloud. Die (logischen) Operato-
ren, aus denen einen Anfrage besteht, werden im Sinne einer parallelen Verarbeitung durch eine
Menge semantisch equivalenter Operatorinstanzen in der Cloud repräsentiert. Die Verarbeitung
der eintreffenden Ereignisse verteilt sich auf diese Operatorinstanzen. Abb. 2.7 skizziert das Pro-
blem der Zuordnung bzw. Platzierung sowohl für die Initiale als auch für die Laufzeitplatzierung. In
den nachfolgenden zwei Abschnitten werden diese separat diskutiert. Diese Trennung zwischen
Initialer und Laufzeitplatzierung wird weiterhin in den nachfolgenden Kapiteln und Abschnitten
fortgesetzt.
(globaler) Anfragegraph CEP in der Cloud
c
...
logischer Operator
a
b
Knoten1 Knoten2 Knoten3
Operatorinstanzen von F2
Ereignisstrom Operator
Abbildung 2.7: Darstellung des Problems der Platzierung von Operatoren
26 Kapitel 2 HintergrundInitiale Platzierung
Aufgabe der Initialen Platzierung5 ist die durch den Benutzer hinzugefügte Anfrage in der Cloud
zu platzieren. Da im Vorfeld immer eine Optimierung durch den MQO - Algorithmus vorgenom-
men wird, müssen lediglich diejenigen Operatoren der neuen Anfrage platziert werden, welche
nicht durch Überlappung mit dem globalen Graphen wiederverwendet werden können. Für die
Initiale Platzierung stellt sich vor Allem das Problem, dass im Vorfeld die Auslastung der neu hin-
zukommenden Operatoren unbekannt ist. Aus diesem Grund ist keine exakte Berechnung der
Anzahl der tatsächlich notwendig werdenden Ressourcen möglich. Als Lösung untersucht [Ji11]
verschiedene Strategien um die Auslastung der neu hinzukommenden Operatoren abzuschätzen.
Zum Einen ist dies eine auf Sampling basierende Methode, welche eine Menge von Samples aus
realen Ereignissen abspielt und die Auslastung misst. Zum Anderen ist dies eine Schätzmethode,
welche auf Basis von Messungen der Bearbeitungszeit eines Ereignisses sowie der Ereignisrate
die Auslastung für den Worst - Case Zustand ableitet. Basierend auf den ermittelten geschätzten
Auslastungswerten kann die Frage für die Abbildung der logischen Operatoren auf Operatorin-
stanzen beantwortet werden (vgl. Abb. 2.7 a ). Nachdem die Anzahl der Operatorinstanzen pro
logischem Operator feststeht, muss eine Zuordnung auf physikalische Ressourcen bzw. Rechner-
knoten erfolgen (vgl. Abb. 2.7 b ). Dieses Problem lässt sich als eindimensionales Bin - Packing
beschreiben und wird im Abschnitt 2.3.3 vorgestellt. Nach der Berechnung der Zuordnung wer-
den die Operatorinstanzen in der Cloud platziert. Die neue Anfrage liefert anschließend gemäß
ihrer Deklaration Ergebnisse über die eingehenden Ereignisströme.
Die Initiale Platzierung erzielt im Allgemeinen kein Optimum in Bezug auf eine effiziente Ressour-
cennutzung. Durch die Messung der Auslastung zur Laufzeit kann eine anschließende Laufzeit-
platzierung und somit eine Optimierung erfolgen.
Laufzeitplatzierung
Die Laufzeitplatzierung6 befasst sich mit der Umstrukturierung und Migration von Operatorenin-
stanzen innerhalb der Cloud mit dem Ziel, eine elastische Skalierung zu ermöglichen und Ressour-
cen effizienter zu nutzen (vgl. Abb. 2.7 c ). Die Platzierung basiert auf der Messung von Laufzei-
tinformationen zur Ressourcennutzung, welche in Form von Auslastungsereignissen übermittelt
werden. In regelmäßigen Abständen wird erfolgt die Laufzeitplatzierung um eine Anpassung ent-
sprechend der Dynamik im CEP System vorzunehmen. Das Problem gestaltet sich ähnlich der
Initialen Platzierung als Bin - Packing mit dem Unterschied, dass sämtliche im System platzierten
Operatorinstanzen Gegenstand der Berechnung sind. Ziel ist es, die Operatorinstanzen so zu
verteilen, dass so wenig wie möglich Ressourcen verwendet werden. Die Laufzeitplatzierung un-
terteilt sich in zwei Schritte. Zunächst werden stark ausgelastete Rechnerknoten identifiziert und
eine entsprechende Teimenge von Operatorinstanzen auf andere Knoten migriert. Ggf. erfolgt
an dieser Stelle eine Aufwärtsskalierung, indem neue Rechnerknoten angefordert werden. Nach
diesem Schritt sind keine Rechnerknoten bezüglich der CPU -Auslastung überlastet. Im anschlie-
ßenden Schritt wird versucht, Operatorinstanzen so zu verteilen, dass möglichst viele Ressourcen
freigegeben werden können (Abwärtsskalierung).
5 in [Ji11] als Initial Placement bezeichnet
6 in [Ji11] als Runtime Placement bezeichnet
2.3 Prototyp 27Bin - Packing
Bin - Packing kann der kombinatorischen Optimierung zugeordnet werden und beschreibt allge-
mein das Problem eine Menge von Objekten unterschiedlicher Größe auf eine minimale Anzahl
von Behälter zu verteilen, ggf. unter Berücksichtigung von festgelegten Bedingungen [CGJ97]
Die zuvor beschriebene Frage nach einer geschickten Zuordnung von Operatorinstanzen zu Rech-
nerressourcen kann als eindimensionales Bin - Packing betrachtet werden. Dabei entsprechen
die Rechnerressourcen den Behältern, die Objekte den Operatorinstanzen und die Eigenschaft
der Größe der CPU -Auslastung. Weitere Bedingungen, wie z. B. das Einhalten der maximal ver-
fügbaren Netzwerkbandbreite, werden explizit geprüft bevor eine Zuordnung getroffen wird. Im
Prototypen sind acht verschiedene Varianten des Bin - Packing Algorithmus implementiert. Diese
lassen sich unterteilen in First - Fit und Best - Fit Bin - Packing. Die First - Fit (FF) Strategie wählt
den ersten Rechnerknoten, welcher den festgelegten Bedingungen genügt. Best - Fit (BF) hinge-
gen wählt aus sämtlichen potentiellen Rechnerknoten, denjenigen aus, der nach einer Platzierung
den geringsten Wert der noch verbleibenden Auslastung hat. Dadurch wird die Nutzung der
Ressourcen maximiert. Im Weiteren gibt es die (nicht exklusiven) Ausprägungen Decreasing (D)
und Prioritized (P). Erstere ordnet die Operatorinstanzen nach abnehmender Auslastung, so dass
zuerst eine Zuordnung für Instanzen mit großer Auslastung erfolgt. Letztere berücksichtigt Nach-
barschaftsbeziehungen der Operatorinstanzen mit dem Ziel, die Netzwerkauslastung sowie die
Ende - zu - Ende Latenz zu reduzieren. Die acht implementierten Strategien sind: FF, FFD, FP,
FFDP, BF, BFD, BDP, BFDP.
2.3.4 Kostenmodell
Grundlage für die Adaption und letztendlich die Minimierung der monetären Kosten ist ein generi-
sches Berechnungs- sowie Preismodell. Gemäß der Pay - per - Use - Philosophie und den Vertrags-
bedingungen des Cloud - Anbieters entstehen Kosten für das laufenden Cloud - basierte CEP -
System. Die Anbieter unterscheiden sich u. a. in der Menge der verfügbaren Ressourcentypen
sowie der Abrechnung der Nutzung dieser. Der bestehende Prototyp abstrahiert von einem kon-
kreten Anbieter, da ein allgemein gültiger (generischer) Ansatz gefordert ist. Im Folgenden wird
dieses Kostenmodell mit den für die vorliegende Arbeit relevanten Details vorgestellt.
Mit dem Ziel, ein generisches Kostenmodell zu formulieren, untersucht [Mey12] Preismodelle
verschiedener Cloud - Anbieter. Das ausgearbeitete und in dem Prototyp verwendete Preismo-
dell legt eine Normierung auf feste Bezugsgrößen fest, welche in der nachfolgenden Auflistung
angegeben ist.
• Kosten für die Nutzung eines CPU -Kerns pro Stunde
• Kosten für die Nutzung von 1 GB Arbeitsspeicher pro Stunde
• Kosten für ein- sowie ausgehender Netzwerkverkehr pro GB
• einmalige Fixkosten
Die Gesamtkosten ergeben sich als Summe der eben aufgelisteten Einzelkosten. Die Berechnung
der monetären Kosten erfordert die Angabe eines Gegenstands, eines konkreten Preismodells
sowie eines Zeitbezugs. Gegenstand der Berechnung kann u. a. ein logischer Operator, eine ein-
zelne Anfrage oder der gesamte Anfragegraph sein. Je nachdem sind die Kosten anteilig, relativ
bezogen zu den Gesamtkosten oder absolut. Der Zeitbezug definiert die Zeitspanne (eine Mi-
nute, eine Stunde u. a. ), in der die Ressourcennutzung abgerechnet werden soll. Das konkrete
Preismodell bildet die Konditionen eines speziellen Anbieters auf dem generischen Preismodell
ab. Diese Abbildung besteht insbesondere aus der Normierung auf die bereits genannten Be-
zugsgrößen.
28 Kapitel 2 HintergrundDie Ressourcennutzung wird über Laufzeitmessungen oder durch eine Schätzung ermittelt. Die
Laufzeitmessung wird in Form von Auslastungsereignissen propagiert. Diese Auslastungsereig-
nisse enthalten u. a. Informationen über die Auslastung bzw. Nutzung der Ressourcen CPU,
Arbeitsspeicher sowie Netzwerk und beziehen sich auf eine Operatorinstanz. Des Weiteren wird
auch die Zuordnung einer Operatorinstanz zu einem Rechnerknoten übermittelt. Ein Abbild des
aktuellen Laufzeitzustands sämtlicher Operatorinstanzen ist durch die Menge der letzten Ausla-
stungsereignisse gegeben. Dieses Abbild zusammen mit der Information über die Anfragen im
System wird als Momentaufnahme verstanden und bildet eine wesentliche Grundlage für die Be-
rechnung der monetären Kosten. Abb. 2.8 zeigt eine Momentaufnahme von zwei Rechnerknoten
in der Cloud. Auf den Rechnerknoten sind Operatorinstanzen der Anfragen 1,2 und 3 platziert.
Die Zugehörigkeit ist in der Abbildung farbig dargestellt. Für die Ressourcen CPU, Arbeitsspeicher
sowie Netzwerk sind die aktuellen Auslastungen angegeben. Wie dargestellt, verteilt sich die
Gesamtauslastung auf sämtliche auf dem Knoten platzierten Operatorinstanzen. So verteilt sich
beispielsweise die CPU - Auslastung von 50% auf Rechnerknoten 1 mit 25%, 15% und 10% auf
drei Operatorinstanzen. Entsprechend ergeben sich die Kosten für eine Operatorinstanz anteilig
aus den Gesamtkosten für den Rechnerknoten, auf dem dieser läuft. Cloud Anbieter berech-
nen letztendlich die Nutzung des kompletten Rechnerknotens, unabhängig von der tatsächlichen
Auslastung auf diesem. Dies bedeutet wiederum, dass bei der Berechnung der relativen Kosten
eine Skalierung der Gesamtauslastung eines Knotens auf 100% erfolgen muss. Z. B. werden die
Kosten bezüglich der CPU - Auslastung der ersten Operatorinstanz (von links) auf Rechnerknoten
1 nicht mit 25% sondern mit 50% berechnet.
Rechnerknoten 1 Rechnerknoten 2
CPU CPU
CPU
CPU
PCPU PCPU
RAM RAM
RAM
RAM
PRAM PRAM
Netzwerk
Netzwerk
Netin Netin
Netout Netout
Anfrage 1 Anfrage 2 Anfrage 3
Abbildung 2.8: Erklärung der Kostenberechnung
Oftmals ist die Frage nach den Kosten einer speziellen Anfrage (für den Benutzer) von Interesse.
Diese können als Summe der Kosten der einzelnen Operatorinstanzen berechnet werden. Dabei
ist zu beachten, dass Operatorinstanzen von mehreren Anfragen gemeinsam verwendet werden
können. Dies ist durch die mit der Anfrage - Optimierung erzielten Wiederverwendung möglich.
In diesem Fall werden die Kosten der betreffenden Operatorinstanz zu gleichen Teilen auf die
Anfragen verteilt.
Weiterhin kann auch der gesamte globale Anfragegraph Gegenstand der Kostenberechnung sein.
Dies entspricht der Summe der Kosten sämtlicher im System laufenden Anfragen. Die Kosten-
berechnung ist Grundlage für den Vergleich von Kosten und somit auch der Minimierung dieser.
2.3 Prototyp 292.3.5 Kosteneffizienz
Ziel der vorliegenden Arbeit ist die Steigerung der Kosteneffizienz durch eine geeignete Adaption
des bestehenden Prototypen. Die Adaption erfolgt dabei über eine Parametrisierung der Plat-
zierung. Die Wahl der Parameterkonfiguration beeinflusst die entstehenden monetären Kosten
und somit die Kosteneffizienz. Der bestehende Prototyp arbeitet mit einer statischen Parameter-
konfiguration, welche zur Laufzeit unverändert bleibt. Die Konfiguration ist mit Standardwerten
gewählt und ist in Bezug auf Kosteneffizienz nicht für alle potentiell möglichen Konstellationen
des sich ändernden Systemzustands optimal.
Abb. 2.9 verdeutlicht das zu lösende Problem der geeigneten Parameterwahl anhand hypothe-
tischer Kostenverläufe, welche sich aus verschiedenen Parameterkonfigurationen ergeben. Die
Darstellung vergleicht für drei unterschiedliche Parameterkonfigurationen die Kostenentwicklun-
gen über einen festgelegten Zeitraum. Die Kurven sind dabei Annahmen und dienen nur zur
Erklärung des Problems. Des Weiteren sind aus Gründen der Darstellung nur drei Konfiguratio-
nen aus der ggf. sehr großen Menge an Parameterkonfigurationen abgebildet. Die Abbildung
zeigt, dass keine Parameterkonfigurationen zu allen Zeitpunkten optimal bezüglich der Kosten ist.
Aufgabe der Adaption ist zu festgelegten Zeitpunkten möglichst effizient eine gute Parameter-
konfiguration zu ermitteln. In Abb. 2.10 sind die minimalen Kosten aufgetragen. Die Adaption
versucht durch Rekonfiguration des Systems die entstehenden Kosten in Richtung dieses Mini-
mums zu verschieben.
An dieser Stelle soll der Begriff Kosteneffizienz näher erläutert werden. Allgemein bezeichnet Ef-
fizienz das Verhältnis zwischen Nutzen und Aufwand und wird nachfolgend unter dem Aspekt der
Wirtschaftlichkeit behandelt. Der Aufwand ist durch die Berechnung und Durchführung der Adap-
tion gegeben, der Nutzen entsprechend durch die potentiell mögliche Kostenreduktion. Gleichung
2.1 verdeutlicht diesen Zusammenhang.
cohne − cmit
ξ= (2.1)
cAdaption
Die monetären Kosten einer Umsetzung ohne Adaption sind mit cohne , die Kosten nach der hy-
pothetischen Durchführung einer Adaption sind mit cmit gegeben. Die mögliche Kostenersparnis
entspricht der Differenz der beiden Kostenwerte. Demgegenüber stehen die Kosten, welche für
die Berechnung und Durchführung der Adaption aufgewandt werden müssen. Diese sind mit
cAdaption bezeichnet. Das angegebene Verhältnis ξ ist ein Maß für die Kosteneffizienz. Ist ξ < 1
sollte eine Adaption verworfen werden, da die Kosten für die Adaption höher sind als deren Nut-
zen. Ist ξ = 1 spricht man von Kostendeckung. Mit ξ > 1 ist ein wirtschaftlicher Vorteil gegeben,
wenn die Adaption durchgeführt wird. Die Gleichung 2.1 ist nur eine vereinfachte Betrachtung der
Zusammenhänge. So ist es allgemein schwierig eine Aussage über die Qualität einer ermittelten
Adaption zu machen, da berücksichtigt werden muss, dass sich das System dynamisch ändert.
Mit dem bestehenden Prototypen existiert, zum Zeitpunkt der Erstellung der vorliegenden Ar-
beit, keine Methode die Kosten cAdaption zu berechnen. Des Weiteren ist keine Aussage über
das zukünftige Verhalten des Systems in Form einer Prognose möglich. Eine Untersuchung die-
ser beiden Sachverhalte wird in der vorliegenden Arbeit nicht angestrebt. Es werden aus diesem
Grund folgende Annahmen getroffen: Die Kosten für eine Adaption werden als vernachlässigbar
klein angenommen. D. h., dass für die Entscheidung der Durchführung einer Adaption lediglich
die Kostendifferenz cohne − cmit betrachtet wird. Des Weiteren wird eine gewisse Stabilität des
Systemverhaltens in Bezug auf die entstehenden Kosten angenommen. Mit diesen Einschrän-
kungen ist die Adaption auf Basis einer Momentaufnahme (vgl. 2.2.2) möglich.
30 Kapitel 2 HintergrundAbbildung 2.9: Kosten in Abhängigkeit der Parameterkonfiguration
Abbildung 2.10: Minimal zu erreichende Kosten
2.3 Prototyp 3132 Kapitel 2 Hintergrund
3 VERWANDTE ARBEITEN
Sie können auch lesen
