52
Schalten und (Ver-)walten mit Microsoft Azure Sensordatenauswertung mit Microsoft Azure

Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

  • Upload
    zuehlke

  • View
    465

  • Download
    2

Embed Size (px)

DESCRIPTION

Haben Sie sich auch schon gewünscht, Ihre Geräte zentral über das Internet überwachen und steuern zu können, seien es nun Maschinen, Haushaltsgeräte oder Smart Devices im Bereich der Hausautomation? Im Rahmen dieses Vortrags lernen Sie eine exemplarische Architektur unter Verwendung von Microsoft Azure zur Lösung dieses Problems kennen. Die von den Geräten empfangenen Statusmeldungen bzw. Events werden dabei zentral gespeichert, wodurch komplexe Auswertungen und Abfragen möglich sind. Oftmals sollen aber nicht nur die empfangenen Daten ausgewertet, sondern einzelne Geräte gezielt konfiguriert oder geschaltet werden, was besondere Herausforderungen an die Architektur mit sich bringt, denn nicht alles was technisch machbar ist, ist unter Kostenaspekten auch sinnvoll. Da es "die eine" Lösung für alle Probleme nicht gibt, können Sie dank einer kurzen Darstellung der unterschiedlichen Methoden, sowie ihrer Vor- und Nachteile, die geeigneten für Ihren Anwendungszweck auswählen.

Citation preview

Page 1: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

Schalten und (Ver-)walten mit Microsoft Azure Sensordatenauswertung mit Microsoft Azure

Page 2: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation ist alles

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 2

Vorführender
Präsentationsnotizen
Menschen kommunizieren schon lange miteinander und dank Email und Facebook sind wir immer auf dem laufenden was sie grade machen, können uns mit Ihnen verabreden oder Aufgaben verteilen. Wäre es aber nicht auch schön, wenn wir dasselbe mit Geräten tun könnten, um sie über das Internet überwachen und steuern zu können?
Page 3: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation ist alles

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

?

Folie 3

Vorführender
Präsentationsnotizen
Wie zum Beispiel bei Offshore Windkraftanlagen, die nur schwer zu erreichen sind. Oder was ist mit der Spedition die möglichst zeitnah über Pannen, Routen- oder Terminabweichungen informiert werden möchte um sofort eingreifen oder umdisponieren zu können. Nicht vergessen werden sollte auch der aufstrebende Bereich der Automatisierung des eigenen Zuhauses. Wer hat es noch nicht erlebt, das er sich unterwegs fragt, ob er wirklich den Herd ausgestellt hat oder aber die Tür abgeschlossen hat. Oder nach einem längeren Urlaub im Winter nach Hause zurückkehrt und er alle Heizungen aufdreht damit man nicht mehr friert. Wäre es nicht prima, wenn man die Heizung bereits vorher anstellen könnte, so dass man in eine warme Wohnung heimkehrt ohne Energie verschwenden müsste? All dies ließe sich einfach lösen, wenn die Daten ebenfalls im Internet verfügbar wären und man seine Geräte auch über dies steuern könnte?
Page 4: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Die Herausforderungen

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 4

Tausende

Geräte

Latenz

Daten-sicherheit

Begrenzte Resourcen

Kosten

Internet-

anbindung

Vorführender
Präsentationsnotizen
Die Herausforderungen an die Lösung sind vielfältig. Die Anzahl der Geräte die an das System angeschlossen sind, kann mehrere tausend betragen und stätig steigen, so dass hohe Anforderungen an die Skalierbarkeit des Systems gestellt werden. Ebenso soll die Latenz, d.h. die Zeit die zwischen einer Zustandsänderung auf dem Gerät und der Sichtbarkeit im Backend möglichst kurz sein und Kommandos, die an die Geräte gesendet werden müssen möglichst zeitnah vom Gerät bearbeitet werden. Um ein überspitztes Beispiel zu nehmen: Wer möchte schon nachts nach Hause kommen und nach dem betätigen des Lichtschalters eine Minute warten, bis das Licht angeht. Auch die Datensicherheit, d.h. Sicherheit gegen ausspähen von fremden Daten oder fälschen von Daten spielt eine wesentliche Rolle, da im deutschsprachigen Raum ohnehin eine hohe Skepsis bezüglich der Speicherung von Daten in der Cloud vorherrscht. Die Geräte verfügen oftmals über begrenzte Resourcen, so dass unter Umständen die Daten nicht lange auf den Geräten zwischengespeichert werden können, oder aber komplexe Verschlüsselungen wie SSL oder Mutual Authentication nicht durchführbar sind. Ein weiterer zentraler Punkt dem die Architektur Rechnung tragen muss ist die Form der Internetanbindung. So sind die Geräte teilweise nur sporadisch mit dem Internet verbunden und zumeist nicht direkt erreichbar, da sie über dynamische IP-Adressen verfügen. Zu guter Letzt sollen die Kosten natürlich möglichst gering gehalten werden, was das bereits vorhandene Spannungsfeld zusätzlich verschärft. Cloud Lösung Im folgenden möchte ich Lösungeswege für die Realisierung mit Azure aufzeigen. Zunächst Speicherung von Daten anschließend Kommunikation mit Geräten.
Page 5: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Ein erster Ansatz

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 5

Azure

Vorführender
Präsentationsnotizen
Web role kurz als public endpoint erklären Im einfachsten Fall kommunizieren die Geräte über ein REST interface direkt mit einer Webrole. Serialisierung der Nachrichten in ein strukturiertes Format wie Json oder XML Diese prüfen die Legitimierung der Geräte dekodieren die Daten und aktualisieren den Eintrag in der Datenbank, so dass zu jedem Zeitpunkt stets der aktuelle Zustand abgefragt werden kann. Wenn immer mehr Geräte mit dem System kommunizieren, müssen auch immer mehr Webroles vorgehalten werden, da das dekodieren und ablegen der Daten in der Datenbank einige Zeit benötigt. Mit steigender Anzahl der Geräte steigt allerdings auch die Last auf die Datenbank immer weiter an, was dazu führt, das die Anfragen ebenfalls immer mehr Zeit benötigen. Eine weitere Erhöhung der Anzahl der Webroles führt auch zu keinem befriedigendem Erfolg, da der Zugriff auf den SQL Server der limitierende Faktor ist. Skalierung der Datenbank (Clusterung) Besonders problematisch wird dies, da die Anfragen nicht gleichverteilt erfolgen, und Perioden mit erhöhter Last von welchen mit geringer oder gar keiner gefolgt werden. Für das System ist es prinzipiell nicht erforderlich, das die Geräte warten müssen, bis die Daten in der Datenbank abgelegt sind. Wichtig ist lediglich, das die Daten an das Backend abgeliefert wurden und nicht verloren gehen können. (Datenbankverfügbarkeit)
Page 6: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Ein erster Ansatz

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

