Konzeption und Analyse einer skalierbaren Architektur für Social Media Streams

Größe: px
Ab Seite anzeigen:

Download "Konzeption und Analyse einer skalierbaren Architektur für Social Media Streams"

Transkript

1 Technische Universität Dresden Professur für Rechnernetze Konzeption und Analyse einer skalierbaren Architektur für Social Media Streams erstellt von: Bill Martin geboren am in Dresden Studiengang: Diplom Informatik Matrikelnummer: Verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Betreuer: Dr.-Ing. Marius Feldmann Dipl. Inf. Torsten Lunze Bearbeitungszeitraum:

2 ii

3 Inhaltsverzeichnis 1. Einleitung Motivation Ziele der Arbeit Gliederung Grundlagen Social Media Die typische 3-Schichten-Architektur Denition Skalierbarkeit Horizontake Skalierbarkeit Vertikale Skalierbarkeit Vor- und Nachteile einer horizontalen und vertikalen Skalierung Dimensionen der Skalierbarkeit Skalierungsstrategien Horizontale Skalierung der Anwendungsschicht Horizontale Skalierung der Datenschicht Systeme zur Umsetzung einer skalierbaren Architektur Hazelcast RabbitMQ ActiveMQ ejabberd Node.js Scribe Weitere Systeme Architektur Best Practices von Social-Media-Diensten Twitter Facebook LinkedIn Fazit und Zusammenfassung iii

4 iv Inhaltsverzeichnis 3. Anwendungsfälle, Anforderungen und Problemanalyse Häug genutze Funktionen von Social-Media-Anwendungen Detaillierte Beschreibung der Anwendungsfälle Anwendungsfalldiagramm Anforderungen Funktionale Anforderungen Nicht-Funktionale Anforderungen Probleme verbreiteter Realisierungen der 3-Schichten-Architektur Probleme verbreiteter Realisierungen der 3-Schichten-Architektur im Kontext von Social Media Vorabanalyse Lasttests Beschreibung und Testsetup Ergebnisse Zusammenfassung Nicht performancebezogener und subjektiver Vergleich der Systeme RabbitMQ Scribe Node.js Hazelcast ejabberd ActiveMQ Zusammenfassung Auswahl zur Umsetzung einer skalierbaren Architektur Konzeption Grundlegende Architektur Architektur mit lokalem Cache Architektur mit verteiltem Cache Konzeptdetails der Architektur Schnittstellen des Systems Datenmodell des Caches Evaluation der Architektur Ziel der Evaluation Test- und Analysewerkzeuge Testumgebung

5 Inhaltsverzeichnis v Testsetup Testvorbereitung Testszenarien Evaluation Implementierung Übersicht Die Core-Komponente Die Store-Komponente Das Datenmodell des Caches Die Message-Komponente Vorstellung der Ergebnisse der Evaluation Ergebnisse Vergleich der Architekturen bezüglich der Erfüllung der Anforderungen Schlussfolgerung Zusammenfassung und Ausblick Zusammenfassung Ausblick Erweiterung der Implementierung Erweiterung der Architektur Erweiterung der Testdurchführung Einsatz der Architektur im Produktivsystem A. Anhang 101 A.1. Lasttestergebnisse mit verteiltem Cache A.2. Lasttestergebnisse mit lokalem Cache und Message-Queue-Invalidierung105 Abbildungsverzeichnis 110 Tabellenverzeichnis 111 Literaturverzeichnis 113

6 vi Inhaltsverzeichnis

7 Kapitel 1. Einleitung 1.1. Motivation Beim Super Bowl 2012, welcher am zwischen den New York Giants und den New England Patriots in Indianapolis stattfand, wurden in den letzten drei Spielminuten der Partie mehr als Twitternachrichten pro Sekunde geschrieben [12]. Anhand dieser gewaltigen Anzahl von verfassten Nachrichten lassen sich drei unterschiedliche Erkenntnisse ableiten. Zum einen welchen Stellenwert Social Media momentan bei den Menschen im täglichen Leben erreicht hat, Millionen von Menschen nutzen Twitter, um ihre Gedanken anderen Menschen mitzuteilen. Zum anderen müssen sich Social Media Dienste der Herausforderung stellen, diese Nutzerzahlen in Zukunft immer öfter konfrontiert und noch weiter wachsen zu sehen. Die letzte Schlussfolgerung, die daraus gewonnen werden kann, ist, dass Twitter eine Architektur und Infrastruktur besitzt, die es ermöglicht einen solchen Nutzer- und Nutzungsansturm erfolgreich standzuhalten. Social-Media-Technologien haben jedoch nicht nur im privaten Umfeld einen hohen Stellenwert, sondern gewinnen auch in Unternehmen immer stärker an Bedeutung. So werden Wikis für Kollaboration und Wissensmanagement genutzt und Microblogging löst, aufgrund des einfachen Informationsaustausches, herkömmliche Informationsmedien wie in vielen Bereichen ab. Zudem werden Activity Streams von externen Systemen eingespeist. Mit steigender Nutzung in gröÿeren Unternehmen fordert ein Social-Media-Dienst eine skalierbare Architektur, um der Menge von Aktivitäten und Informationen besser gewappnet zu sein. Eine Möglichkeit einer Vielzahl von Anwendern Herr zu werden, ist die Verteilung der Zugrislast auf verschiedene Systeme, um so kurze Antwortzeiten zu garantieren. In den heutigen, evolutiv gewachsenen Architekturen zur Realisierung von Social- Media-Anwendungen bildet häug die Datenbank den Flaschenhals hinsichtlich der 1

8 2 Kapitel 1. Einleitung Verarbeitungsgeschwindigkeit und des daraus resultierenden Durchsatzes. Im Unternehmensumfeld werden zur Speicherung der Daten meist relationale Datenbanken verwendet. Diese sind jedoch für die massiven Anfragen von sehr vielen Nutzern in dem Ausmaÿ nicht konzipiert worden. Eine Substitution dieser Datenbanken durch alternative Konzepte wie zum Beispiel NoSQL kann durch die starke Integration in die Gesamtinfrastuktur eines Unternehmens nur in den wenigsten Fällen durchgeführt werden. Eine Lösung bietet hier der Ansatz des Cachings. Dieser ermöglicht das Zwischenspeichern der Daten in einem schnellen aber üchtigen Speicher. Die Einführung des Cachings führt dazu, dass viele Anfragen auf dem Cache ausgeführt werden und so die Datenbank entlastet werden kann. Zusätzlich können mit dem Cache kurze Antwortzeiten garantiert werden, da der Zugri auf einen schnellen Speicher erfolgt. Zur Umsetzung eines Caches in der Architektur ergeben sich zwei Möglichkeiten. Zum einen die lokale Integration auf dem Anwendungsserver zum anderen eine dezentrale Cachekomponente, auf die von allen Anwendungsserver gleichwertig zugegrien werden kann. Damit alle Anwendungsserver beim Architekturansatz mit dem lokalen Cache über einen konsistenten Datensatz verfügen, muss eine Kommunikation zwischen den Servern erfolgen, um sich über Änderungen von Cacheeinträgen auszutauschen. Ein weitverbreiteter Ansatz zur lose gekoppelten Kommunikation zwischen Servern bietet der Message-Queue-Ansatz Ziele der Arbeit Zentrales Ziel dieser ist es zwei unterschiedliche horizontal skalierbare Architekturen, basierend auf der Möglichkeit zur Verwendung eines lokalen bzw. dezentralen Cache, zu konzipieren und ihre Chrakteristiken zu untersuchen. Diese Architekturen sollen durch Hinzufügen von weiteren Systemen die entstehende Last durch wachsende Benutzerzahlen verteilen, um so Echtzeitanforderungen in modernen Social-Media-Systemen zu erfüllen. Ein weiterer positiver Eekt solcher Architekturen ist die Erhöhung der Zuverlässigkeit und Verfügbarkeit.

9 1.3. Gliederung 3 Aus dem zentralen Ziel ergeben sich konkrete Teilziele, aus denen Anforderungen an die jeweilige Architektur deniert werden. Diese bilden die Grundlage für die Konzeption und Analyse sowie der Erreichung der folgenden Ziele: 1. Die Verwendung des Caches soll die Antwortzeiten der durchgeführten Anfragen deutlich verkürzen und so den Durchsatz des Gesamtsystems steigern. Die Fragestellung, welche Zeit vergeht bis das System dem Nutzer eine Rückmeldung zu einer getätigten Anfrage zusendet und wie groÿ der Durchsatz der jeweiligen Architektur, bei steigender Nutzerzahl, durch den Einsatz des Caches ist, bildet eine der zentralen Untersuchungsgegenstände dieser Arbeit. 2. Die wachsende Menge der Daten im Cache, die durch steigende Nutzerzahlen und die Länge der Laufzeit des Systems entstehen, sollen durch eine Verteilung auf mehrere Server gleichmäÿig erfolgen, sodass alle Anwendungsserver einheitlich ausgelastet sind. Wie die Verteilung der Auslastung auf die Server erfolgt, gilt es in dieser für die zwei Architekturen zu analysieren. 3. Bei steigender Nutzerzahl und der daraus unter Umständen resultierenden Verteilung der Nutzer auf mehrere Server soll möglichst schnell ein konsistenter Zustand des Gesamtsystems hergestellt werden. Einer der zentralen Gegenstände der Arbeit ist die Feststellung wie schnell das Gesamtsystem jeweils einen konsistenten Zustand einnehmen kann Gliederung Zu Beginn dieser wird auf notwendige Grundlagen für das Verständnis eingegangen. Dabei werden einige Begrie herausgearbeitet und erläutert. Es werden ebenfalls Skalierungsstrategien und verschiedene Produkte zur Umsetzung einer skalierbaren Architektur vorgestellt. Beispiele existierender Architekturen werden abschlieÿend in diesem Kapitel behandelt. Im Kapitel 3 werden anschlieÿend Anwendungsfälle und Anforderungen von Social Media Diensten vorgestellt. Dabei werden die häugsten Anwendungsfälle herausgegrien und als Anforderungen deniert. Zum Schluss wird hier auf die Probleme von evolutiv gewachsenen Realisierungen von Social-Media-Diensten eingegangen. Nachdem in dem Grundlagenkapitel 6 verschiedene Produkte zur Umsetzung einer skalierbaren Architektur vorgestellt wurden, wird nun im 4. Kapitel eine Vorabanalyse anhand dieser Produkte durchgeführt. Dabei werden die Produkte einem Lasttest unterzogen und die gewonnenen Ergebnisse verglichen.

10 4 Kapitel 1. Einleitung Den Hauptteil der vorliegenden bilden die Kapitel 5 und 6. In diesen wird sowohl die Konzeption als auch die Umsetzung der Architektur und deren Bewertung thematisiert. Als abschlieÿendes Kapitel dient Kapitel 7, um die Ergebnisse und Erkenntnisse zusammenzufassen und einen Ausblick auf weitere Entwicklungen und Überlegungen zu liefern.

11 Kapitel 2. Grundlagen 2.1. Social Media Das Web 2.0 stellt aus rein technischer Sicht keine groÿartige Neuerung oder völlige Überarbeitung des World Wide Web dar [22]. Viele der Technologien und enthaltenen Ansätze existieren schon seit Jahren. Vielmehr ist es ein Ausdruck der veränderten Wahrnehmung altbekannter Techniken [22]. Zentrales Merkmal der sozialen Medien ist die aktive Teilhabe der zuvor passiven Nutzer an der Gestaltung von Internetauftritten [9]. Oft tritt im Zusammenhang von Social Media der Begri Social Software auf oder wird synonym verwendet. Dabei ist Social Software in der Regel ein Softwaresystem zur Unterstützung der menschlichen Kommunikation, Interaktion und Zusammenarbeit [22]. Webanwendungen wie Webblogs, Wikis, Flickr oder soziale Netzwerke wie Facebook oder Xing werden im engeren Sinn als Social Software bezeichnet [22]. Im Gegenzug dazu setzt der Begri Social Media die in sozialen Kommunikationsund Interaktionsbeziehungen eingesetzten neuen Medien in den Vordergrund [22]. Persönliche Beitrage, Texte, Bilder, Videos zur Interaktion sowie deren zugrunde liegenden und unterstützenden Dienste werden mit Social Media umschrieben [22] Die typische 3-Schichten-Architektur Die herkömmliche und klassische 3-Schichten Architektur gliedert sich in die Präsentationsschicht, Anwendungs-/Logikschicht und Datenschicht. Die Einteilung der Architektur in diese Schichten erlaubt es, jede der drei Schichten unabhängig voneinander im Zuge eines Anforderungs- oder Technologiewandels aufzurüsten oder zu ersetzen. Zudem bietet es den Vorteil der verringerten Client-Ausstattung, da die Logik in der Anwendungsschicht ausgeführt wird. So können einfache Clients, wie 5

12 6 Kapitel 2. Grundlagen Abbildung 2.1.: 3-Schichten-Architektur zum Beispiel Browser, als Präsentationsschicht genutzt werden [7]. In der Abbildung 2.1 ist die 3-Schichten Architektur dargestellt. Die Aufgabe der Präsentationsschicht ist die Interaktion mit dem Benutzer des Systems. Diese übersetzt Aufgaben und Ergebnisse in eine nutzerverständliche Repräsentation. Die Anwendungs- bzw. Logikschicht beherbergt Anwendungen, Prozesse und Befehle. Diese Schicht ist verantwortlich für Entscheidungen, Bewertungen und Durchführungen von Berechnungen. Sie ist ebenfalls für den Transport der Daten zwischen den beiden benachbarten Schichten zuständig. Die Datenschicht speichert und lädt die Daten der Anwendung. Der typische Informations- und Datenuss wird vom Nutzer über die Benutzerschnittstelle der Präsentationsschicht initiiert. Diese ruft eine Funktion in der Anwendungsschicht auf, welche sodann eine Anfrage an die Datenschicht stellt. Das Ergebnis dieser Anfrage wird von der Datenschicht an die Anwendungsschicht zurückgegeben. Diese kann mit dem Ergebnis nun weitere Berechnungen durchführen oder einfach an die Präsentationsschicht weiterleiten. Die Präsentationsschicht wandelt das Ergebnis in eine nutzerverständliche Ausgabe um und stellt diese anschlieÿend dar Denition Skalierbarkeit In den letzten zehn Jahren haben wir eine komplette Ersetzung von Ein- Prozessorsystemen durch Mehrprozessorsysteme beobachten können. Diese Entwicklung startete schon in den 80iger Jahren in wissenschaftlichen und technischen Berei-

13 2.3. Denition Skalierbarkeit 7 chen und setzte sich Mitte der 90er Jahre im Massenmarkt durch. Dabei kann man zwei verschiedene Ansätze vollziehen, um ein Mehrprozessorsystem zu erstellen. Zum einen die Entwicklung von Anwendungen auf groÿen Shared-Memory-Servern, dem sogenannten Scale-up. Zum anderen die Entwicklung von Anwendungen auf einer Vielzahl von normalen Servern, welche über ein Verbindungsnetzwerk verbunden sind, das Scale-out. [31] Synonym für die Begrie Scale-out und Scale-up werden die Bezeichnungen horizontal bzw. vertikal verwendet. Diese beiden Begrie werden nachfolgend genauer beschrieben und anschlieÿend im Hinblick auf ihre Eigenschaften und Vorund Nachteile gegenübergestellt Horizontake Skalierbarkeit Ein System skaliert horizontal, wenn es durch Hinzufügen von zusätzlichen Knoten mit identischer Funktionalität erweitert werden kann, um die Gesamtlast auf die neuen und vorhandenen Knoten zu verteilen. Bei der horizontalen Skalierung von Webservern dienen die hinzugefügten Server dazu, die eingehenden Anfragen gleichmäÿig auf alle Knoten zu verteilen. Cluster ist ein gebräuchlicher Begri, um ein skalierbares System zu beschreiben. [8] Ein Cluster ist kostenezienter als ein monolithisches System mit der gleichen Leistung. Die Systeme in einem Cluster sind über ein High-Speed Verbindungsnetz, wie Gigabit Ehternet oder Inniband miteinander verbunden.[8] Vertikale Skalierbarkeit Ein System skaliert vertikal, wenn es durch Hinzufügen von mehr CPUs, Hauptspeicher, Festplatten oder Netzwerkschnittstellen erweitert werden kann, um eine erhöhte Anzahl von Anfragen bedienen zu können [8] Vor- und Nachteile einer horizontalen und vertikalen Skalierung 2003 kostete ein Cluster mit GHz Xeon CPUs, 176 Gigabytes RAM und 7 Terrybytes Festplattenplatz insgesamt 278,000 Dollar. Im Vergleich dazu kostete ein typischer x86-basierter Server, welcher acht 2-GHz Xeon CPUs, 64 Gigabyte RAM, und 8 TB Festplattenplatz besitzt, ungefähr 758,000 Dollar [4]. Die Ausstattung und damit die Performance sind bei beiden Systemen gleich einzuschätzen. Das Verhältnis von Performance zum Preis ist bei dem High-End-Server jedoch viel schlechter als bei den geclusterten Low-End-Systemen. Die High-End-Server haben z.b. durch eine

14 8 Kapitel 2. Grundlagen redundante Stromversorgung eine bessere Verfügbarkeit, die diesen erhöhten Preis rechtfertigen soll. Dies kann aber auch durch fehlertolerante Software bereitgestellt werden, sodass dies auch von Low-End-Cluster-Systemen angeboten werden kann. Erschwerend kommt hinzu, dass die redundante Stromversorgung zu einem erhöhten Stromverbrauch führt. Dies verschlechtert natürlich das Verhältnis von Performance pro Watt bei dem High-End-System gegenüber dem Cluster [3]. Ein weiterer Vorteil der horizontalen Skalierung gegenüber der vertikalen ist, die Erreichung einer unbegrenzten Skalierung [1]. Viele Firmen verlassen sich bei der Skalierung auf Moore's Law, welches aussagt, dass sich die Anzahl der Transistoren, die auf einen Chip passen, alle zwei Jahre verdoppelt. Unternehmen wie Google, Facebook oder Yahoo, wachsen jedoch schneller, sodass sie die Skalierung nicht nur auf ein System beziehen (Scale-Up), sondern ihren Fokus auf Scale-Out setzen. [1] Dimensionen der Skalierbarkeit Die Skalierbarkeit kann in drei verschiedene Dimensionen erfolgen [21]: Gröÿe, geographische Verteilung und administrative Verteilung. Bezüglich der Gröÿe bedeutet dies, die Möglichkeit des einfachen Hinzufügens von Komponenten. Hinter der Dimension geographische Verteilung verbirgt sich die Anforderung, dass das System funktioniert, unabhängig davon, ob es innerhalb einer Institution oder über den gesamte Erde verteilt ist. Skalierbarkeit bezüglich der administrativen Verteilung meint, dass die Funktion des Systems auch über administrative Domänen hinweg sichergestellt sein muss. Im Folgenden werden Hindernisse, die zur erschwerten Durchführung der Skalierbarkeit in den verschiedenen Dimensionen führen und deren Lösungsansätze kurz vorgestellt [21]. Zentrale Dienste, Daten und Algorithmen erschweren die Skalierbarkeit betreend der Gröÿe. Diese können durch Verteilung und Replikation vermieden und so Engpässe bei der Verfügbarkeit unterbunden werden. Zu den eben genannten Hindernissen kommen für die Skalierbarkeit bezüglich der geographischen Verteilung zwei weitere hinzu. Zum einen Latenzzeiten, welche in einer global verbreiteten Anwendung zu erhöhten Antwortzeiten führen, und zum anderen die Verwendung von Broadcast, welches ezient in lokalen Netzwerken funktioniert, jedoch für IP-Weitverkehrsnetze nicht zur Verfügung steht. Um hohen Latenzzeiten entgegenzuwirken, kann eine lokale Vorverarbeitung stattnden oder anstatt auf synchrone Kommunikation lieber auf asynchrone Kommunikation setzen. Ein System über administrative Domänen hinweg zu verteilen ist eine sehr schwere

15 2.4. Skalierungsstrategien 9 Aufgabe. Rechner innerhalb einer administrativen Domäne oder auch Vertrauensdomäne können uneingeschränkt miteinander kommunizieren. Anders verhält es sich mit Rechnern auÿerhalb dieser Domäne. Ist hier eine Kommunikation erwünscht, so müssen Anpassungen an den Sicherheitsrichtlinien vorgenommen werden. Unter anderem müsste beim Vorhandensein einer Firewall, diese entweder gänzlich oder für die gegebene Anwendung geönet werden, um so eine Kommunikation zu ermöglichen Skalierungsstrategien Nachdem im Abschnitt 2.2 die Grundlagen für das Verständnis der 3-Schichten- Architektur geschaen wurden und im vorherigen Abschnitt 2.3 der Begri Skalierbarkeit erklärt wurde, soll dieser Abschnitt genutzt werden, um Möglichkeiten der Skalierbarkeit für die 3-Schichten-Architektur vorzustellen. Hierbei wird auf verschiedene Strategien eingegangen, die sich in der Vergangenheit besonders im Hinblick auf die Skalierbarkeit bewehrt haben. Es erfolgt dabei eine Unterteilung in Strategien für die Anwendungsschicht und für die Datenschicht Horizontale Skalierung der Anwendungsschicht Eine horizontale Skalierung der Anwendungsschicht wird erreicht, wenn die gleiche Anwendung nicht nur auf einem Server ausgeführt wird, sondern auf mehrere Systeme verteilt wird, sodass nur eine Teilmenge der gesamten Nutzer mit einem System kommunizieren. [1] Somit wird die Last auf verschiedene Systeme aufgeteilt (siehe Abbildung 2.2). Bei Ausfall eines Systems können diese Nutzer, durch Migration, auf die restlichen verfügbaren Systeme verteilt werden. Um in einem so verteilten System geeignet Daten abzulegen, zu kommunizieren oder komplexe Berechnungen durchzuführen, werden nachfolgend Strategien, die dies ermöglichen, vorgestellt. Caching und In-Memory-Data-Grid Das Verteilen von Anwendungen durch Lastverteilung erfordert das Verteilen von Daten zwischen den Anwendungen, insbesondere wenn diese Daten entweder aufwendig zu berechnen oder zu bekommen sind. Diese Daten werden in einem Subsystem abgelegt und wiedergeholt. Caches sind als indizierte Tabellen implementiert, bei der ein

16 10 Kapitel 2. Grundlagen Abbildung 2.2.: Horizontale Skalierung der Anwendungsschicht eindeutiger Schlüssel verwendet wird, um ein Datum zu referenzieren. Im Folgenden sind drei unterschiedliche Arten von Caches aufgezählt. Application Caching: entweder implizit, bei dem eine Caching-Schicht automatisch die Anfragen unabhängig von der Anwendung cached, oder explizit, bei dem ein Programm eine Caching-API importieren muss, um sie nutzen zu können [8] Web Caching: Web Cache ist ein Mechanismus zur temporären Speicherung von Webdokumenten, wie HTML-Seiten oder Bilder, um die Bandbreite und Server zu entlasten und die Antwortzeit zu minimieren [8]. Distributed Caching: Bei einem verteilten Cache werden die zu cachenden Daten auf mehrere Server verteilt, sodass die Gröÿe und die Belastbarkeit des Caches erhöht werden kann [8]. Sehr bekannte Vertreter von Caches bzw. In-Memory-Data-Grids sind: Terracotta [43], memcached, Oracle Coherence [38], Hazelcast [30], IBM extreme scale [24], VMware GemFire [46] und Gigaspaces XAP [18]. Messaging und Publish/Subscribe In einem verteilten System, wie es durch die Verteilung der Anwendung auf mehrere Systeme entstanden ist, bietet eine asynchrone Kommunikation Vorteile hinsichtlich der Parallelisierbarkeit, Entkopplung oder Erweiterbarkeit der Kommunikations-

17 2.4. Skalierungsstrategien 11 partner [2]. Durch asynchrone Kommunikationsplattformen, welchen das Prinzip des Nachrichtenaustausches zugrunde liegt, werden Sender und Empfänger entkoppelt. Diese kommunizieren mittels Nachrichten, wobei diese nicht direkt sondern indirekt über Zwischenspeicher übermittelt werden [2]. In einem Publish/Subscribe System kann die 1:1 Beziehung zwischen Sender und Empfänger um eine 1:N Beziehung erweitert werden. Bei solch einem System können mehrere Subscriber ein Thema, Topic oder mehrere Nachrichten-Warteschlangen abonnieren. Sendet nun ein Sender eine Nachricht, so wird diese Nachricht allen Abonnenten übermittelt. Die Anzahl und die jeweiligen Empfänger sind dem Sender nicht bekannt. Map/Reduce Das Programmiermodell Map/Reduce ermöglicht eine eziente nebenläuge Berechnung sehr groÿer Datenmengen in Computerclustern [42]. Die Grundidee von Map/Reduce stammt von der funktionalen Programmiersprache LISP (=List Processing) [42]. In dieser Programmiersprache gibt es zwei Funktionen map() und reduce(). Die Funktion map() wendet eine Funktion sukzessive auf alle Elemente einer Liste an und gibt die durch die Funktion veränderte Liste zurück. Die Funktion reduce() akkumuliert die einzelnen Funktionsergebnisse der Listenpaare und reduziert diese auf einen Ausgabewert [42]. Dieses Prinzip kann für verschiedene Anwendungsgebiete genutzt werden, zum Beipiel verteiltes Suchen, Zählen von Zugrien auf eine URL und Sortieren. Im Kontext von Social Media Streams könnte Map/Reduce zum Auswerten und Aufbereiten von Tagclouds verwendet werden. Von Map/Reduce gibt es zahlreiche Implementierungen in verschiedenen Programmiersprachen und Interpretationen. Das initiale Framework von Google ist in C++ geschrieben. Eine Implementierung, welche sich sehr groÿer Beliebtheit erfreut ist Hadoop von der Apache Software Foundation. Diese ist komplett in Java geschrieben Horizontale Skalierung der Datenschicht Eine horizontale Skalierung der Datenschicht (siehe Abbildung 2.3) erreicht man durch die Verteilung der Datenschicht und somit der Daten auf mehrere Systeme, um somit das Problem der begrenzten Datenmenge und I/O zu lösen. Die gesamten Daten, Lese- und Schreiboperationen können auf die verschiedenen Systeme gleich-

