The Doppler Quarterly (DEUTSCHE) Herbst 2016 | Page 48
Eine physische Architektur für die Verarbeitung am
Netzwerkrand
Folgendes Problem ist lange bekannt: Wenn ein Gerät große Datenmengen
erzeugt, die sofort verarbeitet werden müssen, entstehen bei jeder Übertra-
gung der Daten an eine zentrale Datenbank Latenzen. Im Internet der Dinge
stellt sich ein ähnliches Problem: die Verarbeitungsleistung im Verhältnis zur
Latenz.
Beispiel: Eine Maschine analysiert während der Fertigung die Qualität eines
Fahrzeugteils. Wenn das Teil bei der optischen Abtastung die Qualitätsstan-
dards nicht erfüllt, wird es automatisch aussortiert. Obwohl sich die menschli-
che Arbeit dadurch reduziert, dauert es immer noch ziemlich lange, die Daten
an die zentrale Datenbank und die Compute Engine zu übertragen, die über den
Erfolg des Fertigungsprozesses entscheidet und das Ergebnis an die Maschine
zurückgibt. Solche Verzögerungen stellen selbst für Hochgeschwindigkeits-
netzwerke ein Problem dar, da eine hohe Bandbreite nicht automatisch eine
niedrige Latenz garantiert.
Dieser Prozess wird durch die Cloud noch komplizierter. Die Daten werden
nicht vom Gerät zurück an das Rechenzentrum, sondern stattdessen an einen
Remote-Server gesendet, der Tausende Kilometer entfernt sein kann. Was noch
kritischer ist: Die Übertragung erfolgt über das offene Internet. Aufgrund der
erforderlichen Verarbeitungsleistung stellt die Cloud in diesen Fällen wahr-
scheinlich trotzdem die kostengünstigste Lösung für Entwickler dar.
Beim Edge-Computing wird die Verarbeitung größtenteils an den Rand des
Netzwerks näher an den Entstehungsort der Daten (ein IoT-Gerät, z. B. ein Sen-
sor) verlagert. Bei diesem Modell lassen sich Workloads zwischen dem Daten-
segment (üblicherweise in einer Public Cloud) und dem Computing-Segment (in
der Nähe des IoT-Geräts) aufteilen. Beim Edge-Computing sollen zeitkritische
Daten schnell verarbeitet werden, damit Ergebnisse unverzüglich an das Gerät
zurückgegeben werden können. In diesem Fall geht es um das positive bzw.
negative Ergebnis, das entscheidet, ob das Fahrzeugteil erfolgreich gefertigt
wurde. Darüber hinaus muss die Verarbeitung auch dann fortgesetzt werden
können, wenn keine Verbindung mehr zum zentralen System besteht.
Allerdings sollten die Daten in der Nähe des Geräts – normalerweise temporär
– vorgehalten und letztlich zur dauerhaften Speicherung in die Public Cloud
migriert werden. Folglich wird die Datenverarbeitung und -speicherung in der
Nähe der Quelle repliziert, was aber mehr mit einer Master/Slave-Architektur
vergleichbar ist, bei der das zentrale System letztendlich zur „Single Source of
Truth“ für alle Daten wird und die Verarbeitung am Netzwerkrand lediglich als
Knotenpunkt des zentralen Systems zu verstehen ist.
Wir benötigen eine bessere Strategie und möglicherweise auch mehr Zeit und
Geld, um leistungsfähigere, ausgereiftere IoT-Systeme zu entwickeln, die den
wachsenden Anforderungen und der höheren Komplexität des Internets der
Dinge gerecht werden, ohne den Kostenrahmen zu sprengen.
Ziele
Die Anforderungen an die Datenverarbeitung und -verwaltung haben sich durch
das Internet der Dinge grundlegend verändert. Eine gemeinsame Architektur,
die allgemeine Cloud-Funktionen und Cloud-unabhängige Technologien vereint
und sich problemlos mit bestehenden und zukünftigen Technologien integrie-
ren lässt, schafft eine solide Grundlage für ein IoT-Datenverarbeitungsmodell,
das reaktionsfähiger ist und die Betriebskosten reduziert.
46 | THE DOPPLER | Herbst 2016