Azure

Folie 6

Vorführender
Präsentationsnotizen
Web role kurz als public endpoint erklären Im einfachsten Fall kommunizieren die Geräte über ein REST interface direkt mit einer Webrole. Serialisierung der Nachrichten in ein strukturiertes Format wie Json oder XML Diese prüfen die Legitimierung der Geräte dekodieren die Daten und aktualisieren den Eintrag in der Datenbank, so dass zu jedem Zeitpunkt stets der aktuelle Zustand abgefragt werden kann. Wenn immer mehr Geräte mit dem System kommunizieren, müssen auch immer mehr Webroles vorgehalten werden, da das dekodieren und ablegen der Daten in der Datenbank einige Zeit benötigt. Mit steigender Anzahl der Geräte steigt allerdings auch die Last auf die Datenbank immer weiter an, was dazu führt, das die Anfragen ebenfalls immer mehr Zeit benötigen. Eine weitere Erhöhung der Anzahl der Webroles führt auch zu keinem befriedigendem Erfolg, da der Zugriff auf den SQL Server der limitierende Faktor ist. Skalierung der Datenbank (Clusterung) Besonders problematisch wird dies, da die Anfragen nicht gleichverteilt erfolgen, und Perioden mit erhöhter Last von welchen mit geringer oder gar keiner gefolgt werden. Für das System ist es prinzipiell nicht erforderlich, das die Geräte warten müssen, bis die Daten in der Datenbank abgelegt sind. Wichtig ist lediglich, das die Daten an das Backend abgeliefert wurden und nicht verloren gehen können. (Datenbankverfügbarkeit)
Page 7: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Ein erster Ansatz

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

Azure

Folie 7

Vorführender
Präsentationsnotizen
Web role kurz als public endpoint erklären Im einfachsten Fall kommunizieren die Geräte über ein REST interface direkt mit einer Webrole. Serialisierung der Nachrichten in ein strukturiertes Format wie Json oder XML Diese prüfen die Legitimierung der Geräte dekodieren die Daten und aktualisieren den Eintrag in der Datenbank, so dass zu jedem Zeitpunkt stets der aktuelle Zustand abgefragt werden kann. Wenn immer mehr Geräte mit dem System kommunizieren, müssen auch immer mehr Webroles vorgehalten werden, da das dekodieren und ablegen der Daten in der Datenbank einige Zeit benötigt. Mit steigender Anzahl der Geräte steigt allerdings auch die Last auf die Datenbank immer weiter an, was dazu führt, das die Anfragen ebenfalls immer mehr Zeit benötigen. Eine weitere Erhöhung der Anzahl der Webroles führt auch zu keinem befriedigendem Erfolg, da der Zugriff auf den SQL Server der limitierende Faktor ist. Skalierung der Datenbank (Clusterung) Besonders problematisch wird dies, da die Anfragen nicht gleichverteilt erfolgen, und Perioden mit erhöhter Last von welchen mit geringer oder gar keiner gefolgt werden. Für das System ist es prinzipiell nicht erforderlich, das die Geräte warten müssen, bis die Daten in der Datenbank abgelegt sind. Wichtig ist lediglich, das die Daten an das Backend abgeliefert wurden und nicht verloren gehen können. (Datenbankverfügbarkeit)
Page 8: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Last Verteilung

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 6

Vorführender
Präsentationsnotizen
Um unser Beispiel der Homeautomation wieder aufzugreifen, ist beispielsweise in den Morgen- und Abendstunden mit einer höheren Anzahl an Aktualisierungen zu rechnen als dies tagsüber der Fall wäre. Um die Last besser über die Zeit besser zu verteilen, können Queues verwendet werden. Diese nehmen die Daten von den Webroles entgegen und dem Client kann signalisiert werden, das die Daten empfangen wurden. Die Anfragen der Clients können somit schneller bearbeitet werden und die Webroles stehen für Anfragen von weiteren Clients zur Verfügung. Die Workerroles übernehmen nun, das dekodieren der Nachrichten und das Schreiben in die Datenbank. Die gesamte zu verrichtende Arbeit reduziert sich hierdurch zwar nicht, aber die Queue kann die Daten in Zeiten hoher Aktivität zwischenspeichern, bis eine Workerrole die Daten verarbeiten kann. Es muss damit nicht mehr die Kapazität für Spitzenlast sondern nur noch jene für die durchschnittliche Last vorgehalten werden. Das Loadlevelling führt somit zu einer besseren Ausnutzung der Resourcen und zur Reduzierung der benötigten Instanzen, was sich unmittelbar in den entstehenden Kosten niederschlägt. Die Trennung zwischen Worker und Webroles verbessert darüber hinaus die Absicherung des Services, da im Falle einer Kompromitierung nur die von außen zugreifbaren Webroles betroffen sind, welche lediglich die Berechtigung zum Schreiben in die Queue besitzen während die Workerroles erweiterte Rechte zum Zugriff auf die Datenbank besitzen und nicht von außerhalb zugreifbar sind. Allerdings hat dieser Ansatz auch einen deutlichen Nachteil, der nicht verschwiegen werden sollte. Da die Daten nicht mehr unmittelbar in der Datenbank gespeichert werden, kann es eine Weile dauern, bis die Datenbank den aktuellen Zustand des Geräts widerspiegelt.
Page 9: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Last Verteilung

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 9

