Aufbereitung von statischen und dynamischen Daten in der Cloud

Artikel von Roland Krummenacher im Windows.Developer (8/2014): «Aufbereitung von statischen und dynamischen Daten in der Cloud» als pdf lesen

Ziel dieser Serie ist, dass Sie die Möglichkeiten der Azure- Dienste für Ihre eigenen Applikationen erkennen und deren Konzept verstehen. Ich begleite die fünf Artikel auf meinem Blog, wo Sie weitere Informationen und Links für die technische Umsetzung finden.

Das Problem

Ein Kollege sagte mir einmal: «Die besten Client-Requests sind diejenigen, die gar nie bis zu unserem Server gelangen». Was er damit meinte, erklärte er mir so: Eine Webapplikation liefert statischen und dynamischen Inhalt aus. Zum statischen Inhalt gehören Style-Sheet-Dateien, JavaScript-Dateien, Bilder, Videos und andere  Mediendateien, aber auch statisches HTML wie Header, Footer und Layout.

Dynamischer Inhalt wird zur Laufzeit generiert, typischerweise aus Daten, die in einer Datenbank gespeichert sind. Die Frage ist nun: Wieso muss unser Webserver den statischen Inhalt ausliefern? Ist das nicht eine Verschwendung von Bandbreite und CPU-Zeit unseres Webservers? Können wir diesen statischen Inhalt nicht irgendwo im Internet auslagern, wenn möglich sogar näher zum Client, damit diese Daten schneller geladen werden?

Die Lösung

Für Leser, die bereits meinen ersten Artikel gelesen haben, liegt die Lösung auf der Hand: Wir lagern statischen Inhalt in die Cloud aus (Abb. 1). Dafür verwenden wir den Dienst Azure Storage, der es uns erlaubt, diese statischen Dateien in der Cloud zu speichern und via HTTP direkt in den Browser zu laden. Listing 1 zeigt uns ein einfaches Beispiel anhand einer HTML-Seite, die statischen Inhalt aus der Cloud lädt. Im Header werden die JavaScript-Datei für jQuery und die CSS-Datei des Bootstrap-Frameworks von einem Content Delivery Network geladen (Kasten: «Content Delivery Network»).

Abb. 1: Statischen Inhalt aus der Cloud laden

Dann wird ein Bild direkt vom Azure BLOB Storage geladen. Zum Schluss wird noch mittels jQuery- Get-Funktion statisches HTML vom Azure BLOB Storage in die Seite nachgeladen. Hierfür muss eine entsprechende Cross Origin Resource Sharing Policy auf dem BLOB Storage eingerichtet sein. Weitere Informationen dazu finden Sie auf meinem Blog [1].

Das Auslagern von statischem Inhalt in die Cloud hat neben der Entlastung unseres Webservers noch weitere Vorteile: Mithilfe von Content Delivery Networks kann dieser Inhalt auf der ganzen Welt zwischengespeichert werden und ist damit sehr viel schneller geladen. Kunden in Amerika oder Asien müssen nur noch den dynamischen Inhalt von unserem Webserver in Europa laden. Die großen Script- und Mediendaten werden hochperformant von einem Content-Delivery-Datencenter in ihrer Nähe bereitgestellt. Auch öffentliche Daten aus dem Azure BLOB Storage können mittels Azure CDN
weltweit verteilt werden.

Ein weiterer Vorteil beim Auslagern von statischem Inhalt in die Cloud zeigt sich beim Verwalten und Streaming von Videodateien. Die Azure Media Services können Videodateien live oder On-Demand für Flash, HTML5, iOS, Android und Xbox streamen – inklusive Video-Encoding in der Cloud und wahlweise mit Digital Rights Management [3].

Beurteilung

Dass wir statischen Inhalt in die Cloud und auf ein Content Delivery Network auslagern können, ist nicht neu, und dank den Caching-Funktionalitäten der Browser und Internet-Service-Provider ist das Sparpotenzial auch nicht riesig. Aber in dieser Artikelserie denken wir immer etwas über den Tellerrand hinaus: Wenn wir statischen Inhalt in die Cloud auslagern können, wieso nicht auch dynamischen Inhalt?

Nehmen wir zum Beispiel den Produktkatalog eines Webshops. Er besteht aus verschiedenen Artikeln. Jeder Artikel besitzt eine Artikelnummer, eine Kurz- und eine Detailbeschreibung sowie mehrere Bilder. Diese Daten sind dynamischer Inhalt, sie werden aus der Artikeldatenbank geladen. Solche Daten können wir jedoch auch auf den Azure Storage auslagern.

Abbildung 2 zeigt uns den Aufbau: Wir speichern nur noch die Artikelnummer in unserer Datenbank. Die gesamten Artikelinformationen stehen im BLOB Storage und werden via JavaScript direkt von dort in den Browser nachgeladen. Für Textinhalte kann man wahlweise direkt HTML verwenden, XML oder JSON, wodurch sich diese Lösung auch ideal als Backend für Single-Page-Applikationen anbietet. Ändert sich jetzt die Beschreibung eines Artikels, können die Informationen direkt im Azure Storage geändert werden.

