Lastspitzen mit Cloud-Computing begegnen

Die im Rechenzentrum eingesetzte Hardware in einem e-Commerce-Umfeld muss immer für die Spitzenlast dimensioniert sein. Wird dies nicht gemacht, ist ein Dienst in der Spitzenlast nicht performant oder nicht verfügbar. Gerade bei e-Commerce-Anwendungen ein k.o.-Kriterium und führt damit zu Image-Schäden und Umsatzverlust. Doch was kann dageben unternommen werden. In der letzter Zeit wird immer mehr der Begriff Cloud-Computing genannt. Was ist die Idee dahinter? Vereinfacht dargestellt ist eine Cloud ein Verbund aus vielen (virtuellen) Rechnern, die über Netzelemente mit einander verbunden werden und damit als Summe angesprochen werden können. Die Anzahl der virtuellen Rechner kann nun über eine Management-Plattform gesteuert werden. Es können weitere Rechner in die Produktion genommen werden, wenn die Last auf den in der Produktion befindlichen Systeme über einen bestimmten Schwellwert ansteigt. Bei weniger Last kann die Anzahl der System reduziert werden. Die erforderliche Rechenkapazität kann somit entsprechend dem Lastverhalten gesteuert werden.

Auch wirtschaftlich ist dieses Vorgehen durchaus interessant, weil ein Kunde nur die Rechenleistung bezahlen muss, die er tatsächlich nutzt. Natürlich muss der  gewählte RZ-Dienstleister entsprechende Rechenkapazitäten bereitstellen, damit er die Spitzenlasten seiner Kunden abarbeiten kann. Der RZ-Dienstleister muss auf seiner Cloud-Plattform verschiedene Kunden in der Produktion haben, damit eine gute Verteilung der Rechenleistung vorgenommen werden kann. Die Verteilung kann entweder über Services, Inhalte oder Zeitzone erfolgen. Ziel muss es sein eine gleichmäßige Auslastung über alle Kunden von 60 bis 80% zu erzeugen. Je weniger durchschnittliche Auslastung des Gesamtsystems erreicht wird, desto teurer ist die Gesamtplattform für den Betreiber, aber um so höhere Lastspitzen kann ein Kunde auf der Plattform seinen Kunden oder Diensten zur Verfügung stellen.

Bei einer Cloud denkt in der Regel jeder erst man die großen Dienstleister T-Systems oder Amazon (um nur zwei zu nennen – eine Liste von möglichen Anbietern gibt es bei wikipedia/Umsetzungen). Aber auch kleine Dienstleister können Kunden eine Cloud anbieten. So bietet z.B. der RZ-Betreiber mcs von hamburg.de einen Webcluster für seine Kunden an. Hier können viele kleine Kunden eine skalierbare Rechnerplattform nutzen und so eine hohe Verfügbarkeit und Performance erwerben. Statt einen dedizierten Server zu betreiben, werden hier die Dienste der Kunden auf einer verteilten Plattform betrieben. Eine Plattform, die sich viele Kunden wirtschaftlich nicht leisten könnten. Wenn jeder Kunde eine dedizierten Server hätte, würde er eine durchschnittliche Server-Last bis 70-80% in der Verkehrsspitze fahren. Bei einer Spitzenlast von deutlich über 100% würde seine Verfügbarkeit und Performance nicht mehr sichergestellt sein. Auf dem Webcluster von mcs kann er jedoch diese Spitzen ohne Probleme abrufen.

Können Cloud-Dienste auch bei einer bestehenden dedizierten Plattform genutzt werden? Ich habe mir hierzu einmal ein paar Gedanken gemacht. Im ersten Schritt muss überlegt werden, welche Bereiche einer Seite auf die Cloud überführt werden können. Z.B. könnten dies alle statischen Bereiche einer Web-Seite sein. Über einen vor der Web-Seite geschalteten Proxy können die statischen Seiten ausgeliefert werden. Die dynamischen Seiten(-Elemente) werden vom Proxy nicht berücksichtigt und gehen auch weiterhin direkt auf die eigentlichen Web-Seiten. Der Proxy und auch die eigentliche Webseiten müssen so implementiert werden, dass sie html-Fragmente ausliefern können. Die komplette Seite wird dann erst auf dem Client des Users wieder komplett dargestellt: statische Elemente der Webseite kommen aus dem Proxy und dynamische Elemente werden über Ajax-Requests nachgeladen. Wenn nun der statische Anteil einer Web-Seite deutlich größer ist als der dynamische Teil, so ergibt sich ein großer Performance-Gewinn, weil eine Seite nicht komplett durch den Server bei jeder Anfrage erstellt werden muss. In der Regel können natürlich auch alle großen WCM (Web-Content-Management-Systeme) ihren Content statisch cachen. Da jedoch das WCM diese Leistung erbringt, muss auch entsprechende CPU-Lizenzen bereitgestellt werden. Mit einem open source Produkt, wie z.B. dem Web Varnish, kann ein hochperformantes WebCaching aufgebaut werden. Je nach Konfiguration des WebProxy werden die Seiten (-Elemente) vom Proxy abgefragt und zwischen gespeichert. Ein Seitenabruf wird dann vom WebProxy ausgeliefert. Wenn der WebProxy auf den gleichen dedizierten Servern wie das WCM installiert ist, wird die Last für die WCM-Dienste deutlich reduziert, da z.B. nur noch alle 1 bis 15 Minuten ein Request vom Proxy auf das WCM erfolgt. Bei einem Zugriff von mehreren Anfragen pro Sekunde auf das WCM eine große Lasteinsparung. Das WCM muss jetzt nur noch die echten dynamischen Anfragen bearbeiten.

Doch was hat der vorige Absatz mit Cloud-Computing zu tun? Ganz einfach, der WebProxy wird nun in die Cloud verschoben! Obwohl der Dienst auf einer dedizierten Plattform aufgebaut ist, kann ein kontinuierlicher  Wachstum des Traffics oder plötzlich auftretende Lastspitzen im Rechenzentrum abgefedert werden, ohne die eigene Hardware-Plattform zu erweitern. Die Verteilung des Traffics für eine Domain auf die verschiedenen dedizierten Server oder auf Cloud-Instanzen wird über einen Loadbalancer vorgenommen. Im Fall der Serverplattform für das Stadtportal hamburg.de werden wir in den nächsten Monaten uns weitere Gedanken über diesen Aufbau machen. Ich möchte das zu erwartende Traffic-Wachstum nicht mehr durch die eigene dedizierte Hardware-Plattform bereitstellen, sondern durch den bei mcs bestehenden WebCluster, um damit in der Zukunft WCM-Lizenzen und Hardware-Kosten einzusparen.

Wie das Projekt bei hamburg.de weitergeht und welche technischen Schwierigkeiten zu lösen sein werden, werde ich in Zukunft hier beschreiben.