Vorführender
Präsentationsnotizen
Um unser Beispiel der Homeautomation wieder aufzugreifen, ist beispielsweise in den Morgen- und Abendstunden mit einer höheren Anzahl an Aktualisierungen zu rechnen als dies tagsüber der Fall wäre. Um die Last besser über die Zeit besser zu verteilen, können Queues verwendet werden. Diese nehmen die Daten von den Webroles entgegen und dem Client kann signalisiert werden, das die Daten empfangen wurden. Die Anfragen der Clients können somit schneller bearbeitet werden und die Webroles stehen für Anfragen von weiteren Clients zur Verfügung. Die Workerroles übernehmen nun, das dekodieren der Nachrichten und das Schreiben in die Datenbank. Die gesamte zu verrichtende Arbeit reduziert sich hierdurch zwar nicht, aber die Queue kann die Daten in Zeiten hoher Aktivität zwischenspeichern, bis eine Workerrole die Daten verarbeiten kann. Es muss damit nicht mehr die Kapazität für Spitzenlast sondern nur noch jene für die durchschnittliche Last vorgehalten werden. Das Loadlevelling führt somit zu einer besseren Ausnutzung der Resourcen und zur Reduzierung der benötigten Instanzen, was sich unmittelbar in den entstehenden Kosten niederschlägt. Die Trennung zwischen Worker und Webroles verbessert darüber hinaus die Absicherung des Services, da im Falle einer Kompromitierung nur die von außen zugreifbaren Webroles betroffen sind, welche lediglich die Berechtigung zum Schreiben in die Queue besitzen während die Workerroles erweiterte Rechte zum Zugriff auf die Datenbank besitzen und nicht von außerhalb zugreifbar sind. Allerdings hat dieser Ansatz auch einen deutlichen Nachteil, der nicht verschwiegen werden sollte. Da die Daten nicht mehr unmittelbar in der Datenbank gespeichert werden, kann es eine Weile dauern, bis die Datenbank den aktuellen Zustand des Geräts widerspiegelt.
Page 10: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Neue Anforderungen

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 7

Warum hat er es nicht gleich

gesagt? Ahja, wir brauchen noch eine Auswertung über die

letzten 6 Monate.

Vorführender
Präsentationsnotizen
Häufig kommen neue Anforderungen hinzu, die zuvor nicht bekannt waren. So wäre es z.B. möglich, das eine Auswertung durchgeführt werden soll, an welchen Stellen die LKWs besonders häufig im Stau stehen, um Optimierungen vorzunehmen, oder aber es sollen die Durchschnittstemperaturen der letzten Monate berechnet werden. Da nur der aktuelle Status gespeichert wird, sind hierüber aber keine Informationen verfügbar. Die Lösung wäre also entweder eine neue Tabelle für die historischen Daten hinzuzufügen, oder aber alle Zustandsänderungen zu speichern und somit den aktuellen Zustand zu jedem Zeitpunkt ermitteln zu können.
Page 11: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Neue Anforderungen

•Es existiert keine Historie Problem

•Auswertungen über Geschehnisse aus der Vergangenheit nicht möglich

Auswirkungen

•Speicherung aller Statusänderungen

Lösung

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 11

Vorführender
Präsentationsnotizen
Events weisen die folgenden Eigenschaften auf: Events werden von den Geräten erzeugt Events beschreiben Ereignisse aus der Vergangenheit Events sind unveränderlich Events enthalten üblicherweise weitere Parameter, welche das Event genauer beschreiben Events erhalten die Versionsnumer des Aggregats auf das sie sich beziehen. Da Events unveränderlich sind und somit keine Aktualisierungen durchgeführt werden, kann eine hohe Performance bei Schreiboperationen erreicht werden. Ebenso erleichtert der Ansatz die Events zu speichern das Troubleshooting, im Falle eines Fehlers können die Events in eine Testumgebung überführt wo, da dieser, da alle Zustandsänderungen enthalten sind, nachgestellt werden kann. Auch die Behebung von Fehlern in der Programmlogik gestaltet sich einfacher, da nach Korrektur der Programmlogik, der korrekte Zustand ermittelt werden kann und die resultierenden Daten entsprechend berichtigt werden können. Allerdings hat dieser Ansatz auch einige Nachteile: Ermittlung des aktuellen Zustands ist aufwendig Versionierung des Event Schematas Abfragen über mehrere Aggregate hinweg sind aufwendig Speicherbedarf
Page 12: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Ermittlung des aktuellen Zustands

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 9

Page 13: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Snapshots

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 10

Page 14: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Ist eine SQL Datenbank in diesem Fall das Beste?

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 11

SQL Azure Table Storage

Vorführender
Präsentationsnotizen
20.000 Entitäten pro Sekunde beruhen auf dem Limit des Storage Accounts, allerdings muss dies mit den Queues und Blobs geteilt werden. Ebenso ist es hierfür erforderlich, das die Operationen auf mehreren Partitionen ausgeführt werden. Das Limit für eine Partition beträgt 2.000 Entitäten. Die Angaben beziehen sich auf die maximal erreichbare Performance, die tatsächlich erreichbaren Werte können tiefer liegen. 200 TB für Storage Accounts, welche nach dem 7 Juli 2012 erzeugt wurden. http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx Speicherung von Daten. SQL Azure ermöglicht die Speicherung von maximal 150 GB was mit rund 168 Euro pro Monat zu Buche schlägt. Durch die Verwendung von Federations lässt sich dieses Limit erhöhen. Werden die gleichen Daten im Table Storage abgelegt entstehen hierfür lediglich Kosten in Höhe von 8 Euro, allerdings müssen hierbei Speichertransaktionen separat bezahlt werden. 8 Cent für 1 Millionen Transaktionen. Geht man davon aus, das die Daten gespeichert werden, aber nur selten darauf zugegriffen wird, ist die Verwendung von Table Storage hier günstiger. Ebenso ermöglicht Table Storage durch geschickte Wahl der Partition Id eine potentiell höhere Schreibperformance, was in unserem Szenario ein weiterer Vorteil ist. Nicht verschwiegen werden sollten hier allerdings auch die Nachteile. So ist eine Abfrage über mehrere Partitionen nicht besonders performant und es gibt keine Möglichkeiten ein Join über mehrer Tabellen auszuführen, wie dies SQL Azure erlauben würde. Da aber ohnehin nur Events gespeichert werden sollen, ist dies von untergeordneter Bedeutung.
Page 15: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Zwischenstand

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

{ "DeviceProperties": { "$values": [ { "Key": "Temperature", "Value": "21" }] }, "SourceId": "df0ebd9e-df12-4a67-b794-9b94046a4079", "Version": 1 }

Folie 12