18 12 Kapitel 2. Grundlagen Abbildung 2.3.: Horizontale Skalierung der Datenschicht mäÿig verteilt werden. Mit diese Verteilung der Daten kommen weitere Probleme hinzu. Neue Datensätze oder Änderungen von Datensätzen, die auf einem System hinzugefügt oder vorgenommen werden, müssen auf die anderen Systeme propagiert werden, um die Daten der Systeme synchron zu halten. Im Folgenden werden Lösungsansätze vorgstellt und gezeigt, wie mit diesem Problem umgegangen werden kann. NoSQL-Ansätze Der Begri NoSQL tauchte 1998 zum ersten Mal bei der Datenbank von Carlo Strozzi auf, da dieser für seine Datenbank keine SQL-API zur Verfügung stellte. Ein richtiger Hype um solche Systeme kam mit dem Web 2.0 auf, da Anbieter der Aufgabe gegenüberstanden, groÿe Datenmengen zu verarbeiten [42]. NoSQL Ansätze sind nicht mit dem Begri Skalierbarkeit gleichzusetzen, jedoch unterstützen eine Vielzahl von NoSQL Produkte eine einfache Skalierbarkeit. Dies wird, durch die Art und Weise wie die Daten in einem solchen System gespeichert werden, begünstigt, sei es durch Speicherung der Daten als Schlüssel-Wert-Paare, als unabhängige Dokumente oder als Graphen. NoSQL-Systeme können folgendermaÿen kategorisiert werden: Column-Stores, Document-Stores, Key-Value-Stores und Graphendatenbanken [42]

19 2.5. Systeme zur Umsetzung einer skalierbaren Architektur 13 Replikation Durch Replikation der Daten auf verschiedene Datenbankserver, kann die Zugrislast von einem Server auf mehrere verteilt werden. Hierfür gibt es verschiedene Strategien, z.b. Read-Once-Write-All (ROWA), Primary-Copy-Verfahren oder Voting-Verfahren [40]. Die ROWA-Strategie verlangt die synchrone Änderung aller Replikate vor Abschluss einer Transaktion. Dadurch kann garantiert werden, dass jedes Replikat aktuell ist und zum Lesen jedes beliebig ausgewählt werden kann. Das Speichern von Daten dauert bei diesem Verfahren jedoch sehr lange [40]. Bei dem Primary-Copy-Verfahren wird eine Änderung nur auf einem Replikat durchgeführt, die sogenannte Primärkopie. Diese propagiert die Änderungen nach Abschluss der Transaktion asynchron an alle anderen Replikate [40]. Hinter dem Begri Voting-Verfahren verbirgt sich ein Verfahren, bei dem vor dem Zugri auf ein gespeichertes Objekt zunächst eine ausreichende Anzahl von Stimmen (votes) gesammelt werden muss [40]. Hierbei gibt es noch eine weitere Unterteilung in Mehrheits-Votieren und gewichtetes Votieren. Sharding Bei der horizontalen Fragmentierung von Tabellen (Sharding) wird die Gesamtheit der Daten auf verschiedene Tabellen, entweder lokal (Partitionierung) oder auf verschiedene Datenbankserver, verteilt [48]. Für die Zuordnung der einzelnen Fragmente zu den jeweiligen Datenbankservern müssen Regeln geschaen werden. Hierzu besitzt jeder Datenbankserver einen Wertebereich. Aus den einzufügenden Daten wird ein Hashwert erzeugt. Je nach Hashwert werden die Daten dem jeweiligen Shard zugeordnet und auf dem verantwortlichen DB-Server abgelegt. Dieser ist sowohl für das Speichern als auch für das Lesen des Datensatzes zuständig Systeme zur Umsetzung einer skalierbaren Architektur Hazelcast Bei Hazelcast handelt es sich um ein In-Memory-Data-Grid, welches mittles eines Peer-to-Peer-Ansatzes realisiert ist. Es basiert auf Java und wird unter der Apache Lizenz 2.0 vertrieben. Die Clusterbildung erfolgt dynamisch zur Laufzeit. Für

20 14 Kapitel 2. Grundlagen Abbildung 2.4.: RabbitMQ Komponenten (Quelle: [45]) die Verteilung und Speicherung der Daten gibt es verschiedene spezielle Datenstrukturen, wobei der Zugri auf diese Datenstrukturen denen der Standard-Java- Datenstrukturen entspricht. Zusätzlich zu diesen Strukturen gibt es noch eine Unterstützung für Messaging und Event-Handling [30]. Für den Aufbau eines Clusters genügt es, wenn der Entwickler eine neue Hazelcastinstanz in einer JVM erstellt. Nun kann der Entwickler zum Beispiel eine verteilte Hashmap anlegen, wobei lediglich eine Kennung angegeben werden muss. Die Datenstruktur ist nach erfolgreichem Anlegen im Cluster verteilt. Dabei kümmert sich Hazelcast um die gleichmäÿige Verteilung der Daten und die Datenumverteilung bei Veränderungen des Clusters, welche durch Hinzufügen von neuen Knoten oder bei Ausfall eines vorhandenen Knotens enstehen können. Mitglieder verbinden sich über TCP/IP zu einem vollvermaschten Netz miteinander. Dabei gilt, es verbindet sich immer ein neues Mitglied mit den vorhandenen Mitgliedern. Das älteste Mitglied hört auf Beitreten-Anfragen von neuen Mitgliedern. Wenn eine solche Anfrage kommt, sendet dieser seine Adresse an das neue Mitglied, sodass eine TCP/IP Verbindung aufgebaut werden kann [30] RabbitMQ RabbitMQ ist ein Open-Source-Message-Broker, welcher den AMQP Standard implementiert. Rabbit Technologies Ltd., die Firma hinter RabbitMQ, welche ehemals aus der Firma LShift ausgegründet wurde, ist im April 2010 von SpringSource, einem VMWare Unternehmen, übernommen worden.[41] In RabbitMQ und dessen Nachrichtenmodell gibt es vier grundlegende Komponenten. Diese sind in der Abbildung 2.4 zu sehen. Einen Produzenten (P) und Konsumenten (C), eine Message-Queue (Q) und einen Exchange (X). Der Produzent ist ein Programm, welches Nachrichten versendet, die in einem Puer, der Message-Queue,

21 2.5. Systeme zur Umsetzung einer skalierbaren Architektur 15 abgelegt werden und solange darin verbleiben, bis ein Konsument diese aus dem Puer wieder entnimmt. Der Produzent schickt dabei eine Nachricht niemals direkt in eine Message-Queue, sondern an einen Exchange. Diese einfache Komponente empfängt die Nachrichten von dem Produzenten und leitet diese an Message-Queues weiter. Dabei muss der Exchange genau wissen, was er mit den empfangenen Nachrichten machen soll. Hierfür gibt es Regeln, welche von vier verschiedenen Exchange-Typen deniert sind: direct, topic, headers und fanout. Der fanout-exchange leitet immer alle empfangenen Nachrichten an alle verbundenen Message-Queues weiter. Bei den restlichen Typen erfolgt eine Weiterleitung ausschlieÿlich an Message-Queues, die ein bestimmtes Kriterium erfüllen. Diese Kriterrien werden beim Verbinden der Message-Queues mit den Exchanges mittels eines Bindingkeys angegeben. Erreicht nun eine Nachricht einen Exchange, überprüft dieser, ob der Routing-Key in der Nachricht mit dem Binding-Key der Queue übereinstimmt. Ist dies der Fall, wird diese Nachricht an die jeweilige Queue geleitet. Andernfalls wird die Nachricht verworfen [45] ActiveMQ Ebenso wie bei RabbitMQ aus dem vorherigen Absatz handelt es sich bei Apache ActiveMQ um einen Message Broker. Dieser ist jedoch in Java geschrieben und implementiert nicht das AMQP Protokoll, sondern das Java Message Service (JMS) Protokoll in der Version 1.1 vom Der Vorteil gegenüber RabbitMQ ist, dass sich dieser Broker in eine Java-Anwendung einbetten lässt und das Ausliefern eines Softwarepaketes somit vereinfacht. In der Abbildung 2.5 sind die verschiedenen Komponenten des Java Message Servive und deren Beziehungen zueinander abgebildet. Java Message Service bietet zwei Nachrichtenmodelle an. Zum einen das Point-to-Point-Modell und zum anderen das Publish/Subscribe-Modell an. [35] Bei dem Point-to-Point-Modell besitzt jede Nachricht genau einen Empfänger, der den Erhalt einer Nachricht dem Sender quittiert. Dabei werden gesendete Nachrichten in einer Warteschlange abgelegt und verbleiben darin bis der Empfänger diese aus der Warteschlange entnimmt. Anders verhält es sich bei dem Publish/Subscribe-Modell. Hier kann eine Nachricht gleich mehrere Empfänger besitzen, je nachdem wie viele Klienten ein Topic abonniert haben. Gesendete Nachrichten werden nicht in einer Warteschlange zwischengespeichert, sondern sofort an alle Abonnenten geschickt, d.h. es können erst

22 16 Kapitel 2. Grundlagen Abbildung 2.5.: Übersicht der JMS-Komponentenbeziehungen [35] Nachrichten zu einem Thema empfangen werden, nachdem ein Abonnement für ein Topic vereinbart wurde. Der Abonnent muss jedoch die ganze Zeit für das Empfangen von Nachrichten bereit sein ejabberd ejabberd ist ein Jabber/XMPP Instant Messaging Server, welcher unter GPLv2 lizensiert und in Erlang/OTP geschrieben ist. Neben weiteren Features ist die groÿe Stärke von ejabberd, aufgrund der Verwendung der Programmiersprache Erlang, dass es Cross-Plattform, fehlertolerant, clusterfähig und modular ist [10]. ejabberd implementiert unter anderem die XMPP-Protokollerweiterung XEP- 0060, welche eine generische Publish/Subscribe-Funktionalität deniert. Dieses Protokoll ermöglicht es XMPP-Instanzen Knoten (Topics) auf einem Publish/Subscribe- Dienst zu erstellen und Nachrichten an diese Knoten zu senden. Über eine Eventbenachrichtigung (mit oder ohne Payload), welche als Broadcast an alle Instanzen geschickt wird, die sich mit diesem Knoten verbunden haben, werden diese über die neue Nachricht informiert [11] Node.js Node.js ist eine Plattform zum einfachen Erstellen von schnellen und skalierbaren Netzwerkanwendungen auf Basis von JavaScript. Node.js verwendet ein eventgetriebenes, nicht-blockierendes I/O Modell, welches es leichtgewichtigt und ezient macht, perfekt für datenintensive und verteilte Echtzeitanwendung [25].

23 2.5. Systeme zur Umsetzung einer skalierbaren Architektur 17 Die Idee von serverseitigen JavaScript ist nicht neu, aber bisher waren die JavaScript-Laufzeitumgebungen sehr langsam bei der Interpretation des JavaScript- Sourcecodes. Dies änderte sich mit der V8 JavaScript Engine von Google, welche JavaScript nicht interpretiert, sondern in nativen Maschinencode übersetzt und ausführt. Diese Engine wird unter anderem von Google's Browser Chrome und Node.js verwendet [20]. Node.js zwingt den Entwickler dazu asynchron zu programmieren, der V8 Enginekern allein bietet jedoch keine Nebenläugkeit. Hier erweitert Node.js diesen um eine Event Loop. Für diesen existiert jedoch nur ein Prozess für alle Events und keine Möglichkeit der Änderung [39]. Hier bietet die einfache Skalierbarkeit von Node.js eine Abhilfe. So können mehrere Node.js Prozesse gestartet werden, um die Auslastung von Multicore Systemen zu erhöhen. Im Internet gibt es eine Reihe von Publish/Subscribe-Implementierungen für Node.js. Ein Beispiel hierfür ist fanout.js, ein einfacher PubSub-Nachrichtenserver für Node.js, welcher auf github gehostet ist [13]. Diese Implementierung ermöglicht es, sich mittels TCP zu verbinden, Kanäle zu abonnieren und Nachrichten an andere Kanäle zu schicken. Diese Nachrichten werden dann an alle Abonnenten dieses Kanals geschickt Scribe Scribe ist ein generisches, skalierbares und ezientes System zur Gruppenkommunikation und Eventbenachrichtigung. Es ist eine dezentrale, auf Anwendungsebene bendliche, Multicast-Infrastruktur, welche eine sehr groÿe Anzahl von Gruppen, mit wiederum sehr groÿer Gruppenmitgliederanzahl, unterstützt. Scribe baut auf Pastry auf, welches ein generisches, robustes und selbstorganisierendes Peer-to-Peer Overlay Netzwerk zum Verteilen und Aunden von Objekten ist [33]. Scribe wurde erstmals vom Microsoft Research 2001 beim Third International COST264 Workshop on Networked Group Communication in London vorgestellt [34]. Ein Scribe Sytsem besteht aus einem zyklischen Netzwerk von Pastryknoten, auf welchen jeweils eine Scribeanwendung läuft. Jeder Scribeknoten besitzt eine eindeutige KnotenID, welche aus dem Hash der IP-Adresse des Knoten erstellt wird. Ein Knoten hat die Möglichkeit eine neue Gruppe zu erstellen, der vorhandenen Gruppe beizutreten oder Nachrichten an alle Mitglieder dieser Gruppe zu senden. Jede Gruppe hat eine einzigartige GroupID, welche aus dem Hash des Gruppennamens erzeugt wird. Der Scribeknoten dessen KnodenID numerisch am nähsten zu der GroupID ist, agiert als rendez-vous Punkt für diese Gruppe. Der rendez-vous Punkt ist immer die Wurzel des Multicast-Baumes, welcher für

24 18 Kapitel 2. Grundlagen eine Gruppe erstellt wird. Schickt ein Knoten eine Nachricht an eine Gruppe, so wird diese zunächst an den rendez-vous Punkt, mit Hilfe der GroupID, geleitet. Von diesem Punkt wird die Nachricht dann über Zwischenknoten an alle Mitglieder dieser Gruppe gesendet. Durch das darunterliegende Produkt Pastry kann eine Nachricht in weniger als log 2 b N Schritten zu jedem beliebigen Knoten gesendet werden, wobei N die Anzahl der Knoten ist. Dabei besitzt jeder Knoten nur (2 b 1) log 2 b N + l Einträge in seiner Routingtabelle, welche zum Weiterleiten einer Nachricht benötigt wird Weitere Systeme In diesem Absatz werden weitere Systeme vorgestellt, welche zur Umsetzung einer skalierbaren Architektur dienen könnten. Diese Produkte benden sich momentan noch in einem sehr frühen Entwicklungsstadium, welcher für eine Unternehmensanwendung noch nicht tragbar ist. Dennoch sind diese Systeme erwähnenswert, da ihr Potential schon von einigen Social-Media-Diensten wie Twitter, Thumblr oder LinkedIn erkannt wurde und bei diesen auch praktisch eingesetzt wird. Anfang Februar 2012 wurde der Message-Broker ActiveMQ Apollo in der Version 1.0 veröentlicht. ActiveMQ Apollo ist schneller, zuverlässiger und einfacher zu Warten als ActiveMQ, welcher als Grundlage für diesen Message-Broker diente. Dies wird durch eine radikal andere Threading- und Nachrichtenverteilungs-Architektur erreicht [15]. Das Akka-Framework wird auf der Webseite als die Platorm für die nächste Generation von eventgetriebenen, skalierbaren und fehlertoleranten Architekturen auf der JavaVM bezeichnet [26]. Diese Plattform stellt Module und Lösungen bereit, um eine Anwendung nebenläug, skalierbar und fehlertolerant zu gestalten. Dies wird mit Hilfe von Aktoren, asynchroner Nachrichtenverteilung und Aktor-Supervisor- Hierarchien erreicht. Es gibt für Akka sowohl eine API für Scala und Java als auch eine Spring- und Guice-Integration. Das System Apache Kafka bendet sich derzeit mit der Versionsnummer im Inkubator der Apache Software Foundation [16]. Es ist ein verteiltes Publish/Subscribe-Nachrichten-System. Kafka stellt eine Publish/Subscribe- Lösung bereit, welche die gesamte Activity-Stream-Data und dessen Verarbeitung abwickeln kann.

25 2.6. Architektur Best Practices von Social-Media-Diensten Architektur Best Practices von Social-Media-Diensten In diesem Abschnitt werden eine Reihe von Architektur Best-Practices von Social- Media-Diensten vorgestellt und erläutert. Diese Dienste sind nicht ohne Grund ausgewählt worden. Sie sind aufgrund ihrer groÿen Popularität einer sehr groÿen Nutzerzahl ausgesetzt. Diese umfasst mehrere Millionen Nutzer. Die Architekturen in den jeweiligen Abschnitten sollen eine Richtung vorgeben, wie eine ideale skalierbare Architektur für Social Media Dienste aussehen könnte. Der Erstellungsprozess einer skalierbaren Architektur ist nicht einfach, sondern ein iterativer Prozess, da zukünftige Nutzerzahlen oder Datenmengen nicht oder nur schwer prognostiziert werden können. Das heiÿt, ob eine Architektur wirklich skalierbar ist, kann erst festgestellt werden, wenn die Grenzen der Skalierung und der Belastbarkeit einer Archtitektur erreicht sind. Das bedeutet, wenn die Antwortzeiten nicht mehr den geforderten Anforderungen entsprechen, der Speicherplatz zum Abspeichern der Daten nicht mehr ausreicht oder gar eine Anwendung nicht mehr verfügbar ist, weil die Server unter der Last zusammengebrochen sind Twitter Twitter ist ein Dienst mit dem Personen, Organisationen, Unternehmen und Massenmedien kurze Textnachrichten über das Internet verbreiten können. Seit der Gründung 2006 steigen die Nutzerzahlen stetig an. Im Juni 2011 sind es über 300 Millionen [44]. Diese Nutzer erzeugen jeden Tag über 50 Millionen Tweets, das sind pro Sekunde mehr als 600. Diese Zahlen können jedoch, wie in der Einleitung geschildert, zu besonderen Ereignissen jedoch bei Weitem übertroen werden. Mit den stetig wachsenden Nutzerzahlen sah sich Twitter auch immer der Aufgabe gestellt, ihre Architektur den Nutzeranforderungen anzupassen und umzugestalten, um den Anforderungen gerecht zu werden. Die Twitter Nutzer generieren pro Tag 7 Terrabyte an Daten. Das sind pro Jahr 2 Petabyte [47]. Diese Zahlen verdoppeln sich pro Jahr. Für die Speicherung dieser Datenmenge und deren Verarbeitung und Aufbereitung verwendet Twitter eine Vielzahl von verschiedenen Open-Source-Produkten. Diese verschiedenen Produkte werden im Folgenden vorgestellt und erläutert, wie diese genau funktionieren. Um diese 7 Terrabyte an Daten ezient zu Speichern und Auswerten zu können, benötigt man einen Cluster. Dieser fügt jedoch eine zusätzliche Komplexitätsschicht

26 20 Kapitel 2. Grundlagen Abbildung 2.6.: FlockDB [5] ein. Deshalb verwendet man bei Twitter das Apache Top-Level Projekt Hadoop, welches mit HDFS ein verteiltes Dateisystem zur Verfügung stellt und mit Hilfe von Map/Reduce sehr ezient analysiert werden kann [47]. Da die Map/Reduce Programme sehr komplex und deshalb schwierig zu lesen und zu erweitern sind, hat man mit Pig, einer High-Level-Sprache zur Datenanalyse, eine Alternative gefunden, mit der nur 5% des ursprünglichen Hadoop Map/Reduce-Codes geschrieben werden muss. Zu dem Apache Hadoop Ökosystem gehört ebenfalls das Open-Source-Produkt HBase, eine verteilte und spaltenorientierte Datenbank, welche nach Google's Bigtable modelliert wurde. Mit diesem System und Hadoop wurde die Nutzersuche neu implementiert, welche gegenüber der Vorgängerversion komplexere Benutzerkalkulationen und zusätzliche Dienste in Echtzeit anbieten kann. In gewisser Hinsicht kann Twitter als groÿer, gerichteter, sozialer Graph angesehen werden, in dem entlang der Kanten Kurznachrichten versendet werden können [42]. FlockDB ist eine Open-Source Graphendatenbank, welche einen in Echtzeit verteilten Speicher für soziale Graphen bei Twitter darstellt [42]. Im Mittelpunkt steht eine einfache, horizontale Skalierbarkeit, welche durch eine Aufteilung des Graphen in beliebig viele Shards realisiert wird [42]. Die Daten werden in MySQL-Datenbanken geschrieben. Das Twitter-eigene Framework Gizzard wird verwendet, siehe Abbilung 2.6, um das Sharding und Partitionieren zu behandeln und so die Verteilung der Daten auf die verschiedenen MySQL-Instanzen zu verwalten.

27 2.6. Architektur Best Practices von Social-Media-Diensten 21 In der Abbildung 2.6 ist ein weiteres Produkt abgebildet, Kerstrel. Kerstrel ist ein Message-Queue-Server, welcher eine Scala-Portierung des zuvor verwendeten, in Ruby geschriebenen Message-Systems Starling darstellt. Dieses wurde durch Kerstrel aufgrund der besseren Performance ersetzt. Sollte eine Schreiboperation fehlschlagen, da eine Shard aufgrund eines Systemausfalls nicht erreichbar ist, wird diese Operation in die Message-Queue geschrieben und ausgeführt, sobald die Shard wieder verfügbar ist. Dies fördert die Konsistenz und lässt das System als immer verfügbar erscheinen. Bei der Vielzahl unterschiedlicher Sytsme fallen für jedes System unabhängig voneinander Log-Daten an. Die Aufgabe, diese eektiv zur Auswertung zu konsolidieren, übernimmt das Produkt Scribe, welches von Facebook entwickelt und Open-Source zur Verfügung gestellt wurde [14] Facebook Genauso schnell wie sich Twitter entwickelt hat, ist auch Facebook seit dem Bestehen im Jahr 2004 stetig gewachsen. Facebook ist eine Online-Community zum Erstellen, Betreiben und Pegen sozialer Netzwerke. Sie nutzen ebenso viele Open-Source- Produkte wie Twitter, um die Architektur so skalierbar wie möglich zu machen [14]. Zu Spitzenzeiten werden auf Facebook 1.2 Millionen Fotos pro Sekunde hochgeladen. Für diese Zahl braucht es eine eziente Speicherung der Fotos. Hierfür wird bei Facebook Haystack verwendet. Dies ist ein Objekt-Store welcher explizit für Fotodaten gedacht ist und den unnötigen Metainformation-Overhead eliminiert. HayStack speichert Fotos in einem 10 GB groÿen Bucket mit einem Megabyte Metadateninformation pro Gigabyte. Ein Haystack besteht aus zwei Dateien: Die Haystack-Store- Datei mit den Needles, zum Wiedernden der Osets der einzelnen Fotos, und die Index-Datei. Die Präsentations-Schicht bei Facebook wird in PHP programmiert. PHP ist zwar leicht zu lernen jedoch im Vergleich zu anderen Programmiersprachen sehr langsam. Hier verwendet Facebook das Tool HipHop. HipHop ist ein Source-Code- Transformator, welcher PHP-Source-Code in hochoptimierten C++-Code transformiert und mit Hilfe von g++ kompiliert [14]. Als Webserver verwendet Facebook Tornado, ein nicht-blockierendes Server- Framework, welches in Python geschrieben ist [14]. Es ist dafür entwickelt worden, um tausende paralleler Connections behandeln zu können, perfekt für Echtzeit Webdienste. Um nicht alle Datenaufrufe auf die darunterliegenden Systeme weiterzuleiten, wird bei Facebook massiv auf Memcached gesetzt. Hier wird versucht so viele Daten wie möglich zu cachen, damit diese dem Nutzer ohne lange Antwortzeiten zur

28 22 Kapitel 2. Grundlagen Verfügung stehen. Am 10. Februar 2010 wurde Facebook Messages vorgestellt, die erste Endnutzeranwendung bei Facebook, welches auf dem System Apache Hadoop aufbaut. Bei Facebook wurde Hadoop vorher traditionell, in Zusammenarbeit mit Hive, für das Speichern und Analysieren von groÿen Datenmengen im Datawarehouse verwendet. Facebook entschied sich, aufgrund der Anforderungen an Konsistenz, Verfügbarkeit, dem Datenmodell und der Skalierbarkeit Hadoop und dessen Ökosystem, mit HBase, Hive und ZooKeeper, anstelle von Apache Cassandra oder Voldemort, ebenfalls für das neue Nachrichtensystem zu verwenden. Hierfür mussten jedoch einige Anpassungen an Hadoop gemacht werden, um den Echtzeitanforderungen von Facebook zu genügen. [6]. Bei diesem riesigen System von unterschiedlichen Architekturkomponenten kommt es dazu, dass die von jedem System erstellten Log-Dateien zur Auswertung konsolidiert werden müssen. Hierzu verwendet Facebook Scribe, einen skalierbaren Dienst zum Aggregieren von Logdaten, welcher diese in Echtzeit von einer Vielzahl von Servern streamt [14] LinkedIn LinkedIn ist das gröÿte Online-Berufsnetzwerk weltweit. Es verfügt über mehr als 135 Millionen Mitglieder in mehr als 200 Ländern und Regionen (Stand vom 3. November 2011) [29]. Dieses soziale Netzwerk dient der Pege bestehender Geschäftskontakte oder zur Knüpfung neuer Verbindungen. So ist es zum Beispiel möglich, ehemaligen Kollegen bzw. Klassenkameraden oder interne Kontakte bei der Suche einer neuen Stelle zu nden oder neue Geschäftsbeziehungen zu knüpfen. Hierzu kann man ein persönliches Prol oder ein Firmenprol erstellen, auf welchem man z.b. seinen Lebenslauf hinterlegen oder für neue Produkte werben kann. Des Weiteren bietet LinkedIn an, fachliche Fragen an Branchenexperten zu stellen und Ratschläge zu erhalten. Im Jahre 2008 hatte LinkedIn schon mehr als 22 Millionen Nutzer und 130 Millionen Verbindungen. Bis zur Umsetzung der heute existierenden Architektur gab es 3 Iterationen [23]. Begonnen wurde 2003 mit einer monolithischen Webanwendung mit einer Datenbank. Der komplette LinkedId Netzwerkgraph wurde in der Cloud, im RAM, gespeichert. Die Suche ist mit Lucene umgesetzt. Diese wird auf dem gleichen Servern gespeichert, wie die Cloud. Der Kommunikationsuss sieht bei einer Änderung folgende Schritte vor: Die Webanwendung ändert die Datenbank und die Datenbank