Abb. 2: Dynamischen Inhalt aus der Cloud laden

Stammt die Artikelbeschreibung von einem externen Lieferanten, kann der Azure Storage auch in den Enterprise-Application-Integration-Prozess (EAI) aufgenommen werden, zum Beispiel mit Microsoft BizTalk Server (lokal) oder Azure BizTalk Services (Cloud).

Read Models in der Cloud

Gehen wir noch einen Schritt weiter und sagen: Alle Daten werden via Cloud Storage ausgeliefert. Wir unterteilen unsere Applikation dazu nach dem Command-Query-Separation-Prinzip (CQS): Queries geben ein Resultat für eine Abfrage zurück, ändern aber nichts am Zustand eines Systems. Commands führen eine Zustandsänderung aus, besitzen aber keinen Rückgabewert. In ASP.NET MVC ist diese Unterteilung in der Regel einfach: Wenn Sie ein Formular absenden, führen Sie einen Command aus, wenn Sie das Resultat einer Abfrage darstellen, eine Query. Wir können also Query-Resultate aus der Datenbank laden, als so genannte Read Models für die Darstellung im Client aufbereiten und im Azure BLOB Storage zwischenspeichern. Abbildung 3 zeigt das Verfahren.

Abb. 3: Read Models in der Cloud

Commands werden vom Client an den Server gesendet. Der Server verarbeitet Content Delivery Network Ein Content Delivery Network, abgekürzt CDN, erlaubt es Softwareentwicklern, öffentliche Daten an verschiedenen Orten auf der Welt zu cachen. CDNs bestehen aus verschiedenen Datencentern, so genannten CDN Edges oder Endpoints. Diese Datencenter sind im Internet strategisch zentral gelegen und dafür optimiert, die Inhalte mit möglichst wenig Latenzzeit und möglichst großer Bandbreite ausliefern zu können. Fragt ein Benutzer nach einem bestimmten Inhalt, wird er via DNS-Protokoll an den nächstgelegenen verfügbaren CDN Endpoint geroutet. Dabei werden die Latenzzeit und weitere Faktoren, wie die aktuelle Belastung des Internets, berücksichtigt. CDNs können nur für öffentliche Inhalte genutzt werden, also Daten, die im Internet von allen eingesehen werden dürfen.

Nicht öffentliche Daten sollten aus Sicherheitsgründen nicht via CDN übermittelt werden. Das Microsoft Azure CDN besteht zum Zeitpunkt des Verfassens dieses Artikels aus 29 Endpoints [2]. Abb. 3: Read Models in der Cloud das Command und speichert die Zustandsänderung in der Datenbank. Die geänderten Daten werden dann in der Cloud gespeichert. Für eine Abfrage (Query) holt sich der Client das entsprechende JSON Read Model vom Azure Storage und stellt es dar. Der Server wird davon entlastet.

Diese Lösung lässt sich noch weiter optimieren: Man könnte anstelle des Azure BLOB Storage den Azure Table Storage verwenden, der ebenfalls über eine JSON/REST-Schnittstelle verfügt, aber im Gegensatz zum BLOB Storage die Daten strukturiert ablegt und damit rudimentäre Abfrageoperationen wie Filtern oder Projektionen auf den Daten ermöglicht. Weiter wäre es auch denkbar, die Commands asynchron via Cloud an den Server zu senden, zum Beispiel über den Azure- Service-Bus-Messaging-Dienst. Dies führt letztlich zu einer Architektur, die am Command Query-Responsibility-Segregation-Prinzip (CQRS) angelehnt ist. Informationen zu CQRS finden Sie unter [4] und im Zusammenhang mit Azure auf meinem Blog [1].

Fazit

Dieser dritte Artikel in der Serie «Real World Azure» zeigt, wie wir statischen und dynamischen Inhalt in die Cloud auslagern können, um unsere Applikationen performanter und skalierbarer zu machen. Dazu verwenden wir den Azure Storage und, für öffentliche Inhalte, Content-Delivery-Netzwerke. Das Prinzip wurde in diesem Artikel anhand von Webapplikationen vorgestellt.

Es lässt sich aber auch auf Desktop-, Service- oder Embedded-Applikationen adaptieren, die Daten von einem Backend beziehen. Im nächsten Artikel werden wir sehen, wie die Zuverlässigkeit und Skalierbarkeit von zeitgesteuerten Prozessen dank dem Azure Scheduler verbessert werden kann.

Links & Literatur

[1] Link nicht mehr aktuell (2021)
[2] http://msdn.microsoft.com/en-us/library/azure/gg680302.aspx
[3] http://azure.microsoft.com/en-us/solutions/media/#getstarted
[4] http://codebetter.com/gregyoung/2009/08/13/command-queryseparation/