Vorführender
Präsentationsnotizen
Da über Shared Access Policies bzw. ACS der Zugriff auf die Queues eingeschränkt werden kann und die Queues von außen zugreifbar sind kann auf die Webrole verzichtet werden, wodurch Kosten eingespart werden können. Dies gillt allerdings nur für den Fall, das die Geräte in der Lage sind SSL Verbindungen aufzubauen, welche für die Verwendung des SB zwingend erforderlich sind und b Wird eine Storage Queue verwendet, so ist es erforderlich einen Service vorzusehen, welcher die benötigten URLs inklusive Shared Access Tokens zur Verfügung stellt. Bei Verwendung von SB Queues kann der Zugriff über ACS eingeschränkt werden, wofür seitens Azure ein Access Control Service (ACS) zur Verfügung gestellt wird. Ein weiterer Vorteil der SB Queues ist das sie long polling (55s timeout) unterstützen und die Geräte weder den Service bei neu eingestellten Events benachrichtigen müssen noch das dieser die Queue pollen muss(evtl. mit exponentiellem Backoff). Auch wenn Operationen auf den Storage Queues um den Faktor 10 günstiger sind, können sie bei der Forderung nach niedriger Latenz und geringem Füllungsgrad zu höheren Kosten führen. Ein Problem, das unabhängig von der verwendeten Queue besteht ist, das es prinzipiell möglich ist mit Hilfe eines kompromittierten Geräts Statusänderungen eines anderen Gerätes vorzutäuschen. Aus diesem Grund sollte die Events vom Gerät mit einer Signatur versehen werden, welche bei der Verarbeitung durch die Workerrole geprüft wird. Sollte die Signatur ungültig sein werden die Daten nicht übernommen und der Vorfall protokolliert.
Page 16: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Zwischenstand

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

{ "DeviceProperties": { "$values": [ { "Key": "Temperature", "Value": "21" }] }, "SourceId": "df0ebd9e-df12-4a67-b794-9b94046a4079", "Version": 1 }

PartitionKey : Device ID RowKey : Version

Folie 16

Vorführender
Präsentationsnotizen
Da über Shared Access Policies bzw. ACS der Zugriff auf die Queues eingeschränkt werden kann und die Queues von außen zugreifbar sind kann auf die Webrole verzichtet werden, wodurch Kosten eingespart werden können. Dies gillt allerdings nur für den Fall, das die Geräte in der Lage sind SSL Verbindungen aufzubauen, welche für die Verwendung des SB zwingend erforderlich sind und b Wird eine Storage Queue verwendet, so ist es erforderlich einen Service vorzusehen, welcher die benötigten URLs inklusive Shared Access Tokens zur Verfügung stellt. Bei Verwendung von SB Queues kann der Zugriff über ACS eingeschränkt werden, wofür seitens Azure ein Access Control Service (ACS) zur Verfügung gestellt wird. Ein weiterer Vorteil der SB Queues ist das sie long polling (55s timeout) unterstützen und die Geräte weder den Service bei neu eingestellten Events benachrichtigen müssen noch das dieser die Queue pollen muss(evtl. mit exponentiellem Backoff). Auch wenn Operationen auf den Storage Queues um den Faktor 10 günstiger sind, können sie bei der Forderung nach niedriger Latenz und geringem Füllungsgrad zu höheren Kosten führen. Ein Problem, das unabhängig von der verwendeten Queue besteht ist, das es prinzipiell möglich ist mit Hilfe eines kompromittierten Geräts Statusänderungen eines anderen Gerätes vorzutäuschen. Aus diesem Grund sollte die Events vom Gerät mit einer Signatur versehen werden, welche bei der Verarbeitung durch die Workerrole geprüft wird. Sollte die Signatur ungültig sein werden die Daten nicht übernommen und der Vorfall protokolliert.
Page 17: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Zwischenstand

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

{ "DeviceProperties": { "$values": [ { "Key": "Temperature", "Value": "21" }] }, "SourceId": "df0ebd9e-df12-4a67-b794-9b94046a4079", "Version": 1 "HMAC": "80070713463e7749b90c2dc24911e275" }

PartitionKey : Device ID RowKey : Version

Folie 17

Vorführender
Präsentationsnotizen
Da über Shared Access Policies bzw. ACS der Zugriff auf die Queues eingeschränkt werden kann und die Queues von außen zugreifbar sind kann auf die Webrole verzichtet werden, wodurch Kosten eingespart werden können. Dies gillt allerdings nur für den Fall, das die Geräte in der Lage sind SSL Verbindungen aufzubauen, welche für die Verwendung des SB zwingend erforderlich sind und b Wird eine Storage Queue verwendet, so ist es erforderlich einen Service vorzusehen, welcher die benötigten URLs inklusive Shared Access Tokens zur Verfügung stellt. Bei Verwendung von SB Queues kann der Zugriff über ACS eingeschränkt werden, wofür seitens Azure ein Access Control Service (ACS) zur Verfügung gestellt wird. Ein weiterer Vorteil der SB Queues ist das sie long polling (55s timeout) unterstützen und die Geräte weder den Service bei neu eingestellten Events benachrichtigen müssen noch das dieser die Queue pollen muss(evtl. mit exponentiellem Backoff). Auch wenn Operationen auf den Storage Queues um den Faktor 10 günstiger sind, können sie bei der Forderung nach niedriger Latenz und geringem Füllungsgrad zu höheren Kosten führen. Ein Problem, das unabhängig von der verwendeten Queue besteht ist, das es prinzipiell möglich ist mit Hilfe eines kompromittierten Geräts Statusänderungen eines anderen Gerätes vorzutäuschen. Aus diesem Grund sollte die Events vom Gerät mit einer Signatur versehen werden, welche bei der Verarbeitung durch die Workerrole geprüft wird. Sollte die Signatur ungültig sein werden die Daten nicht übernommen und der Vorfall protokolliert.
Page 18: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Schalten und (Ver-)walten mit Microsoft Azure

Henrik Puls

Datenauswertungen Sie haben die Wahl

10. Mai 2013 Folie 13

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls

Vorführender
Präsentationsnotizen
Analyse des Eventstreams Direkte Abfragen auf die in SQL Azure gespeicherten Daten HD Insight (Apache Hadoop on Azure)
Page 19: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Datenauswertung

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 14

