BOSON Architektur

BOSON Architektur

Um unseren Kunden eine Architektur-Lösung zu bieten die permanente Datenströme unterschiedlichster Größe verarbeitet, ad hoc Anpassungen sowie alternierende Lastszenarien beherrscht und weniger Administration erfordert, haben wir die BOSON Architektur entworfen.

Kontaktieren Sie uns

Dataflow Management Architecture

Das im Big Data Umfeld zurzeit am meisten favorisierte Architekturkonzept ist die Lambda Architektur. Sie ist ein modernes Konzept, das immer dann eingesetzt wird, wenn Rohdaten und deren Berechnungen zu jeder Zeit auf einen beliebigen Zeitpunkt zurückgesetzt und wieder neu verarbeitet werden müssen.
Die Lambda Architektur erlaubt es z.B. eine fehlerhafte Anwendung zu korrigieren, wieder zu deployen und damit alle Prozesse ab dem Zeitpunkt der fehlerhaften Ausführung erneut durchlaufen zu lassen, ohne die Konsistenz des Gesamtsystems zu beeinträchtigen.

Eine Erweiterung der Lambda Architektur ist die Kappa Architektur, die vereinfacht gesagt der Lambda Architektur ohne Batch-Verarbeitung entspricht. 
Beide Architekturansätze sind hervorragende und verbreitete Lösungen, die jedoch viel Entwicklung, Administration, Speicherplatz und eine hundertprozentige Data Provenance erfordern. Eine genauere Erklärung dafür geben wir im Abschnitt Streaming Architektur.

Um unseren Kunden eine Architektur-Lösung zu bieten die permanente Datenströme unterschiedlichster Größe verarbeitet, ad hoc Anpassungen sowie alternierende Lastszenarien beherrscht und weniger Administration erfordert, haben wir die BOSON Architektur entworfen.
Ziel der BOSON Architektur ist, auf Basis dieser Anforderungen eine übersichtliche, einfach zu administrierende, fehlertolerante und selbstüberwachende Unternehmensarchitektur zu gestalten. Gleichzeitig ermöglicht die Architektur von der Datenbeschaffung und Datenverarbeitung (Aggregation, Reporting etc.) über die Speicherung in Data Lakes bis zur Auswertung durch BI und Predictive Analytics alles zu verwalten und miteinander zu verbinden. Darüber hinaus soll sie sowohl nach außen als auch nach innen höchsten Securityanforderungen gerecht werden.
Der Kern der BOSON Architektur ist eine zentrale Streaming und Coordination Unit, die alle Abläufe steuert.

Basis der BOSON Architektur ist die Integrated Hybrid Infrastructure (IHI), die den Rahmen für Fehlertoleranz, Security, Cloud, On Demand Compute und den verteilten Anwendungsablauf liefert.

 

BOSON Architektur Blueprint

MySecondWay BOSON Architecture Blueprint

 

Die folgenden fünf Hauptkomponenten bilden die BOSON Architektur, die sicher, reaktiv, kostenbewusst und selbstüberwachend ist. Sie lassen sich je nach Kundenwunsch individuell definieren.

Business Driven Process Management

Agile Methoden wie Scrum oder Kanban sind im Development und im Projektmanagement heute in nahezu allen Unternehmen Standard. Agiles Handeln ermöglicht ein schnelles Agieren oder Reagieren auf Änderungen.

Wir verwenden hierfür den Begriff Business Driven Process Management. BDPM bedeutet eine schnelle Anpassung der Business Prozesse auf die Anforderungen des Marktes.
Im Fokus dieses Ansatzes steht die Forderung, dass eine Komponente im Business Prozess jederzeit durch eine andere Komponente ausgetauscht werden kann, ohne dass der Geschäftsprozess unterbrochen oder angehalten werden muss. Wichtig für unsere Kunden ist, dass zum Austausch von Komponenten keinerlei Kenntnisse der Gesamtinfrastruktur erforderlich sind. Komponenten, wie z.B. eine Datenbank oder ein neues oder weiteres BI/Analytics System, können ausgewechselt oder hinzugefügt werden, ohne die Abhängigkeiten der Geschäftsprozesse zu kennen oder beachten zu müssen.

On Demand Compute

In Volumen und Inhalt sich permanent ändernde Datenströme erzeugen nicht vorhersehbare Last auf die zur Verfügung stehenden Ressourcen. Unternehmen müssen darauf reagieren können. Zwei mögliche Vorgehensweisen sind hierfür in der Praxis relevant.

