"Elastische Skalierbarkeit in der Cloud" - spritpreisrechner.at zeigt, wie man es nicht macht...

Liebe Leser!

Zugegeben - es ist immer ungleich viel schwerer, Leistung zu erbringen, als Fehlleistung zu kritisieren (als Beispiel sei die österreichische Fußball-Nationalmannschaft angeführt) - aber "die Initiative des BMWFJ für mehr Preistransparenz und Wettbewerb" hat nicht gerade einen Blitzstart hingelegt. Siehe hierfür z.B. http://diepresse.com/home/meinung/marginalien/685968/BenzinpreisRechner-stuerzt-ab_Die-Roboter-sind-schuld, wo es - sehr sarkastisch - heißt:

"Die lange erwartete 'Spritpreis-Datenbank' hätte am Dienstag online gehen sollen. Doch die Homepage kollabierte. Mit so einem Ansturm konnte ja wirklich niemand rechnen."

Seit nunmehr ca. 2 Jahren ist "Cloud Computing" in aller Munde - und die Vorteile, die das neue Paradigma ins Rennen führt, und hier interessiert uns insbesonder das Modell "Platform as a Service (PaaS)" gemeinsam mit elastischer Skalierbarkeit, auch "Auto-Scaling" genannt. Der Anwendungsfall "Spritpreis-Datenbank" - ein paar Clients melden Daten ein (Anforderung 1), viele viele (ev. auch extrem viele - Entschuldigung, wieder sarkastisch) Clients holen Daten ab (Anforderung 2), und die Daten müssen nicht transaktional-aktuell sein (Anforderung 3: soll heißen - es ist ok, wenn ein Client noch kurz den alten Preis bekommt, auch wenn der neue Preis gerade eingemeldet wurde), man verzeihe den Terminus - schreit gerade nach dem Lösungsmuster "PaaS-Cloud mit Auto-Scaling".

Wie hätte coopXarch nun die Architektur ausgelegt:

1. Web Role spritpreis-meldung@cloudanbieter.com
1. Eine "Web Role" (wir folgen hier der Microsoft Windows Azure Nomenklatur) ist das Eingangstor für Web Requests und läuft normalerweise auf einer Cloud Instanz (i.e. früher "ein Server"). Diese Web Role ist für die Melder, egal ob es Menschen über ein Web Formular sind, oder ein Automatismus, der die Preise updated (wieder über ein HTTP-basiertes Protokoll, z.B. REST).
2. Da es eine bekannte Anzahl an Meldern gibt, ist es leicht die Anzahl der Knoten zu dimensionieren - z.B. ein Knoten pro 150 potentielle Benutzer (Warum 150? weil z.B. der Apache Web Server Konfigurations-Wert "maxClients" auf 150 eingestellt ist oder der Tomcat maximal 150 worker threads bietet).
2. Web Role spritpreis-auskunft@cloudanbieter.com
1. Das ist nun die Web Role für die Auskunftsapplikation - wieder können hier Menschen vor einen Web Browser oder einer "mobilen App" sitzen bzw. Robots / Crawler, welche die Web Role für Preisauskünfte ansteuern. Hier ist die elastische Skalierbarkeit unumgänglich, da zum Design-Zeitpunkt nicht gesagt werden kann, wie viele Clients auf das Auskunftsservice zugreifen werden. Noch dazu ist mit Spitzen zu rechnen - eben (sic!) bei der Inbetriebnahme. Die Skalierung in Form des Hochstarts neuer Serverinstanzen, um die Last der Anfragen bewältigen zu können, übernimmt nun der Cloud Controller des PaaS Anbieters. Das Starten dieser zusätzlichen Instanzen muss dabei nicht länger als 10-30 Sekunden dauern - daher die Bezeichnung "elastisch", i.e. "quasi in Echtzeit je nach aktuellem Bedarf".
3. NoSQL Datenbank
1. Nachdem Konsistenz hier eine untergeordnete Rolle spielt (siehe Anforderung 3), wird eine NoSQL Datenbank verwendet, die hoch skalierbar ist und z.B. dokumentenorientiert arbeitet (Dokument "Tankstelle", Embedded Dokument "Produkt", Embedded Dokument "Preis") - ich würde hier die MongoDB als geeignet vorschlagen, da sie auch (Index-basierte) Geo-Abfragen bietet (z.B. für den Anwendungsfall "Zeige mir den billigsten Diesel im Umkreis von 5km"). Die VMWare CloudFoundry PaaS Cloud bietet etwa die MongoDB als persistenten Storage an.
4. Worker Roles "Datenbank Cleanup", "Report Generator" etc.
1. Eine "Worker Role" arbeitet "im Hintergrund" auf einer Datenbasis, um gewisse Aufgaben auszuführen. In diesem Falle könnten alle Spritpreise, die älter als die gehaltene Historie von 14 Tagen (Anforderung 4) sind, aus der Datenbank gelöscht werden. Oder es könnten Preisverlaufskurven generiert und als Bilder abgelegt werden, um Abfragen möglichst effizient mit den Verlaufskurven ausliefern zu können (Anforderung 5).

Zugegeben - viele PaaS Anbieter sind noch im Beta-Stadium bzw. bieten eventuell nur unzureichende Service Levels - ich als staatlich befugter und beeideter Ziviltechniker für Informatik finde es jedoch besonders schade, dass der Staat (in Gestalt des BMWFJ) diese unsere Kompetenz nicht zu Rate gezogen hat, um ein innovatives Service mittels innovativer Technik umzusetzen (und dieser somit ein Stückchen mehr zum Durchbruch zu verhelfen) und verbleibe, mit besten Grüßen,

Euer,
JWR@coopXarch.