Vorführender
Präsentationsnotizen
Implementierung eines Event Stores ist nicht trivial. Verwendung von Azure Storage Queue hier theoretisch möglich. Um zu vermeiden, das zur Ermittlung des aktuellen Zustands eines Aggregats der Event Stream wieder eingespielt werden muss, kann der jeweils aktuelle Zustand in einer SQL Datenbank abgelegt werden, wodurch Abfragen über mehrere Aggregate einfacher ausgeführt werden können. Sollen keine weiteren Datenprojektionen oder nur sehr wenige verwendet werden, so kann eine Storage Queue verwenden werden, da diese unter Umständen preiswerter ist. Problematisch könnte sich hierbei allerdings erweisen, dass es nicht möglich ist mehrere Nachrichten auf einmal zu lesen oder zu schreiben. Die Implementierung des Event Stores ist nicht trivial Es muss sichergestellt werden, dass die Events sowohl gespeichert, als auch publiziert werden Für Azure Table Storage kann dies wie folgt erreicht werden: Innerhalb einer Transaktion werden zwei Entities eingetragen Event Kopie des Events in die Liste der unpublizierten Events Nachdem das Event erfolgreich publiziert wurde, wird die Kopie entfernt Im Falle eines Neustarts der Applikation oder einer Störung, wird die Liste mit unpublizierten Events gelesen und erneut versucht diese zu publizieren
Page 20: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Datenauswertung

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 15

Vorführender
Präsentationsnotizen
Um zu vermeiden, das zur Ermittlung des aktuellen Zustands eines Aggregats der Event Stream wieder eingespielt werden muss, kann der jeweils aktuelle Zustand in einer SQL Datenbank abgelegt werden, wodurch Abfragen über mehrere Aggregate einfacher ausgeführt werden können. Sollen keine weiteren Datenprojektionen oder nur sehr wenige verwendet werden, so kann eine Storage Queue verwenden werden, da diese unter Umständen preiswerter ist. Problematisch könnte sich hierbei allerdings erweisen, dass es nicht möglich ist mehrere Nachrichten auf einmal zu lesen oder zu schreiben. Die Implementierung des Event Stores ist nicht trivial Es muss sichergestellt werden, dass die Events sowohl gespeichert, als auch publiziert werden Für Azure Table Storage kann dies wie folgt erreicht werden: Innerhalb einer Transaktion werden zwei Entities eingetragen Event Kopie des Events in die Liste der unpublizierten Events Nachdem das Event erfolgreich publiziert wurde, wird die Kopie entfernt Im Falle eines Neustarts der Applikation oder einer Störung, wird die Liste mit unpublizierten Events gelesen und erneut versucht diese zu publizieren
Page 21: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Datenauswertung

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 16

Vorführender
Präsentationsnotizen
Alternativ: Verwendung von Topics and Subscriptions Wir hatten vorhin angesprochen, das unter Umständen, Events wieder in das System eingespielt werden müssen. Wie lässt sich dies realisieren? Nun zum einen können alle Events direkt über das Topic erneut ins System eingespielt werden, oder aber die Projektionen läden sich die für sie interessanten Events direkt aus dem Event Store. Relevant hierbei ist vor allem ob nur eine Projektion betroffen ist oder aber alle, z.B. wenn die gesamte Read Datenbank verworfen werden soll.
Page 22: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Datenauswertung

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 22

Vorführender
Präsentationsnotizen
Alternativ: Verwendung von Topics and Subscriptions Wir hatten vorhin angesprochen, das unter Umständen, Events wieder in das System eingespielt werden müssen. Wie lässt sich dies realisieren? Nun zum einen können alle Events direkt über das Topic erneut ins System eingespielt werden, oder aber die Projektionen läden sich die für sie interessanten Events direkt aus dem Event Store. Relevant hierbei ist vor allem ob nur eine Projektion betroffen ist oder aber alle, z.B. wenn die gesamte Read Datenbank verworfen werden soll.
Page 23: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

HDInsight Apache Hadoop on Azure

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 18

Input data

Mapper

Mapper

Mapper

Reducer

Reducer

Reducer

Result data

Merge (k1, [v1, v2, …, vn])

Split (k1, v1)

Sort by k1

Vorführender
Präsentationsnotizen
Big data Analyse MapReduce Ausführung auf Clustern Map, Reduce und Combine Klassen konfigurierbar Derzeit ist HDInsight nur als Preview verfügbar und so ist es nicht verwunderlich, das es sich noch nicht optimal in die Azure Landschaft eingliedert. Insbesondere müssen Erweiterungen derzeit noch in Java geschrieben werden. �€257,37 Preis für Hauptknoten bereits enthalten, der Preis weiterer Instanzen ist daher geringer
Page 24: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Schalten und (Ver-)walten mit Microsoft Azure

Henrik Puls

Steuerung der Geräte

Wie kann ein Gerät, das keine öffentliche IP-Adresse besitzt, angesprochen werden?

10. Mai 2013 Folie 19

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls

Page 25: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation

Polling Polling mit

exponentiellem Backoff

Long Polling Web sockets

Push notifications

SMS

(z.B. twillio 0,07€ pro SMS)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 20

Vorführender
Präsentationsnotizen
Es ist gut zu wissen, das es in der Wohnung kalt ist, aber noch hilfreicher wäre es natürlich, wenn man dies von unterwegs auch ändern könnte, so dass man nach seinem Urlaub in eine warme Wohnung heimkehrt. Da die Geräte für gewöhnlich über keine statische IP-Adresse verfügen können diese nicht einfach über das Internet angesprochen werden. Statt den Geräten direkt mitzuteilen, was sie zu tun haben, können die Geräte daher den Service fragen, ob neue Daten für sie verfügbar sind (Pull statt Push) Reines Polling ist mit mehreren Problemen belastet: Um die Last auf den Server zu reduzieren muss der Polling Intervall möglichst hoch gewählt werden, was aber auch dazu führt, das ein Befehl erst nach längerer Zeit ausgeführt wird. Sofern es tolerierbar ist, das ein Befehl im schlechtesten Fall eine Minute benötigt um übermittelt zu werden kann dieses Verfahren eingesetzt werden. Im Fall der Windkraftanlage mag dies auch in Ordnung sein, wenn aber beispielsweise eine Lampe einschaltet, dann möchte man wohl kaum eine Minute im dunkeln stehen. Eine Verbesserung dazu stellt das Polling mit exponentiellem Backoff dar. Hier geht man davon aus, das nachdem ein Befehl empfangen wurde, zeitlich nahe weitere Befehle folgen werden und der Intervall daher schritt für schritt verlängert wird, sofern keine Nachrichten empfangen wurden. Für unser Problem stellt dies aber keine nennenswerte Verbesserung dar. Eine Verbesserung bringt der long polling Ansatz mit sich, da hier die Verbindung offen bleibt, bis entweder eine Nachricht empfangen wird, oder aber die Verbindung getrennt wird. Aufgrund des Load Balancers wird die Verbindung bei Azure nach ca. 1 Minute beendet. Problematisch ist zusätzlich das zumindest beim IIS der für die Webroles Verwendung findet Für jede Verbindung ein eigener Thread erstellt wird, was die maximale Anzahl stark reduziert. Die Verwendung von node.js könnte hier besser geignet sein. Web sockets bleiben offen nach dem Daten empfangen wurden, ähnlich einer TCP/IP Verbindung, dies muss allerdings sowohl von Client als auch vom Server unterstützt werden. Ist das Gerät über eine mobile Verbindung angeschlossen, kommen zusätzlich noch push notifications sowie SMS in Frage. Die Benachrichtung über SMS eignet sich vor allem dann, wenn das Gerät nur sehr selten mit dem Service kommuniziert, dieses aber sehr schnell reagieren soll, wenn im Kommandos Gesendet werden. Nach Empfang einer SMS kann das Gerät sich dann direkt mit dem Service verbinden um die Kommandos abzuholen.
Page 26: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Polling

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 21

