Serverless bedeutet nicht, dass es keine Server gibt. Es ist kein "Mörder" für Container und auch kein kurzlebiger Trend. Es handelt sich um einen neuen Ansatz zur Erstellung von Systemen in der Cloud. In diesem Artikel werden wir die Architektur von Serverless-Anwendungen betrachten, die Rolle des Serverless-Dienstanbieters und Open-Source-Projekte beleuchten. Am Ende sprechen wir über die Anwendungsfragen von Serverless.
Ich möchte den Backend-Bereich einer Anwendung (sogar eines Online-Shops) schreiben. Das kann ein Chat, ein Content-Veröffentlichungsdienst oder ein Load-Balancer sein. In jedem Fall wird es einige Herausforderungen geben: Du musst die Infrastruktur vorbereiten, die Abhängigkeiten der Anwendung definieren und dir Gedanken über das Betriebssystem des Hosts machen. Dann musst du kleine Komponenten aktualisieren, die die Funktionalität des restlichen Monolithen nicht beeinträchtigen. Und das Skalieren unter Last sollten wir auch nicht vergessen.
Was wäre, wenn wir flüchtige Container verwenden, in denen die benötigten Abhängigkeiten bereits vorinstalliert sind und die Container voneinander sowie vom Host-Betriebssystem isoliert sind? Wir zerteilen das Monolith in Mikrodienste, die unabhängig voneinander aktualisiert und skaliert werden können. Indem ich den Code in einen solchen Container packe, kann ich ihn auf jeder Infrastruktur ausführen. Das klingt schon besser.
Und was, wenn ich keine Container einrichten möchte? Ich möchte nicht über die Skalierung der Anwendung nachdenken. Ich möchte nicht für untätige Container zahlen, wenn die Auslastung des Dienstes minimal ist. Ich will einfach nur Code schreiben. Mich auf die Geschäftslogik konzentrieren und Produkte im Handumdrehen auf den Markt bringen.
Diese Überlegungen führten mich zu serverlosen Computing. Serverless bedeutet in diesem Fall nicht die physische Abwesenheit von Servern, sondern keine Kopfschmerzen beim Management der Infrastruktur.
Die Idee besteht darin, die Logik der Anwendung in unabhängige Funktionen zu zerlegen. Diese haben eine ereignisgesteuerte Struktur. Jede Funktion führt eine "Mikroaufgabe" aus. Alles, was vom Entwickler verlangt wird, ist, die Funktionen in die von dem Cloud-Anbieter bereitgestellte Konsole hochzuladen und sie mit Ereignisquellen zu verknüpfen. Der Code wird auf Anfrage in einem automatisch vorbereiteten Container ausgeführt, und ich bezahle nur für die Ausführungszeit.
Lassen Sie uns klären, wie der Entwicklungsprozess für die Anwendung nun aussehen wird.
Vom Standpunkt des Entwicklers
Früher haben wir über eine Anwendung für einen Online-Shop gesprochen. Im traditionellen Ansatz wird die Hauptlogik des Systems von einer monolithischen Anwendung erfüllt. Der Server mit der Anwendung läuft ständig, selbst wenn keine Last vorhanden ist.
Um zu serverless zu wechseln, zerlegen wir die Anwendung in Mikroaufgaben. Für jede von ihnen schreiben wir unsere eigene Funktion. Die Funktionen sind unabhängig voneinander und speichern keine Informationen über den Zustand (stateless). Sie können sogar in verschiedenen Sprachen geschrieben sein. Wenn eine von ihnen "ausfällt", stoppt die gesamte Anwendung nicht. Die Architektur der Anwendung wird folgendermaßen aussehen:
Die Funktionsteilung in Serverless ähnelt der Arbeit mit Mikroservices. Doch ein Mikroservice kann mehrere Aufgaben übernehmen, während eine Funktion idealerweise eine einzige Aufgabe erfüllt. Stellen wir uns vor, es gilt, Statistiken zu sammeln und diese auf Anfrage des Benutzers auszugeben. Im mikroservicebasierten Ansatz wird dies von einem einzelnen Service mit zwei Eingabepunkten erledigt: für das Schreiben und für das Lesen. In der serverlosen Architektur wären das zwei voneinander unabhängige Funktionen. Der Entwickler spart Rechenressourcen, wenn beispielsweise die Statistiken häufiger aktualisiert werden als ausgegeben.
Serverless-Funktionen müssen innerhalb eines kurzen Zeitrahmens (Timeout) ausgeführt werden, der vom Dienstanbieter vorgegeben wird. Bei AWS beträgt das Timeout beispielsweise 15 Minuten. Das bedeutet, dass langlebige Funktionen (long-lived) an diese Anforderungen angepasst werden müssen – genau das unterscheidet Serverless von anderen derzeit beliebten Technologien (Containern und Platform as a Service).
Jeder Funktion weisen wir ein Ereignis zu. Ein Ereignis ist ein Trigger für eine Aktion:
Ereignis
Aktion, die die Funktion ausführt
Ein Bild des Produkts wurde in den Speicher hochgeladen
Bild komprimieren und in das Verzeichnis hochladen
Die Adresse des physischen Geschäfts wurde in der Datenbank aktualisiert
Neuen Standort auf die Karten laden
Der Kunde bezahlt das Produkt
Zahlungsverarbeitung starten
Ereignisse können HTTP-Anfragen, Streaming-Daten, Nachrichtenwarteschlangen und mehr sein. Die Ereignisquellen sind Änderungen oder das Auftreten von Daten. Zusätzlich können Funktionen nach Zeitplan ausgeführt werden.
Die Architektur wurde ausgearbeitet, und die Anwendung ist fast serverlos geworden. Als nächstes gehen wir zum Dienstanbieter über.
Vom Anbieter aus
Normalerweise bieten cloudbasierte Dienstanbieter serverlose Berechnungen an. Sie werden unterschiedlich bezeichnet: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Wir werden den Dienst über die Konsole oder das persönliche Dashboard des Anbieters nutzen. Den Code für die Funktionen kann man auf verschiedene Arten hochladen:
- Code in den integrierten Editor über die Web-Konsole schreiben,
- ein Archiv mit dem Code hochladen,
- mit öffentlichen oder privaten Git-Repositories arbeiten.
Hier konfigurieren wir die Ereignisse, die die Funktion auslösen. Die Ereignismengen können je nach Anbieter unterschiedlich sein.
Der Anbieter hat auf seiner Infrastruktur ein automatisiertes System für Function as a Service (FaaS) aufgebaut:
- Der Funktionscode gelangt in den Speicher des Anbieters.
- Wenn ein Ereignis auftritt, werden auf dem Server automatisch Container mit einer vorbereiteten Umgebung bereitgestellt. Jeder Instanz der Funktion steht ein eigener isolierter Container zur Verfügung.
- Aus dem Speicher wird die Funktion in den Container gesendet, berechnet und das Ergebnis zurückgegeben.
- Die Anzahl der parallelen Ereignisse wächst – damit wächst auch die Anzahl der Container. Das System skalieret automatisch. Wenn keine Benutzer auf die Funktion zugreifen, bleibt sie inaktiv.
- Der Anbieter legt die Zeitspanne für die Container fest – wenn innerhalb dieses Zeitrahmens keine Funktionen im Container erscheinen, wird er zerstört.
So erhalten wir Serverless "out of the box". Wir zahlen nach dem Modell pay-as-you-go, und zwar nur für die Funktionen, die genutzt werden, und nur für die Zeit, in der sie genutzt wurden.
Um die Entwickler mit dem Dienst vertraut zu machen, bieten Anbieter bis zu 12 Monate kostenfreies Testen an, begrenzen jedoch die gesamte Rechenzeit, die Anzahl der Anfragen pro Monat, die finanziellen Mittel oder die verbrauchte Leistung.
Der Hauptvorteil der Zusammenarbeit mit einem Anbieter ist die Möglichkeit, sich keine Sorgen um die Infrastruktur (Server, virtuelle Maschinen, Container) machen zu müssen. Von Seiten des Anbieters kann FaaS sowohl auf eigenen Entwicklungen als auch mit Hilfe von Open-Source-Tools realisiert werden. Darüber werden wir gleich sprechen.
Von der Seite der Open Source
In den letzten Jahren hat die Open-Source-Community intensiv an Serverless-Tools gearbeitet. Dabei tragen auch die größten Akteure des Marktes zur Entwicklung von serverlosen Plattformen bei:
- Google bietet Entwicklern ihr Open-Source-Tool an ― . An seiner Entwicklung haben IBM, RedHat, Pivotal und SAP mitgewirkt;
- IBM haben an der Serverless-Plattform gearbeitet, die später zum Projekt der Apache Foundation wurde;
- Microsoft haben teilweise den Code der Plattform .
offen gelegt. Die Entwicklungen im Bereich der Serverless-Frameworks gehen weiter. und werden innerhalb zuvor vorbereiteter Kubernetes-Cluster bereitgestellt, funktioniert sowohl mit Kubernetes als auch mit Docker Swarm. Das Framework dient als eine Art Controller ― auf Anfrage bereitet es innerhalb des Clusters eine Ausführungsumgebung vor und startet anschließend die Funktion dort.
Frameworks bieten Möglichkeiten zur Anpassung des Tools an die eigenen Bedürfnisse. So kann der Entwickler in Kubeless die Timeout-Einstellung für die Ausführung der Funktion anpassen (Standardwert – 180 Sekunden). Fission versucht, das Problem des Cold Starts zu lösen, indem einige Container immer aktiv gehalten werden (was jedoch zusätzliche Kosten für ungenutzte Ressourcen mit sich bringt). OpenFaaS bietet eine Reihe von Triggern in verschiedenen Variationen: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs und weitere.
Einstiegsanleitungen finden Sie in der offiziellen Dokumentation der Frameworks. Die Arbeit mit ihnen erfordert etwas mehr Fähigkeiten als bei der Verwendung eines Anbieters – mindestens die Fähigkeit, einen Kubernetes-Cluster über die CLI zu starten. Im besten Fall sollten zusätzliche Open-Source-Tools (zum Beispiel ein Queue-Manager wie Kafka) in die Arbeit einbezogen werden.
Unabhängig davon, ob wir mit Serverless über einen Anbieter oder mit Open-Source arbeiten, profitieren wir von einer Reihe von Vor- und Nachteilen des Serverless-Ansatzes.
Aus der Perspektive der Vor- und Nachteile
Serverless fördert Konzepte der Container-Infrastruktur und des Microservices-Ansatzes, bei dem Teams in einer multilingualen Umgebung arbeiten können, ohne an eine bestimmte Plattform gebunden zu sein. Der Aufbau von Systemen wird vereinfacht und die Fehlerbehebung wird leichter. Die Microservice-Architektur ermöglicht es, neue Funktionen deutlich schneller hinzuzufügen als bei monolithischen Anwendungen.
Serverless reduziert die Entwicklungszeit noch weiter, da der Entwickler sich ausschließlich auf die Geschäftslogik der Anwendung und das Schreiben von Code konzentrieren kann. Infolgedessen wird die Markteinführungszeit der Entwicklungen verkürzt.
Ein zusätzlicher Vorteil ist die automatische Skalierung unter Last, wobei wir nur für genutzte Ressourcen zahlen und das auch nur zu Zeiten ihrer Nutzung.
Wie jede Technologie hat auch Serverless seine Nachteile.
Ein Beispiel für einen Nachteil kann die Kaltstartzeit sein (im Durchschnitt bis zu 1 Sekunde für Sprachen wie JavaScript, Python, Go, Java, Ruby).
Einerseits hängt die tatsächliche Zeit des kalten Starts von vielen Variablen ab: der Sprache, in der die Funktion geschrieben ist, der Anzahl der Bibliotheken, dem Umfang des Codes und der Interaktion mit zusätzlichen Ressourcen (wie Datenbanken oder Authentifizierungsservern). Da der Entwickler diese Variablen steuern kann, hat er die Möglichkeit, die Startzeit zu verkürzen. Andererseits kann der Entwickler jedoch die Startzeit des Containers nicht beeinflussen – hier hängt alles vom Anbieter ab.
Ein kalter Start kann zu einem warmen Start werden, wenn die Funktion einen zuvor von einem Ereignis gestarteten Container wiederverwendet. Dies kann in drei Fällen auftreten:
- wenn Kunden den Dienst häufig nutzen und die Anzahl der Aufrufe der Funktion steigt;
- wenn der Anbieter, die Plattform oder das Framework es ermöglichen, dass Teile der Container ständig laufen;
- wenn der Entwickler Funktionen nach einem Timer ausführt (zum Beispiel alle 3 Minuten).
Für viele Anwendungen ist der Cold Start kein Problem. Hier sollte man sich am Typ und den Zielen des Dienstes orientieren. Eine Startverzögerung von einer Sekunde ist nicht immer kritisch für eine geschäftliche Anwendung, könnte jedoch für medizinische Dienste entscheidend sein. In diesem Fall wäre ein serverloser Ansatz wahrscheinlich nicht geeignet.
Ein weiterer Nachteil von Serverless ist die kurze Lebensdauer der Funktion (Timeout, innerhalb dessen die Funktion ausgeführt werden muss).
Sollten langfristige Aufgaben anstehen, kann eine hybride Architektur verwendet werden – Serverless mit einer anderen Technologie kombinieren.
Nicht alle Systeme werden im Serverless-Modell funktionieren können.
Einige Anwendungen werden weiterhin Daten und Status während der Ausführung speichern. Einige Architekturen bleiben monolithisch, und einige Funktionen werden langlebig sein. Doch ähnlich wie einst Cloud-Technologien und später Container, hat Serverless eine vielversprechende Zukunft.
In diesem Zusammenhang möchte ich gerne zum Thema der Anwendung des Serverless-Ansatzes überleiten.
Aus der Perspektive der Anwendung
Im Jahr 2018 ist der Anteil der Serverless-Nutzung . Zu den Unternehmen, die diese Technologie bereits in ihren Dienstleistungen implementiert haben, gehören große Marktteilnehmer wie Twitter, PayPal, Netflix, T-Mobile und Coca-Cola. Dabei ist zu beachten, dass Serverless kein Allheilmittel ist, sondern ein Werkzeug zur Lösung bestimmter Aufgabenstellungen:
- Ressourcenausfälle reduzieren. Es ist nicht notwendig, eine virtuelle Maschine für Dienste aufrechtzuerhalten, die selten genutzt werden.
- Daten "on-the-fly" verarbeiten. Bilder komprimieren, Hintergründe zuschneiden, Videocodecs ändern, mit IoT-Sensoren arbeiten, mathematische Operationen ausführen.
- "Verknüpfen" Sie verschiedene Dienste miteinander. Ein Git-Repository mit internen Programmen, ein Chatbot in Slack mit Jira und einem Kalender.
- Lastenausgleich durchführen. Hier bleiben wir genauer darauf eingehen.
Angenommen, es gibt einen Dienst, der 50 Besucher hat. Für diesen läuft eine virtuelle Maschine mit schwacher Hardware. Periodisch steigt die Last auf den Dienst exponentiell. In diesem Fall kann die schwache Hardware nicht mithalten.
Sie können ein Load-Balancer-System aktivieren, das die Last beispielsweise auf drei virtuelle Maschinen verteilt. In dieser Phase können wir die Last nicht genau vorhersagen, weshalb wir einen Teil der Ressourcen für „Notfälle“ bereit halten. Und dadurch zahlen wir auch für Untätigkeit.
In dieser Situation können wir das System durch einen hybriden Ansatz optimieren: Hinter dem Load-Balancer belassen wir eine virtuelle Maschine und verlinken sie mit einem Serverless Endpoint, der Funktionen bereitstellt. Wenn die Last den Schwellenwert überschreitet, startet der Load-Balancer Funktionsinstanzen, die einen Teil der Anfrageverarbeitung übernehmen.
Auf diese Weise kann Serverless in Szenarien eingesetzt werden, in denen nicht sehr häufig, aber intensiv eine große Anzahl an Anfragen bearbeitet werden muss. In diesem Fall ist es vorteilhafter, mehrere Funktionen für 15 Minuten zu starten, als eine virtuelle Maschine oder einen Server ständig laufen zu lassen.
Trotz aller Vorteile von Serverless-Computing sollte vor der Implementierung zuerst die Logik der Anwendung bewertet und verstanden werden, welche Aufgaben Serverless in diesem speziellen Fall lösen kann.
Serverless und Selectel
Bei Selectel haben wir bereits über unser Control Panel. Wir entwickeln nun unsere eigene FaaS-Plattform. Unser Ziel ist es, Entwicklern eine einfache und flexible Schnittstelle zu bieten, um ihre Aufgaben mit Serverless zu lösen.
Wenn Sie Ideen haben, wie die ideale FaaS-Plattform aussehen sollte und wie Sie Serverless in Ihren Projekten einsetzen möchten, teilen Sie diese bitte in den Kommentaren mit. Wir werden Ihre Anregungen in die Entwicklung der Plattform einfließen lassen.
Verwendete Materialien in dem Artikel:
Quelle: habr.com