Eine Vorgehensweise erfordert, dass die eigene Rechenleistung so kalkuliert ist, dass im Normalbetrieb maximal 60% der Rechenkapazität benötigt wird. Steigende Last wird durch die bisher nicht genutzte Kapazität ausgeglichen. Das funktioniert bis max. 95% der zur Verfügung stehenden Kapazitäten genutzt sind. Wird weiterhin Last erzeugt, kollabiert das System. Daher muss das System entweder permanent überwacht und neue Kapazitäten hinzugefügt oder das Risiko eingegangen werden, dass Geschäftsprozesse abbrechen oder nicht rechtzeitig beendet sind. Dies führt entweder zur Erhöhung der Fixkosten oder zu unkalkulierbaren Prozesslaufzeiten.

Die zweite Vorgehensweise, die eine Hauptkomponente der BOSON Architektur bildet, ist die Nutzung einer Hybrid Cloud Lösung mit On Demand Compute. Hierbei nutzt das Unternehmen seine Rechnerkapazitäten in der Private Cloud und kann diese soweit verringern, dass im Normalbetrieb 80% der Kapazitäten genutzt werden. Über intelligentes Monitoring und moderne Analysemethoden wird die Last auf dem System überwacht und eine Vorhersage über das Verhalten des Systems in den nächsten Minuten getroffen. Übersteigt die Auslastung des Systems einen (frei definierbaren) Schwellenwert von z.B. 90%, so werden automatisch (On Demand) Kapazitäten aus der Public Cloud hinzugefügt.

Die Public Cloud dient dabei nur zur Rechenunterstützung (Compute) bzw. Entlastung des Systems.
Alle Daten bleiben im Unternehmen innerhalb der Private Cloud. Sensible Daten die in die Public Cloud übertragen werden müssen können über einen Proxy-Service völlig transparent verschlüsselt und wieder entschlüsselt werden.

 

MySecondWay Cloud encryption

Streaming Architecture

Bei vielen Big Data Umgebungen werden Daten auf dem (HDFS-)Filesystem oder in Datenbanken gespeichert und dann über verteilte Jobs ausgewertet. Ein Nachteil dieser Methode ist die Speicherung der Daten selbst. Die Datenspeicher werden durch die rasante Entwicklung immer günstiger, jedoch steigt das Datenvolumen. Wurden früher pro Tag hunderte Megabytes an Daten gespeichert, so sind es heute Gigabytes bis Terabytes. Das Speichern dieser Daten erhöht die Fixkosten durch die Anzahl der benötigten Festplatten verbunden mit einem erhöhten Stromverbrauch, mehr Lagerplatz und administrative Aufgaben sowie zusätzliche Mitarbeiter. Parallel dazu steigt die Verarbeitungsdauer, denn die Daten müssen vom Datenspeicher zur Auswertung transferiert werden. Mit der Zeit wird die Datenmenge so groß, dass die Datenlieferung (das Lesen der Daten) länger dauert als die Verarbeitung selbst und schnelle Auswertungen somit nicht mehr möglich sind.
In den meisten Fällen ist eine Zwischenspeicherung von Datenströmen nicht notwendig, da die Rohdaten selbst nur Just-In-Time nutzbar sind. Ein Beispiel hierfür sind IP-Adressen. Die Berechnung der Geodaten einer IP-Adresse liefert zukünftig sehr wahrscheinlich einen anderen Standort. Eine Transformation oder Aggregation der Rohdaten ist daher oft wichtig, um zu einem späteren Zeitpunkt aus diesen Daten die richtigen Informationen und damit die korrekten Ergebnisse zu erhalten.

Diese Vorgehensweise wirkt sich positiv auf den Speicherplatzbedarf zur Einhaltung der Data Provenance aus.
Moderne Data Lakes speichern daher nicht mehr alle Information, sondern nur noch transformierte bzw. aggregierte Daten und vermeiden somit das Auftreten von Dark Data. Das Vermeiden von Dark Data spart Speicherplatz und verringert das Risiko, dass früher gespeicherte Informationen heute nutzlos sind oder mittlerweile rechtlich nicht mehr gespeichert werden dürfen. Das Ergebnis ist ein Data Lake mit Smart Data.