Vorführender
Präsentationsnotizen
Der Load Balancer für die Webroles arbeitet nach dem Roundrobin Prinzip. Da somit nicht sinnvoll ist Daten auf der Webrole zwischenzuspeichern, werden die Kommandos in eine Tabelle im Table Storage geschrieben. Als Partition key wird dabei die ID des Clients verwendet, so dass alle Kommandos für einen Client mit möglichst geringem Aufwand ermittelt werden können. Als Row key wird ein Timestamp verwendet um sicherzustellen, das Kommandos die zuerst eingestellt werden, auch als erstes an die Geräte übermittelt werden. Beim einstellen der Kommandos können auch ältere Kommandos, die durch das neue Kommando ohnehin überschrieben werden, entfernt werden um unnötige Befehle zu vermeiden und beispielsweise beim schalten einer Lampe Flackern zu verhindern. Sobald das Kommando erfolgreich abgeliefert wurde, kann es aus der Tabelle entfernt werden. Je nach Anwendungsfall kann es sinnvoll sein, das Kommando Erst dann aus der Liste zu entfernen, wenn sichergestellt wurde, das es nicht nur vom Client empfangen sondern auch ausgeführt wurde. Nach Ablauf einer Gewissen Zeitspanne kann es dann erneut zur Übermittlung an den Client freigegeben, oder aber gelöscht werden.
Page 27: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 22

19,0

Command

Command

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 28: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

19,0

Command

Command

Folie 28

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 29: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

19,0

Command

Command

Folie 29

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 30: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

19,0

Command

Folie 30

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 31: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

19,0

Command

Folie 31

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 32: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

21,0

Folie 32

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 33: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

21,0

Event

Folie 33

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 34: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kommunikation über Subscriptions (Long polling)

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013

21,0

Event

Folie 34

Vorführender
Präsentationsnotizen
Long Polling Falls die Clients in der Lage sind SSL Verbindungen aufzubauen, kann der Topic and Subscription Service des Service Bus benutzt werden. Die Clients können auf sie mit HTTPS oder aber über AMQP zugreifen, welches kürzlich verfügbar geworden ist. Innerhalb der nächsten 12 Monate soll außerdem MQTT unterstützt werden. Von Seiten Microsoft werden beide Protokolle als wesentlich besser für ein M2M Szenario angesehen als HTTP, vor allem da sie wesentlich kompakter sind. Besonders praktisch erweist sich dabei das Long polling mit einem maximalen Timeout von 55s unterstützt wird, wodurch sich die Anzahl der benötigten Anfragen reduziert und dennoch eine kurze Übertragungszeit für die Kommandos realisiert werden kann. Sofern die Clients keine SSL Verbindung aufbauen können, kann die Authentifizierung der Clients und der Abruf von Nachrichten aus der Subscription durch eine vorgeschaltete Webrole erfolgen, was allerdings mit deutlich höheren Kosten verbunden wäre. Zur Authentifizierung muss der Client zunächst einen ACS Token abrufen welcher im Default Fall eine Gültigkeit von 20 Minuten besitzt. Allerdings ist diese Zeitspanne variabel. Hierbei sollten die Clients einen optimistischen Ansatz verfolgen und den Token so lange wiederverwenden, bis der Server eine 401 Unauthorized Meldung zurückliefert. Die Zeitspanne kann dann nach belieben geändert werden, ohne das Änderung an den Clients notwendig werden und es können Störungen durch Ungenauigkeiten bei der Zeitmessung vermieden werden. Überarbeiten: Die Storage Queues welche zum Empfang von Statusaktualisierungen verwendet werden unterstützen kein Long polling. Aus diesem Grund müsste die Queue permanent gepollt werden, was mit sehr hohen Kosten verbunden wäre. Die Queues werden daher von den Workern mit exponentiellem Backoff gepollt, so dass sichergestellt werden kann, das die Daten zwar möglichst schnell verarbeitet werden, die Kosten dabei aber nicht extrem ansteigen. Sollte ein Gerät längere Zeit keine Events mehr gesendet haben, so muss es dies dem Service nach dem einstellen der Nachricht signalisieren, wodurch die Worker veranlasst werden, die Qeueus sofort zu überprüfen. Eine Alternative dazu wäre anstelle der Storage Queue eine Service Bus Queue zu verwenden, welche über Long polling abgefragt werden. Da Operationen auf den Storage Queues jedoch derzeit um den Faktor 10 günstiger sind, lohnt sich derzeit dieser kompliziertere Ansatz. Die gesendeten Daten solltrn dann mit Keyed-Hash Message Authentication Code (HMAC) versehen werden, welcher von den Webroles vor dem einfügen in die Queues geprüft wird. Um ein ausspähen der Daten zu verhindern sollten diese verschlüsselt übertragen werden.
Page 35: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Provisioning

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls

Registration

URIs, ACS Credentials

10. Mai 2013 Folie 35