29 2.6. Architektur Best Practices von Social-Media-Diensten 23 ändert die Cloud wurde die Datenbank repliziert, um die Last von der zentralen Datenbank zu nehmen. Die Datenbankreplikate beinhalten nur die Read-Only Daten. Ein RepDB- Server hat die Updates der Datenbankreplikate übernommen. Neben der Auslagerung der Suche auf einem extra Server wurde eine neue Komponente eingeführt, der Datenbus. Der Datenbus dient zur Verteilung der Updates an alle Komponenten. Die Datenbank sendet die Änderungen an den Datenbus, welcher diese anschlieÿend an die Datenbankrepliken, die Suche und die Cloud verteilt. Der letzte Iterationsschritt wurde 2008 gemacht. Bei diesem Schritt wurde die Businesslogik in verschiedene Services aufgeteilt, sodass der Webserver nur noch die Präsentation übernehmen muss. Für alle anderen Funktionen ruft der Webserver die verschiedenen Services auf, um zum Beispiel Prole oder Gruppen zu bearbeiten. Jeder Service besitzt seine eigene Datenbank. Neben dem generellen Aufbau der Architektur hat sich auch die Kommunikationsarchitektur während der Iterationen geändert. Im ersten Iterationsschritt handelte es sich noch um eine Pull-basierte-Architektur. Das heiÿt, es musste jedesmal vom Nutzer eine Abfrage gestartet werden, damit dieser über Neuerungen erfährt. Dies wurde im zweiten Iterationsschritt angepasst. Hier kam es zu einem Wechsel zur Push-basierten-Architektur, was bedeutet, dass beim Eintreen eines Events ein Push-Update durchgeführt wird. Die Benachrichtigung über Updates erfolgt mittels Java-Message-Service (JMS) [28]. Die komplette mobile Anbindung von Nutzern zu LinkedIn ist mit Node.js umgesetzt [37]. Dies geschah nach einer intensiven Analyse unterschiedlicher Produkte wie Ruby, Node.js, Java und Scala aus Gründen der Skalierbarkeit und dem enormen Performancevorteil gegenüber anderer Produkte [37]. So konnte die ehemalige Umsetzung mit 15 Server mit jeweils 15 Instanzen (virtuelle Server) auf jeder physikalischen Maschine auf nur vier Instanzen reduziert werden, wobei der doppelte Trac behandelt werden kann [37] Fazit und Zusammenfassung Nachdem in den vorherigen Abschnitten verschiedene Architekturen und Infrastrukturen vorgestellt wurden, soll dieser Absatz genutzt werden, um die Erkenntnisse der Umsetzungen zusammenzufassen. Alle vorgestellten Architekturen verwenden den Scale-Out-Ansatz, um die Zugrislast auf verschiedene Server in einem Cluster zu verteilen. Hierbei verwenden sie Hardware von der Stange, um die Implementierungskosten gering zu halten. För-

30 24 Kapitel 2. Grundlagen derlich für dieses Ziel ist zusätzlich der Einsatz von Open-Source-Software, die unter anderem selbst entwickelt und der Community jederzeit bereitgestellt wird. Bei der Verwendung von Open-Source-Software wird nicht nur auf ein Produkt gesetzt, sondern je nach Einsatz und Zweck auf verschiedene Implementierungen zurückgegrien. In einigen Aspekten der Architektur kommt ein NoSQL-Ansatz zum Tragen. Die vorgestellten Architekturen bzw. Infratsrukturen wurden den jeweiligen Anforderungen stetig angepasst und immer weiter ausgebaut. Begonnen wurde dabei jeweils mit der 3-Schichten-Architektur, welche Grundlage für weitere Überlegungen war. Der Weg zu einer skalierbaren Architektur ist ein iterativer Prozess, bei dem neue Produkte zur Umsetzung dieses Ziels evaluiert und getestet werden. Eine Umstellung eines neuen Architekturansatzes erfolgt nicht auf einmal, sondern wird erst parallel zu dem existierenden Ansatz gefahren und sukzessive immer mehr hinzugeschaltet.

31 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse Social-Media-Dienste sind während der bisherigen Entwicklungszeit zu sehr komplexen Anwendungen mit zahlreichen Funktionen entwickelt worden. In diesem Kapitel werden Anwendungsfälle beschrieben, aus denen Anforderungen abgeleitet werden. Diese Anforderungen werden in funktionale und nicht-funktionale Anforderungen untergliedert. Dabei stellen die funktionalen Anforderungen ein Hilfsmittel dar, um die nicht-funktionalen Anforderungen zu bewerten Häug genutze Funktionen von Social-Media-Anwendungen Um die Anforderungsanalyse zu unterstützen und die aus der Analyse resultierenden Anforderungen genau zu spezizieren, wurde im Rahmen dieser eine Analyse zur Verwendung von Funktionen bei Social-Media-Anwendungen, am Beispiel des Enterprise Microblogging Dienstes Communote des Unternehmens Communote GmbH, durchgeführt. Hierzu wurden Access.log-Dateien, welche Aufrufe einer Anwendung speichern, auf die Häugkeit bestimmter Funktionsaufrufe untersucht. Im ersten Schritt wurde zunächst die generelle Nutzung bestimmter Funktionen analysiert. Das Ergebnis dieser Untersuchung ist in Abbildung 3.1 zu sehen. In dem Diagramm ist die prozentuale Häugkeit der Aufrufe der Funktionen abgebildet. Ersichtlich ist, dass sich fast die komplette Nutzung des Systems auf das Schreiben und Antworten sowie auf das Einschränken der Gesamtmenge aller Nachrichten durch sogenannte Filter beschränkt. In einem weiteren Schritt wurden die genauen Filtereinschränkungen auf ihr prozentuales Auftreten untersucht. Die entsprechenden Filter und deren prozentuale 25

32 26 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse Abbildung 3.1.: Ergebnis der Nutzungsanalyse der Funktionen Abbildung 3.2.: Ergebnis der Nutzungsanalyse der Filter Häugkeit ist in Abbildung 3.2 dargestellt. Im Diagramm 3.2 ist zu sehen, dass etwa ein Drittel der gesamten Aufrufe zur Darstellung der Menge aller Nachrichten ohne Filter durchgeführt werden. Bei dem anderen Drittel wird die Gesamtmenge aller Nachrichten auf bestimmte Blogs reduziert. Eine geringe Rolle spielen dagegen die Filter im Hinblick auf die zeitlichen Grenzen. Diese werden nur zu etwa einem Prozent genutzt. Der Betrachtungszeitraum dieser Untersuchung bezog sich insgesamt auf einen Monat. Aus den Erkenntnissen dieser Nutzungsanalyse wurden die funktionalen Anforderungen abgeleitet. Diese werden in den folgenden Abschnitten näher beschrieben.

33 3.2. Detaillierte Beschreibung der Anwendungsfälle Detaillierte Beschreibung der Anwendungsfälle Im nachfolgenden Abschnitt soll eine detaillierte Beschreibung der Anwendungsfälle erfolgen. Die Nutzer dieser Anwendung können Nutzer sein, die direkt oder mittels eines externen Systems, wie zum Beispiel einen XMPP- oder -Client, interagieren. Die Anwendung soll einer sehr groÿen Anzahl von Nutzern die Möglichkeit bieten, eine Nachricht zu schreiben. Dazu muss jeder Nutzer einen Blog festlegen und anschlieÿend eine Notiz eingeben. Nach Absenden dieser Nachricht bekommt der Nutzer eine Information angezeigt, ob dieser Vorgang erfolgreich gewesen ist oder nicht. Ist der Vorgang positiv verlaufen, so muss sichergestellt sein, dass die Nachricht erfolgreich gespeichert ist. Zusätzlich wird die Nachricht an alle Nutzer propagiert, sodass diese über die neue Information benachrichtigt werden. Ist eine neue Nachricht von einem Anwender geschrieben worden, kann sie von anderen Nutzern gelesen werden. Hierzu erhält der Anwender mit Hilfe von Filtern eine Übersicht über alle von dem Nutzer oder anderen Nutzern erstellten Nachrichten, in chronologischer Reihenfolge. Neue oder bearbeitete Nachrichten, die nach dem Önen einer Filterübersicht erstellt werden, werden dem Anwender innerhalb eines denierten Zeitraumes angezeigt oder über ein externes System kommuniziert. Das Bearbeiten einer Nachricht erfolgt genauso wie das Erstellen einer neuen Nachricht, nur mit dem Unterschied, dass zuvor die gewünschte Nachricht, die geändert werden soll, eindeutig bestimmt und der geänderte Text separat eingegeben werden muss. Nach Absenden der geänderten Nachricht bekommt der Nutzer eine Information angezeigt, ob dieser Vorgang erfolgreich gewesen ist oder nicht. Ist der Vorgang erfolgreich gewesen, muss sichergestellt sein, dass die Nachricht denitiv gespeichert ist. Zusätzlich wird die erstellte Nachricht an alle Nutzer übermittelt, damit diese über die neue Nachricht informiert werden Anwendungsfalldiagramm In folgendem Abschnitt werden die eben beschriebenen Anwendungsfälle in einem Anwendungsfalldiagramm (Abbildung 3.3) grasch dargestellt und verdeutlicht Anforderungen In diesem Kapitel werden die verschiedenen Anforderungen an die Architektur aufgestellt. Diese werden in funktionale und nicht-funktionale Anforderungen aufge-

34 28 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse Abbildung 3.3.: Anwendungsfalldiagramm teilt. Die aufgestellten Anforderungen dienen im Kapitel 2.4 als Vergleichs- und Bewertungskriterium, um die verschiedenen Lösungsansätze gegenüberzustellen. Dabei stellen die funktionalen Anforderungen ein Hilfsmittel dar, um die nicht-funktionalen Anforderungen zu bewerten. Im Folgenden werden funktionale Anforderungen mit dem Kürzel AF und einer Nummer und die nicht-funktionalen Anforderungen mit dem Kürzel NF und einer Nummer gekennzeichnet Funktionale Anforderungen In diesem Abschnitt werden alle Funktionen, die das System bereitstellen soll, kurz beschrieben. Zu jeder Funktion gehören eine Beschreibung und die erforderlichen Eingabedaten. AF-1 Nachricht schreiben Beschreibung: Der Anwender hat die Möglichkeit über ein Eingabefeld eine neue Nachricht in das System einzufügen. Dazu muss der Nutzer einen Blog auswählen und eine Notiz eingeben. Nach Absenden der Nachricht wird diese gespeichert und innerhalb des denierten Zeitraumes (NF-1) an alle Nutzer propagiert, sodass diese über die neue Nachricht informiert werden.

35 3.4. Anforderungen 29 Akteure: Anwender und externe Systeme wie XMPP- oder -Client Eingabedaten: Inhalt der Notiz Vorbedingung: Das System ist bereit eine neue Nachricht aufzunehmen. Nachbedingung: Die Nachricht ist gespeichert und alle Anwender und externe Systeme haben diese Nachricht erhalten. AF-2 über Nachrichten informieren Beschreibung: Der Anwender erhält mit Hilfe von Filtern eine Übersicht über alle, von dem Nutzer oder von anderen Nutzern erstellten Nachrichten in chronologischer Reihenfolge. Neue oder bearbeitete Nachrichten, die nach Önen einer Filterübersicht erstellt werden, werden dem Anwender nach einem denierten Zeitraum (NF-1) angezeigt oder dieser wird über ein externes System informiert. Akteure: Anwender und externe Systeme wie XMPP- oder -Client Eingabedaten: Filterkriterium Vorbedingung: Nachricht wurde erstellt Nachbedingung: Keine AF-3 Nachrichten ltern Beschreibung: Der Anwender erhält mit Hilfe verschiedener Filterkriterien die Möglichkeit, eine Übersicht über alle Nachrichten in chronologischer Reihenfolge zu bekommen, die diesem Filterkriterium entsprechen. Diese Filterkriterien können sowohl den Inhalt der Nachricht als auch Eigenschaften der Nachricht, wie zum Beispiel Erstellungsdatum, Tags, Verfasser und Blog betreen. Neue oder bearbeitete Nachrichten, die nach Önen einer Filterübersicht erstellt werden, werden dem Anwender nach einem denierten Zeitraum (NF-1) angezeigt oder dieser wird über ein externes System

36 30 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse informiert. Akteure: Anwender und externe Systeme wie XMPP- oder -Client Eingabedaten: Filterkriterium Vorbedingung: Nachricht wurde erstellt Nachbedingung: Keine AF-4 Nachricht bearbeiten Beschreibung: Der Anwender hat die Möglichkeit eine vorhandene Nachricht zu bearbeiten. Hierzu muss dieser die Nachricht eindeutig bestimmen und den geänderten Text eingeben. Nach Absenden der Nachricht wird diese gespeichert und innerhalb des denierten Zeitraumes (NF-1) an alle Nutzer propagiert, sodass diese über die neue Nachricht informiert werden. Akteure: Anwender und externe Systeme wie XMPP- oder -Client Eingabedaten: Geänderter Inhalt der Notiz Vorbedingung: Zu ändernde Nachricht wurde erstellt Nachbedingung: Die geänderte Nachricht ist gespeichert und alle Anwender und externe Systeme haben diese Nachricht erhalten. AF-5 Benachrichtigung an externe Systeme Beim Schreiben (AF-1) oder Bearbeiten (AF-4) einer Nachricht ist es möglich, andere Nutzer durch Angabe im Text direkt zu informieren. Diese Benachrichtigungen werden innerhalb des denierten Zeitraumes (NF-1) an die angegebenen Nutzer über die angebundenen externen Systeme versendet.

37 3.4. Anforderungen Nicht-Funktionale Anforderungen Abgeleitet aus den Zielen, welche in Abschnitt 1.2 deniert worden sind, werden nachfolgend die nicht-funktionalen Anforderungen, unter denen die Funktionalitäten aus Absatz zu erbringen sind, dargelegt. Diese bilden die Grundlage für die Analyse, Konzeption, Implementierung und Evaluation der skalierbaren Architekturen dieser Arbeit, sowie der Erreichung der denierten Ziele. Um den Zusammenhang der Anforderungen zu den Zielen explizit herauszustellen, werden diese zunächst genannt und den Zielen, aus denen sie abgeleitet wurden, zugeordnet. Anschlieÿend erfolgt eine umfassende Beschreibung der jeweiligen nichtfunktionalen Anforderungen. Ziel 1: Leistung der Architektur NF-1: Quality of Service NF-2: Durchsatz Ziel 2: gleichmäÿige Verteilung NF-3: Skalierbarkeit NF-4: Lastumfang Ziel 3: schnelle Konvergenz gegen konsistenten Zustand NF-5: Eziente Konvergenz gegen konsistenten Zustand NF-6: Dauerhaftigkeit Damit die Anforderungen genau quantizieren werden können, wurde im Rahmen der Analyse, welche im Abschnitt 3.1 beschrieben wurde, eine Untersuchung durchgeführt. In der Tabelle 3.1 wird ein Ausschnitt der Ergebnisse vorgestellt. Die Werte stellen die durchschnittliche und maximale Häugkeit der aufgeführten Funktionen von rund 60 Mitarbeitern pro acht Stunden Arbeitstag dar. Funktion durschn. Häugkeit pro 8h max Häugkeit pro 8h TimeLineNotes FilterBlog FilterUser FilterTag 5 30 Tabelle 3.1.: Durchschnittliche und maximale Häugkeit der Aufrufe für 60 Nutzer

38 32 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse Diese Ergebnisse der Analyse dienen zur genauen Festlegung der Werte für die nicht-funktionalen Anforderungen NF-4 Lastumfang und NF-2 Durchsatz. NF-1 Quality of Service 1994 entwarf Jakob Nielson zehn Faustregeln für die Website-Gestaltung. Nach Nielson sollte das System in einer angemessenen Zeit (d.h innerhalb weniger Sekunden) reagieren und den Systemzustand sichtbar machen [36]. Die Anforderungen an das Zeitverhalten des zu erstellenden Systems sind nicht ganz so scharf deniert, sodass das System aus Usabilitygründen nur mit Sicherheit garantieren muss, dass 95% der Nachrichten in dem Zeitraum von 10 Sekunden bis maximal 5 Minuten verbreitet sind. Dabei gilt die Anforderung an eine schnelle Konvergenz gegen einen konsistenten Zustand (NF-5). NF-2 Durchsatz Basierend auf oben genannter Analyse zur maximalen Häugkeit der Aufrufe für 60 Nutzer, welche bei dem Unternehmen Communote GmbH durchgeführt wurde, und der nicht-funktionalen Anforderung NF-4 Lastumfang ergeben sich folgende Anforderungen an den Durchsatz für die jeweilige Nutzeranzahl, welche in Tabelle 3.2 dargestellt sind. Eine weitere Analyse hat ergeben, dass ein Nutzer pro 8 Stunden Arbeitstag fünf neue Nachrichten erstellt. Die Hochrechnung des Durchsatzes für die jeweiligen Nutzerzahlen ist ebenso in der Tabelle 3.2 aufgeführt wie der aufsummierte Gesamtdurchsatz für alle Interaktionen mit dem System. Funktion TimeLineNotes 0,66 3,3 6,6 FilterBlog 0,91 4,58 9,1 FilterUser 0,33 1,6 3,3 FilterTag 0,13 0,69 1,3 neue Nachricht 0,17 0,86 1,73 Gesamt 2,2 11,03 22,63 Tabelle 3.2.: Durchsatz der Aufrufe für 1.000, und Nutzer pro Sekunde NF-3 Skalierbarkeit Inkrementelle Skalierbarkeit ist eine zentrale Anforderung des Systems. Dem System muss es möglich sein, bei wachsenden Nutzerzahlen durch Hinzufügen von zusätzli-

39 3.5. Probleme verbreiteter Realisierungen der 3-Schichten-Architektur 33 chen Ressourcen die Anforderung Quality of Service (NF-1) einzuhalten. NF-4 Lastumfang Der Enterprise Microblogging-Dienst Communote, des Unternehmens Communote GmbH, richtet sich, wie an der Bezeichnung erkennbar, vorrangig an Unternehmen. Dabei sollen Klein- und Mittelständige Unternehmen ebenso wie Groÿkonzerne die Möglichkeit haben, Communote einzusetzen. Aus diesem Grund muss das System einen gleichzeitigen Zugri von 1.000, und Nutzern standhalten. NF-5 Eziente Konvergenz gegen konsistenten Zustand Der Zeitraum, in dem verschiedene Nutzer des Systems unterschiedliche Systemzustände sehen, soll möglichst gering sein, das heiÿt die Propagierung von neuen Nachrichten an andere Server des Systems soll sehr schnell erfolgen. Werden Benachrichtigungen über neue Nachrichten an externe Systeme geschickt (AF-4), so muss sichergestellt sein, dass diese im System vorhanden sind. NF-6 Dauerhaftigkeit Das System muss sicherstellen, dass Nachrichten dauerhaft gespeichert werden, d.h. wenn der Nutzer eine Rückmeldung bekommt, dass eine Nachricht gespeichert wurde, muss garantiert sein, dass diese im System permanent vorhanden ist Probleme verbreiteter Realisierungen der 3-Schichten-Architektur Die Abbildung 3.4 zeigt eine häuge Realisierungsform der 3-Schichten-Architektur. Dabei werden jeweils die Anwendungs- und Datenschicht durch einen Server repräsentiert. Der im Abschnitt 2.2 beschriebene Ablauf des Informations- und Datenusses funktioniert in dieser Realisierungsform sehr gut für einen Nutzer oder für eine kleine Anzahl von Nutzern. Greifen jedoch zehntausende oder sogar hunderttausende Anwender auf das System zu, sind die einzelnen Server der Zugrislast dieses Implementierungskonzeptes nicht mehr gewachsen. In der Abbildung 3.5 wird gezeigt, auf welche Komponenten der Architektur sich eine erhöhte Nutzerzahl auswirkt. Der Server der Anwendungsschicht besitzt nur eine begrenzte Anzahl von Verbindungen zur Bindung von Clients. Ist eine denierte Grenze erreicht, können sich

40 34 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse Abbildung 3.4.: Realisierungen der 3-Schichten-Architektur [2] Abbildung 3.5.: 3-Schichten-Architektur mit vielen Benutzern keine neuen Clients mehr mit der Anwendungsschicht verbinden. Somit ist diesen Nutzern die Anwendung verwehrt. Mitunter hat die Anwendung, die auf dem Server der Anwendungsschicht läuft, eine rechenintensive und komplexe Logik implementiert. Rufen nun eine Vielzahl von Nutzern diese Logik auf, kann dies zur Überlastung des Servers führen. Ebenfalls kritisch ist die Ausfallsicherheit. Fällt der Server der Anwendungsschicht aus, kann das System von keinem Nutzer mehr genutzt werden. Eine weitere Komponente, welche mit einer steigenden Anzahl von Nutzern einen Flaschenhals der Architektur darstellt, ist die Verbindungsleitung zwischen der Anwendungs- und Datenschicht. Aufgrund der häug gestellten Anfragen der Anwendungsschicht an die Datenschicht und die daraus resultierende Rücksendung der Ergebnisse von der Datenschicht an die Anwendungsschicht, ist die Verbindungslei-

41 3.6. Probleme verbreiteter Realisierungen der 3-Schichten-Architektur im Kontext von 35 Social Media tung zwischen den beiden Schichten stark belastet. Je nach Durchsatz dieser Leitung erfolgt früher oder später eine Überlastung. Die Datenschicht ist für das Speichern und Laden von Daten verantwortlich. Der Server dieser Schicht besitzt nur eine begrenzte Anzahl von Schreib- und Leseoperationen auf die Daten, die in einem Zeitfenster durchgeführt werden können. Greifen nun eine Vielzahl von Nutzern auf diesen Server zu, können die Operationen nicht mehr in der gewünschten Zeit durchgeführt werden. Ebenso wie die begrenzten Operationen ist der Speicherplatz auf dem Server begrenzt. Mehr Nutzer könnten unter Umständen mehr Daten erzeugen für die, die Festplatte des Servers keinen ausreichenden Platz bietet. Gleichermaÿen wie bei der Anwendungsschicht ist der Server der Datenschicht für die Funktion der Anwendung erforderlich. Fällt dieser aus, können Funktionen der Anwendung nicht korrekt ausgeführt werden Probleme verbreiteter Realisierungen der 3-Schichten-Architektur im Kontext von Social Media Wie in dem Abschnitt erläutert, ist die horizontale Skalierung der Anwendungsschicht ein probates Mittel, um die Zugrislast auf verschiedene Anwendungsserver aufzuteilen. Hierzu wird die gleiche Anwendung auf mehrere Server verteilt, sodass nur eine Teilmenge der gesamten Nutzer mit einem System kommunizieren. Dies funktioniert sehr gut für eine ganze Reihe von Webanwendungen wie zum Beispiel Unternehmenswebseiten, E-Commerce, Buchungs- oder Bank-Anwendungen, da die Nutzer die einzelnen Aktionen, die diese Anwendungen bereitstellen, unabhängig und isoliert voneinander durchführen können. Bei transaktionalen Aktionen können diese bei einem Konikt zurückgerollt werden. Im Kontext von Social-Media stellen die Aktionen, die ein Social-Media-Dienst bereitstellen muss, Aktionen zur Kommunikation, Interaktion und Zusammenarbeit dar, bei denen Inhalte von den Nutzern erzeugt werden (User Generated Content). Dies bedeutet eine Aktion ist nicht isoliert, sondern hat zwingend Auswirkung auf andere Nutzer. Dies muss, falls kommunizierende Nutzer an unterschiedlichen Anwendungsserver angemeldet sind, über die Grenzen der Anwendungsserver hinaus funktionieren. Damit ein Anwendungsserver nicht ständig die Datenbank abfragen muss (polling), ob neue Änderungen von einem anderen Anwendungsserver in die Datenbank

42 36 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse eingepegt worden sind, muss eine zusätzliche Schicht zur Kommunikation eingeführt werden. Diese ermöglicht, dass sich die Anwendungsserver über neue Nachrichten, die ein Nutzer erstellt hat, informieren kann ohne die Persistenzschicht durch Anfragen zu belasten. Diese zusätzliche Schicht wird im Folgenden als Caching/Messaging-Tier bezeichnet und erweitert die traditionelle 3-Schichten-Architektur zu einer 4-Schichten- Architektur (siehe Abbildung 3.6). Abbildung 3.6.: 4-Schichten-Architektur Ein weiterer Vorteil dieser 4-Schichten-Architektur, neben der Entlastung der Persistenzschicht, ist die einfachere Einbindung neuer Social-Media-Streams (siehe Abbildung 3.7). Für diese Systeme gelten die selben Skalierungseigenschaften wie für die Anwendungsserver der eigentlichen Webanwendung. Als Beispiele sind in Abbildung 3.7 eine Anbindung von XMPP-Diensten, mobile Endgeräte und genannt. Für die Umsetzung des Caching/Messaging-Tier stehen eine Vielzahl von sowohl kommerzieller als auch Open-Source Produkte zur Auswahl bereit. In dem Abschnitt 2.5 wurden bereits eine Reihe von Produkten vorgestellt. Im nachfolgenden Kapitel werden diese nun betreend verschiedenster Kriterien gegenübergestellt.

43 3.6. Probleme verbreiteter Realisierungen der 3-Schichten-Architektur im Kontext von 37 Social Media Abbildung 3.7.: 4-Schichten-Architektur

44 38 Kapitel 3. Anwendungsfälle, Anforderungen und Problemanalyse

45 Kapitel 4. Vorabanalyse In diesem Kapitel werden die im Abschnitt 2.5 vorgestellten Systeme einer Vorabanalyse unterzogen, um deren Eignung für die Umsetzung einer skalierbaren Architektur festzustellen. Hierzu ndet eine Betrachtung sowohl aus objektiver Perspektive, anhand von Lasttests, als auch unter nicht performancebezogener und subjektiver Perspektive statt Lasttests In diesem Abschnitt wird auf die ausgeführten Lasttests eingegangen, deren Ergebnisse als objektives Bewertungskriterium zur Auswahl eines geeigneten Produktes dienen sollen Beschreibung und Testsetup Zur Testdurchführung standen drei virtuelle Maschinen (VMs) auf einem Intel Xeon E5620 mit 2.4GHz und zirka 4GB RAM zur Verfügung. Diese waren über einen SSH- Tunnel erreichbar (siehe Abbildung 4.1). Die Lasttests wurden mit dem Programm Apache JMeter durchgeführt, wobei diese verteilt und entfernt durchgeführt wurden (vgl. [17]). Hierbei kam die Tatsache, dass dies durch einen SSH-Tunnel stattnden musste, erschwerend hinzu. Um dies zu ermöglichen musste JMeter angepasst werden [32]. Für die jeweiligen Tests wurde für jedes Produkt ein separates Testprogramm erstellt, welches die von JMeter benötigte Schnittstelle implementiert, sodass diese mittels JMeter gestartet, instrumentiert und ausgewertet werden konnte (vgl. Abbildung 4.2). Die Rollen der einzelnen Akteure für die Tests wurden unterschiedlich auf die drei VMs verteilt. Bei den zentralen Produkten RabbitMQ, ActiveMQ, Node.js und ejabberd wurde eine VM genutzt, um den jeweiligen Server darzustellen. Die anderen VMs dienen als Instanzen, die auf diesen zentralen Server zugreifen und 39

46 40 Kapitel 4. Vorabanalyse Abbildung 4.1.: Testumgebung Abbildung 4.2.: UML-Diagramm der Testimplementierungen