Mit einer Streaming Architektur fließen die Daten ausfallsicher von der Quelle bis zum Data Lake durch das Unternehmen und werden an geeigneten Stellen transformiert oder aggregiert. Eine Unterbrechung des Datenflusses durch den Ausfall eines Prozessschrittes (Netzwerk, Softwarefehler usw.) hat keine Auswirkungen auf den Prozess.

Onsite/Offsite (Hybrid) Cloud

Die Voraussetzung für On Demand Compute ist eine sichere und einfach zu administrierende Hybrid Cloud Umgebung.
In der Private Cloud werden sensible Daten gespeichert und verarbeitet. Die Public Cloud dient zur Erhöhung der Rechenleistung und speichert selbst keine Daten. Sensible Daten werden verschlüsselt, bevor sie zur Berechnung in die Public Cloud transferiert werden. Hierfür dienen sogenannte Proxys (Kommunikationsschnittstellen), die on the fly sensible Daten verschlüsseln. Ein Encryption-Proxy, der in konfigurierbaren Abständen den Verschlüsselungsalgorithmus und den Schlüssel ändert, sichert sensible Daten bevor sie zur Berechnung in die Public Cloud gesendet werden. Die Ergebnisse der Public Cloud werden durch einen Decryption-Proxy automatisch entschlüsselt, sobald sie wieder zurück in der Private Cloud angekommen sind.

Neural Predicitve Analytics

Predictive Analytics umfasst ein weites Feld von statistischen Verfahren zu denen unter anderem Predictive Modeling und Data Mining zählen. Diese Verfahren analysieren aktuelle und historische Daten um daraus Vorhersagen auf zukünftige Ereignisse oder Trends zu berechnen.
Modernes Predictive Analytics wird von Neuronalen Netzwerken unterstützt. Neuronale Netzwerke (Artificial Neural Networks oder auch Künstliche neuronale Netzwerke) unterstützen bei der Mustererkennung, beim Finden von Ausreißern, bei der Clustersuche und vielem mehr. Der Vorteil von Neuronalen Netzwerken liegt darin, dass sie in der Lage sind ganz neue Zusammenhänge zu erkennen oder auch selbstständig Vermutungen aussprechen und teilweise Fragen dazu stellen.

Durch den Zusammenschluss von Predictive Analytics und Neural Networks werden alle Daten mittels Machine Learning bewertet, in Zusammenhang gebracht und dann über statistische Verfahren ausgewertet. Die Ergebnisse werden präziser und aussagefähiger als sie es mit bisher möglichen Systemen waren.

Die BOSON Architektur in der Praxis

Unsere Referenzimplementierung der BOSON Architektur ist speziell auf Security und die Verwendung von Open Source Software ausgelegt.
Den Rahmen der Umsetzung bildet die Integrated Hybrid Infrastructure auf Basis von OpenStack. 

Zentrale Streaming und Coordination Unit

Kern der Architektur ist Apache NiFi. Apache NiFi empfängt alle Datenströme und verarbeitet diese oder leitet sie weiter. Bei einer Unterbrechung achtet NiFi automatisch auf die Zwischenspeicherung (Queuing) der Datenströme und sorgt über Backpressure dafür, dass kein System überlastet wird und somit nicht ausfällt. NiFi bietet eine große Anzahl von fertigen Micro-Services und ein einfaches Framework zur Erweiterung. Dies spart Entwicklungskosten, da weniger Java, Scala oder Python Entwickler benötigt werden.

Apache NiFi dient dabei als zentrale Streaming und Coordination Unit mit der es einfach wird CEP Anforderungen umzusetzen.

Kern der Architektur ist Apache NiFi

Apache NiFi Copyright © 2015 The Apache Software Foundation

Kern der Architektur ist Apache NiFi

  • Zentrale Streaming und Coordination Unit
  • Einfache Umsetzung von CEP Anforderungen
  • Reaktive Businessprozesse

Integriert, sicher und erweiterbar

Integrated Hybrid Infrastructure auf Basis von OpenStack

Das Thema Security spielt in mehreren Bereichen eine besondere Rolle. Zum einen dürfen nur berechtigte Personen Zugriff auf Daten innerhalb der IHI erhalten und zum anderen muss die Infrastruktur auch innerhalb eines Unternehmens einzelne Bereiche gegeneinander abschotten. Hierfür nutzen wir die Securitymöglichkeiten von OpenStack und Hadoop um die Infrastruktur bestmöglich abzusichern.

