Bei Serverless geht es nicht um die physische Abwesenheit von Servern. Dies ist kein Containerkiller oder ein vorübergehender Trend. Dies ist ein neuer Ansatz zum Aufbau von Systemen in der Cloud. Im heutigen Artikel werden wir auf die Architektur serverloser Anwendungen eingehen. Sehen wir uns an, welche Rolle der Serverless-Dienstanbieter und Open-Source-Projekte spielen. Lassen Sie uns abschließend über die Probleme bei der Verwendung von Serverless sprechen.
Ich möchte einen Serverteil einer Anwendung (oder sogar eines Online-Shops) schreiben. Dies kann ein Chat, ein Content-Publishing-Dienst oder ein Load Balancer sein. In jedem Fall wird es viel Kopfzerbrechen geben: Sie müssen die Infrastruktur vorbereiten, die Anwendungsabhängigkeiten bestimmen und über das Host-Betriebssystem nachdenken. Dann müssen Sie kleine Komponenten aktualisieren, die den Betrieb des restlichen Monolithen nicht beeinträchtigen. Vergessen wir nicht die Skalierung unter Last.
Was wäre, wenn wir kurzlebige Container nehmen würden, in denen die erforderlichen Abhängigkeiten bereits vorinstalliert sind und die Container selbst voneinander und vom Host-Betriebssystem isoliert sind? Wir werden den Monolithen in Microservices unterteilen, die jeweils unabhängig voneinander aktualisiert und skaliert werden können. Indem ich den Code in einem solchen Container platziere, kann ich ihn auf jeder Infrastruktur ausführen. Schon besser.
Was ist, wenn Sie keine Container konfigurieren möchten? Ich möchte nicht über eine Skalierung der Anwendung nachdenken. Ich möchte nicht für im Leerlauf laufende Container bezahlen, wenn die Auslastung des Dienstes minimal ist. Ich möchte Code schreiben. Konzentrieren Sie sich auf die Geschäftslogik und bringen Sie Produkte in Lichtgeschwindigkeit auf den Markt.
Solche Gedanken führten mich zum Serverless Computing. Serverlos bedeutet in diesem Fall Nicht das physische Fehlen von Servern, sondern das Fehlen von Problemen bei der Infrastrukturverwaltung.
Die Idee ist, dass die Anwendungslogik in unabhängige Funktionen zerlegt wird. Sie haben eine Eventstruktur. Jede Funktion führt eine „Mikroaufgabe“ aus. Der Entwickler muss lediglich die Funktionen in die vom Cloud-Anbieter bereitgestellte Konsole laden und mit Ereignisquellen korrelieren. Der Code wird bei Bedarf in einem automatisch vorbereiteten Container ausgeführt und ich bezahle nur die Ausführungszeit.
Mal sehen, wie der Anwendungsentwicklungsprozess jetzt aussehen wird.
Von Seiten des Entwicklers
Vorhin haben wir über eine Bewerbung für einen Online-Shop gesprochen. Beim traditionellen Ansatz wird die Hauptlogik des Systems von einer monolithischen Anwendung ausgeführt. Und der Server mit der Anwendung läuft ständig, auch wenn keine Last vorhanden ist.
Um auf Serverlos umzusteigen, unterteilen wir die Anwendung in Mikrotasks. Für jede davon schreiben wir unsere eigene Funktion. Die Funktionen sind unabhängig voneinander und speichern keine Zustandsinformationen (zustandslos). Sie können sogar in verschiedenen Sprachen verfasst sein. Wenn einer von ihnen „fällt“, wird die gesamte Anwendung nicht gestoppt. Die Anwendungsarchitektur sieht folgendermaßen aus:
Die Aufteilung in Funktionen in Serverless ähnelt der Arbeit mit Microservices. Ein Microservice kann jedoch mehrere Aufgaben ausführen, und eine Funktion sollte idealerweise eine davon ausführen. Stellen wir uns vor, dass die Aufgabe darin besteht, Statistiken zu sammeln und diese auf Wunsch des Benutzers anzuzeigen. Beim Microservice-Ansatz wird eine Aufgabe von einem Dienst mit zwei Einstiegspunkten ausgeführt: Schreiben und Lesen. Beim Serverless Computing handelt es sich dabei um zwei unterschiedliche Funktionen, die nicht miteinander in Zusammenhang stehen. Der Entwickler spart Rechenressourcen, wenn beispielsweise Statistiken häufiger aktualisiert als heruntergeladen werden.
Serverlose Funktionen müssen in einem kurzen Zeitraum (Timeout) ausgeführt werden, der vom Dienstanbieter festgelegt wird. Für AWS beträgt das Timeout beispielsweise 15 Minuten. Das bedeutet, dass langlebige Funktionen an die Anforderungen angepasst werden müssen – das unterscheidet Serverless von anderen heute gängigen Technologien (Container und Platform as a Service).
Wir weisen jeder Funktion ein Ereignis zu. Ein Ereignis ist ein Auslöser für eine Aktion:
Veranstaltung
Die Aktion, die die Funktion ausführt
Ein Produktbild wurde in das Repository hochgeladen.
Komprimieren Sie das Bild und laden Sie es in ein Verzeichnis hoch
Die Adresse des physischen Geschäfts wurde in der Datenbank aktualisiert
Laden Sie einen neuen Standort in Karten
Der Kunde bezahlt die Ware
Starten Sie die Zahlungsabwicklung
Ereignisse können HTTP-Anfragen, Streaming-Daten, Nachrichtenwarteschlangen usw. sein. Ereignisquellen sind Änderungen oder Vorkommnisse von Daten. Darüber hinaus können Funktionen durch einen Timer ausgelöst werden.
Die Architektur wurde ausgearbeitet und die Anwendung wurde fast serverlos. Als nächstes gehen wir zum Dienstleister.
Von Seiten des Anbieters
Typischerweise wird Serverless Computing von Cloud-Dienstleistern angeboten. Sie heißen unterschiedlich: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Wir nutzen den Dienst über die Konsole oder das persönliche Konto des Anbieters. Funktionscode kann auf eine der folgenden Arten heruntergeladen werden:
- Code in integrierten Editoren über die Webkonsole schreiben,
- Laden Sie das Archiv mit dem Code herunter,
- Arbeiten Sie mit öffentlichen oder privaten Git-Repositorys.
Hier richten wir die Ereignisse ein, die die Funktion aufrufen. Die Ereignissätze können bei verschiedenen Anbietern unterschiedlich sein.
Der Anbieter hat das Function as a Service (FaaS)-System auf seiner Infrastruktur aufgebaut und automatisiert:
- Der Funktionscode landet im Speicher auf der Anbieterseite.
- Wenn ein Ereignis eintritt, werden Container mit einer vorbereiteten Umgebung automatisch auf dem Server bereitgestellt. Jede Funktionsinstanz verfügt über einen eigenen isolierten Container.
- Aus dem Speicher wird die Funktion an den Container gesendet, berechnet und gibt das Ergebnis zurück.
- Die Zahl der Parallelveranstaltungen wächst – die Zahl der Container wächst. Das System skaliert automatisch. Wenn Benutzer nicht auf die Funktion zugreifen, ist sie inaktiv.
- Der Anbieter legt die Leerlaufzeit für Container fest. Wenn während dieser Zeit keine Funktionen im Container angezeigt werden, wird dieser zerstört.
Auf diese Weise erhalten wir Serverless sofort einsatzbereit. Wir vergüten die Leistung im Rahmen des Pay-as-you-go-Modells und zwar nur für die in Anspruch genommenen Funktionen und nur für die Zeit, in der diese in Anspruch genommen wurden.
Um Entwickler an den Dienst heranzuführen, bieten die Anbieter bis zu 12 Monate kostenlose Tests an, begrenzen jedoch die Gesamtrechenzeit, die Anzahl der Anfragen pro Monat, die Mittel oder den Stromverbrauch.
Der Hauptvorteil der Zusammenarbeit mit einem Anbieter besteht darin, dass Sie sich keine Gedanken über die Infrastruktur (Server, virtuelle Maschinen, Container) machen müssen. Der Anbieter wiederum kann FaaS sowohl mit eigenen Entwicklungen als auch mit Open-Source-Tools umsetzen. Lassen Sie uns weiter darüber sprechen.
Von der Open-Source-Seite
Die Open-Source-Community arbeitet seit einigen Jahren aktiv an serverlosen Tools. Auch die größten Marktteilnehmer tragen zur Entwicklung serverloser Plattformen bei:
- Google bietet Entwicklern sein Open-Source-Tool an - . IBM, RedHat, Pivotal und SAP waren an seiner Entwicklung beteiligt;
- IBM arbeitete auf einer serverlosen Plattform , das dann ein Projekt der Apache Foundation wurde;
- Microsoft teilweise den Plattformcode geöffnet .
Auch Entwicklungen in Richtung serverloser Frameworks sind im Gange. и Bereitstellung in vorgefertigten Kubernetes-Clustern, Funktioniert sowohl mit Kubernetes als auch mit Docker Swarm. Das Framework fungiert als eine Art Controller – es bereitet auf Wunsch eine Laufzeitumgebung innerhalb des Clusters vor und startet dort dann eine Funktion.
Frameworks bieten Raum für die Konfiguration des Tools entsprechend Ihren Anforderungen. Daher kann ein Entwickler in Kubeless das Zeitlimit für die Funktionsausführung konfigurieren (der Standardwert beträgt 180 Sekunden). Um das Kaltstartproblem zu lösen, schlägt Fission vor, einige Container ständig laufen zu lassen (obwohl dies Kosten für Ressourcenausfallzeiten mit sich bringt). Und OpenFaaS bietet eine Reihe von Triggern für jeden Geschmack und jede Farbe: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs und andere.
Anleitungen für den Einstieg finden Sie in der offiziellen Dokumentation der Frameworks. Die Zusammenarbeit mit ihnen erfordert etwas mehr Fähigkeiten als bei der Zusammenarbeit mit einem Anbieter – dies ist zumindest die Fähigkeit, einen Kubernetes-Cluster über die CLI zu starten. Beziehen Sie höchstens andere Open-Source-Tools ein (z. B. den Kafka-Warteschlangenmanager).
Unabhängig davon, wie wir mit Serverless arbeiten – über einen Anbieter oder unter Verwendung von Open Source – erhalten wir eine Reihe von Vor- und Nachteilen des Serverless-Ansatzes.
Unter dem Gesichtspunkt der Vor- und Nachteile
Serverless entwickelt die Ideen einer Container-Infrastruktur und eines Microservice-Ansatzes, bei dem Teams mehrsprachig arbeiten können, ohne an eine Plattform gebunden zu sein. Der Aufbau eines Systems wird vereinfacht und Fehler lassen sich leichter beheben. Mit der Microservice-Architektur können Sie dem System viel schneller neue Funktionen hinzufügen als bei einer monolithischen Anwendung.
Serverless verkürzt die Entwicklungszeit noch weiter, Dadurch kann sich der Entwickler ausschließlich auf die Geschäftslogik und Codierung der Anwendung konzentrieren. Dadurch wird die Time-to-Market für Entwicklungen verkürzt.
Als Bonus erhalten wir eine automatische Skalierung für Last, und wir zahlen nur für die eingesetzten Ressourcen und nur zum Zeitpunkt der Nutzung.
Wie jede Technologie hat Serverless Nachteile.
Ein solcher Nachteil kann beispielsweise die Kaltstartzeit sein (im Durchschnitt bis zu 1 Sekunde für Sprachen wie JavaScript, Python, Go, Java, Ruby).
Einerseits hängt die Kaltstartzeit in Wirklichkeit von vielen Variablen ab: der Sprache, in der die Funktion geschrieben ist, der Anzahl der Bibliotheken, der Codemenge, der Kommunikation mit zusätzlichen Ressourcen (den gleichen Datenbanken oder Authentifizierungsservern). Da der Entwickler diese Variablen kontrolliert, kann er die Startzeit verkürzen. Andererseits kann der Entwickler die Startzeit des Containers nicht kontrollieren – alles hängt vom Anbieter ab.
Ein Kaltstart kann zu einem Warmstart werden, wenn eine Funktion einen von einem vorherigen Ereignis gestarteten Container wiederverwendet. Diese Situation wird in drei Fällen auftreten:
- wenn Clients den Dienst häufig nutzen und die Anzahl der Aufrufe der Funktion zunimmt;
- wenn der Anbieter, die Plattform oder das Framework es Ihnen ermöglicht, einige Container ständig laufen zu lassen;
- wenn der Entwickler Funktionen mit einem Timer ausführt (z. B. alle 3 Minuten).
Für viele Anwendungen ist ein Kaltstart kein Problem. Dabei muss man sich an der Art und den Aufgaben des Dienstes orientieren. Eine Startverzögerung von einer Sekunde ist für eine Geschäftsanwendung nicht immer kritisch, kann jedoch für medizinische Dienste kritisch werden. In diesem Fall wird der Serverless-Ansatz voraussichtlich nicht mehr geeignet sein.
Der nächste Nachteil von Serverless ist die kurze Lebensdauer einer Funktion (Zeitüberschreitung, während der die Funktion ausgeführt werden muss).
Wenn Sie jedoch mit langlebigen Aufgaben arbeiten müssen, können Sie eine Hybridarchitektur verwenden – kombinieren Sie Serverless mit einer anderen Technologie.
Nicht alle Systeme können mit dem serverlosen Schema arbeiten.
Einige Anwendungen speichern während der Ausführung weiterhin Daten und Status. Einige Architekturen bleiben monolithisch und einige Funktionen werden langlebig sein. Allerdings ist Serverless (wie Cloud-Technologien und dann Container) eine Technologie mit großer Zukunft.
In diesem Sinne möchte ich reibungslos zum Thema der Verwendung des Serverless-Ansatzes übergehen.
Von der Anwendungsseite
Für 2018 der Prozentsatz der serverlosen Nutzung . Zu den Unternehmen, die die Technologie bereits in ihren Diensten implementiert haben, gehören Marktgiganten wie Twitter, PayPal, Netflix, T-Mobile und Coca-Cola. Gleichzeitig müssen Sie verstehen, dass Serverless kein Allheilmittel ist, sondern ein Werkzeug zur Lösung einer Reihe von Problemen:
- Reduzieren Sie Ressourcenausfallzeiten. Für Dienste mit wenigen Aufrufen ist es nicht erforderlich, ständig eine virtuelle Maschine vorzuhalten.
- Verarbeiten Sie Daten im Handumdrehen. Komprimieren Sie Bilder, schneiden Sie Hintergründe aus, ändern Sie die Videokodierung, arbeiten Sie mit IoT-Sensoren und führen Sie mathematische Operationen durch.
- „Kleben“ Sie andere Dienste zusammen. Git-Repository mit internen Programmen, Chatbot in Slack mit Jira und Kalender.
- Balancieren Sie die Last. Schauen wir hier genauer hin.
Nehmen wir an, es gibt einen Gottesdienst, der 50 Personen anzieht. Darunter befindet sich eine virtuelle Maschine mit schwacher Hardware. Von Zeit zu Zeit nimmt die Belastung des Dienstes deutlich zu. Dann kommt schwache Hardware nicht zurecht.
Sie können einen Balancer in das System integrieren, der die Last beispielsweise auf drei virtuelle Maschinen verteilt. Zu diesem Zeitpunkt können wir die Auslastung nicht genau vorhersagen, daher halten wir eine bestimmte Menge an Ressourcen „in Reserve“. Und wir zahlen zu viel für Ausfallzeiten.
In einer solchen Situation können wir das System durch einen hybriden Ansatz optimieren: Wir lassen eine virtuelle Maschine hinter dem Load Balancer und stellen eine Verbindung zum Serverless Endpoint mit Funktionen her. Wenn die Last den Schwellenwert überschreitet, startet der Balancer Funktionsinstanzen, die einen Teil der Anforderungsverarbeitung übernehmen.
Somit kann Serverless dort eingesetzt werden, wo eine große Anzahl von Anfragen nicht zu oft, aber intensiv bearbeitet werden muss. In diesem Fall ist die Ausführung mehrerer Funktionen für 15 Minuten rentabler als die ständige Wartung einer virtuellen Maschine oder eines Servers.
Bei allen Vorteilen des Serverless Computing sollten Sie vor der Implementierung zunächst die Anwendungslogik bewerten und verstehen, welche Probleme Serverless im Einzelfall lösen kann.
Serverlos und Selectel
Bei Selectel sind wir es bereits über unser Control Panel. Jetzt bauen wir unsere eigene FaaS-Plattform. Wir möchten, dass Entwickler ihre Probleme mit Serverless über eine praktische, flexible Schnittstelle lösen können.
Wenn Sie Ideen dazu haben, wie die ideale FaaS-Plattform aussehen sollte und wie Sie Serverless in Ihren Projekten nutzen möchten, teilen Sie diese in den Kommentaren mit. Bei der Entwicklung der Plattform berücksichtigen wir Ihre Wünsche.
Im Artikel verwendete Materialien:
Source: habr.com