47 4.1. Lasttests 41 ihn so unter Last setzen. In den dezentralen Produkten, wie Hazelcast und Scribe, wurden alle drei VMs gleichberechtigt betrachtet und auf jedem dieser drei Server eine JMeter-Instanz zum Testen gleichzeitig gestartet. Nach Abschluss der jeweiligen Tests wurden die Testergebnisse auf dem JMeter-Client konsolidiert und für die Analyse aufbereitet. Allen Implementierungen ist gleich, dass sie das Publish/Subscribe-Paradigma umsetzen, welches, wie in Abschnitt erwähnt, zahlreiche Vorteile bei der Serverzu-Server-Kommunikation bietet. Jedes Produkt interpretiert dieses Paradigma auf seine ganz eigene Art und Weise, so werden zum Beispiel bei Scribe, Node.js und ejabberd Topics bzw. Nodes angelegt. Diese können von Subscribern abonniert und von Sendern als Ziel für Nachrichten verwendet werden. Bei RabbitMQ wird dies durch Bindings zwischen der Nachrichtenwarteschlange und dem Exchange ausgedrückt. Für die Produkte Hazelcast und ActiveMQ gibt es keine solche Elemente. Hier setzt ein Subscriber einen Eventlistener auf eine Datenstruktur bzw. abonniert eine gesamte Warteschlange. Da es für den produktiven Einsatz von hoher Bedeutung ist zu wissen, wie lange es dauert ein Abonnoment abzuschlieÿen, wurde dieses Zeitverhalten ebenfalls durch Lasttests untersucht. Den Hauptteil des Lasttests stellt jedoch die Messung der Durchsatzrate der Nachrichten dar. Diese wird in Nachrichten pro Sekunde, kurz M/s gemessen. Im Nachfolgenden werden die Lasttestergebnisse tabellarisch für jedes Produkt dargestellt. Dabei wird zunächst auf das Zeitverhalten bei der Herstellung einer Publish/Subscribe-Verbindung eingegangen und anschlieÿend auf die Durchsatzrate der Nachrichten. Auf eine Deutung und Auswertung der Ergebnisse wird in dem folgenden Abschnitt verzichtet, da dies bereits in dem darauolgenden Absatz durchgeführt wird Ergebnisse RabbitMQ In der Tabelle 4.1 ist die durchschnittliche Dauer in Millisekunden dargestellt, die RabbitMQ benötigt, um eine bestimmte Anzahl von Bindings zu erzeugen. Eine Verdoppelung der Bindinganzahl führt in etwa zu einer Verdoppelung der durchschnittlichen Dauer. Bei dem Nachrichtendurchsatz, welcher in Nachrichten pro Sekunde (Messages per Seconds, kurz M/s) gemessen wird, zeigt sich RabbitMQ sehr stark. Selbst bei einer

48 42 Kapitel 4. Vorabanalyse Anzahl Bindings durchschn. Dauer in ms Standardabweichung Tabelle 4.1.: RabbitMQ: Erstellung der Bindings sehr hohen Binding- und Postanzahl werden durchschnittlich Nachrichten pro Sekunde versendet. Bindings Posts Delay in ms Durchsatz M/s Standardabweichung Tabelle 4.2.: RabbitMQ: Nachrichtendurchsatz Node.js Die Erstellung von Topics ist bei Node.js wesenlich kürzer als die Erstellung der Bindings bei RabbitMQ. Dafür erzeugt Node.js jedoch bei dieser Aktion eine höhere CPU-Auslastung. Diese ist ab einer Topicanzahl von mehr als so groÿ, dass das komplette System stehen bleibt und somit keine weiteren Messungen durchgeführt werden können. Anzahl Topics durchschn. Dauer in ms Standardabweichung Tabelle 4.3.: Node.js: Erstellung von Topics In der Tabelle 4.4 ist die Nachrichten-Durchsatzrate für die jeweilige Anzahl von Topics und Posts aufgeführt. Bei einer hohen Anzahl von Topics kam es immer öfter

49 4.1. Lasttests 43 dazu, dass das System überlastet war und beim Übermitteln von Nachrichten Fehler auftraten. Dies konnte durch Heraufsetzen des Sendeintervalls an einigen Stellen behoben werden. Ab einer Topicanzahl von mehr als war dies jedoch nicht mehr möglich. Topics Posts Delay in ms Durchsatz M/s Standardabweichung Fehler Fehler Fehler - Tabelle 4.4.: Node.js: Nachrichtendurchsatz ActiveMQ Die Geschwindingkeit mit der bei ActiveMQ Nachrichten übermittelt werden können, entspricht in etwa der von RabbitMQ. Das System ist ebenso belastbar, sodass dieses auch einer sehr hohe Anzahl von Posteinträgen standhält und diese mit ca Nachrichten pro Sekunde überträgt. Posts Delay in ms Durchsatz M/s Standardabweichung x Tabelle 4.5.: ActiveMQ: Nachrichtendurchsatz Hazelcast Bei Hazelcast werden die Nachrichten (Posts) auf die Mitglieder des Hazelcast- Clusters verteilt abgelegt. Dies geschieht mit einer guten Durchsatzrate. Im durchgeführten Test wird ein Hazelcast-Cluster mit drei Knoten zusammengestellt, wobei ein

50 44 Kapitel 4. Vorabanalyse Knoten aktiv die Nachrichten sendet. Der Test hat ergeben, dass Nachrichten mit zirka 1400 Nachrichten pro Sekunde auf die drei Knoten verteilt werden. Posts Delay in ms Durchsatz M/s Standardabweichung Tabelle 4.6.: Hazelcast: Nachrichtendurchsatz Scribe Ebenso wie Hazelcast verfolgt Scribe einen dezentralen Ansatz. Für den Test wurde deshalb jeweils eine Instanz auf einer VM gestartet, wobei eine Instanz aktiv die Nachrichten sendet. Im Schnitt wurden 180 Nachrichten pro Sekunde bis zu einer Topicanzahl von propagiert. Bei einer Topicanzahl ab kommt es aufgrund der hohen CPU-Auslastung zu Fehlern bei der Übersendung von Nachrichten. Topics Posts Delay in ms Durchsatz M/s Standardabweichung Fehler - Tabelle 4.7.: Scribe: Nachrichtendurchsatz ejabberd Mit ejabberd wurde ein weiterer zentraler Vertreter getestet. Dieser wurde aufgrund seiner sehr guten Performancewerte und dem verbreiteten Einsatz im Unternehmensumfeld in die Vorabanalyse mit aufgenommen. Leider konnten diese Werte in dem Test nicht bestätigt werden. So kam es beim Anlegen von Knoten (Topics) zu Fehlern aufgrund der hohen CPU-Auslastung. Im Gegensatz dazu zeigte sich die Durchsatzrate sehr stabil. Hier konnte bei der Steigerung der Nachrichtenzahl von auf und gleichzeitiger Verzehn-

51 4.1. Lasttests 45 Anzahl Nodes durchschn. Dauer in ms Standardabweichung Fehler - Tabelle 4.8.: ejabberd: Erstellung der Nodes fachung der Node-Anzahl ein konstanter Durchsatz von zirka 240 Nachrichten pro Sekunde erzielt werden. Nodes Posts Delay in ms Durchsatz M/s Standardabweichung Tabelle 4.9.: ejabberd: Nachrichtendurchsatz Zusammenfassung Sehr gute Lasttestergebnisse lieferte RabbitMQ sowohl bei der Erstellung von Bindings als auch bei der Nachrichtendurchsatzrate. Eine Verdoppelung der Anzahl der Bindings führte jeweils zu einer Verdoppelung der Zeit, die für das Anlegen dieser Bindings benötigt wurde. Der Nachrichtendurchsatz bei RabbitMQ bei Nachrichten ist mit 4301 Nachrichten pro Sekunde sehr hoch. Dies trit ebenso für Hazelcast und ActiveMQ zu. Hier lagen die Nachrichtendurchsätze bei Hazelcast bei 1474 und bei ActiveMQ bei 3612 Nachrichten pro Sekunde. Nicht ganz so gute Lasttestergebnisse konnten bei den Produkten Node.js, Scribe und ejabberd erreicht werden. Hier führte die Erstellung von einer groÿen Anzahl von Topics bzw. Nodes dazu, dass die Systeme überlastet waren. Bei ejabberd kam es deswegen zu Fehlermeldungen. Bei Scribe und Node.js führte das Erstellen von Topics dazu, dass die VM zu 99,9% ausgelastet war und auf keine Eingaben mehr reagierte. Bei Scribe und ejabberd war die Durchsatzrate der Nachrichten bei einer Nachrichtenanzahl von , bei Scribe mit rund 178 bzw. bei ejabberd mit rund 241 Nachrichten pro Sekunde, gut. Mit Node.js hingegen konnten bei einer Nodeanzahl von noch rund 98 Nachrichten pro Sekunde versendet werden. Nach Erhöhnung der Nodeanzahl auf sank die Durchsatzrate jedoch auf 14 Nachrichten pro Sekunde herab und lag mit diesem Wert so niedrig wie keines der anderen Produkte.

52 46 Kapitel 4. Vorabanalyse 4.2. Nicht performancebezogener und subjektiver Vergleich der Systeme In diesem Abschnitt ndet ein Vergleich unter einer nicht performancebezogenen und ganz subjektiven Perspektive statt. Hierbei wird eine Aussage zu folgenden Schwerpunkten gegeben, welche in den Tabellen 4.10 und 4.11 gegenübergestellt werden: Architektur: Wie erstreckt sich das Produkt in der Infrastruktur? Details: Welche Technologie wird verwendet? Verbreitung: Wie viel Zuspruch erfährt das Produkt? Reifegrad: Ist die Entwicklung des Produktes ausgereift? Dokumentation: Wie ausführlich ist die Dokumentation und erleichtert diese die Umsetzung? Community: Wie aktiv ist die Community des Produktes? Integration: Wie lässt sich das Produkt in Anwendungen integrieren? RabbitMQ Zentraler Dreh- und Angelpunkt bei der RabbitMQ-Implementierung ist der Nachrichtenbroker, welcher aufgrund seiner guten Performanceeigenschaften sehr verbreitet ist. Aufgrund der Tatsache, dass dieser den AMQP Standard implementiert und seit einigen Jahren stetig verbessert wird, ist der Reifegrad sehr hoch, nicht zuletzt aufgrund der sehr aktiven Community, welche in Foren und Mailinglisten aktiv diskutieren. Den Einstieg erleichtert ein ausführliches Tutorial auf der Webseite von RabbitMQ. Für zahlreiche Programmiersprachen gibt es Clients, um mit dem RabbitMQ-Message-Broker mittels AMQP zu kommunizieren Scribe Seit der Veröentlichung im Jahr 2001 wurde Scribe jahrelang weiter entwickelt. Leider scheint dies nur bis zum Jahre 2009 geschehen zu sein. Seitdem ist die letzte stabile Version 2.1 veröentlicht worden. Genauso stehen geblieben scheinen die Aktivitäten der Community zu sein. In Mailinglisten wird nur ab und zu ein neuer Eintrag erstellt. Der dezentrale Ansatz der mit Scribe verfolgt wird, ist sehr interessant. Der Einstieg wird durch das Vorhandensein von nur einem Tutorial erschwert. Die

53 4.2. Nicht performancebezogener und subjektiver Vergleich der Systeme 47 Implementierung in Java setzt voraus, dass das gesamte Programm, welches Scribe verwendet, in Java geschrieben sein muss Node.js Node.js ist noch ein sehr junges Produkt, welches aktuell die Version trägt. Die Community wächst sehr schnell, genauso wie das Interesse daran. Die Dokumentation wird stetig ausgebaut und um eine Vielzahl von Beispielen erweitert. Eine Reihe von namhaften Unternehmen wie ebay, LinkedIn, Microsoft und Yahoo! setzen dieses Produkt schon produktiv ein Hazelcast In zahlreichen Fachzeitschriften, wie dem Javamagazin und dem Javaspektrum wurde von Hazelcast ausführlich berichtet. Die Beispiele in den Zeitschriften und in der ausführlichen Dokumentation auf der Website, welche auch Einblick geben wie Hazelcast grundsätzlich funktioniert, erleichtern den ersten Umgang mit Hazelcast. Die Programmierung ist sehr einfach und funktioniert problemlos. Die zahlreichen Testemonials, welche auf der Webseite aufgeführt sind, lassen auf eine recht gute Verbreitung schlieÿen. In der Hazelcast Google Gruppe wird über Probleme und deren Lösung diskutiert ejabberd Der in Erlang geschriebene Jabber/XMPP Instant-Messaging-Server wird aufgrund der Implementierung des XMPP-Standards sowohl für Instant Messagaging als auch für Server-zu-Server-Kommunikation von vielen Unternehmen eingesetzt. Die Community ist sehr aktiv und bestrebt ejabberd weiterzuentwickeln. Für XMPP gibt es zahlreiche Clients, die es ermöglichen mittels ejabberd zu kommunizieren. Die Dokumentation ist sehr gut, nur bei der Dokumentation der Sicherheitskonguration könnte der Einstieg durch Beispiele erleichert werden, um so Problemen bei der Benutzung vorzubeugen ActiveMQ Das Apache Top-Level-Projekt AcviveMQ unterstützt eine breite Masse an unterschiedlichen Clients für verschiedenste Programmiersprachen und Protokolle von Java, C, C++, C# Ruby, Perl, Python bis PHP. ActiveMQ kann sowohl als zentrale, standalone Servervariante oder in einer Anwendung eingebettet betrieben werden.

54 48 Kapitel 4. Vorabanalyse Durch den Apache Background und deren sehr groÿe und aktive Community ndet ActiveMQ sehr starke Verbreitung. Zahlreiche Bücher über Java Message Service oder ActiveMQ erleichtern den Einstieg mit ActiveMQ genauso wie die sehr gute Dokumentation Zusammenfassung RabbitMQ Scribe Node.js Hazelcast ejabberd ActiveMQ Architektur zentral dezentral zentral dezentral zentral zentral Details MQ Multicast Node.js IMDG XMPP MQ Verbreitung weit gering wächst gering weit weit Tabelle 4.10.: nicht performancebezogene Gegenüberstellung der Systeme RabbitMQ Scribe Node.js Hazelcast ejabberd ActiveMQ Reifegrad ausgereift mittel jung gut ausgereift ausgereift Dokumentation sehr gut mäÿig mäÿig gut gut gut Community aktiv inaktiv wächst aktiv aktiv aktiv Integration gut Java gut Java gut gut Tabelle 4.11.: subjektive Gegenüberstellung der Systeme Die aktivsten Communities besitzen die Produkte RabbitMQ, ejabberd und ActiveMQ. Hier wird sowohl in den Mailinglisten der Produkte als auch in denen der Standards, die sie jeweils implementieren, intensiv über Probleme und die Weiterentwicklung diskutiert. Anders verhält es sich hingegen bei Scribe, wo die Weiterentwicklung seit 2009 stehen geblieben zu seien scheint. Die Dokumentation bei RabbitMQ, Hazelcast und ActiveMQ ist hervorhebenswert, im Gegensatz zu Scribe, wo nur ein Tutorial bei dem Einstieg und dem Verständnis der Programmierung helfen soll. Ebenso dürftig dokumentiert ist die Sicherheitskonguration von ejabberd. Das Fehlen dieser Dokumentation führte zu einer langwierigen Fehlersuche Auswahl zur Umsetzung einer skalierbaren Architektur Hinsichtlich der in dem Abschnitt geforderten nicht-funktionalen Anforderung: NF-2 Durchsatz erfüllen alle betrachteten Produkte den für Nutzer ermittelten Wert bei der Erstellung von Nachrichten von zirka 2 Nachrichten pro Sekunde.

55 4.2. Nicht performancebezogener und subjektiver Vergleich der Systeme 49 Deshalb haben, für die Auswahl der Produkte, die nicht performancebezogenen und subjektiven Vergleiche der Systeme, die Entscheidung festgelegt. Die Produkte RabbitMQ, ActiveMQ, ejabberd und Hazelcast zeichneten sich bei dem Vergleich durch ihre weite Verbreitung, ausgereiften Entwicklungsstand, sehr guter Dokumentation, aktiver Community und guter Integration, gegenüber Scribe und Node.js, aus. Die zusätzliche Möglichkeit von ActiveMQ und Hazelcast diese in Java-Anwendungen zu integrieren und somit eine zusätzliche Infrastrukturkomponente zu vermeiden, bringt einen Vorteil gegenüber RabbitMQ und ejabberd und führt zur Auswahl dieser Produkte für die Umsetzung zweier Architekturansätze zur Realisierung einer skalierbaren Architektur im Kontext von Social-Media-Streams. Wie die zwei Architekturkonzepte konkret umgesetzt werden, wird in dem nachfolgenden Kapitel beschrieben, bevor die beiden Konzepte in dem Kapitel 6 in einer Evaluation bezüglich ihrer Eignung zur Umsetzung einer skalierbaren Architektur für Social-Media-Stream-Anwendungen gegenübergestellt werden.

56 50 Kapitel 4. Vorabanalyse

57 Kapitel 5. Konzeption Dieses Kapitel beschreibt zwei Architekturkonzepte sowie das Datenmodell eines Caches für eine skalierbare Architektur. Im ersten Schritt werden zunächst die zwei unterschiedlichen Architekturen vorgestellt, die zur Realisierung einer skalierbaren Architektur genutzt werden können. In dem darauolgenden Abschnitt wird ein Einblick in die Systemschnittstellen und die Konzepte der Datenablage, der für die in Abschnitt 3 vorgestellten Anforderungen, gegeben. Die unterschiedlichen Konzepte führen zu unterschiedlichen Implementierungen, welche im nachfolgenden Kapitel zu denen im Kapitel 3 denierten nicht-funktionalen Anforderungen evaluiert und anschlieÿend verglichen werden. Die aufgeführte Abbilung 5.1 zeigt eine Übersicht über die verschiedenen Implementierungen für die umzusetzenden Architekturen. Was sich inhaltlich hinter den Begrien und Bezeichnungen verbirgt, wird, wie eingangs erwähnt, in diesem Kapitel in den einzelnen Abschnitten näher erläutert. Abbildung 5.1.: Übersicht über Architektur- und Implementierungskombination 51

58 52 Kapitel 5. Konzeption Abbildung 5.2.: Architektur mit lokalem Cache 5.1. Grundlegende Architektur In diesem Abschnitt werden zwei Architekturvorschläge dargestellt und erläutert wie die im Abschnitt 3.6 vorgestellte Cache- und Messaging-Schicht der 4-Schichten- Architektur umgesetzt werden kann. Hierzu werden, ergänzend zu der Beschreibung, UML-Deployment-Diagramme genutzt, um die Architekturkomponenten und deren Interaktionen zu verdeutlichen. Diese Form der Visualisierung erlaubt es die Architekturen technologieunabhängig zu beschreiben Architektur mit lokalem Cache Die nachfolgende Abbildung 5.2 zeigt den ersten der zwei Architekturvorschläge. In diesem wird die Social-Media-Anwendung in einer Laufzeitumgebung, dem Application-Container, welcher sich in einem Anwendungsserver bendet, ausgeführt. Die Social-Media-Anwendung beinhaltet die Kernkomponente (Core), welche die Grundfunktionalitäten der Anwendung bereitstellt. Diese Komponente wird um die Komponente Store und MQ erweitert. Die Message-Queue-Komponente, kurz MQ, ist zuständig für die Weiterleitung und Entgegennahme von Nachrichten zu bzw. von anderen Social-Media-Anwendungen. Die Store-Komponente übernimmt das Laden und Speichern von Daten. Hierfür

59 5.1. Grundlegende Architektur 53 Abbildung 5.3.: Architektur mit verteiltem Cache stehen der Komponente drei verschiedene Ziele zur Verfügung. Zum einen der lokale Cache, welcher zur performanten Abspeicherung von häug angefragten Daten genutzt wird. Zum anderen die Datenbank, die sowohl Daten dauerhaft ablegt als auch Daten liefert, die über die im Cache verfügbaren hinausgehen. Als weiteres Ziel steht die Message-Queue-Komponente zur Verfügung. Diese wird von der Store- Komponente genutzt, um andere Social-Media-Anwendungen über neu verfügbare Daten zu informieren Architektur mit verteiltem Cache Anders als in dem im Abschnitt beschriebenen Architekturvorschlag bendet sich der Cache bei diesem Architekturvorschlag nun nicht mehr lokal zusammen mit der Social-Media-Anwendung in der Laufzeitumgebung, sondern auf separaten Cache-Servern. Diese sind gemeinsam mit der Gesamtarchitektur in der Abbildung 5.3 zu sehen. Ebenso wie die Social-Media-Anwendung in der Architektur mit lokalem Cache

60 54 Kapitel 5. Konzeption aus dem Abschnitt besteht diese Social-Media-Anwendung aus verschiedenen Komponenten, wobei die Kernkomponente (Core) die Grundfunktionalitäten der Anwendung bereitstellt und die Store-Komponente das Laden und Speichern von Daten übernimmt. Wie bereits erwähnt wird in diesem Architekturkonzept ein verteilter Cache verwendet. Dieser wird zur performanten Abspeicherung von häug angefragten Daten genutzt. Darüber hinaus steht die Datenbank, die zum einen Daten dauerhaft ablegt und zum anderen Daten liefert, die über die verfügbaren Daten des Caches hinausgehen, zur Verfügung. Die Zuordnung welche Daten von welcher Datenbasis geholt bzw. in welche Datenbasis geschrieben werden, übernimmt die Store-Komponente. Für die Anwendung erscheint der verteilte Cache wie ein logisch zusammenhängender Cache. Ob diese Cache-Server untereinander, zum Beispiel zur Datenreplikation, verbunden seien müssen, hängt von dem verwendeten Produkt ab. Die Funktionalität könnte ebenso von der Store-Komponente übernommen werden. Die optionale Verbindung zwischen den Cache-Servern ist unabhängig davon in der Abbildung 5.3 eingezeichnet Konzeptdetails der Architektur In diesem Abschnitt wird auf Konzeptdetails der im vorherigen Abschnitt grundlegenden Architektur näher eingegangen. Hierzu werden zunächst die Systemschnittstellen vorgestellt, bevor das Datenmodell der Architektur genauer betrachtet wird Schnittstellen des Systems Basierend auf den Anwendungsfalldenitionen aus dem Kapitel 3 werden im nachfolgenden Abschnitt die daraus abgeleiteten Systemschnittstellen und deren Operationen vorgestellt. Erstellen einer neuen Nachricht Um Nachrichten erstellen zu können, bietet das System eine System-Schnittstelle zum Erstellen einer neuen Nachricht an, was in Abbildung 5.4 verdeutlicht wird. Hierbei muss der Inhalt der neuen Nachricht als PostDetail deniert werden. Als Rückmeldung liefert die Schnittstelle ein Boolean-Wert, welcher den Erfolg dieser Aktion repräsentiert.

61 5.2. Konzeptdetails der Architektur 55 Abbildung 5.4.: System-Schnittstelle zum Erstellen einer neuen Nachricht Abbildung 5.5.: System-Schnittstelle zum Bearbeiten einer vorhandenen Nachricht Bearbeiten einer vorhandenen Nachricht Neben dem Erstellen von Nachrichten wurde im Kapitel 3 eine Möglichkeit gefordert, bereits erstellte Nachrichten bearbeiten zu können. Hierzu muss zunächst die gewünschte Nachricht ausgewählt werden. Anschlieÿend kann diese unter Verwendung einer eindeutigen Identikationsnummer und einem neuen Inhalt überschrieben werden. Der Erfolg dieser Aktion wird mittels eines Boolean-Wertes bestätigt. Die Schnittstellendenition ist in Abbildung 5.5 zu sehen. Filtern von Nachrichten Um sich eine Übersicht über bereits erstellte Nachrichten zu verschaen, wird eine System-Schnittstelle zum Filtern von Nachrichten zur Verfügung gestellt. Dieses ist in Abbildung 5.6 deniert. Der Schnittstelle können einer Reihe von zusammengestellten Filterkriterien übergeben werden. Das System erstellt anhand dieser Kriterien eine Filteransicht mit Nachrichten, deren Eigenschaften die festgelegten Kriterien erfüllen.

62 56 Kapitel 5. Konzeption Abbildung 5.6.: System-Schnittstelle zum Filtern von Nachrichten Datenmodell des Caches Nachfolgend wird beschrieben, wie die einzelnen Nachrichten, Berechtigungen und Filter in dem Cache abgelegt werden. Die Cacheeinträge stellen die Daten der Funktionen, welche in Kapitel 3 als funktionale Anforderungen deniert wurden, dar. Bei den ersten Überlegungen zur Gestaltung des Datenmodells des Caches haben sich zwei mögliche Umsetzungen herausgestellt. Zum einen der lterbasierte Cache und zum anderen der datenbasierte Cache. Bei dem lterbasierten Cache werden die Nachrichten entsprechend der ausgeführten Filteranfragen im Cache abgelegt. Dies ermöglicht eine sehr eziente Abfrage von Nachrichten bezüglich ihrer Filterparameter. Der Nachteil dieser Methode ist jedoch, dass beim Einfügen einer neuen Nachricht alle Filtereinträge, die im Cache angelegt sind und deren Filterkriterien den Eigenschaften der neuen Nachricht entsprechen, invalidiert werden müssen. Diesen Nachteil besitzt der datenbasierte Cache nicht. Bei dieser Form der Abspeicherung werden die Daten unabhängig von den Filtern in einer lter-neutralen Repräsentation abgelegt. Das Einfügen kann so sehr schnell erfolgen. Das Erstellen von Ergebnismengen basierend auf Filteranfragen ist hingegen sehr langsam, da der komplette Datenbestand auf das gewünschte Filterkriterium hin untersucht werden muss. Unterstützt durch Dienste wie RSS oder Funktionen wie das Auto-Refresh von Webseiten ist die Anzahl der Filterungen, die auf vorhandene Nachrichten ausgeführt werden, gröÿer als die Anzahl der neuen Nachrichten, die in dem Cache eingefügt werden müssen. Dies führt zu der Schlussfolgerung, dass die Umsetzung des lterbasierten Caches geeigneter ist als die des datenbasierten Caches. Deshalb wird im folgenden Abschnitt auch nur auf das Konzept zur Realisierung des lterbasierten Caches eingegangen. Bei einigen Anforderungen gibt es nicht nur eine, sondern mehrere Möglichkeiten diese geeignet im Cache abzulegen. Sie führen schlieÿlich zu unterschiedlichen

