Der Betrieb eigener Serverinfrastrukturen gilt mittlerweile als antiquiert und ist nur in speziellen Fällen noch sinnvoll. Im Zuge der Digitalisierung übernahmen Cloud Anbieter die serverseitig anfallenden Aufgaben, auch in Bezug auf die Verwaltung und Skalierung. Dadurch lagern Unternehmen die Kosten für die Anschaffung von Hardware oder die Durchführung von Softwareupdates der Server an die Cloud Anbieter aus. Somit werden sie vor allem finanziell entlastet.
Der Vorteil für den Cloud Anbieter liegt darin, dass ungenutzte Ressourcen einfach einem anderen Kunden zugeteilt werden können. Auch niedrigere Stromkosten und der Mengenrabatt bei der Anschaffung der Hardware senken die anfallenden Kosten. Nach dem Prinzip des Utility Computing muss der Kunde somit nur tatsächlich verbrauchte Rechenleistung und Ressourcen bezahlen. Wie Cloud Anbieter die gewünschten Ressourcen zur Verfügung stellen, bekommt der Kunde meist nicht mit. Durch intelligentes Load-Balancing können die Servernetze des Cloud Anbieters auf Lastspitzen reagieren und Ressourcen hinzuschalten oder bei wenigen Zugriffen ungenutzte Server abschalten und so Kosten optimieren. Eine hohe garantierte Verfügbarkeit und die Möglichkeit beinahe unendlich zu skalieren, sind nur einige der Vorteile, die eine Cloud Lösung mit sich bringt.
Im Folgenden wird im ersten Schritt die Serverless Architecture als Gesamtkonzept genauer erklärt. Anschließend werden die gängigsten Skalierungsmethoden vorgestellt, die von Cloud Anbietern eingesetzt werden.
Was genau ist Serverless Architecture?
Der Begriff ”Serverless” wird ins Deutsche übersetzt mit ”serverlos”. Dies bedeutet natürlich nicht, dass keine physischen Server mehr vorhanden sind. Es heißt nur, dass Entwickler Anwendungen erstellen und ausführen können ohne Server verwalten zu müssen. Routineaufgaben wie die Verwaltung und vor allem die Skalierung werden vom Cloud Anbieter übernommen. Der auszuführende Code wird vom Entwickler in sogenannte Container gepackt, die dann vom Server in der Cloud ausgeführt werden. Sind die Container einmal in der Cloud, werden sie über ein eventgetriebenes Ausführungsmodell ”getriggert”. Häufig genutzte ”Trigger” sind z.B. das Schreiben in eine bestimmte Datenbanktabelle oder das Einloggen eines Users. Die Anwendung kann auf das Event reagieren und im Container die gewünschte Funktion der Anwendung ausführen. Container können außerdem bedarfsabhängig agieren und können so automatisch bei steigender oder sinkender Nachfrage nach oben oder unten skaliert werden.
Auch die Abrechnung basiert auf dem eventgetriebenen Ausführungsmodell. Das heißt, man bezahlt nicht für die Zeit, in der der Container verfügbar ist, sondern für die Anzahl und die Dauer der Ausführungen. Dies ist möglich, weil dem Container erst in dem Moment, in dem sich das Event ereignet, dynamisch Ressourcen zugewiesen werden. So fallen keine Kosten an, wenn der Container nicht getriggert wird.
Serverless Lösungen lassen sich grob in zwei Unterkategorien unterteilen: Backend-as-a- Service (BaaS) und Functions-as-a-Service (FaaS). Meist ist jedoch zweiteres gemeint, wenn über klassisches Serverless Computing gesprochen wird. Sie überschneiden sich teilweise, weil in beiden Varianten der Entwickler dem Hosting des Backends wenig, bis keine Beachtung schenken muss. Um die Vorteile der jeweiligen Kategorien zu vereinen, nutzen die meisten größeren Apps wie Instagram in ihren Backend-Infrastrukturen eine Mischform.
Functions-as-a-Service
Das klassische Serverless Modell nennt sich Functions-as-a-Service und beschreibt grob das oben erklärte eventgetriebene Ausführungsmodell. Entwickler schreiben serverseitige Logik, die in Containern ausgeführt wird, sobald sich ein bestimmtes Event ereignet. Die Logik wird in einzelne Funktionen aufgeteilt, die jeweils eine einzelne Aktion ausführen. Die Funktion kann innerhalb von Millisekunden gestartet werden und sofort Anfragen verarbeiten. Bei mehreren gleichzeitigen Anfragen wird die Funktion mehrfach automatisch vom System kopiert. Ein Use-Case hierfür wäre unter anderem die Batch-Verarbeitung von Dateien oder die Übersetzung von eingehenden Texten in eine andere Sprache. FaaS eignet sich also immer dann, wenn die Anwendung zustandslos ist (oder an eine Datenbank angebunden) und/oder wenn sie sehr unregelmäßige Lastspitzen hat. Auch für asynchrone Anwendungen bietet FaaS viele Vorteile. Einige populäre Anbieter für Cloud Functions sind AWS Lambda, Azure Functions und Firebase Cloud Functions.
Backend-as-a-Service
BaaS ist im Gegensatz zu FaaS nicht eventgetrieben. Funktionen können meist über API’s aufgerufen werden und werden direkt vom Cloud Provider zur Verfügung gestellt. In diesem Fall muss kein serverseitiger Code vom Entwickler selbst geschrieben werden, sondern nur über API’s aus der clientseitigen Anwendung heraus aufgerufen. Populäre Anwendungsfälle sind die Authentifizierung von Nutzern, die Nutzung von Datenbanken in der Cloud oder das Nutzen von neuronalen Netzen für Machine Learning Algorithmen.
Ein großer Unterschied liegt in der Skalierung. Während Anwendungen, die im FaaS-Modell genutzt werden, einfach repliziert werden können, um Lastspitzen zu bedienen, ist dies bei BaaS komplizierter. Teilweise muss hier manuell vom Kunden skaliert werden, nämlich immer dann, wenn die Skalierungslogik von der klassischen Containerreplizierung abweicht. Der wohl bekannteste BaaS-Anbieter ist Google Firebase, das über zahlreiche Funktionen wie Authentifizierung, Cloud Storage, Realtime-Datenbanken etc. verfügt. Weitere Anbieter sind AWS und Microsoft Azure.
Wie skalieren serverlose Anwendungen?
Bereits Mitte der 1990er Jahre beschreibt John Young den Begriff Skalierbarkeit wie folgt: ”Die Fähigkeit [eines Systems, Anm. d. Verf.] das Performance-Niveau aufrecht zu erhalten, wenn man neue Prozessoren hinzufügt”. Dies wird auch heute noch als Teil der Definition verwendet, beschreibt aber nicht mehr alle Eigenschaften der Skalierbarkeit.
In der IT-Branche wird heutzutage ein System als skalierbar definiert, wenn es die folgenden Fähigkeiten besitzt:
1. Die Fähigkeit eines Systems oder einer Anwendung, auch dann noch zu funktionieren, wenn es in Größe oder Volumen verändert wird, um die geänderten Anforderungen des Anwenders zu erfüllen. Es wird entweder am Produkt selbst (z.B. Arbeitsspeicher oder CPU-Kerne) oder in einem neuen Kontext (z.B. ein neues Betriebssystem) skaliert.
2. Die Fähigkeit, nicht nur in der neu skalierten Umgebung zu funktionieren, sondern außerdem einen Mehrwert daraus zu ziehen. Mögliche Vorteile sind z.B., dass das System gleichzeitig mehr Nutzer bedienen kann als davor oder dass sie die Anfragen der selben Anzahl von Nutzern schneller bearbeiten kann.
Welche Rolle spielt die Elastizität?
Häufig wird die Elastizität als Synonym für Skalierbarkeit verwendet, in der Praxis stimmt das aber nur bedingt. Während Skalierbarkeit im Allgemeinen die oben gegebenen Definitionen widerspiegelt, also die Fähigkeit Hardwareressourcen dynamisch an die Last anzupassen, stellt die Elastizität sicher, dass Lastspitzen dynamisch bewältigt werden. Sie ist also die Fähigkeit, die Ressourcen so anzupassen, dass der Kunde möglichst wenig ungenutzte Ressourcen bezahlen muss. Dadurch wird sichergestellt, dass im Optimalfall die verfügbaren Ressourcen genau den aktuellen Anforderungen entsprechen. Die Grenzen der verfügbaren Ressourcen werden von der Elastizität festgelegt, während sich die Skalierbarkeit innerhalb dieser Grenzen bewegt. Idealerweise bewegen sich beide in einer Art Synergieeffekt, da beide allein jeweils nicht sonderlich effizient sind. Die effektive Nutzung von Skalierungsmethoden bedingt also die Elastizität.
Welche Methoden der Skalierung gibt es?
Skalierbarkeit wird auf der Anwendungsebene umgesetzt. Skalierbare Systeme bedienen sich zweier Methoden, um einer wachsenden Menge an Workloads gerecht zu werden und diese zu verarbeiten: der vertikalen und der horizontalen Skalierung.
Vertikale Skalierung
Die erste und am häufigsten genutzte Skalierungsmethode ist die sogenannte vertikale Skalierung. Fast jede Anwendung, die entsprechende Cloud vorausgesetzt, kann begrenzt vertikal skalieren. Dies geschieht entweder durch einen Transfer der Anwendung in eine größere virtuelle Maschine oder durch die Zuteilung von mehr Rechenkapazität an die entsprechende VM. Durch mehr CPU-Kerne, größeren Festplattenspeicher oder durch eine Erhöhung des Grafikspeichers kann die Anwendung so gleichzeitig eine höhere Anzahl an Clientanfragen bedienen.
Häufig muss vertikale Skalierung nicht vom Anwendungsentwickler mitgeplant werden, da die meisten Anwendungen dies von Haus aus unterstützen. Bei einer REST-API kann z.B. der Load-Balancer eingehende Anfragen automatisch auf die verfügbaren Ressourcen aufteilen. Ein Nachteil der vertikalen Skalierung ist die Downtime des Servers, die so lange abgewartet werden muss, bis die gewünschte Hardware hinzugefügt oder entfernt wurde. Somit besteht bei vertikalen Skalierungsmethoden immer ein höheres Risiko für Totalausfälle.
Horizontale Skalierung
Die horizontale Skalierung hingegen beschreibt das Ergänzen des Clusters um zusätzliche physische Maschinen. Dies können weitere Server, Datenbanken etc. sein. Durch eine Erhöhung der Knotenanzahl im Cluster verringert sich nun die Last, die jeder einzelne zu tragen hat. So werden neue Endpunkte für Clientanfragen geschaffen.
Horizontale Skalierung bietet sich vor allem bei eventbasierten Systemen an, da einfach mehrere Instanzen derselben Anwendung erzeugt werden. Bei Functions-as-a-Service setzen Cloud Anbieter meist auf horizontale Skalierung. Für jedes Event wird ein neuer Container erzeugt, der die entsprechende Funktion ausführt. Ist die Kapazität eines einzelnen Knotens im Cluster ausgereizt, werden einfach weitere hinzugeschalten, um die Last für jeden einzelnen zu reduzieren. So lassen sich Anwendungen mit diesem Prinzip praktisch unendlich skalieren
Klassische Anwendungen wie REST-API’s haben den Nachteil, dass sie manuellen Konfigurationsaufwand benötigen, um horizontal skalieren zu können. Hier muss geregelt sein, welche Anfrage an welchen Knoten weitergeleitet wird und wie allgemein die Last im Server-Cluster verteilt wird. Aufgrund geringer Ausfallzeiten des Clusters und der schnellen Anpassung an Laständerungen setzen viele der großen Internetfirmen und Webservices wie Google, Facebook und Amazon unter anderem auf die horizontale Skalierung.
Fazit
Abschließend muss noch einmal verdeutlicht werden, dass die beschriebenen Methoden nur einen theoretischen Ansatz darstellen und keine in der Praxis exakt so umgesetzt wird. Meistens werden Mischformen verwendet, um die Cloud-Infrastrukturen auf maximale Leistung und Effizienz auszurichten und die Kosten für den Kunden nach dem Pay-Per-Use Prinzip zu minimieren.
Die am häufigsten in der Realität verwendete Form könnte man als diagonale Skalierung bezeichnen. Sie beschreibt eine Mischform der beiden Methoden. In der Praxis bedeutet dies, dass einem einzelnen Server so lange neue Kapazitäten zur Verfügung gestellt werden, bis seine Konfiguration das nicht mehr zulässt. Ab dann wird der Server physisch repliziert, das heißt es werden weitere gleiche Serverinstanzen zum Servercluster hinzugefügt.
Im nächsten Teil der Artikelreihe wird eine Beispielapplikation in der Cloud in Bezug auf ihre Skalierbarkeit analysiert, wobei Faktoren wie Aufwand und mögliche Probleme betrachtet werden und ein weiteres Augenmerk auf die Kosten bei steigender Nutzeranzahl gelegt wird.
Verwendete Quellen: HOSKIN, Fletcher J. s J. J. s J.: Exploring IBM’s New-Age Mainframes – ISBN 978–1885068156; Skalierbarkeit; Elastizität[/artikel_text]