Vorführender
Präsentationsnotizen
Bevor ein Gerät mit dem Service kommunizieren kann, muss es sich zunächst beim Service anmelden. Hierbei wird zunächst geprüft, ob sich das Gerät berechtigt ist auf den Service zuzugreifen und nicht bereits registriert ist. Hierbei kann beispielsweise die Seriennummer des Geräts verwendet werden. Ebenso ist es möglich Geräte auf eine Blacklist zu setzen um zu verhindern, das z.B. gestohlene Geräte sich am Service anmelden können. Anschließend wird falls erforderlich ein Topic, sowie eine Event Queue für das Gerät erzeugt. Die Entscheidung ob ein Topic oder eine Queue erzeugt wird hängt davon ab, wie viele Geräte diese bereits Bedienen. Die maximale Anzahl wird hauptsächlich durch die zu tolerierende Verzögerung bei der Abarbeitung von Events und Kommandos bestimmt. Für jeden Client: 1. Subscription erzeugen 2. Correlation Filter für Subscription 3. Berechtigungen für Client zum Zugriff auf Event Queue und Command Queue setzen 4. Client Informationen abspeichern Im Anschluss daran wird eine Subscription für das Topic erstellt und mit einem Filter versehen um sicherzustellen, das nur Kommandos von dem Gerät empfangen werden, die auch tatsächlich für das Gerät bestimmt sind. Zusätzlich dazu erstellt er die einen Account für den Client und weißt ihm die entsprechenden Rechte zum lesenden Zugriff auf die Command Queue, sowie zum Schreibenden Zugriff auf die Event Queue zu. Da der Provisioning Service zur Erzeugung der Topics, Subscriptions, Queues und Berechtigungen erweiterte Privilegien benötigt, sollte dieser nicht direkt von außen erreichbar sein. Denkbar wäre zum einen das sich die Clients über einen Webservice selbst registrieren können oder aber die Registrierung durch einen Benutzer über eine Weboberfläche geschieht. Registrieungsgesuche von bereits registrierten Clients sollten abgelehnt werden. Correlation Filter sind effizienter als SQL Filtern, können aber nur die Correlation Id auf Gleichheit prüfen. In diesem Szenario bietet es sich an, die Id des jeweiligen Clients als Correlation Filter zu verwenden. Service bus rights and claims Service Bus definiert einen claim type mit drei unterschiedlichen Werten. Send Listen Manage Um die Keys zum Zugriff auf den Storage Account nicht nach draußen geben zu müssen werden Shared Access Signatures verwendet. Die Shared Access Signatures sind begrenzte Zeit gültig und spezifizieren die Zugriffsrechte. Im Fall der Queue sind dies Read, Add, Update, Process. Im Gegensatz zu ACS kann dafür nicht auf einen vorhandenen Service zurückgegriffen werden, so dass dieser selbst implementiert werden muss.
Page 36: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

• Maximale Größe eines Storage Accounts beträgt 100 /200 TB – Bis zu 5 / 20 Storage Accounts für eine Azure Subscription

• Maximal 10.000 Queues/Topics in einem Service Bus Namespaces – Bis zu 50 Namespaces für eine Azure Subscription

• WASABi zum Autoscaling der Web- und Worker Roles (Microsoft Enterprise Library Autoscaling Application Block)

Skalierung

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 24

Vorführender
Präsentationsnotizen
Autoscaling Seit dem 3 Juni 2013 werden web roles und worker roles sowie virtuelle Maschinen auf Minuten statt auf Stundenbasis abgerechnet. So dass es nun auch sinnvoll sein kann bei Bedarf für kürzere Zeiträume zusätzliche Instanzen zu starten. Ebenso wird eine gestoppte Instanz nun nicht mehr berechnet. Zuvor musste die Instanz hierzu gelöscht werden.
Page 37: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Event Fan-in

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls

Durchsatz: ~ 2000 Nachrichten / Sekunde Erreichbarer Durchsatz verringert sich, da bei mehreren Subscriptions Nachrichten dupliziert werden. Topics skalieren nicht automatisch!

Maximal: 2000 Subscriptions je Topic

Table Storage Durchsatz: ~ 2000 Nachrichten / Sekunde pro Table Storage Partition ~ 20.000 Nachrichten / Sekunde pro Storage Account

Folie 37

Page 38: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Command Fan-out

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 26

Page 39: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Blick auf das Ganze

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 39

Page 40: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

• Principle of least privilege

• Access Control Services (ACS) für Service Bus

• Shared Access Policies

• Verwendung von Filtern

• Absicherung des Übertragungskanals – Mutual Authentication – SSL – HMAC

Sicherheit

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls 10. Mai 2013 Folie 28

Vorführender
Präsentationsnotizen
Falls möglich, sollte Mutual Authentication für den Zugriff auf den Server verwendet werden. Zum einen ist damit ein mitschneiden der Kommunikation nicht möglich und zum anderen kann sichergestellt werden, das nur noch legitimierte Clients den Service aufrufen können. Das hierzu auf dem Client benötigte Zertifikat sollte nach Möglichkeit in einem TPM abgelegt werden, so dass es nicht aus dem Gerät ausgelesen werden kann. Auch wenn dieses Vorgehen bereits eine gewisse Sicherheit bietet, sollte keinesfalls die weitere Absicherung des Services vernachlässigt werden, da auch mit einem TPM nicht sichergestellt werden kann, das die Software, die auf dem Client läuft nicht manipuliert wurde.
Page 41: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Sicherheit Shared Access Policies

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 29

Vorführender
Präsentationsnotizen
Shared Access Policy für Storage Queues und Table Storage Shared Access Signature Permissions: Read, Add, Update, Process
Page 42: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Performance / Ausfallsicherheit

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 30

Page 43: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Performance

• Statusaktualisierungen auf dem Client sammeln und als Batch übertragen

• Bei Bedarf den Übertragungsintervall anpassen

• Batch Inserts verwenden, falls möglich

• Ausnutzung der maximalen Nachrichtengröße

• Evtl. zu hohe End-to-End Latenz – Status auf dem Client Faken – Zusätzliche Subscription für Live Monitoring

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 31