63 5.2. Konzeptdetails der Architektur 57 Varianten. Die verschiedenen Konzepte führen zu unterschiedlichen Implementierungen, welche im nachfolgenden Kapitel im Hinblick auf die im Kapitel 3 denierten nicht-funktionalen Anforderungen evaluiert und verglichen werden. Im Folgenden wird beschrieben, wie die einzelnen Nachrichten und Filter in dem Cache abgelegt werden. Dabei wird zunächst gezeigt, wie das Schlüssel-Wert-Paar in dem Cache gespeichert wird. Anschlieÿend wird in einem Pseudoalgorithmus und anhand eines Beispiels gezeigt wie sich dieser Cacheeintrag verhält, wenn a) eine neue Nachricht in dem Cache abgelegt wird und b) ein neuer Filter von einem Nutzer angelegt wird. Die Konventionen bei der Angabe der Cacheeinträge entsprechen der Folgenden: KEY - VALUE [optional : Kurze Erläuterung.] Nachrichten speichern Eine Nachricht wird unter dem Schlüssel message: zusammen mit einer eindeutigen Identikationsnummer dieser Nachricht und der Nachricht als Wert in dem Cache abgelegt. Dies geschieht jedesmal, wenn eine neue Nachricht in dem System eingepegt oder ein Filter Nachrichten aus der Datenbank in den Cache geladen wird. Der Eintrag des Caches gestaltet sich folgendermaÿen: message:{#msgid} - { message } : Speichert eine Nachricht und deren Informationen. Die Nachricht selbst wird als JSON-Wert abgespeichert. Ist nun beispielsweise eine neue Nachricht mit der Identikationsnummer 1, dem Inhalt Hallo Welt!, von Nutzer user1, im Blog blog1 mit dem Tag tag1 im Cache abgespeichert worden, so sieht der Cacheeintrag folgendermaÿen aus: message:1 - { id : 1, message : Hallo Welt!, user : user1, blog : blog1, tags : [tag1]} Variante 1: Berechtigungen speichern In diesem Abschnitt wird eine Variante vorgestellt, um Berechtigungen im Cache abzuspeichern. Hierzu wird unter dem Schlüssel user_right_ zusammen mit der eindeutigen Identikationsnummer des Blogs und der eindeutigen Identikationsnummer des Nutzers ein Wert von 0 bis 3 abgelegt. Dabei repräsentiert der Wert 0, dass der jeweilige Nutzer keine Rechte für den jeweiligen Blog besitzt. Bei dem Wert

64 58 Kapitel 5. Konzeption 1 verfügt dieser über Leseberechtigung, bei Wert 2 Schreibberechtigung und bei Wert 3 die VerwaltenBerechtigung für den jeweiligen Blog. Schematisch gestaltet sich der Cacheintrag dann wie folgt: user_right_{#blogid}:{#userid} - {0, 1, 2, 3} : (0 = keine, 1 = lesen, 2 = schreiben, 3 = verwalten). Das folgende Beispiel zeigt einen Eintrag für den Blog blog1, für welchen der Nutzer namens user1 aktuell eine Leseberechtigung besitzt: user_right_blog1:user1-1 Variante 2: Berechtigungen speichern In der Variante der Berechtigungsspeicherung werden zu jeder Berechtigung pro Nutzer eine kommaseparierte Liste von Blog-Identikationsnummern abgelegt. blog_rights_read:{#userid}: - [ blog_ids] : Speichert die Blog IDs, für die der jeweilige Nutzer die Berechtigung besitzt, diese zu lesen. blog_rights_write:{#userid}: - [ blog_ids] : Speichert die Blog IDs, für die der jeweilige Nutzer die Berechtigung besitzt, in diesen zu schreiben. blog_rights_manage:{#userid}: - [ blog_ids] : Speichert die Blog IDs, für die der jeweilige Nutzer die Berechtigung besitzt, diese zu verwalten. Das folgende Beispiel zeigt einen Eintrag für den Nutzer user1, welcher aktuell Leseberechtigungen für Blog 1,2 und 3 besitzt: blog_rights_read:user1 - [ 1,2,3 ] Speicherung der Nachrichten eines Blogs Die Nachrichten eines Blogs werden unter dem Schlüssel blog_messages: zusammen mit der Identikationsnummer des Blogs abgelegt. Der Wert dieses Schlüssels bildet eine nach Datum absteigend, kommaseparierte Liste von Nachrichtenidentikationsnummern. In der Liste werden jedoch nur Nachrichten eines Blogs gespeichert, welche keine Direkt-Nachrichten an Nutzer sind, denn diese werden separat abgelegt (siehe 5.2.2) und müssen bei entsprechenden Filtern vereinigt werden. Wie dies funktioniert wird z.b. in Abschnitt gezeigt. blog_messages:{#blogid} - [ msg_ids ] : Speichert die 150 aktuellsten Nachrichten IDs zu dem jeweiligen Blog (ohne Direct Messages).

65 5.2. Konzeptdetails der Architektur 59 Das folgende Beispiel zeigt einen Eintrag für Blog blog1, welcher aktuell 3 Nachrichten enthält: blog_messages:blog1 - [ 3,2,1 ] Nachfolgend wird in Pseudoalgorithmen gesezeigt, wie sich der Cache beim Aufrufen des Blog-Tabs und beim Hinzufügen einer neuen Nachricht zu einem Blog verhält. Listing 5.1: Hinzufügen einer Nachricht Message message =... ; // Message in blog1 Cache. set (" message :" + message.id, message ); List msglist ; if ( Cache. get (" blog_messages :" + message. blog )!= NULL ) { msglist = Cache. get (" blog_messages :" + message. blog ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" blog_messages :" + message. blog, msglist ); } Listing 5.2: Aufrufen der Nachrichten eines Blogs long user =... ; // current user long blogid =... ; // the id of the blog List msglist ; if ( userhasrightsforblo g ( blogid, user ) { if ( Cache. get (" blog_messages :" + blogid ) == NULL ) { msglist = getblogmessagesfromdb ( blogid ); Cache. set (" blog_messages :" + blogid, msglist ) } else { msglist = Cache. get (" blog_messages :" + blogid ); } } for ( long msgid : msglist ){... = Cache. get (" message :" + msgid );... } Speicherung der Direkt-Nachrichten eines Nutzers Die Direkt-Nachrichten eines Nutzers werden unter dem Schlüssel direct_messages: zusammen mit der Identikationsnummer des Nutzers abgelegt. Der Wert dieses

66 60 Kapitel 5. Konzeption Schlüssels bildet eine nach Datum absteigend, kommaseparierte Liste von Nachrichtenidentikationsnummern. direct_messages:{#userid} - [ msg_ids ] : Speichert die 150 aktuellsten Nachrichten IDs der Direct Messsages eines Nutzers. Das folgende Beispiel zeigt einen Eintrag für Nutzer user1, welchem aktuell 3 Direkt-Nachrichten zugestellt worden sind: direct_messages:user1 - [ 6,5,4 ] In dem nachfolgenden Pseudoalgorithmen wird gesezeigt, wie sich der Cache beim Filtern der Direkt-Nachrichten und beim Hinzufügen einer neuen Nachricht verhält. Listing 5.3: Hinzufügen einer Nachricht Message message =... ; // Message in blog1 Cache. set (" message :" + message.id, message ); List msglist ; List userlist = ge tdir ectm ess ageu sers ( message ) for ( long user : userlist ){ if ( Cache. get (" direct_ messages :" + user )!= NULL ) { msglist = Cache. get (" direct_messages :" + user ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" direct_messages :" + user, msglist ); } } Listing 5.4: Aufrufen der Direkt-Nachrichten long user =... ; // current user List directmsglist ; if ( Cache. get (" direct_messages :" + user ) == NULL ) { directmsglist = getdirectmessagesfromdb ( user ); Cache. set (" direct_messages :" + user, directmsglist ); } else { directmsglist = Cache. get (" direct_ messages :" + user ); } for ( long msgid : directmsglist ){... = Cache. get (" message :" + msgid );... }

67 5.2. Konzeptdetails der Architektur 61 Speicherung des Nachrichten für werden unter dem Schlüssel me_tab: zusammen mit der Identikationsnummer des Nutzers abgelegt. Der Wert dieses Schlüssels bildet eine nach Datum absteigende, kommaseparierte Liste von Nachrichtenidentikationsnummern. me_tab:{#userid} - [ msg_ids ] : Speichert die 150 aktuellsten Nachrichten IDs, die an den jeweiligen Nutzer gerichtet sind. Das folgende Beispiel zeigt einen Eintrag für Nutzer den user1, an welchen aktuell 3 Nachrichten übermittelt worden: me_tab:user1 - [ 3,2,1 ] Nachfolgend wird in Pseudoalgorithmen gezeigt, wie sich der Cache beim Aufrufen und beim Hinzufügen einer neuen Nachricht verhält. Listing 5.5: Aufrufen long user =... ; // current user List msglist ; if ( Cache. get (" me_tab :" + user ) == NULL ) { } msglist = getmemessagesfromdb ( user ); Cache. set (" me_tab :" + user, msglist ); else { } msglist = Cache. get (" me_tab :" + user ); for ( long msgid : msglist ){ }... = Cache. get (" message :" + msgid );... Listing 5.6: Hinzufügen einer Nachricht Message message =... ; // Message for user1 Cache. set (" message :" + message.id, message ); List msglist ; if ( Cache. get (" me_tab :" + user )!= NULL ) { msglist = Cache. get (" me_tab :" + user ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" me_tab :" + user, msglist ); }

68 62 Kapitel 5. Konzeption Speicherung des Nutzer können den Elementen Blogs, Nutzern und Tags folgen. Für jedes Element wird eine kommaseparierte Liste von Nutzer-Identikationsnummern von denjenigen Nutzern im Cache gespeichert, die diesem Element folgen. blogs_follower:{#blogid} - [ user_ids ] : Speichert Follower eines Blogs. user_follower:{#userid} - [ user_ids ] : Speichert Follower eines Nutzers. tag_follower:{#tag} - [ user_ids ] : Speichert Follower eines Tags. Folgt beispielsweise Nutzer user1 dem Blog blog1, so wird dies entsprechend im Cache abgelegt: blogs_follower:blog1 - [ user1 ] Zusätzlich zu dieser Information wird eine nach Datum absteigend, kommaseparierte Liste von Nachrichtenidentikationsnummern unter dem Schlüssel following_messages_user: unter Angabe der Identikationsnummer des Nutzers gespeichert, wie nachfolgend ersichtlich wird. following_messages:{#userid} - [ msg_ids ] : Speichert die 150 Nachrichten für einen Nutzer, deren Eigenschaften dieser folgt. Für den Nutzer user1 könnte dieser Cacheeintrag dann wie folgt aussehen: following_messages:user1 - [ 3,2,1 ] In dem Pseudoalgorithmen wird nachfolgend gezeigt, wie sich der Cache beim Aufrufen des Following-Tabs und beim Hinzufügen einer neuen Nachricht verhält. Listing 5.7: Aufrufen des Following-Tabs long user =... ; // current user List msglist ; if ( Cache. get (" following_ messages :" + user ) == NULL ) { } msglist = getfollowingmessagesfromdb ( user ); Cache. set (" following_messages :" + user, msglist ); else { } msglist = Cache. get (" following_ messages :" + user ); for ( long msgid : msglist ){

69 5.2. Konzeptdetails der Architektur 63 }... = Cache. get (" message :" + msgid );... Listing 5.8: Neue Nachricht Message message =... ; // new message Cache. set (" message :" + message.id, message ); List followerlist ; long blogid = extractblogid ( message. blog ) followerlist = Cache. get (" blogs_ follower :" + blogid ); for ( long user : followerlist ){ List msglist = Cache. get (" following_messages :" + user ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" following_messages :" + user, msglist ); } long userid = extractuserid ( message. user ) followerlist = Cache. get (" user_ follower :" + userid ); for ( long user : followerlist ){ List msglist = Cache. get (" following_messages :" + user ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" following_messages :" + user, msglist ); } List taglist = extracttags ( message. tags ) for ( String tag : taglist ) followerlist = Cache. get (" tag_follower :" + tag ); for ( long user : followerlist ){ List msglist = Cache. get (" following_messages :" + user ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" following_messages :" + user, msglist ); } }

70 64 Kapitel 5. Konzeption Speicherung des Tabs: Alle Nachrichten Nachrichten für den Alle Nachrichten-Tab werden aus der Vereinigungsmenge der Nachrichten aller Blogs, für die der jeweilige Nutzer die Berechtigung besitzt, und der Menge aller Direktnachrichten, die in diesen Blogs an den Nutzer gerichtet sind, gebildet. Wie die Nachrichten für einen Blog und die Direkt-Nachrichten für einen Nutzer im Cache abgelegt werden, wurde im Punkt Speicherung der Nachrichten eines Blogs bzw. Speicherung der Direkt-Nachrichten eines Nutzers gezeigt. Im folgenden Abschnitt wird deshalb nur auf den Pseudoalgorithmus eingegangen, um zu zeigen, wie diese beiden Einträge im Cache genutzt werden, um den Inhalt des Alle Nachrichten-Tabs zu erstellen. Listing 5.9: Aufrufen des Alle Nachrichten-Tabs long user =... ; // current user List directmsglist ; List blogslist ; List allmsglist ; blogslist = getblogsuserhasrights ( user ); for ( long blogid : blogslist ){ if ( Cache. get (" blog_messages :" + blogid ) == NULL ) { List msglist = ge tblo gmes sage sfr omdb ( blogid ); Cache. set (" blog_messages :" + blogid, msglist ); me rgel ists Orde rbyd ate ( allmsglist, msglist ) } else { List msglist = Cache. get (" blog_ messages :" + blogid ); me rgel ists Orde rbyd ate ( allmsglist, msglist ) } } if ( Cache. get (" direct_messages :" + user ) == NULL ) { directmsglist = getdirectmessagesfromdb ( user ); Cache. set (" direct_messages :" + user, msglist ); } else { directmsglist = Cache. get (" direct_ messages :" + user ); } me rgel ists Orde rbyd ate ( allmsglist, directmsglist ) for ( long msgid : allmsglist ){... = Cache. get (" message :" + msgid );

71 5.2. Konzeptdetails der Architektur 65 }... Listing 5.10: Neue Nachricht Message message =... ; // new message Cache. set (" message :" + message.id, message ); List userlist = ge tdir ect Mess ageu sers ( message ) for ( long user : userlist ){ if ( Cache. get (" direct_messages :" + user )!= NULL ){ List msglist = Cache. get (" direct_ messages :" + user ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" direct_messages :" + user, msglist ); } } long blogid = extractblogid ( message. blog ); if ( Cache. get (" blog_messages :" + blogid )!= NULL ){ List msglist = Cache. get (" blog_ messages :" + blogid ); insertdateorderedmessage ( msglist, message. id ) Cache. set (" blog_messages :" + blogid, msglist ); } Variante 1: Nutzerorientierte Speicherung der Filter Bei der nutzerorientierten Speicherung der Filter werden für jeden Nutzer deren aufgerufene Filter in einer kommaseparierten Liste im Cache abgelegt. Zusätzlich wird zu dieser Information eine nach Datum absteigende, kommaseparierte Liste von Nachrichtenidentikationsnummern unter dem Schlüssel lter_messages: gefolgt von der Identikationsnummer des Nutzers gespeichert. Diese Liste enthält exakt die Nachrichten IDs, welche den gespeicherten Filtern entsprechen. lter:{#userid} - [ Filter ]: Speichert für einen Nutzer dessen Filter in einer kommaseparierten Liste. lter_messages:{#userid} - [ msg_ids ]: Speichert für einen Nutzer die 150 aktuellsten Nachrichten IDs zu allen seinen Filtern. Das folgende Beispiel zeigt einen Eintrag für den Nutzer user1, welcher nach dem Tag status, nach dem Blog blog1 und nach dem Nutzer user2 ausgewählt hat:

72 66 Kapitel 5. Konzeption lter:user1 - [ tagfilter=status, blogfilter=blog1, userfilter=user2 ] Der entsprechende Cacheeintrag der Nachrichtenliste könnte wie folgt aussehen: lter_messages:user1 - [ 6,4,2,1 ] Der folgende Pseudocode verdeutlicht, wie sich der Cache verhält, wenn ein Nutzer nach dem Tag status ltert. Listing 5.11: Aufrufen eines Filters long user =... ; // current user String filter = " status "; // filter for tag " status " List msglist ; List filterlist ; if ( Cache. get (" filter :" + userid ) == NULL ){ } filterlist. append (" tagfilter =" + filter ); Cache. set (" filter :" + userid, filterlist ); msglist = getfiltermessagesfromdb ( filter, userid ); Cache. set (" filter_messages :" + userid, msglist ); else { } filterlist = Cache. get (" filter :" + userid ); if (! filterlist. contains (" tagfilter =" + filter )){ } filterlist. append (" tagfilter =" + filter ); Cache. set (" filter :" + userid, filterlist ); List dbmsglist ; dbmsglist = getfiltermessagesfromdb ( filter, userid ); List msglist ; msglist = Cache. get (" filter_messages :" + userid ); mergelistsorderbydate ( dbmsglist, msglist ) Cache. set (" filter_messages :" + userid, msglist ); for ( long msgid : msglist ){ } Message message = Cache. get (" message :" + msgid ); if ( message. tags. contains ( filter ))... Wird eine neue Nachricht dem System hinzugefügt so müssen sämtliche Filter, die davon betroen sind aktualisiert werden. Der folgende Pseudocode, am Beispiel eines Tag-Filters, verdeutlicht diesen Vorgang.

73 5.2. Konzeptdetails der Architektur 67 Listing 5.12: Hinzufügen einer Nachricht // Message in blog1 with tag " status " Message message =... ; Cache. set (" message :" + message.id, message ); long blogid = message. blog ; List taglist = gettaglist ( message. tags ); List userlist = getuserswhichhasrightsforblog ( blogid ); List msglist ; List filterlist ; for ( String tag : taglist ) { for ( long userid : userlist ) { if ( Cache. get (" filter :" + userid )!= NULL ) { filterlist = Cache. get (" filter :" + userid ); if ( filterlist. contains (" tagfilter =" + tag )){ msglist = Cache. get (" filter_messages :" + userid ); insertdateorderedmessage ( msglist, message. id ) Cache. set ( filter + " _tag_messages :" + userid, msglist ); } } } } Variante 2: Filterorientierte Speicherung der Nachrichten pro Blog Bei der Variante der lterorientierten Speicherung von Nachrichten pro Blog wird eine nach Datum absteigende, kommaseparierte Liste von Nachrichtenidentikationsnummern zu dem Filterkriterium pro Blog gespeichert. Die Filterkriterien umfassen die Eigenschaften Nutzer und Tag. Das Filterkriterium Blog wird durch den im Punkt Speicherung der Nachrichten eines Blogs vorgestellten Cacheeintrag gebildet. blog_messages:{#blogid} - [ msg_ids ] : (siehe 5.2.2). {#userid}_user_messages:{#blogid} - [ msg_ids ] : Speichert für einen Blog die 150 aktuellsten Nachrichten IDs zu dem jeweiligen Nutzer. {#tag}_tag_messages:{#blogid} - [ msg_ids ] : Speichert für einen Blog die 150 aktuellsten Nachrichten IDs zu dem jeweiligen Tag.

74 68 Kapitel 5. Konzeption Das nachfolgend aufgeführte Beispiel zeigt einen Eintrag für das Tag status in dem Blog blog1: status_tag_messages:blog1 - [ 1, 2, 3 ] Der folgende Pseudocode verdeutlicht, wie sich der Cache verhält, wenn ein Nutzer nach dem Tag status ltert. Dieser Vorgang verhält sich äquivalent zum Filtern nach einem Nutzer. Listing 5.13: Aufrufen eines Filters String filter = " status "; // filter for tag " status " List blogslist ; List filtermsglist ; blogslist = getblogsuserhasrights ( user ); for ( long blogid : blogslist ){ } List msglist ; if ( Cache. } get ( filter + " _ tag_ messages :" + blogid ) == NULL ){ msglist = getfiltermessagesfromdb ( filter, blogid ); Cache. else { set ( filter + " _tag_messages :" + blogid, msglist ); List msglist = Cache. } get ( filter + " _tag_messages :" + blogid ); me rgel ists Orde rbyd ate ( filtermsglist, msglist ) for ( long msgid : allmsglist ){ }... = Cache. get (" message :" + msgid );... Wird eine neue Nachricht dem System hinzugefügt, so müssen sämtliche Filter, die davon betroen sind, aktualisiert werden. Der folgende Pseudocode, am Beispiel eines Tag-Filters, verdeutlicht diesen Vorgang. Listing 5.14: Hinzufügen einer Nachricht // Message in blog1 with tag " status " Message message =... ; Cache. set (" message :" + message.id, message );

75 5.3. Evaluation der Architektur 69 long blogid = message. blog ; List filterlist = gettaglist ( message. tags ); List msglist ; for ( String filter : filterlist ) { if ( Cache. get ( filter + " _ tag_ messages :" + blogid )!= NULL ) { msglist = Cache. get ( filter + " _tag_messages :" + blogid ); insertdateorderedmessage ( msglist, message. id ) Cache. set ( filter + " _tag_messages :" + blogid, msglist ); } } 5.3. Evaluation der Architektur Der nächste Abschnitt wird genutzt, um das Konzept zur Evaluation der Architektur vorzustellen. Dabei werden die verfolgten Ziele, die zu verwendeten Werkzeuge, die für den Test notwendige Umgebung und die durchzuführenden Testschritte beschrieben Ziel der Evaluation Ziel der Evaluation ist es die Architektur auf die Erfüllung der nicht-funktionalen Anforderungen aus dem Kapitel 3 zu untersuchen. Das vorrangige Ziel ist die Beantwortung der Frage wie gut die Architektur bei einer steigenden Nutzeranzahl durch Hinzufügen neuer Resourcen unter Einhaltung der anderen nicht-funktionalen Anforderung, wie NF-1: Quality of Service, NF-5: eziente Konvergenz gegen konsistenten Zustand und NF-6: Dauerhaftigkeit, skaliert. Hierbei wird das Zeitverhalten (NF-1) mittels Zeitmessung und die Verfügbarkeit (NF-5 und NF-6) der Daten im System untersucht Test- und Analysewerkzeuge Zum Testen der Architektur wird, wie schon bei der Vorabanalyse aus dem Kapitel 4, das Werkzeug Apache JMeter genutzt. JMeter wird sowohl für die Ausführung der Funktionen der Social-Media-Anwendung als auch zur Aufzeichnung des zeitlichen Verhaltens des Systems verwendet.

76 70 Kapitel 5. Konzeption Abbildung 5.7.: Monitoringübersicht von JavaMelody Quelle: [27] In verteilten Anwendungen ist es wichtig die Kommunikation, die zwischen diesen Anwendungen durchgeführt wird, zu analysieren. Hierzu werden Logging- Anweisungen in der Anwendung eingefügt, welche das Zeitverhalten bei der Kommuniktaion zwischen den VMs in Log-Dateien schreiben. Die einzelnen Zeiten werden mit Hilfe von eigens dafür entwickelten Programmen aus den Log-Dateien extrahiert und für die Analyse aufbereitet. Neben der Analyse des Netzwerkaufkommens zwischen den einzelnen VMs ist die Beobachtung der Hardware-Ressourcen der VM ernorm wichtig. Hierzu wird das Werkzeug JavaMelody [27] verwendet. Dieses wird zur Überwachung der CPU- und RAM-Belastung sowie zur Analyse der Java Virtual Machine verwendet. JavaMelody zeichnet sich durch die einfache Integration in JavaEE-Anwendungs- Server aus. Hierzu müssen nur die notwendigen JAR-Bibliotheken in dem WAR- File der Anwendung abgespeichert und ein Filter in der web.xml der Anwendung hinzugefügt werden. Nach Starten des Anwendungsservers steht unter der Adresse: die Oberäche von JavaMelody, siehe Abbildung 5.7, zur Verfügung. Unter der Adresse: lassen sich die Monitoringergebnisse und -diagramme als PDF exportieren Testumgebung Es werden insgesamt acht verschiedene virtuelle Maschinen zur Evaluation der Architektur verwendet. Die Maschinen werden jeweils einem Aufgabenzweck zugeteilt. Wie diese Zuteilung erfolgt, ist in Abbildung 5.8 zu sehen.

77 5.3. Evaluation der Architektur 71 Abbildung 5.8.: Lasttestumgebung In der Übersicht 5.8 ist ersichtlich, dass zwei VMs zur Durchführung des JMeter- Testplanes genutzt werden. Eine VM dient dabei zur Ausführung der Datenbank, auf den restlichen fünf virtuellen Maschinen wird jeweils die Social-Media-Anwendung in Betrieb genommen. Im Folgenden wird gezeigt, wie die unterschiedlichen virtuellen Maschinen für den jeweiligen Einsatz ausgestattet und eingerichtet sind. 1 x Datenbank-VM: Anzahl Kerne: 4 Festplattenplatz: 20GB RAM: 8GB Betriebssystem: Linux Datenbank: PostgreSQL x Lasttest-VM: Anzahl Kerne: 1 Festplattenplatz: 2GB RAM: 2GB

78 72 Kapitel 5. Konzeption Betriebssystem: Linux JMeter: x Anwendungs-VM: pro VM 1 Tomcat Anzahl Kerne: 2 Festplattenplatz: 10GB RAM: 4GB Betriebssystem: Linux Die Testumgebung kann in verschiedenen Kongurationen gefahren werden, um so die Skalierbarkeit zu evaluieren. Von den fünf zur Verfügung stehenden virtuellen Maschinen für die Social-Media-Anwendung kann die Konguration von einer bis zu einem Umfang von allen fünf Maschienen variieren. Bei voller Auslastung mit jeweils einem Tomcat können so parallel fünf Anwendungen ausgeführt werden Testsetup In diesem Abschnitt wird auf das Testsetup eingegangen. Dabei werden die verschiedenen Kongurationsmöglichkeiten und deren konkrete Ausprägungen kurz genannt. In einer abschlieÿenden Übersicht werden die verschiedenen Kombinationsmöglichkeiten des Testsetups verdeutlicht. Wie in der nicht-funktionalen Anforderung NF-4 Lastumfang im Abschnitt gefordert, sollen Klein- und Mittelständige Unternehmen ebenso wie Groÿkonzerne die Möglichkeit haben Communote einzusetzen. Um die Nutzbarkeit für den jeweiligen Einsatzzweck zu überprüfen, wird der Test jeweils mit den nachfolgend aufgezählten Nutzerzahlen durchgeführt: Nutzer Nutzer Nutzer Zusätzlich zu den unterschiedlichen Nutzerzahlen werden unterschiedliche Nachrichtenanzahlen in dem jeweiligen Testsetup betrachtet. Diese werden als Grundlage

79 5.3. Evaluation der Architektur 73 für die Filterungen genutzt. In der in dieser durchgeführten Analyse zur Verwendung von Funktionen bei Social-Media-Anwendungen, am Beispiel des Enterprise Microblogging Dienstes Communote des Unternehmens Communote GmbH, wurde ermittelt, dass von einem Nutzer an einem Arbeitstag, mit einem Umfang von 8 Arbeitsstunden, durchschnittlich fünf Nachrichten erstellt werden. Nimmt man ein Unternehmen mit Nutzern als Grundlage an, so sind nach einem Monat zirka und nach einem Jahr mit 200 Arbeitstagen zirka Nachrichten erstellt worden. Deshalb liegen folgende Nachrichtenzahlen vor Durchführung der Filterungen vor: Nachrichten Nachrichten Folgende Architekturen, welche ausführlich in Kapitel 5.1 beschrieben wurden, sollen evaluiert werden: lokaler Cache mit Message-Queue zur Invalidierung zentraler Cache, welcher für alle Instanzen zur Verfügung steht Im Abschnitt wurden Konzepte zur Umsetzung von zwei unterschiedlichen Cache-Strategien für die Abspeicherung der Daten erstellt. Diese werden in einer Vorabanalyse gegenübergestellt und eine geeignete Strategien zur Durchführung der Architekturevaluation ausgewählt: Nutzerorientierte Speicherung der Filter Filterorientierte Speicherung der Nachrichten pro Blog Die Verteilung der Nutzer erfolgt in folgenden Staelungen: 1 Instanz 3 Instanzen 5 Instanzen Mit Hilfe dieser einzelnen Kongurationen ergeben sich, wie in Abbildung 5.9 ersichtlich, die Kombinationen für die jeweilige Testsetupkonguration: Zunächst wird die derzeitig vorliegende Standardimplementierung des Microblogging-Dienstes Communote getestet. Die gewonnenen Ergebnisse sollen die Vergleichsgrundlage für die in diesem Abschnitt vorgestellten Testsetupkongurationen bilden.

80 74 Kapitel 5. Konzeption Abbildung 5.9.: Kombinationen der Testsetupkonguration Testvorbereitung Bevor die Testszenarien des Testplans durchgeführt werden können, müssen einige Daten zur Durchführung auf dem System, inbesondere der Datenbank, vorhanden sein. Dies betrit die Nutzer, die Blogs und die Berechtigungen der Nutzer auf die jeweiligen Blogs. Die Testdatengenerierung erfolgt durch eine entwickelte Komponente, die diese Daten in die Datenbank ablegt. Jeder Nutzer besitzt nach erfolgreichem Abschluss der Generierung eine Berechtigung zum Schreiben für jeweils 3 Blogs und die Berechtigung zum Lesen auf jeweils 7 weitere Blogs. Diese 3 schreibberechtigten Blogs werden für die Testszenarien genutzt, um darin neue Nachrichten zu erstellen oder darauf zusammen mit den 7 leseberechtigten Blogs Filteranfragen durchzuführen. Wie schon in Abschnitt erwähnt, bilden unterschiedliche Nachrichtenmengen ( und Nachrichten) die Grundlage für die Filterungen. Diese werden bei der Testvorbereitung ebenfalls jeweils in der Datenbank angelegt. Bei der Erstellung einer neuen Nachricht wird zufällig ein Nutzer aus der Nutzerbasis ausgewählt. Anschlieÿend wird willkürlich ein Blog aus den 3 Blogs, für die der Nutzer eine Berechtigung zum Schreiben hat, genutzt, um darin eine Nachricht zu erstellen. Die Nachricht enthält einen Blindtext mit 300 Zeichen. Der Umfang von 300 Zeichen entspricht in etwa rund 60 Prozent der Fälle der Anzahl von Zeichen, die in gewöhnlichen, von Menschen erstellten Nachrichten im Social-Media-Kontext vorliegen. In dieser Nachricht werden ein statischer Tag und zwei dynamische Tags, die sich aus der aktuellen Uhrzeit und dem Nutzernamen ergeben, verwendet.

81 5.3. Evaluation der Architektur Testszenarien Für die jeweilige Testdurchführung werden in einem Thread im JMeter 100 Nutzer verwendet. Diese Zahl bildet einen Kompromiss aus der Fähigkeit der virtuellen Maschine die gewünschte Anzahl an JMeter-Threads zu erstellen und parallel auszuführen, und der Wahrscheinlichkeit, dass ein Nutzer mehrfach für einen Testdurchlauf zufällig ausgewählt wird. Da, wie im Abschnitt beschrieben, folgende Nutzerzahlen getestet werden sollen: Nutzer, Nutzer und Nutzer führt dies dazu, dass für den Lasttest mit Nutzer 10 Threads, für den Lasttest mit Nutzer 50 Threads und für den Lasttest mit Nutzer 100 Threads gestartet werden müssen. Bei der Erstellung von gleichzeitig mehreren Threads kann es zu Lastproblemen bei dem JMeter-Lasttestserver kommen, daher wird die Möglichkeit von JMeter genutzt, eine Ramp-Up-Zeit für die Threads zu denieren. Diese Ramp-Up-Zeit dient dazu, dass die Vielzahl an Threads in einem Abstand von 30 Sekunden nacheinander gestartet werden und es so zu keinen Problemen bei der Testdurchführung kommt. Die Laufzeit des Lasttests beträgt für Nutzer eine Stunde und für und Nutzer zwei Stunden. Diese Dauer genügt, um das System ausreichend lange unter Last zu stellen, Analysen durchzuführen und Schlussfolgerungen ableiten zu können. Zu dieser reinen Testzeit kommt die oben genannte Ramp-Up-Zeit hinzu, in der die komplette Anzahl der Threads erstellt werden. Die Kommunikation bzw. die Funktionsaufrufe der Lasttest-VMs auf die Anwendungs-VMs wird über die REST-API realisiert. Dies hat den Vorteil, dass die Ergebnismengen besser zu analysieren sind, da die Ergebnisse in der JSON- Repräsentation zurückgeliefert werden und so einfacher zu interpretieren sind sowie zur Verwendung von weiteren Testschritten genutzt werden können. Um ein äquivalentes Verhalten, dass über das Web-Front-End der Social-Media- Anwendung erfolgt, zu simulieren, werden zusätzliche Funktionen, die über das eigentliche Testszenario hinausgehen, aufgerufen. Dies sind die Blogliste, die Nutzerliste und die Tag-Cloud. Ein weiterer Vorteil dieser Methode ist, dass durch den Aufruf dieser Funktionen Ergebnismengen zurückgeliefert werden, die für die anschlieÿende Filterung genutzt werden können. Mit Hilfe der funktionalen Anforderungen sollen die nicht-funktionalen Anforderungen der Architektur evaluiert werden. Die funktionalen Anforderungen nden sich in den einzelnen Testszenarien wieder. Wie sich der Testablauf der einzelnen Testszenarien gestaltet, wird nachfolgend verdeutlicht.

82 76 Kapitel 5. Konzeption Testdurchlauf In einem Testdurchgang wird pro Nutzer die Nachrichtenliste aller für den Nutzer sichtbaren Nachrichten ohne jegliche Filter geladen. Zusätzlich wird die Nutzerliste der Ersteller dieser Nachrichten und die Tag-Cloud, die sich aus den verwendeten Tags der Nachrichten zusammen setzt, aufgerufen. Aus der Ergebnismenge der Nachrichtenliste wird jeweils zufällig ein Wert für einen Blog, eine NutzerID und ein Tag gewählt, welcher als Parameter für die anschlieÿende Filterung dient. Bei der Filterung wird mittels der vorhandenen Werte jeweils nach einem Blog, einem Nutzer und nach einem Tag geltert. Bevor die Filterung mit diesen Parametern erfolgt, wird eine neue Nachricht mit 300 Zeichen und 3 Tags erstellt. Im folgenden Ablauf wird der Verlauf des Filterszenarios schematisch dargestellt. ServerID = userid modulo Anzahl_Instanzen; LOOP i=0; i<n; i=i+1 Request: Alle Nachrichten von allen Berechtigten Blogs ohne Filter Extract: Zufällig eine BlogId aus Ergebnismenge wählen Extract: Zufällig eine NutzerId aus Ergebnismenge wählen Extract: Zufällig ein Tag aus Ergebnismenge wählen Request: TagCloud mit den Tags die in diesen Nachrichten verwendet wurden Request: Alle Nutzer die diese Nachrichten verfasst haben Mit 25 prozentiger Wahrscheinlichkeit Nachricht erstellen Mit 90 prozentiger Wahrscheinlichkeit Request: Filter mit der extrahierten BlogId ausführen Mit 16 prozentiger Wahrscheinlichkeit Request: Filter mit der extrahierten NutzerId ausführen Mit 10 prozentiger Wahrscheinlichkeit Request: Filter mit dem extrahierten Tag ausführen Die prozentualen Wahrscheinlichkeiten, mit der eine Filteranfrage durchgeführt wird, ergibt sich aus der in dem Abschnitt ermittelten durchschnittlichen Häu- gkeit der Filteraufrufe für 60 Nutzer.

83 Kapitel 6. Evaluation Nachdem im vorherigen Kapitel die Konzeption der Architektur und deren Evaluation ausführlich beschrieben wurde, wird in dem vorliegenden Kapitel die Evaluation der Architektur behandelt. Dabei wird zunächst auf die Implementierung eingegangen. Da die Implementierung nur als Hilfsmittel zur Analyse der Architektur genutzt wird, ist dieser Abschnitt auf das Wesentliche reduziert. Anschlieÿend wird die eigentliche Evaluation behandelt. Dabei wird auf die Ergebnisse, deren Interpretation und die daraus abgeleiteten Schlussfolgerungen eingegangen Implementierung In diesem Abschnitt soll ein Einblick in die Implementierung gegeben werden. Die Umsetzung erfolgt am Beispiel des Enterprise Microblogging Dienstes Communote des Unternehmens Communote GmbH. Der Enterprise Microblogging Dienst Communote deckt den Use-Case der Social-Media-Stream Anwendung ab. Hinzukommt, dass diese in Zusammenarbeit mit der Communote GmbH entstanden ist. Für die Bearbeitung des Themas der wurde der Quellcode von Communote zur Verfügung gestellt und bildet die Grundlage für die Implementierung Übersicht In der folgenden Abbildung 6.1 ist die gesamte Implementierung der einzelnen Komponenten ersichtlich. Das Klassendiagramm zeigt die in Absatz 5.1 vorgestellten Komponenten. Wie diese einzelnen Komponenten konkret umgesetzt sind und miteinander interagieren wird in den nächsten Absätzen verdeutlicht. 77

84 78 Kapitel 6. Evaluation Abbildung 6.1.: Übersicht der Implementierung

85 6.1. Implementierung Die Core-Komponente Die Core-Komponente dient zur Ausführung der Kernfunktionalitäten der Social- Media-Stream-Anwendung. Die vorliegende Implementierung der Core-Komponente des Microblogging-Dienstes Communote wird um die Elemente CreateUpdateNoteEvent und die Schnittstelle QueryExecutionInterceptor erweitert. Die Klasse CreateUpdateNoteEvent implementiert die Event-Schnittstelle der Core-Komponente. Dieses Event wird immer dann abgefeuert, wenn eine neue Nachricht in der Social-Media-Stream-Anwendung erstellt wird. Wie dieses Event genutzt wird, wird in Abschnitt näher erläutert. Die Schnittstelle QueryExecutionInterceptor wird in der Core-Komponente der Communote Anwendung in der Klasse QueryManagement verwendet. Die Methoden der Schnittstelle beforeexecution und afterexecution werden jeweils vor bzw. nach der Ausführung von Datenbankabfragen in der Methode queryexecution der Klasse QueryManagement durchgeführt. Die konkrete Umsetzung der Schnittstelle QueryExecutionInterceptor erfolgt in der Store-Komponente Die Store-Komponente Zentraler Punkt der in Abschnitt 5.1 in den Abbildungen 5.2 und 5.3 vorgestellten Architekturen ist die Komponente Store. Für die Store-Komponente stellt die Klasse QueryExecutionInterceptorImpl die grundlegenden Funktionen bereit. Diese Klasse implementiert die von der Core- Komponente bereitgestellte und nach auÿen sicht- und benutzbare Schnittstelle QueryExecutionInterceptor. In der Store-Komponente wird diese Schnittstelle wie schon erwähnt von der Klasse QueryExecutionInterceptorImpl umgesetzt. In den beiden Methoden beforeexecution und afterexecution werden mit Hilfe der Schnittstellen Cache und Cachstrategie die Ergebnismengen von Datenbankabfragen mittels der Methode storeincache der konkreten Cache-Strategy in den Cache abgelegt bzw. mit der Methode retrievefromcache der jeweiligen Cache-Strategie aus dem Cache geladen. Ebenso eine zentrale Rolle spielt die Klasse CreateUpdateNoteEventListener. Diese regestriert sich in der Core-Komponente auf das Event CreateUpdateNoteEvent. Wann immer so ein Event in der Core-Komponente ausgelöst wird, wird die Klasse CacheEntryInvalidator dazu benutzt, den Cache zu invalidieren, insbesondere die neu erstellte Nachricht in den Cache einzupegen. Das Invalidieren des Caches kann je nach Architektur dazu führen, dass entweder mittels der Klasse HazelcastCache

86 80 Kapitel 6. Evaluation Abbildung 6.2.: Cache-Provider Implementierungen die neue Nachricht in dem verteilten Cache abgelegt wird oder andere Instanzen von Social-Media-Stream-Anwendungen über eine MessageQueue informiert werden. Dazu dient das optionale Attribut des Klassentyps NoteMessageSender. Wie dies genau abläuft, wird in Abschnitt beschrieben Das Datenmodell des Caches Die unterschiedlichen Konzepte, welche in Abschnitt vorgestellt wurden, werden durch unterschiedliche Cache-Provider Implementierungen umgesetzt. Diese verschiedenen Datenmodelle sind in Abbildung 6.2 verdeutlicht. Die aufgeführten Provider implementieren die Schnittstelle CacheElementProvider. Der CacheElementProvider wird beim Ablegen von Daten in den Cache verwendet, um zum einen den Schlüssel für den Cacheeintrag bereitzustellen und zum anderen die Verweildauer des Cacheeintrages im Cache bestimmen zu können. Die Schnittstelle verlangt von den Umsetzungen die Methoden getcontenttype() und gettime- ToLive() zu realisieren. Die Methode getcontenttype() stellt den Schlüssel für den jeweiligen Cacheeintrag bereit. Mit der Methode gettimetolive() kann beim Einfügen eines Datums in den Cache die Dauer festgelegt werden, für die dieser Eintrag darin vorhanden ist Die Message-Komponente Die Message-Komponente bietet die grundlegenden Funktionen zur entkoppelten Kommunikation von Social-Media-Stream-Anwendungen mittels Message-Queue. Die Integration dieser Komponente ist optional. Sie ist abhängig von der verwendeten Architektur. Die Komponente wird ausschlieÿlich für die in Absatz vorgestellte Architektur mit lokalem Cache verwendet. Die Komponente stellt die Klassen NoteMessageSender, NoteMessageHandler und

87 6.2. Vorstellung der Ergebnisse der Evaluation 81 die Schnittstelle MessageListener, welche die Klasse NoteMessageHandler implementiert, bereit. Die Klasse NoteMessageHandler ist verantwortlich für das Empfangen neuer Nachrichten über die Message-Queue. Hierzu wird beim Erstellen dieser Klasse der entsprechende Listener auf die Message-Queue gesetzt. Erreicht eine neue Nachricht eine Instanz über die Message-Queue, so wird die Methode onmessage der Klasse NoteMessageHandler automatisch durch den Listener aufgerufen und sorgt dafür, dass die Nachricht in den lokalen Cache eingepegt wird. Das Versenden einer neuen Nachricht wird durch die Klasse NoteMessageSender ermöglicht. Diese Klasse wird, wie eingangs erwähnt, nur in der Architektur mit lokalem Cache verwendet. Deutlich wird dies an der Kardinalität der NoteMessageSender-Instanz in der Klasse CacheEntryInvalidator. Hier besteht die Möglichkeit, dass die Klasse NoteMessageSender entweder gesetzt wird oder nicht. Nur bei Vorhandensein dieser Klasse erfolgt eine Benachrichtigung über eine neue Nachricht an andere Instanzen Vorstellung der Ergebnisse der Evaluation In diesem Abschnitt sollen nun die Ergebnisse und deren Interpretation vorgestellt werden, die aus der Evaluation der Architektur hervorgehen Ergebnisse In dem vorliegenden Teilabschnitt wird auf die einzelnen Ergebnisse der Lasttestdurchläufe, welche in Abschnitt vorgestellt wurden, eingegangen. Dabei werden nur die reinen Daten vorgestellt. Eine Interpretation und Schlussfolgerung ndet in den nachfolgenden Abschnitten statt. Es werden zu jedem Lasttestdurchlauf jeweils das 90%-Perzentil der Aufrufzeiten für die jeweilige Funktion und die Durchsatzrate aufgeführt. Das 90%-Perzentil zeigt den Wert, unter dem 90 Prozent aller Messwerte bei dem zeitlichen Verbrauch in Millisekunden liegen. Standardimplementierung als Referenzwerte In der Tabelle 6.1 sind die 90%-Perzentile bezüglich der Dauer, die der jeweilige Funktionsaufruf benötigt bis er die Ergebnismenge zurück liefert, in Millisekunden dargestellt. Die Tabelle ist dabei in 1.000, und Nutzer sowie jeweils in

88 82 Kapitel 6. Evaluation (100k) und (1M) Nachrichten, die vor den Testdurchläufen in der Datenbank vorhanden sind, geteilt Nutzer Nutzer Nutzer Funktion 100k 1 Mio. 100k 1 Mio. 100k 1 Mio. Login TimeLineNotes TimeLineTags TimeLineUsers WriteBlogPost FilterBlog FilterUser FilterTag Tabelle 6.1.: Standardimplementierung: 90%-Perzentil der Dauer in Millisekunden Die Funktionen Login und das Schreiben einer neuen Nachricht (WriteBlog- Post) dauern generell nur sehr wenige Millisekunden und steigen bei zunehmender Nutzer- und Nachrichtenanzahl nur sehr gering an. Anders verhält es sich hingegegen bei den noch vorhandenen Funktionen, die während des Lasttests ausgeführt werden. Hier liegt der Zuwachs der Dauer, bei einer Verzehnfachung der Nachrichtenanzahl, von einer Verdrei- bis zu einer Verfünachung. Beim Filtern nach Tags führt die Erhöhung der Nachrichtenanzahl von auf Nachrichten zu einer Erhöhung der Dauer um mehr als das Zehnfache. Eine Verzehnfachung der Nutzerzahlen, von auf Nutzern, führt in der Regel nur maximal zu einer Verdoppelung der Dauer. Ausnahmen sind hierbei die Funktionen TimeLineNotes und FilterTag, wo jeweils eine Steigerung um 300% bei einer Verzehnfachung der Nutzerzahl zu verzeichnen ist. In der Tabelle 6.2 ist der Durchsatz für die einzelnen Funktionen, die pro Minute bei der Durchführung der Lasttests erreicht wurden, dargestellt. Der Durchsatz, der bei jedem Lasttestdurchgang erreicht werden kann, ist, wie in Abschnitt beschrieben, durch die Nutzungsintensität der einzelnen Nutzerzahlen beschränkt. Dies wird besonders deutlich, wenn man sich die Durchsatzraten von 1.000, und Nutzern mit jeweils vorhanden Nachrichten betrachtet. Hier führt ein Zuwachs der Nutzerzahlen zu einer Erhöhung des Durchsatzes, da mehr Nutzer mehr Aktionen pro Sekunde durchführen. Das System besitzt bei dieser Nachrichtenanzahl noch Reserven, sodass eine Erhöhung der Nutzerzahl auch zu einer Erhöhung des Durchsatzes führt. Anders hingegen verhält es sich bei der Nachrichtenanzahl von einer Million. Bei Zunahme der Nutzerzahl von auf

89 6.2. Vorstellung der Ergebnisse der Evaluation Nutzer Nutzer Nutzer Funktion 100k 1 Mio. 100k 1 Mio. 100k 1 Mio. Login 33 23, , ,6 TimeLineNotes 33 23, , ,6 TimeLineTags 33 23, , ,6 TimeLineUsers 33 23, , ,6 WriteBlogPost 8,5 6 17,6 5,3 18,1 4,7 FilterBlog 29,7 21, , ,9 FilterUser 5,6 3,9 11,3 3,6 11,7 3,2 FilterTag 3 2,2 5,8 1,9 6 1,8 Tabelle 6.2.: Standardimplementierung: Durchsatz pro Minute verringert sich der Durchsatz um zirka ein Viertel, zum Beispiel bei der Funktion TimeLineNotes. Dies geht auf die Erhöhung der Dauer, die eine Funktion zum Zurückliefern der Ergebnismenge benötigt, zurück, wie in der Beschreibung zur Tabelle 6.1 bereits aufgeführt. Um den Vorteil der skalierbaren Architektur gegenüber der Standardimplementierung eindeutig aufzeigen zu können, werden die Lasttests bei der Evaluierung der Architektur ausschlieÿlich mit einer Nachrichtenanzahl von einer Million in der Datenbank durchgeführt. Evaluation der Cachestrategien Bevor die Evaluation der Architekturen durchgeführt wird, soll zunächst ein Vergleich und eine Auswahl einer geeigneten Cachestrategie für die Evaluation erfolgen. Hierzu werden die in Abschnitt konzipierten Varianten: Nutzerorientierte Speicherung der Filter und Filterorientierte Speicherung der Nachrichten pro Blog gegenübergestellt. Für die Analyse dieser Strategien wurde der Lasttest, welcher in Abschnitt vorgestellt wurde, verwendet. Der Lasttest wurde auf einer Anwendungs-VM mit Nutzern jeweils pro Cachestrategie zwei, vier und acht Stunden durchgeführt. In der Abbildung 6.3 ist die Zeitauswertung des Lasttests mit der Cachestrategie: Nutzerorientierte Speicherung der Filter intervallnormiert dargestellt. In diesem Diagramm wird deutlich, dass der prozentuale Anteil der Aufrufe, deren Ladezeiten bzw. Dauer des Aufrufes weniger als eine Sekunde benötigen, bei steigender Dauer des Lasttests zunehmen. Im Gegenzug nimmt der prozentuale Anteil der Aufrufe, die mehr als eine Sekunde dauern, ab. Das heiÿt, der prozentuale Anteil der Aufrufe, die den Cache nutzen, steigt mit Laufzeit des Lasttests. Deutlicher wird dies bei der zweiten Cachestrategie: Filterorientierte Speicherung

90 84 Kapitel 6. Evaluation Abbildung 6.3.: Zeitauswertung der Nutzerorientierte Speicherung der Filter Abbildung 6.4.: Zeitauswertung der Filterorientierte Speicherung der Nachrichten pro Blog, dessen Zeitauswertung in der Abbildung 6.4 zu sehen ist. Bei dieser Strategie dauern nach zwei Stunden Lasttestdurchlauf zirka 40 Prozent der Aufrufe weniger als 100 Millisekunden. Die Zahl der Aufrufe, die weniger als 100 Millisekunden Zeit benötigen, beträgt nach 8 Stunden in etwa 50 Prozent. Hingegen fällt die Anzahl der Aufrufe, die zwischen 3 und 10 Sekunden dauern, ab. Im Vergleich der beiden Cachestrategien ist demnach zu sehen, dass der prozentuale Anteil der Aufrufe, die weniger als eine Sekunde dauern, bei der Variante Filterorientierte Speicherung der Nachrichten pro Blog nach zwei Stunden Laufzeit zirka 15 Prozent höher sind, als bei der Cachestrategie: Nutzerorientierte Speicherung der Filter. Im Verhältnis dazu ist der Anteil der Aufrufe, die zwischen drei und zehn Sekunden dauern, bei der Variante Filterorientierte Speicherung der Nachrichten pro Blog zirka 5 Prozent höher als die der Cachestrategie: Nutzerorientierte Speicherung der Filter. Schlussfolgernd ist zu sagen, dass die Filterorientierte Speicherung der Nachrichten pro Blog besser als die Nutzerorientierte Speicherung der Filter ist, da pro-

91 6.2. Vorstellung der Ergebnisse der Evaluation 85 zentual mehr Aufrufe in einer kürzeren Zeit gecacht werden können und somit die Anzahl der Aufrufe, die eine Ladezeit von bis zu 100 Millisekunden besitzen, gröÿer ist. Diese Aussage wird in den aufgeführten Tabellen 6.3 und 6.4 unterstützt. In diesen werden die Hit-Miss-Ratio für die jeweilige Cachestrategie dargestellt. Die Hit- Miss-Ratio beschreibt das Verhältnis zwischen Zugrien auf den Cache, welche ein Ergebnis erfolgreich zurückliefern (Hit), und denen, die ohne Treer auf den Cache zurückliefern (Miss). Blog-Filter Nutzer-Filter Tag-Filter Hit-Miss-Ratio: 2h 0,19 0,17 0,12 Hit-Miss-Ratio: 4h 0,35 0,37 0,26 Hit-Miss-Ratio: 8h 1,14 1,20 1,03 Tabelle 6.3.: Hit-Miss-Ratio für Nutzerorientierte Speicherung der Filter Blog-Filter Nutzer-Filter Tag-Filter Hit-Miss-Ratio: 2h 1,36 1,40 2,34 Hit-Miss-Ratio: 4h 4,21 2,02 6,22 Hit-Miss-Ratio: 8h 11,40 2,74 16,45 Tabelle 6.4.: Hit-Miss-Ratio für Filterorientierte Speicherung der Nachrichten Im Vergleich der Hit-Miss-Ratio-Werte für die beiden Cachestrategien ist zu sehen, dass die Hit-Miss-Ratio für die Filterorientierte Speicherung der Nachrichten sehr viel höher ist als bei der Nutzerorientierte Speicherung der Filter. Die Ursache hierfür ist, dass es sich dabei um einen kollaborativen Cacheansatz handelt, d.h. Cacheeinträge, die von anderen Nutzern durch Filteranfragen gefüllt worden sind, können andere Nutzer für ihre Filteranfragen verwenden. So kommt es zu weniger Zugrien auf den Cache, die kein Ergebnis zurückliefern (Misses). Aus dem Grund, dass die Hit-Miss-Ration schon nach kurzer Zeit viel gröÿer ist und somit die Anzahl der Aufrufe, die weniger als 100 Millisekunde für eine Ergebnisrückgabe benötigen, höher ist, wird die Cachestrategie: Filterorientierte Speicherung der Nachrichten pro Blog für die nachfolgende Evaluation der Architekturen verwendet. Was bei dieser Gegenüberstellung deutlich wird, ist, dass der Anteil der Aufrufe, die länger als 3 Sekunden dauern, mit zirka 30 bis 40 Prozent deutlich zu hoch ist. Bei diesen Aufrufen handelt es sich um nicht oder noch nicht gecachte Aufrufe. Aus dieser Erkenntnis wird die Schlussfolgerung gezogen, dass nur noch Aufrufe durchgeführt werden, welche auch gecacht werden können. So entfallen bei den Lasttests zum

92 86 Kapitel 6. Evaluation Architekturvergleich die in Abschnitt genannten Aufrufe: TagCloud mit den Tags die in diesen Nachrichten verwendet wurden und Alle Nutzer die diese Nachrichten verfasst haben. Darüber hinaus werden die Wahrscheinlichkeiten, welche im Testdurchlauf in Abschnitt 5.3.6, basierend auf der Häugkeit mit der ein Funktionsaufruf durchgeführt wird (siehe Tabelle 3.1 im Abschnitt 3.4.2), eingeführt wurden, entfernt, da das Auftreten der Filter nach Nutzern bzw. Tags für eine Analyse zu gering ist. Als weitere Maÿnahme wird bei den Lasttests für die Evaluation der Architektur eine Prefetch-Phase vor dem eigentlichen Lasttest durchgeführt. In dieser Phase werden zu jedem Nutzer die 150 zuletzt erstellten Nachrichten, die dieser Nutzer lesen kann, in den Cache geladen. Da bei jeder Filterabfrage in dem eigentlichen Lasttest nur die letzten 15 Einträge abgefragt werden, sorgt diese Maÿnahme dafür, dass während des Lasttests keine Filter-Anfragen mehr gegen die Datenbank erfolgen, sondern ausschlieÿlich gegen den Cache. Architektur mit verteiltem Cache In diesem Abschnitt werden die Lasttestergebnisse der Architektur mit verteiltem Cache vorgestellt. In der Tabelle 6.5 sind die 90%-Perzentile bezüglich der Dauer, die der jeweilige Funktionsaufruf benötigt bis er die Ergebnismenge zurückliefert, in Millisekunden dargestellt. Die Tabelle ist dabei in 1.000, und Nutzer sowie jeweils in der Systemkonguration mit 1, 3 und 5 Anwendungsserver geteilt. Die Lasttestergebnisse für die Nutzerzahl sind mit diesem System überragend. 90 Prozent aller Aufrufe dauern deutlich weniger als 100 Millisekunden. Aus diesem Grund ist eine Verteilung der Nutzerzahlen auf 3 bzw. 5 Server nicht notwendig, da eine Verteilung der Cachedaten auf mehrere Server nur unnötig Netzwerkverkehr zur Übertragung verursacht, welches sich durch die erhöhten Antwortzeiten bei 3 bzw. 5 äuÿert. Anders verhält es sich bei Nutzern. Hier reicht ein Anwendungserver nicht aus, dass die 90%-Perzentile aller Funktionsaufrufe unter 3 Sekunden liegen. Eine Verteilung auf 3 Server führt dazu, dass bei Nutzern 90 Prozent aller Aufrufe unter einer Sekunde liegen. Durch der Verteilung von Nutzern auf 5 Servern liegen 90 Prozent der Antwortzeiten aller Funktionsaufrufe unter zwei Sekunden. Die Lasttestdurchführung mit Nutzern war mit dieser Umsetzung auf 1 und 3 Servern nicht möglich, da das System während der Ausführung nach einiger Zeit nicht mehr reagierte.

93 6.2. Vorstellung der Ergebnisse der Evaluation Nutzer Nutzer Nutzer Funktion 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. Login WriteBlogPost TimeLineNotes FilterBlog FilterUser FilterTag Tabelle 6.5.: Architektur mit verteilten Cache: 90%-Perzentil der Dauer in Millisekunden In der Tabelle 6.6 ist die Systemauslastung für die jeweiligen Lasttests dargestellt. Es ist die durchschnittliche CPU-Auslastung, Java-Heap-Belastung und der Durchsatz, welcher pro Sekunde von dem System erreicht wird, aufgeführt Nutzer Nutzer Nutzer System-Wert 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. CPU-Auslastung 12% 17% 12% 46% 50% 39% % Heap-Nutzung in 1,3 0,8 0,6 2,5 1,7 1, ,8 Gigabyte Durchsatz pro Sekunde ,9 95, Tabelle 6.6.: Architektur mit verteilten Cache: Systemauslastung Bei Nutzern ist die Systemauslastung relativ gering. Diese steigt bei zunehmender Nutzeranzahl an. So ist die CPU-Auslastung bei Nutzern auf einem Server knapp 4-mal so hoch wie bei Nutzern und die Java-Heap-Belastung doppelt so hoch. Diese kann durch Verteilung der Last auf 3 Server um 0,8 GB gemindert werden. Dabei steigt ebenso der Durchsatz des Gesamtsystems. Unerwarteterweise steigt beim Erhöhen der Server-Anzahl bei Nutzern die CPU-Auslastung, denn bei einer Nutzerzahl von , welche auf 5 Server verteilt sind, beträgt die CPU- Auslastung nur 33 Prozent. In der Abbildung 6.5 sind die Invalidierungszeiten in Millisekunden von Hazelcast bei einer Verteilung von Nutzern auf 5 Anwendungsservern dargestellt. Dieser Verlauf verkörpert die Zeit, die vergeht, um eine neue Nachricht von einem Anwendungsserver im Cache abzulegen und diese für alle weiteren Anwendungsserver verfügbar zu machen. Sehr bemerkenswert ist, dass diese Zeit, mit Ausnahme von ein paar Ausreissern, konstant über die gesamte Lasttestdauer unter 500 Millisekunden liegt.

94 88 Kapitel 6. Evaluation Abbildung 6.5.: Hazelcast-Invalidierungszeiten in Millisekunden Anders verhält es sich hingegen mit der Gesamtzeit, die vergeht bis eine neue Nachricht sowohl in der Datenbank als auch in dem für alle Anwendungsserver verfügbaren Cache abgelegt ist. Diese Zeiten sind, für Nutzer, die auf 5 Anwendungserver verteilt sind, im Diagramm 6.6 dargestellt. Im Anhang A.1 benden sich die Diagramme für alle verteilten Lasttestkongurationen. Abbildung 6.6.: Hazelcast-Speicherzeiten in Millisekunden Wie zu erkennen steigen die Invalidierungszeiten in der Ramp-Up-Phase des Lasttests, also in der Zeit, die benötigt wird, um alle 100 Threads zu erstellen, an. Ist die volle Anzahl von 100 Threads erstellt und somit eine Simulation von Nutzern auf das System erzeugt, liegt die Zeit, bis eine neue Nachricht sowohl in der Datenbank als auch im Cache vorhanden ist, bei zirka 2,5 bis 3 Sekunden. In einigen Ausnahmefällen kann diese auch maximal 5,5 Sekunden betragen. In der Tabelle 6.7 sind die Mittelwerte und die Maximalwerte der Invalidierungszeiten, für die auf 3- bzw. 5-Anwendungserver verteilte Architektur, in Millisekunden dargestellt. Die Mittelwerte der Invalidierungszeiten bleiben trotz Verteilung auf 3- oder 5-

95 6.2. Vorstellung der Ergebnisse der Evaluation Nutzer Nutzer Nutzer Wert 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. Mittelwert Maximum Tabelle 6.7.: Mittelwert und Maximum der Invalidierungszeiten in Millisekunden Anwendungsserver relativ konstant, steigen jedoch insgesamt beim Zuwachs der Nutzerzahlen. Die Maximalwerte der Invalidierungszeiten fallen bei der Verteilung auf mehrere Anwendungsserver bei Nutzern um den Faktor 10 und bei Nutzern um die Hälfte. Architektur mit lokalem Cache In diesem Abschnitt werden die Lasttestergebnisse der Architektur mit lokalem Cache und Invalidierung mittels Message-Queue vorgestellt. In der Tabelle 6.8 sind die 90%-Perzentile bezüglich der Dauer, die der jeweilige Funktionsaufruf benötigt bis er die Ergebnismenge zurückliefert, in Millisekunden dargestellt. Die Tabelle ist dabei ebenso wie in dem vorherigen Abschnitt in 1.000, und Nutzer sowie jeweils in der Systemkonguration mit 1, 3 und 5 Anwendungsserver geteilt. Die Lasttestergebnisse für die Nutzerzahl sind genau wie bei der Architektur mit verteiltem Cache sehr gut. 90 Prozent aller Aufrufe dauern deutlich weniger als 100 Millisekunden. Eine Verteilung der Nutzerzahlen auf 3 bzw. 5 Server ist nicht notwendig, da dies keine deutliche Verringerung der Antwortzeiten zur Folge hat. Bei und Nutzern konnte eine Lasttestdurchführung mit einem Anwendungsserver nicht durchgeführt werden, da das System während der Ausführung nach einiger Zeit wegen Überlastung nicht mehr reagierte. Abhilfe schate eine Verteilung auf drei Anwendungsserver bei Nutzern bzw. auf fünf Anwendungsserver bei Nutzern. Bei der Verteilung von Nutzern auf 3 Anwendungsserver liegt das 90%-Perzentil der Filteraufrufe unter drei Sekunden. Das Erstellen einer neuen Nachricht dauert in 90 Prozent der Fälle mehr als 3 Sekunden. Bei einer Verteilung von Nutzern auf 5 Anwendungsserver können 90 Prozent aller Filteranfragen nicht unter drei Sekunden erfolgen. Das Schreiben neuer Nachrichten dauert in 90 Prozent der Fälle mehr als 10 Sekunden. In der Tabelle 6.6 ist die Systemauslastung für die jeweiligen Lasttests dargestellt. Es ist die durchschnittliche CPU-Auslastung, Java-Heap-Belastung und der Durchsatz, welcher pro Sekunde von dem System erreicht wird, aufgeführt.

96 90 Kapitel 6. Evaluation Nutzer Nutzer Nutzer Funktion 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. Login WriteBlogPost TimeLineNotes FilterBlog FilterUser FilterTag Tabelle 6.8.: Architektur mit lokalem Cache: 90%-Perzentil der Dauer in Millisekunden Nutzer Nutzer Nutzer System-Wert 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. CPU-Auslastung 10% 3% 2% - 50% 10% % Heap-Nutzung in 1,0 0,6 0,5-1,4 0, ,2 Gigabyte Durchsatz pro Sekunde Tabelle 6.9.: Architektur mit lokalem Cache: System Auslastung Mit 10% CPU-Auslastung ist die Systemauslastung bei einer Nutzerzahl von sehr gering, fällt bei Verteilung auf 5 Server sogar auf nur 2% und steigt erst durch Erhöhung der Nutzerzahlen. So ist die CPU-Auslastung trotz Verteilung auf 3 Anwendungsserver bei Nutzern 5-mal so hoch. Bei einer Verteilung auf 5 Anwendungsserver fällt diese, trotz Verdoppelung der Nutzerzahlen, um 13%. Die Java- Heap-Belastung verändert sich Dank der Verteilung auf mehrere Anwendungsserver bei steigender Nutzerzahl nur sehr gering. Dies liegt daran, dass das Produkt Eh- Cache, welches als lokaler Cache verwendet wird, einer zu hohen Heap-Belastung durch Auslagerung von Cacheelementen auf die Festplatte entgegenwirkt. Der Durchsatz ist bei trotz Verteilung auf 5 Server um 15 Anfragen pro Sekunde geringer als bei Nutzern auf 3 Anwendungsserver. In der Abbildung 6.7 sind die Invalidierungszeiten in Millisekunden der Message- Queue bei einer Verteilung von Nutzern auf 5 Anwendungsserver abgebildet. Diese Zeiten stellen die Gesamtzeit, die vergeht bis eine neue Nachricht sowohl in der Datenbank als auch in dem lokalen Cache eines jeden Anwendungsservers abgelegt ist, dar. Im Anhang A.2 benden sich die Diagramme für alle verteilten Lasttestkon- gurationen. Wie zu erkennen ist, steigen die Invalidierungszeiten in der Ramp-Up-Phase des

97 6.2. Vorstellung der Ergebnisse der Evaluation 91 Abbildung 6.7.: MessageQueue-Speicherzeiten in Millisekunden Lasttests, also der Zeit, die benötigt wird, um alle 100 Threads zu erstellen, an. Ist die volle Anzahl von 100 Threads angelegt und somit eine Simulation von Nutzern auf das System erzeugt, kann es mehr als 60 Sekunden dauern, bis eine neue Nachricht sowohl in der Datenbank als auch im lokalen Cache des Anwendungsservers vorhanden ist. Im Mittelwert liegt diese Zeit bei zirka 3,8 Sekunden. In der Tabelle 6.10 sind die Mittelwerte und die Maximalwerte der Invalidierungszeiten, für die auf 3- bzw. 5-Anwendungserver verteilte Architektur, in Millisekunden dargestellt Nutzer Nutzer Nutzer Wert 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. 1 S. 3 S. 5 S. Mittelwert Maximum Tabelle 6.10.: Mittelwert und Maximum der Invalidierungszeiten in Millisekunden Wie in der Tabelle 6.10 zu erkennen ist, fallen die Zeiten für den Mittelwert bei der Verteilung von 3- auf 5-Anwendungsserver. Besonders deutlich wird dies bei Nutzern. Der Mittelwert der Invalidierungszeit beträgt bei 5-Anwendungsserver nur zirka ein Fünftel der Zeit, die bei 3-Anwendungsserver benötigt wird. Insgesamt steigt sowohl der Mittelwert als auch der Maximalwert der Invalidierungszeit beim Zuwachs der Nutzerzahlen.

98 92 Kapitel 6. Evaluation Vergleich der Architekturen bezüglich der Erfüllung der Anforderungen Nachdem im vorangegangenen Abschnitt die Evaluationsergebnisse der verschiedenen Architekturen vorgestellt wurden, wird dieser Abschnitt für den Vergleich beider Architekturen hinsichtlich der im Kapitel 3 denierten nicht-funktionalen Anforderungen genutzt. NF-1 Quality of Service Nach Nielson sollte das System in einer angemessenen Zeit (d.h. innerhalb weniger Sekunden) reagieren und den Systemzustand sichtbar machen [36]. In der heutigen Zeit brechen Nutzer nach 3 Sekunden Ladezeit ihre Aktion mit der Webseite ab [19]. Aus diesem Grund sollten die Filteranfragen und das Erstellen einer neuen Nachricht in 90 Prozent der Fälle nicht mehr als 3 Sekunden dauern. Für eine Nutzerzahl von kann dies durch beide Architekturen erfüllt werden. Hier liegen die Ladezeiten nie über 100 Millisekunden. Bei der Architektur mit lokalem Cache und Message-Queue-Invalidierung kommt es bei und Nutzern dazu, dass das Anlegen einer neuen Nachricht mehr als 3 Sekunden bzw. 10 Sekunden dauert. Bei Nutzern dauern auch einige Filteranfragen mehr als 3 Sekunden. Dies ist bei der Architektur mit verteiltem Cache nicht der Fall. Die einzigen Ausnahmen sind die Ladezeiten bei Nutzern auf einem Anwendungsserver, die mehr als 3 Sekunden brauchen. Dies kann jedoch durch Verteilung auf 3 Anwendungsserver verhindert werden. Generell kommt es bei der Architektur mit lokalem Cache bei steigender Nutzerzahl und der daraus resultierenden steigenen Datenmenge dazu, dass das System durch das Abspeichern der Daten in dem lokalen Cache zusätzlich zu der Ausführung eigentlichen Anwendungslogik belastet wird und so längere Antwortzeiten entstehen. Dies ist bei der Architektur mit verteiltem Cache nicht der Fall. Bei dieser Architektur können die benötigten Resourcen, die zum Abspeichern von Daten in den Cache gebraucht werden, von anderen Anwendungsservern übernommen werden. Die Möglichkeit der Verteilung des Speicherungsvorganges führt zu einer Entlastung des Anwendungsservers und so, inbesondere bei einer Nutzerzahl von , zu deutlich kürzeren Antwortzeiten gegenüber der Architektur mit lokalem Cache.

99 6.2. Vorstellung der Ergebnisse der Evaluation 93 NF-2 Durchsatz Der Gesamt-Durchsatz ist bei beiden Architekturen deutlich höher als durch die nicht-funktionale Anforderung angegeben. Der bei Nutzern verlangte Gesamt- Durchsatz von 22 Interaktionen pro Sekunde ist bei der Architektur mit lokalem Cache mit 45 pro Sekunde zirka doppelt so hoch und bei der Architektur mit verteiltem Cache mit 76 pro Sekunde sogar mehr als 3-mal so hoch. Bezüglich des Durchsatzes zum Filtern nach einem Blog kann die Architektur mit lokalem Cache und Message-Queue-Invalidierung diese Anforderung nicht erfüllen. Hier liegt die Architektur mit zirka 8 Filteranfragen pro Sekunde eine Anfrage pro Sekunde unter den geforderten 9,1 Filteranfragen pro Sekunde. NF-3 Skalierbarkeit Beide Architekturen erfüllen die nicht-funktionale Anforderung bezüglich der Skalierbarkeit sehr gut, da bei beiden Architekturen durch Hinzufügen zusätzlicher Anwendungsserver die Belastbarkeit, in Form von mehr Nutzern, erhöht werden kann. Dies spiegelt sich durch sinkende Systemauslastungen und steigenden Durchsatz wider. NF-4 Lastumfang Beide Architekturen schaen es durch eine Verteilung auf bis zu 5 Anwendungsserver den Lastumfang von 1.000, und Nutzern stand zu halten. Für Nutzer sind hierfür bei beiden Architekturen 5 Anwendungsserver notwendig. NF-5 Eziente Konvergenz gegen konsistenten Zustand Bei der Anforderung an die Konsistenz des Systems spielt die Invalidierungszeit des Caches eine ganz entscheidende Rolle. Diese soll so gering wie möglich sein, damit der Cache aller Anwendungsserver zu jedem Zeitpunkt den gleichen aktuellen Stand besitzt. Bei der Architektur mit lokalem Cache und Message-Queue-Invalidierung beträgt die Invalidierungszeit bei Nutzern mehr als 60 Sekunden. In dieser Zeit ist der lokale Cache eines Anwendungsservers inkonsistent, da dessen Cache noch nicht die neue Nachricht enthält, die auf einem anderen Anwendungsserver erstellt worden ist. Die Zeitspanne des inkonsistenten Zustands beträgt bei der Architektur mit verteiltem Cache bei Nutzern nur maximal 5,5 Sekunden. Dieser Wert ist deutlich besser als bei der Architektur mit lokalem Cache mit Message-Queue-Invalidierung.

100 94 Kapitel 6. Evaluation Bei dieser Anforderung zeigt sich ein konzeptioneller Nachteil der Architektur mit dem lokalen Cache gegenüber der Architektur mit verteiltem Cache, unabhängig vom eingesetzten Produkt. Durch die Invalidierung in jedem lokalen Cache eines jeden Anwendungsservers ist die Zeit in der das Gesamtsystem sich in keinem konsistenten Zusatand bendet länger als bei der Architektur mit verteiltem Cache, bei der die Invalidierung nur einmal im Cache durchgeführt werden muss und anschlieÿend für alle Anwendungsserver sichtbar ist. NF-6 Dauerhaftigkeit Durch die Verwendung einer relationalen Datenbank ist bei beiden Architekturen sichergestellt, dass die Daten dauerhaft vorhanden sind. Somit ist garantiert, dass, wenn der Nutzer eine Rückmeldung bekommt, dass eine Nachricht gespeichert wurde, diese tatsächlich im System dauerhaft vorhanden ist. Bei den Daten, welche in dem Cache der jeweiligen Architektur im Hauptspeicher der Anwendungsserver vorhanden sind, gibt es jedoch Unterschiede. Bei der Architektur mit lokalem Cache und Message-Queue-Invalidierung sind, wie der Name schon sagt, die jeweiligen Cachedaten lokal abgespeichert. Wenn ein Anwendungsserver in dieser Architektur ausfällt, sind die Daten des Caches nicht mehr vorhanden, d.h. beim erneuten Hochfahren des Anwendungsservers muss zunächst der Cache mit den vorhandenen Daten aus der Datenbank gefüllt werden. Dies ist bei der Architektur mit verteiltem Cache nicht der Fall. Der gesamte Cache wird zwar dezentral auf den Anwendungsservern verteilt, jedoch bietet das verwendete Produkt Hazelcast die Funktion des automatischen Backups und der automatischen Migration bei Ausfall an. Jeder Cacheeintrag, welcher in Hazelcast angelegt wird, wird auf einem weiteren Anwendungsserver dupliziert abgelegt. Fällt einer der beiden Anwendungsserver aus, erfolgt eine Migration der Daten auf einen anderen Anwendungsserver, sodass nach erfolgreicher Migration wieder zwei identische Cacheeinträge im System vorhanden sind. Diese Funtkionalität ist ein Vorteil der Architektur mit verteiltem Cache gegenüber der Architektur mit lokalem Cache und Message-Queue-Invalidierung. Übersicht In der Tabelle 6.11 werden die Ergebnisse des Vergleiches hinsichtlich der Erfüllung der nicht-funktionalen Anforderungen noch einmal übersichtlich dargestellt.

101 6.2. Vorstellung der Ergebnisse der Evaluation 95 Anforderung A. verteiltem Cache A. mit lokalem Cache NF-1: Quality of Service NF-2: Durchsatz NF-3: Skalierbarkeit NF-4: Lastumfang NF-5: Eziente Konvergenz gegen konsistenten Zustand NF-6: Dauerhaftigkeit Tabelle 6.11.: Vergleich der Architekturen hinsichtlich der Anforderungen Schlussfolgerung In der Evaluation der beiden Architekturansätze wurde gezeigt, dass durch den Einsatz des Cachings, welcher bei beiden Architekturen verwendet wird, eine deutliche Performancesteigerung gegenüber der Standardimplementierung erzielt werden konnte. So konnte bei der Architektur mit verteiltem Cache bei Nutzern ein Durchsatz von 76 Anfragen pro Sekunde erreicht werden, welcher im Vergleich zur Standardimplementierung mit einem Durchsatz von zirka einer Anfrage pro Sekunde 76 mal höher ist. Bei dem Architekturansatz mit lokalem Cache und Message-Queue- Invalidierung ist der Durchsatz 45 mal höher als bei der Standardimplementierung. In einer Vorabanalyse der Cachestrategien wurde deutlich, dass es wichtig ist, auf die richtige Art und Weise Daten im Cache abzulegen, da sonst der Vorteil des Cachings nicht zum Tragen kommt. Bei dem Vergleich der lterorientierten Cachestrategie mit der nutzerorientierten Filterung wurde festgestellt, dass die Hit-Miss-Ratio bei der lterorientierten Cachestrategie nach acht Stunden Lasttestlaufzeit bis zu 16-mal höher war als die Hit-Miss-Ratio der nutzerorientierten Filterung. Bereits nach 2 Stunden Laufzeit wies der prozentuale Anteil der Aufrufe, die weniger als eine Sekunde dauern, bei der Variante Filterorientierte Speicherung der Nachrichten pro Blog einen zirka 15 Prozent höheren Wert auf als bei der Cachestrategie: Nutzerorientierte Speicherung der Filter. Deshalb wurde die lterorientierte Cachestrategie für die Umsetzung der Architektur ausgewählt, da diese durch ihren kollaborativen Ansatz dazu führt, dass der Cache schnell gefüllt werden kann und die Anzahl der Daten im Cache deutlich geringer als bei der nutzerorientierten Filterung sind, da die Daten im Cache von allen Nutzern verwendet werden können. Im vorangegangenen Abschnitt wurde ein Vergleich der beiden Architekturen

102 96 Kapitel 6. Evaluation durchgeführt. Das Ergebnis dieses Vergleiches ist, dass die Architektur mit verteiltem Cache alle denierten nicht-funktionalen Anforderungen erfüllt. Insbesondere die nicht-funktionale Anforderung NF-2: Durchsatz lag bei der Architektur mit verteiltem Cache bei Nutzern mit einem Gesamtdurchsatz von 76 Anfragen pro Sekunde im Vergleich zum Architekturansatz mit lokalem Cache und Message- Queue-Invalidierung, 31 Anfragen pro Sekunde, über dessen Gesamtdurchsatz. Dies lag zum einen daran, dass die Invalidierungszeit des verteilten Caches mit maximal 5,5 Sekunden 10-mal kürzer war als die maximale Invalidierungszeit der lokalen Caches über die Message-Queue. Zum anderen, dass die Filteranfragen bei der Architektur mit verteiltem Cache mit rund 1,4 Sekunden in etwa nur halb so lange für eine Ergebnisrückgabe gebraucht haben wie die Architektur mit lokalem Cache und Message-Queue-Invalidierung. Aus diesen Zahlen kann nun abgeleitet werden, dass sich zur Umsetzung einer skalierbaren Architektur für Social-Media-Streams die Architektur mit verteiltem Cache besser eignet als der Architekturansatz mit lokalem Cache und Message-Queue- Invalidierung.

103 Kapitel 7. Zusammenfassung und Ausblick Ziel dieser war es eine Architektur zu konzipieren, die es erlaubt durch das Hinzufügen von zusätzlichen Systeminstanzen die geforderten Echtzeitanforderungen von Social-Media-Stream-Anwendungen auch bei wachsenden Benutzerzahlen durch geeignete Verteilung zu erfüllen Zusammenfassung Zu Beginn dieser wurden drei konkrete Kernziele hinsichtlich der Leistungssteigerung durch den Einsatz eines Caches, einer gleichmäÿigen Auslastung der Anwendungsserver bei Verteilung der Systemarchitektur auf mehrere Server und einer ezienten Konvergenz des Systems bei Verteilung gegen einen konsistenten Zustand deniert. Mit den beiden Produkten ActiveMQ und Hazelcast, welche in Kapitel 4 als besonders geeignet für die Umsetzung der beiden unterschiedlichen skalierbaren Architekturansätze ermittelt wurden, wurden zwei unterschiedliche Architekturen konzipiert und umgesetzt. Zum einen eine Architektur mit lokalem Cache und Invalidierung dieses Caches mittels einer Message-Queue zum anderen eine Architektur mit verteiltem Cache. Zur Umsetzung der Architektur mit lokalem Cache und Invalidierung dieses Caches mittels einer Message-Queue wurde das Produkt ActiveMQ genutzt. Für die Architektur mit verteiltem Cache wurde hingegen Hazelcast verwendet. Die beiden Architekturen wurden mittels Lasttests, welche aus den denierten nicht-funktionalen Anforderungen aus Abschnitt abgeleitet wurden, untersucht und gegenübergestellt. Durch den Einsatz des Caches konnten die Antwortzeiten der Architekturen verringert und so der Durchsatz gesteigert werden. Dieser ist bei einer Nutzerzahl von und einer Verteilung auf 5 Anwendungsserver bei der Architektur mit dem 97

104 98 Kapitel 7. Zusammenfassung und Ausblick lokalen Cache 45 mal höher und bei der Architektur mit verteiltem Cache 76 mal höher als bei der Standardimplementierung, welche ohne Vorhandensein des Caches auf einem Anwendungsserver ausgeführt wurde. Bei dieser Lasttestkonguration konnte ebenso festgestellt werden, dass bei der Durchführung von Filteranfragen 90 Prozent der Antwortzeiten bei der Architektur mit verteiltem Cache nur etwa halb so lang waren wie bei der Architektur mit dem lokalen Cache. Beim Anlegen neuer Nachrichten waren die Antwortzeiten bei der Architektur mit dem lokalen Cache sogar 10 mal länger als bei der Architektur mit verteiltem Cache. Die Gründe hierfür werden nachfolgend nocheinmal zusammengefasst. Die Evaluation der beiden Architekturen hat ergeben, dass beide sehr gut skalieren, d.h. durch Hinzufügen neuer Anwendungsserver konnte die Systemauslastung jedes einzelnen Servers verringert und die Datenmenge pro Anwendungsserver minimiert werden. Bei beiden Architekturen führte eine Verteilung von einem Anwendungsserver auf fünf Anwendungsserver dazu, dass die CPU-Auslastung bis zu einem Faktor 5 verringert wurde. Die Heap-Nutzung nahm bei der Verfünachung der Anwendungsserver um 50 Prozent ab. Hinsichtlich des Ziels der ezienten Herstellung eines konsistenten Zustandes des Gesamtsystems wurden die beiden Architekturansätze im Bezug auf die Invalidierungszeiten des Caches untersucht und verglichen. Die Analyse hat einen konzeptionellen Nachteil der Architektur mit dem lokalen Cache gegenüber der Architektur mit verteiltem Cache ergeben. Durch die Invalidierung in jedem lokalen Cache eines jeden Anwendungsservers ist die Zeit, in der das Gesamtsystem sich in keinem konsistenten Zustand bendet, länger als bei der Architektur mit verteiltem Cache, bei der die Invalidierung nur einmal im Cache durchgeführt werden muss und für alle Anwendungsserver sichtbar ist. So ergaben die Messungen, dass der Mittelwert der Invalidierungszeit bei Nutzern und einer Verteilung auf 5 Anwendungsserver bei der Architektur mit lokalem Cache zirka 6 mal langsamer ist als bei der Architektur mit verteiltem Cache. Bei der maximalen Invalidierungszeit, die bei den Architekturen während des Lasttests aufgetreten ist, war der Wert bei der Architektur mit lokalem Cache sogar über 10 mal gröÿer als der von der Architektur mit verteiltem Cache. Zur Erfüllung gewünschter Echtzeitanforderungen in modernen Social-Media- Systemen und der nicht-funktionalen Anforderungen: Skalierbarkeit, Quality-of- Service, Dauerhaftigkeit, eziente Konvergenz gegen einen konsistenten Zustand sowie Lastumfang und Durchsatz eignet sich die Architektur mit verteiltem Cache am Besten, da sie alle geforderten Anforderungen, bei einer Verteilung auf 5 Anwen-

105 7.2. Ausblick 99 dungsserver für eine Nutzerzahl von Nutzern, erfüllt Ausblick Erweiterung der Implementierung Wie schon öfter in dieser Arbeit erwähnt, ist die Implementierung der funktionalen Anforderungen nur ein Hilfsmittel, um die nichtfunktionalen Anforderungen der Architektur zu evaluieren. Aus diesem Grund wurden, basierend auf in einer Communote GmbH internen Untersuchung zur Nutzung des Microblogging-Dienstes Communote, die am häugsten genutzten Funktionen als funktionale Anforderungen aufgenommen und umgesetzt. Diese Funktionen entsprechen jedoch nur einem Bruchteil des Funktionsumfanges des Microblogging-Dienstes Communote. Der Umfang der Implementierung könnte in der fortgesetzten Implementierungsphase erweitert werden, sodass der komplette Umfang des Microblogging-Dienstes Communote erreicht wird Erweiterung der Architektur Im Abschnitt 2.6 wurden eine Reihe von Architektur Best Practices vorgestellt. Zu diesen Architekturkonzepten zählen neben den eingesetzten Komponenten bei der in dieser Arbeit umgesetzten Architektur, die Realisierung einer Suchfunktion mit dem Produkt Apache Lucene und die Datenhaltung mittels einer NoSQL- Implementierung. Diese skalierbaren Architekturkomponenten könnten in einer weiteren Betrachtung in die konzipierte Architektur integriert werden bzw. vorhandene Komponenten ersetzen. Neben der Erweiterung der Architektur um weitere Komponenten könnte die Gesamtarchitektur der skalierbaren Social-Media-Stream Lösung über den gesamten Globus verteilt werden. Die entworfene Architektur könnte dabei ein Bestandteil der Gesamtarchitektur darstellen. Diese Bestandteile könnten dann auf verschiedene Kontinente der Erde angesiedelt und miteinander verbunden werden, was den Vorteil hätte, dass die Gesamtarchitektur besser lokal skaliert Erweiterung der Testdurchführung In dieser Arbeit wurden umfangreiche Analysen der Architektur in verschiedenen Lasttestszenarien durchgeführt. Um ein noch realistischeres Bild vom Verhalten der Architektur zu bekommen, können die vorhandenen Lasttestszenarien um zusätzliche Szenarien erweitert werden. Denkbar wären Szenarien mit gröÿeren Nutzerzah-

106 100 Kapitel 7. Zusammenfassung und Ausblick len, mehr Blogs und mehr Nachrichten. Zu der Anreicherung von Lasttestszenarien könnte eine intensive Analyse der Systemparameter erfolgen. Um ein wirklich realistisches Verhalten der Architektur zu analysieren, ist ein Einsatz zur Untersuchung in dem Produktivsystem möglich. Während dieser Untersuchung würden keine simulierten Nutzer mehr mit dem System interagieren, sondern tatsächliche Nutzer des Systems Einsatz der Architektur im Produktivsystem Nach erfolgreichem Abschluss der erweiterten Testdurchführung kann eine Umstrukturierung der bisherigen evolutiv gewachsenen Architektur des Produktivsystems hin zu einer Architektur mit verteiltem Cache erfolgen. Die in dieser gezeigten Vorteile der Architektur würden so in dem Produktivsystem zum Tragen kommen und so den Nutzern ein positiveres Nutzungsempnden bieten.

107 Anhang A. Anhang A.1. Lasttestergebnisse mit verteiltem Cache Abbildung A.1.: Nutzer - 1 Instanz Abbildung A.2.: Nutzer - 3 Instanzen Abbildung A.3.: Nutzer - 5 Instanzen 101

108 102 Anhang A. Anhang Abbildung A.4.: Nutzer - 1 Instanz Abbildung A.5.: Nutzer - 3 Instanzen Abbildung A.6.: Nutzer - 5 Instanzen Abbildung A.7.: Nutzer - 5 Instanzen Abbildung A.8.: Invalidierungszeiten Nutzer - 3 Instanzen

109 A.1. Lasttestergebnisse mit verteiltem Cache 103 Abbildung A.9.: Invalidierungszeiten Nutzer - 5 Instanzen Abbildung A.10.: Invalidierungszeiten Nutzer - 3 Instanzen Abbildung A.11.: Invalidierungszeiten Nutzer - 5 Instanzen

110 104 Anhang A. Anhang Abbildung A.12.: Invalidierungszeiten Nutzer - 5 Instanzen

111 A.2. Lasttestergebnisse mit lokalem Cache und Message-Queue-Invalidierung 105 A.2. Lasttestergebnisse mit lokalem Cache und Message-Queue-Invalidierung Abbildung A.13.: Nutzer - 1 Instanz Abbildung A.14.: Nutzer - 3 Instanzen Abbildung A.15.: Nutzer - 5 Instanzen Abbildung A.16.: Nutzer - 3 Instanzen Abbildung A.17.: Nutzer - 5 Instanzen

112 106 Anhang A. Anhang Abbildung A.18.: Nutzer - 5 Instanzen Abbildung A.19.: Invalidierungszeiten Nutzer - 3 Instanzen Abbildung A.20.: Invalidierungszeiten Nutzer - 5 Instanzen Abbildung A.21.: Invalidierungszeiten Nutzer - 3 Instanzen

113 A.2. Lasttestergebnisse mit lokalem Cache und Message-Queue-Invalidierung 107 Abbildung A.22.: Invalidierungszeiten Nutzer - 5 Instanzen Abbildung A.23.: Invalidierungszeiten Nutzer - 5 Instanzen

Storage-Trends am LRZ. Dr. Christoph Biardzki

Storage-Trends am LRZ. Dr. Christoph Biardzki Storage-Trends am LRZ Dr. Christoph Biardzki 1 Über das Leibniz-Rechenzentrum (LRZ) Seit 50 Jahren Rechenzentrum der Bayerischen Akademie der Wissenschaften IT-Dienstleister für Münchner Universitäten

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim

Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim Tobias Neef Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim Tobias Neef Fakultät für Informatik Hochschule Mannheim tobnee@gmail.com

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Big-Data-Technologien - Überblick - Prof. Dr. Jens Albrecht

Big-Data-Technologien - Überblick - Prof. Dr. Jens Albrecht Big-Data-Technologien - Überblick - Quelle: http://www.ingenieur.de/panorama/fussball-wm-in-brasilien/elektronischer-fussball-smartphone-app-helfen-training Big-Data-Anwendungen im Unternehmen Logistik

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Diplomarbeit: Open Source Rapid Web Development Frameworks - Eine Untersuchung der Skalierungsstrategien

Diplomarbeit: Open Source Rapid Web Development Frameworks - Eine Untersuchung der Skalierungsstrategien Diplomarbeit: Open Source Rapid Web Development Frameworks - Eine Untersuchung der Skalierungsstrategien Ergebnispräsentation Kolloquium Ralf Geschke FOM Köln 27.04.2009 Gliederung Einleitung Vorgehensweise

Mehr

Caching. Hintergründe, Patterns &" Best Practices" für Business Anwendungen

Caching. Hintergründe, Patterns & Best Practices für Business Anwendungen Caching Hintergründe, Patterns &" Best Practices" für Business Anwendungen Michael Plöd" Senacor Technologies AG @bitboss Business-Anwendung!= Twitter / Facebook & co. " / kæʃ /" bezeichnet in der EDV

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Big Data Informationen neu gelebt

Big Data Informationen neu gelebt Seminarunterlage Version: 1.01 Copyright Version 1.01 vom 21. Mai 2015 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Clouds. Erwartungen der Nutzer. Wolkig bis Heiter. (c) 2013, Peter Sturm, Universität Trier. Er ist verwöhnt! Er ist nicht dankbar!

Clouds. Erwartungen der Nutzer. Wolkig bis Heiter. (c) 2013, Peter Sturm, Universität Trier. Er ist verwöhnt! Er ist nicht dankbar! Clouds Wolkig bis Heiter Erwartungen der Nutzer Er ist verwöhnt! Verfügbarkeit Viele Anwendungen Intuitive Interfaces Hohe Leistung Er ist nicht dankbar! Mehr! Mehr! Mehr! Moore 1 Erwartungen der Entwickler

Mehr

Excel beschleunigen mit dem mit Windows HPC Server 2008 R2

Excel beschleunigen mit dem mit Windows HPC Server 2008 R2 Excel beschleunigen mit dem mit Windows HPC Server 2008 R2 Steffen Krause Technical Evangelist Microsoft Deutschland GmbH http://blogs.technet.com/steffenk Haftungsausschluss Microsoft kann für die Richtigkeit

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Einführung in Hauptspeicherdatenbanken

Einführung in Hauptspeicherdatenbanken Einführung in Hauptspeicherdatenbanken Harald Zankl Probevorlesung 13. 01., 13:15 14:00, HS C Inhaltsverzeichnis Organisation Überblick Konklusion Harald Zankl (LFU) Hauptspeicherdatenbanken 2/16 Organisation

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Managed Cloud Services

Managed Cloud Services Managed Cloud Services Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Cloud Services

Mehr

Studienprojekt HP-MOM

Studienprojekt HP-MOM Institute of Parallel and Distributed Systems () Universitätsstraße 38 D-70569 Stuttgart Studienprojekt HP-MOM High Performance Message Oriented Middleware 23. Januar 2013 Kurt Rothermel, Frank Dürr, Patrick

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Informationsbroschüre

Informationsbroschüre Informationsbroschüre Überwachung, Lastverteilung, automatische Aufgaben für Microsoft Dynamics NAV Mit IT IS control 2011 können Sie viele Mandanten und NAV-Datenbanken praktisch gleichzeitig mit wenigen

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Connection Architecture Teil 3 CICS Transaction Gateway el0100 copyright W. G. Spruth,

Mehr

Softwareentwicklung in der industriellen Praxis

Softwareentwicklung in der industriellen Praxis Softwareentwicklung in der industriellen Praxis Cloud-Systeme: Besonderheiten bei Programmierung und Betrieb Steffen Gemkow / Paul Fritsche - ObjectFab GmbH 26.11.2012 Simple is beautiful Don t repeat

Mehr

JBoss 7 als Plattform für hochverfügbare Anwendungen

JBoss 7 als Plattform für hochverfügbare Anwendungen JBoss 7 als Plattform für hochverfügbare Anwendungen Orientierungspunkt 04/2013 24.05.2013, OIO Dirk Weil, GEDOPLAN GmbH Dirk Weil GEDOPLAN GmbH, Bielefeld Java EE seit 1998 Konzeption und Realisierung

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

SEMT. Prof. G. Bengel. Searching as a Service (Programming Model: MapReduce)

SEMT. Prof. G. Bengel. Searching as a Service (Programming Model: MapReduce) Hochschule Mannheim Fakultät für Informatik SEMT Prof. G. Bengel Sommersemester 2009 Semester 8I Searching as a Service (Programming Model: MapReduce) Michel Schmitt (520361) 1.06.2009 Inhalt 1. Einführung...

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda Test nichtfunktionaler in der Praxis am Beispiel einer netzzentrierten Anwendung Februar 2011 Test nichtfunktionaler Agenda 1. 2. 3. 4. 5. 6. TAV Tagung Februar 2011 Julia Remmert Public Wincor Nixdorf

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Inhaltsverzeichnis. Teil 1 Node.js... 1

Inhaltsverzeichnis. Teil 1 Node.js... 1 xiii Teil 1 Node.js... 1 1 Was ist Node.js? 3 1.1 Die Zeitalter des Webs................................... 3 1.1.1 1990 bis 2000: Das Web 1.0....................... 3 1.1.2 2000 bis 2010: Das Web 2.0.......................

Mehr

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Brownbag am Freitag, den 26.07.2013 Daniel Bäurer inovex GmbH Systems Engineer Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

200 Millionen Messwerte pro Tag. App-Monitoring bei RTLs wer-kennt-wen.de

200 Millionen Messwerte pro Tag. App-Monitoring bei RTLs wer-kennt-wen.de 200 Millionen Messwerte pro Tag App-Monitoring bei RTLs wer-kennt-wen.de Agenda Vorstellung Historische Betrachtung Klassisches Monitoring Die Evolution des Monitoring Realtime Monitoring Zusammenfassung

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

MapReduce in der Praxis

MapReduce in der Praxis MapReduce in der Praxis Rolf Daniel Seminar Multicore Programmierung 09.12.2010 1 / 53 Agenda Einleitung 1 Einleitung 2 3 Disco Hadoop BOOM 4 2 / 53 1 Einleitung 2 3 Disco Hadoop BOOM 4 3 / 53 Motivation

Mehr

Das Zettabyte. CeBIT 2011. Dr. Wolfgang Martin Analyst, ibond Partner und Ventana Research Advisor

Das Zettabyte. CeBIT 2011. Dr. Wolfgang Martin Analyst, ibond Partner und Ventana Research Advisor Das Zettabyte CeBIT 2011 Dr. Wolfgang Martin Analyst, ibond Partner und Ventana Research Advisor Das Zetabyte: analytische Datenbanken Die Datenflut. Analytische Datenbanken: Was ist neu? Analytische Datenbanken:

Mehr

Oracle Big Data Technologien Ein Überblick

Oracle Big Data Technologien Ein Überblick Oracle Big Data Technologien Ein Überblick Ralf Lange Global ISV & OEM Sales NoSQL: Eine kurze Geschichte Internet-Boom: Erste Ansätze selbstgebauter "Datenbanken" Google stellt "MapReduce"

Mehr

Spark, Impala und Hadoop in der Kreditrisikoberechnung

Spark, Impala und Hadoop in der Kreditrisikoberechnung Spark, Impala und Hadoop in der Kreditrisikoberechnung Big Data In-Memory-Technologien für mittelgroße Datenmengen TDWI München, 22. Juni 2015 Joschka Kupilas, Data Scientist, Adastra GmbH 2 Inhalt Vorwort

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Testen von webbasierten Benutzeroberflächen

Testen von webbasierten Benutzeroberflächen Studiengruppe: IB6C Email: qasmi@hm.edu Dozent: Michael Theis 1 Agenda: Das eine basierte Testumgebung 2 Wer kennt diese Situationen nicht? =>Typische Fehler bei Webanwendungen! 3 Fehler wie diese sollten

Mehr

Einführung in Hadoop

Einführung in Hadoop Einführung in Hadoop Inhalt / Lern-Ziele Übersicht: Basis-Architektur von Hadoop Einführung in HDFS Einführung in MapReduce Ausblick: Hadoop Ökosystem Optimierungen Versionen 10.02.2012 Prof. Dr. Christian

Mehr

Persönlichkeiten bei bluehands

Persönlichkeiten bei bluehands Persönlichkeiten bei Technologien bei Skalierbare Anwendungen mit Windows Azure GmbH & co.mmunication KG am@.de; posts..de/am 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit

Mehr

Microsoft System Center Data Protection Manager 2010 installieren & konfigurieren

Microsoft System Center Data Protection Manager 2010 installieren & konfigurieren Microsoft System Center Data Protection Manager 2010 installieren & konfigurieren Inhalt Data Protection Manager 2010 Installieren... 2 Große Festplatte für Backup s hinzufügen... 7 Client Agent installieren...

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

Dokumentenorientierte Datenbanken - MongoDB

Dokumentenorientierte Datenbanken - MongoDB Dokumentenorientierte Datenbanken - MongoDB Jan Hentschel Ultra Tendency UG Übersicht Dokumente sind unabhängige Einheiten Bessere Performance (zusammengehörige Daten werden gemeinsam gelesen) Objektmodell

Mehr

Mobile Backend in der

Mobile Backend in der Mobile Backend in der Cloud Azure Mobile Services / Websites / Active Directory / Kontext Auth Back-Office Mobile Users Push Data Website DevOps Social Networks Logic Others TFS online Windows Azure Mobile

Mehr

Apache Lucene. Mach s wie Google! Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.org

Apache Lucene. Mach s wie Google! Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.org Apache Lucene Mach s wie Google! Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.org 1 Apache Apache Software Foundation Software free of charge Apache Software

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Algorithmen. Consistent Hashing Bloom Filter MapReduce. Distributed Hash Tables. Einführung 1

Algorithmen. Consistent Hashing Bloom Filter MapReduce. Distributed Hash Tables. Einführung 1 Algorithmen Consistent Hashing Bloom Filter MapReduce Distributed Hash Tables Einführung 1 Consistent Hashing Problem: Wie finde ich den Speicherort für ein Objekt in einem verteilten System mit n Knoten?

Mehr

Cloud-Provider im Vergleich. Markus Knittig @mknittig

Cloud-Provider im Vergleich. Markus Knittig @mknittig Cloud-Provider im Vergleich Markus Knittig @mknittig As Amazon accumulated more and more services, the productivity levels in producing innovation and value were dropping primarily because the engineers

Mehr

Programmieren was ist das genau?

Programmieren was ist das genau? Programmieren was ist das genau? Programmieren heisst Computerprogramme herstellen (von griechisch programma für Vorschrift). Ein Computerprogramm ist Teil der Software eines Computers. Als Software bezeichnet

Mehr

Ausgewählte Kapitel der Systemsoftware: Cloud Computing

Ausgewählte Kapitel der Systemsoftware: Cloud Computing Ausgewählte Kapitel der Systemsoftware: Cloud Computing Zunächst heiter bis wolkig, später dauerhaft bedeckt Timo Hönig Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Neue Ansätze der Softwarequalitätssicherung

Neue Ansätze der Softwarequalitätssicherung Neue Ansätze der Softwarequalitätssicherung Googles MapReduce-Framework für verteilte Berechnungen am Beispiel von Apache Hadoop Universität Paderborn Fakultät für Elektrotechnik, Informatik und Mathematik

Mehr

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt. Arbeitsblätter Der Windows Small Business Server 2011 MCTS Trainer Vorbereitung zur MCTS Prüfung 70 169 Aufgaben Kapitel 1 1. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Big Data in der Forschung

Big Data in der Forschung Big Data in der Forschung Dominik Friedrich RWTH Aachen Rechen- und Kommunikationszentrum (RZ) Gartner Hype Cycle July 2011 Folie 2 Was ist Big Data? Was wird unter Big Data verstanden Datensätze, die

Mehr

Cloud-Plattform: Appscale Hochschule Mannheim

Cloud-Plattform: Appscale Hochschule Mannheim Florian Weispfenning Cloud-Computing Seminar Hochschule Mannheim WS0910 1/28 Cloud-Plattform: Appscale Hochschule Mannheim Florian Weispfenning Fakultät für Informatik Hochschule Mannheim florian.weispfenning@stud.hs-mannheim.de

Mehr

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

Play!: Elastische Skalierbarkeit für Web-Anwendungen

Play!: Elastische Skalierbarkeit für Web-Anwendungen Play!: Elastische Skalierbarkeit für Web-Anwendungen Axel Irriger GB Telecommunications & Media msg systems ag Mergenthalerallee 55-59 65760 Eschborn axel.irriger@msg-systems.com Abstract: Die Entwicklung

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Repeatable Benchmarking Mahout

Repeatable Benchmarking Mahout Studienarbeitsexposé Repeatable Benchmarking Mahout Entwicklung eines Lasttest-Rahmenwerkes für Apache Mahout von: Oliver Fischer Institut für Informatik Humbold-Universität zu Berlin Matrikelnummer: 19

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Mailbox Cluster Konzepte

Mailbox Cluster Konzepte Ideen für grosse Mailstores Mailbox Cluster Konzepte Felix J. Ogris (fjo@dts.de) Version 1.0 2008-05-25 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis 1 Schema 4 2 Storage 5 2.1 Mailbox- und

Mehr

Charakteristika und Vergleich von SQL- und NoSQL- Datenbanken

Charakteristika und Vergleich von SQL- und NoSQL- Datenbanken Universität Leipzig Fakultät für Mathematik und Informatik Abteilung Datenbanken Dozent: Prof. Dr. Erhard Rahm Betreuer: Stefan Endrullis Problemseminar NoSQL-Datenbanken Semester: WS 11/12 Charakteristika

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576 ein verteiltes und repliziertes Dateisystem is funded by the European Commission XtreemOS IPunder project contract IST-FP6-033576 1 Das XtreemOS Projekt Europäisches Forschungsprojekt gefördert von der

Mehr

WI EDI Solution. Stand 17.02.2012

WI EDI Solution. Stand 17.02.2012 WI EDI Solution Stand 17.02.2012 WIAG Überblick 2011 - SAP, SAP BW, SAP SEM/BPS, SAP BPC, SAP R/3, ABAP, Netweaver sind eingetragene Warenzeichen der SAP AG, Walldorf Folie 1 Inhalt Was ist WIEDIS? IDOC

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

Big Data. Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover

Big Data. Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover Big Data Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover Agenda Was ist Big Data? Parallele Programmierung Map/Reduce Der Big Data Zoo 2 3Vs oder: Was ist Big Data? Deutsche Telekom:

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2.

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2. Cloud Computing Frank Hallas und Alexander Butiu Universität Erlangen Nürnberg, Lehrstuhl für Hardware/Software CoDesign Multicorearchitectures and Programming Seminar, Sommersemester 2013 1. Definition

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

Aufgabenblatt 1 Musterlösung

Aufgabenblatt 1 Musterlösung Prof. Dr. rer. nat. Roland Wismüller Aufgabenblatt 1 Musterlösung Vorlesung Verteilte Systeme Sommersemester 2015 Aufgabe 1: Heterogenität und Offenheit a) Da beide Rechner an das Internet angeschlossen

Mehr

EHCache und Terracotta. Jochen Wiedmann, Software AG

EHCache und Terracotta. Jochen Wiedmann, Software AG EH und Terracotta Jochen Wiedmann, Software AG Autor Perl-Contributor DBD::mySQL 2, DBI::Proxy, DBI::Shell, DBD::CSV, Net::Daemon, RPC::Pl(Client Server) (Autor) DBI (Developer) ASF-Member (Apache Software

Mehr

Institut für Verteilte Systeme

Institut für Verteilte Systeme Institut für Verteilte Systeme Prof. Dr. Franz Hauck Seminar: Multimedia- und Internetsysteme, Wintersemester 2010/11 Betreuer: Jörg Domaschka Bericht zur Seminarssitzung am 2011-01-31 Bearbeitet von :

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Wide Column Stores. Felix Bruckner Mannheim, 15.06.2012

Wide Column Stores. Felix Bruckner Mannheim, 15.06.2012 Wide Column Stores Felix Bruckner Mannheim, 15.06.2012 Agenda Einführung Motivation Grundlagen NoSQL Grundlagen Wide Column Stores Anwendungsfälle Datenmodell Technik Wide Column Stores & Cloud Computing

Mehr

Warum Anwendungen nicht skalieren Wie man Performance- und Skalierbarkeitsprobleme findet und eliminiert

Warum Anwendungen nicht skalieren Wie man Performance- und Skalierbarkeitsprobleme findet und eliminiert Warum Anwendungen nicht skalieren Wie man Performance- und Skalierbarkeitsprobleme findet und eliminiert Alois Reitbauer, dynatrace Software Mirko Novakovic, codecentric GmbH Agenda Skalierbarkeit Das

Mehr

Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen

Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen DATA WAREHOUSE Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen Alfred Schlaucher, Detlef Schroeder DATA WAREHOUSE Themen Big Data Buzz Word oder eine neue Dimension

Mehr

Serviceorientiertes Design für Internet-GIS

Serviceorientiertes Design für Internet-GIS Serviceorientiertes Design für Internet-GIS Dr.-Ing. Peter Korduan Universität Rostock Agrar- und Umweltwissenschaftliche Fakultät Professur für Geodäsie und Geoinformatik Inhalt Einleitung Wozu serviceorientiertes

Mehr

Kademlia A Peer-to-peer Information System based on the XOR Metric

Kademlia A Peer-to-peer Information System based on the XOR Metric Kademlia A Peer-to-peer Information System based on the XOR Metric Martynas Ausra 12.5.2007 Zusammenfassung Das Kademlia-Protokoll wurde im Jahr 2002 an New York University von Petar Maymounkov und David

Mehr

BigTable. 11.12.2012 Else

BigTable. 11.12.2012 Else BigTable 11.12.2012 Else Einführung Distributed Storage System im Einsatz bei Google (2006) speichert strukturierte Daten petabyte-scale, > 1000 Nodes nicht relational, NoSQL setzt auf GFS auf 11.12.2012

Mehr