Sichere Kommunikation

Für die sichere Kommunikation zwischen Private Cloud und Public Cloud werden modernste VPN-Technogien verwendet. Sensible Daten werden on the fly über einen Verschlüsselungsproxy geleitet, so dass diese bei Wunsch nie unverschlüsselt außerhalb der Private Cloud sind. Der Proxy ist ein von uns geschriebenes Modul, das permanent den Schlüssel ändert und dadurch die Sicherheit der Daten zusätzlich erhöht.

Industrie 4.0 und IoT ready

Metriken bzw. Systemdaten werden von jeder Rechnerinstanz über das IoT-Standardprotokoll MQTT an NiFi gesendet. Dadurch können bestehende oder zukünftige Machine-to-Machine Anbindungen über denselben Kommunikationsbus betrieben werden. Dies spart Zeit und Kosten und öffnet den Weg in Richtung IoAT (Internet of Anything) bzw. IoE (Internet of Everything).

Berechnungen, Analysen und Reports

Berechnungen, Analysen, Reports und sonstige Anwendungen werden über Hadoop oder Apache Spark Applikationen durchgeführt. Über Hadoop 2 und im Speziellen YARN (Yet Another Resource Negotiator) werden die benötigten Compute-Ressourcen für Hadoop-Applikationen und Apache Spark gesteuert und verwaltet.

Modernes Monitoring

Monitoring in der Hybrid Cloud

Das Monitoring in der Hybrid Cloud wird über ein modernes Push-Verfahren realisiert.
Die heutzutage meist genutzten Monitoringsysteme wie Nagios oder Icinga sind Pull-Systeme und haben den Nachteil, dass beim Einsatz von Autoscaling permanent die Konfiguration angepasst werden muss. 
Über zusätzliche Tools wie z.B. check_mk ist eine permanente Nachkonfiguration von Nagios/Icinga zwar möglich aber nicht sehr komfortabel. Aus unserer Sicht ist Nagios/Icinga für moderne Systeme, die On Demand Compute verwenden, nicht die beste Option.

Nagios oder Icinga nicht immer beste Wahl

Jonah Kowall, Research Vice President bei Gartner, erläutert die Nachteile von Nagios/Icinga bereits Anfang 2013 in seinem Artikel mit der etwas drastischen Überschrift „Got Nagios? Get rid of it.”.

Monitoring-System Riemann

In der BOSON Architektur setzen wir als Monitoring-System Riemann ein.
Über Riemann werden alle Systeme überwacht und das Alerting gesteuert. Dabei kann Riemann intelligent erkennen ob eine Lastgrenze durch ein Problem überschritten wurde oder ob dies nur eine kurzfristige Spitze wie z.B. durch Installation einer Anwendung ist.

Offen, erweiterbar und zentral gesteuert

Für alle anderen Bereiche wie z.B. Predictive Analytics, BI, Metriken oder dem Data Lake können verschiedene Anwendungen und Systeme zum Einsatz kommen. Dabei spielt die jeweilige Erfahrung der Anwendungsteams und vor allem des DevOps-Teams eine entscheidende Rolle.
Um langfristig eine wachsende und harmonisierende Prozesslandschaft zu gewährleisten ist es wichtig, dass alle Systeme und Anwendungen gut miteinander agieren können und Updates oder Upgrades zueinander passen.

Der wichtigste Grundsatz der BOSON Architektur ist, dass jede Kommunikation über eine zentrale Streaming und Coordination Unit wie z.B. Apache NiFi durchgeführt wird. Sämtliche Nachrichten, Events oder sonstige Daten werden über diese Komponente gesteuert. Auch das Monitoring über Riemann oder das Speichern von Metriken wird bei uns über NiFi durchgeführt.

Dadurch kann jede Komponente zu jeder Zeit ausgetauscht oder Upgedatet werden ohne das gesamte System stoppen zu müssen. Durch NiFi, als zentrale Koordinationsstelle, kann der Workflow der Geschäftsprozesse geändert oder erweitert werden ohne das System zu beeinflussen. Jederzeit und im laufenden Betrieb. Dies führt zu einer emergenten Organisation der Unternehmensprozesse.

My Second Way

Sie haben noch Fragen?

Sprechen Sie uns an. Oder senden Sie uns eine eMail an contact@MySecondWay.com