Vorführender
Präsentationsnotizen
Sofern diese möglich ist sollten Daten auf dem Gerät gesammelt und zyklisch übertragen werden. Auf diese Weise reduziert sich die Zeit in der ein Gerät mit dem Service verbunden sein muss. Von großem Interesse ist dies vor allem dann, wenn das Gerät über eine Mobile Verbindung gekoppelt ist, welche in Abhängigkeit von der Verbindungszeit bezahlt werden muss. Ein weiter Vorteil ist die Entlastung der Webroles so dass diese mehr Clients bearbeiten können. Sollen die Daten in kürzeren Zyklen angezeigt werden, so könnte über ein Kommando der Intervall zum übermitteln der Daten für einen gewissen Zeitrahmen herabgesetzt werden. Aus Kostengründen, ist es sinnvoll die maximale Größe einer Nachricht in der Queue von 64KB auszunutzen. Aus diesen Gründen, sollten mehrere Status updates auf dem Client gesammelt werden und anschließend übertragen werden. Ein weiterer Vorteil, der sich daraus ergibt, ist das die Inserts in den Table Storage ebenfalls als Batch ausgeführt werden können und somit schneller als einzelne Updates sind. Ein Problem kann dann entstehen, wenn es notwendig ist, einem Benutzer die Updates möglichst zeitnah anzuzeigen. In diesem Fall könnte ein Kommando an den Client gesendet werden, welchen ihn dazu veranlasst, die Updates in schnelleren Zeitabständen oder bei jeder Aktualisierung zu übertragen. Um sicherzustellen, das der Client in den Resourcen schonenden Modus zurückfällt sollte die Anforderung zeitlich begrenzt werden, kommt innerhalb dieser Zeitspanne keine erneute Anforderung wird wieder gewartet, bis das Limit erreicht wird.
Page 44: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Table Storage Performance

• Bis zu 500 / 2.000 Entitäten pro Sekunde je Partition

• Bis zu 5.000 / 20.000 Entitäten pro Sekunde

• Wichtig: – Mehrere Threads verwenden – Batch inserts verwenden

– ServicePointManager.DefaultConnectionLimit = 100; – ServicePointManager.Expect100Continue = false; – ServicePointManager.UseNagleAlgorithm = false;

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 32

Page 45: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Sprechen wir über den Preis

• Annahmen – 10.000 Geräte – 1 Statusaktualisierung alle 5 Minuten mit 1kB Größe – 100 Kommandos pro Tag – Long polling mit 55s Timeout – Jeweils 2 Rollen (SLA) – Maximal 10MB Daten pro Gerät in der SQL Datenbank

• Achtung – Die Preisberechnung soll nur eine grobe Vorstellung der

Kosten geben – Unter anderem entstehen zusätzliche Kosten für:

– Ausgehendes Datenvolumen – Weitere Projektionen – Zusätzliche Worker zur Verringerung der End-to-End Latenz – Zusätzliche Webroles

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 33

Page 46: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Sprechen wir über den Preis Stand: 16.06.2013

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 34

Dienst Geamtkosten bei 10k je Monat

Long polling (Service Bus Topics) 47520 Leere Nachrichten pro Monat (55s Timeout, 30 Tage) * 10k = 476 Millionen

354,48€

Kommandos (Service Bus Topics) 3000 Kommandos pro Monat (x2 für In & Out) * 10k = 60 Millionen

44,69€

Events (Service Bus Topic) 8640 Nachrichten (x2 für In & Out für Storage Writer) * 10k = 173 Millionen

128,84€

Speicher lokal redundant 1 Aktualisierung alle 5 Minuten je 1 KB 8,44 MB pro Monat * 10k = 83 GB

4,34€ (Kosten addieren sich je Monat)

Speichertransaktionen 1 Aktualisierung alle 5 Minuten je 1 KB 8640 Transaktionen pro Monat * 10k = 87 Millionen

6,48€

Workerroles 4 Extra Small instances (Provisioning)

42,90€

Workerroles 6 Small instances

257,37€

Projektion (Service Bus Subscription) 8640 Transaktionen * 10k = 86 Millionen

64,05€

SQL Datenbank 10 MB Daten je Gerät = 100 GB

130,94€

1034,09€

Vorführender
Präsentationsnotizen
Zusätzliche Kosten: Outgoing Traffic 100 GB für 8,49€ Transaktionen und Subscriptions für weitere Projektionen 47100 leere Nachrichten für Long Polling bei nicht gefüllter Queue. Für die Kosten die bei einer Subscription zum Schreiben der Daten entstehen, können die Kosten (ca. 0,20€) also prinzipiell vernachlässigt werden.
Page 47: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Kostenentwicklung über die Jahre

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 35

1034,09

1.138,25 €

1.242,41 €

1.450,73 €

1.867,37 €

0,10 € 0,11 €

0,12 €

0,15 €

0,19 €

0,00 €

0,05 €

0,10 €

0,15 €

0,20 €

0,25 €

0,30 €

0,35 €

0,40 €

0

200

400

600

800

1000

1200

1400

1600

1800

2000

1 2 4 8 16

Gesamtkosten Kosten je Gerät

Vorführender
Präsentationsnotizen
Wie zu erkennen ist, steigen die Kosten linear über die Zeit an. Es sollte erwogen werden, wie häufig Aktualisierungen der Daten erforderlich sind und welche Daten gespeichert werden müssen. Ebenso sollte darüber nachgedacht werden, die Daten nach Ablauf einer gewissen Zeit zu entfernen und diese durch Snapshots, welche den letzten Zustand darstellen zu ersetzen.
Page 48: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Schalten und (Ver-)walten mit Microsoft Azure

Henrik Puls

Fazit

10. Mai 2013 Folie 36

Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls

Page 49: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

• Hohe Kosten für Aufbau und Betrieb eines eigenen Data Centers können vermieden werden

• Gute Skalierbarkeit für tausende Geräte

• Die entstehenden Kosten beeinflussen die Architektur maßgeblich

• Die eine Lösung für alle Probleme existiert nicht

• Aber es lässt sich für viele Probleme eine gute Lösung mit Azure realisieren

Fazit

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 37

Page 50: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

Fragen

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 38

Page 51: Sensordatenauswertung mit Microsoft Azure (Developer Week 2013)

© Zühlke 2013

• Using Service Bus for Things June 2012 MSDN Magazine "Using Service Bus for Things"

• A Smart Thermostat on the Service Bus July 2012 MSDN Magazine "A Smart Thermostat on the Service Bus"

• Scalability Targets for Storage Accounts http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx

Weitere Informationen

10. Mai 2013 Schalten und (Ver-)walten mit Microsoft Azure | Henrik Puls Folie 39