Serverlose Racks

Bei Serverless geht es nicht um die physische Abwesenheit von Servern. Dies ist kein „Killer“ für Container und kein vorübergehender Trend. Dies ist ein neuer Ansatz zum Erstellen von Systemen in der Cloud. In dem heutigen Artikel werden wir uns mit der Architektur von Serverless-Anwendungen befassen und herausfinden, welche Rolle der Serverless-Dienstanbieter und Open-Source-Projekte spielen. Am Ende werden wir über Serverless sprechen.

Ich möchte die Serverseite der Anwendung schreiben (ja sogar einen Online-Shop). Dies kann ein Chat, ein Dienst zum Veröffentlichen von Inhalten oder ein Load Balancer sein. In jedem Fall wird es viele Kopfschmerzen geben: Sie müssen die Infrastruktur vorbereiten, die Anwendungsabhängigkeiten ermitteln und über das Host-Betriebssystem nachdenken. Dann müssen Sie kleine Komponenten aktualisieren, die die Arbeit des restlichen Monolithen nicht beeinträchtigen. Vergessen wir nicht die Skalierung unter Last.

Was aber, wenn wir kurzlebige Container verwenden, 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 Mikrodienste aufteilen, von denen jeder unabhängig von den anderen aktualisiert und skaliert werden kann. Nachdem ich den Code in einem solchen Container abgelegt habe, kann ich ihn auf jeder Infrastruktur ausführen. Schon besser.

Und wenn Sie keine Container konfigurieren möchten? Ich möchte nicht über die Skalierung der Anwendung nachdenken. Ich möchte nicht für im Leerlauf laufende Container bezahlen, wenn die Belastung des Dienstes minimal ist. Ich möchte Code schreiben. Konzentrieren Sie sich mit Lichtgeschwindigkeit auf Geschäftslogik und Marktprodukte.

Solche Gedanken führten mich zu Serverless Computing. Serverlos bedeutet in diesem Fall nicht das physische Fehlen von Servern, sondern das Fehlen von Kopfschmerzen bei der Verwaltung der Infrastruktur.

Die Idee ist, dass die Anwendungslogik in unabhängige Funktionen zerfällt. Sie haben eine Ereignisstruktur. Jede der Funktionen führt eine "Mikrotask" aus. Der Entwickler muss lediglich die Funktionen in die vom Cloud-Anbieter bereitgestellte Konsole laden und sie mit den Ereignisquellen korrelieren. Der Code wird auf Anfrage in einem automatisch vorbereiteten Container ausgeführt, und ich bezahle nur die Ausführungszeit.

Mal sehen, wie der Anwendungsentwicklungsprozess jetzt aussehen wird.

Vom Entwickler

Zuvor haben wir über die Anwendung für den 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 zu Serverless zu wechseln, teilen wir die Anwendung in Mikrotasks auf. Unter jedem von ihnen schreiben wir unsere eigene Funktion. Funktionen sind unabhängig voneinander und speichern keine Statusinformationen. Sie können sogar in verschiedenen Sprachen geschrieben werden. Wenn einer von ihnen abstürzt, wird die gesamte Anwendung nicht gestoppt. Die Anwendungsarchitektur sieht folgendermaßen aus:


Die Unterteilung in Funktionen in Serverless ähnelt der Arbeit mit Microservices. Ein Microservice kann jedoch mehrere Aufgaben ausführen, und im Idealfall sollte eine Funktion eine ausführen. Stellen Sie sich vor, die Aufgabe besteht darin, Statistiken zu sammeln und auf Anfrage des Benutzers anzuzeigen. Beim Microservice-Ansatz wird die Aufgabe von einem Service mit zwei Einstiegspunkten ausgeführt: Schreiben und Lesen. Beim Serverless Computing sind dies zwei verschiedene Funktionen, die nicht miteinander verbunden sind. Ein Entwickler spart Rechenressourcen, wenn beispielsweise Statistiken häufiger aktualisiert als heruntergeladen werden.

Serverlose Funktionen müssen in einer kurzen Zeitspanne (Timeout) ausgeführt werden, die vom Dienstanbieter festgelegt wird. Für AWS beträgt das Zeitlimit beispielsweise 15 Minuten. Dies bedeutet, dass langlebige Funktionen (langlebig) geändert werden müssen, um die Anforderungen zu erfüllen - dieser Serverless unterscheidet sich 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:
Ereignisse können HTTP-Anforderungen, Streaming-Daten, Nachrichtenwarteschlangen usw. sein. Ereignisquellen sind die Änderung oder das Erscheinungsbild von Daten. Darüber hinaus können Funktionen per Timer ausgeführt werden.

Die Architektur funktionierte und die Anwendung wurde fast serverlos. Als nächstes gehen wir zum Dienstleister.

Vom Anbieter

Serverless Computing wird normalerweise von Cloud-Dienstanbietern angeboten. Sie nennen es anders: Azure-Funktionen, AWS Lambda, Google Cloud-Funktionen, IBM Cloud-Funktionen.

Wir werden den Dienst über die Konsole oder das persönliche Konto des Anbieters nutzen. Der Funktionscode kann auf eine der folgenden Arten heruntergeladen werden:

• Schreiben Sie Code in integrierten Editoren über die Webkonsole.
• Laden Sie das Archiv mit dem Code herunter,
• Arbeit mit öffentlichen oder privaten Git-Repositories.

Hier konfigurieren wir die Ereignisse, die die Funktion aufrufen. Unterschiedliche Anbieter können unterschiedliche Ereignissätze haben.



Der Anbieter seiner Infrastruktur hat das FaaS-System (Function as a Service) aufgebaut und automatisiert:

1. Der Funktionscode gelangt auf der Anbieterseite in das Repository.
2. Wenn ein Ereignis auftritt, werden Container mit der vorbereiteten Umgebung automatisch auf dem Server bereitgestellt. Jede Funktionsinstanz verfügt über einen eigenen isolierten Container.
3. Aus dem Speicher wird die Funktion an den Container gesendet, berechnet, das Ergebnis zurückgegeben.
4. Die Anzahl der parallelen Ereignisse wächst - die Anzahl der Container wächst. Das System skaliert automatisch. Wenn Benutzer nicht auf die Funktion zugreifen, ist sie inaktiv.
5. Der Anbieter legt die Leerlaufzeit der Container fest. Wenn während dieser Zeit die Funktionen nicht im Container angezeigt werden, werden sie zerstört.

So bekommen wir Serverless aus der Box. Wir zahlen für den Service nach dem Pay-as-you-go-Modell und nur für die Funktionen, die verwendet werden, und nur für den Zeitpunkt, zu dem sie verwendet wurden.

Um Entwicklern den Service näher zu bringen, bieten Anbieter bis zu 12 Monate kostenlose Tests an. Sie begrenzen jedoch die gesamte Rechenzeit, die Anzahl der Anfragen pro Monat, das Geld 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 kann FaaS sowohl in eigenen Entwicklungen als auch mithilfe von Open-Source-Tools implementieren. Wir werden weiter darüber sprechen.

Aus Open Source

In den letzten Jahren hat die Open-Source-Community aktiv an serverlosen Tools gearbeitet. Insbesondere die größten Marktteilnehmer tragen zur Entwicklung serverloser Plattformen bei:

• Google bietet Entwicklern sein Open-Source-Tool Knative an . Die Entwicklung umfasste IBM, RedHat, Pivotal und SAP.
• IBM arbeitete an der OpenWhisk Serverless-Plattform, die dann zum Apache Foundation-Projekt wurde.
• Microsoft hat den Azure Functions- Plattformcode teilweise geöffnet.

Entwicklungen werden auch in Richtung serverloser Frameworks durchgeführt. Kubeless und Fission werden in vorbereiteten Kubernetes-Clustern bereitgestellt. OpenFaaS funktioniert sowohl mit Kubernetes als auch mit Docker Swarm. Das Framework fungiert als eine Art Controller - auf Anfrage bereitet es die Laufzeit innerhalb des Clusters vor und führt dort eine Funktion aus.

Frameworks lassen Raum für die Toolkonfiguration, die Ihren Anforderungen entspricht. In Kubeless kann der Entwickler das Zeitlimit für die Ausführung der Funktion festlegen (der Standardwert ist 180 Sekunden). Die Spaltung bei dem Versuch, das Problem des Kaltstarts zu lösen, bietet die Möglichkeit, einen Teil der Container ständig in Betrieb zu halten (obwohl dies die Kosten für Ausfallzeiten 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.

Anweisungen für den Einstieg finden Sie in der offiziellen Dokumentation der Frameworks. Die Arbeit mit ihnen erfordert etwas mehr Fähigkeiten als die Arbeit mit einem Anbieter - dies ist zumindest die Möglichkeit, einen Kubernetes-Cluster über die CLI zu starten. Fügen Sie maximal andere Open-Source-Tools hinzu (z. B. den Warteschlangenmanager von Kafka).

Unabhängig davon, wie wir mit Serverless arbeiten - über einen Anbieter oder Open Source - erhalten wir eine Reihe von Vor- und Nachteilen des Serverless-Ansatzes.

Aus der Perspektive der Vor- und Nachteile

Serverless entwickelt die Ideen der Containerinfrastruktur und des Microservice-Ansatzes, bei denen Teams im mehrsprachigen Modus arbeiten können, ohne an eine Plattform gebunden zu sein. Das Erstellen eines Systems wird vereinfacht und das Beheben von Fehlern wird einfacher. Mit der Microservice-Architektur können Sie dem System viel schneller neue Funktionen hinzufügen als bei einer monolithischen Anwendung.

Serverless reduziert die Entwicklungszeit noch weiter, da sich der Entwickler ausschließlich auf die Geschäftslogik und -codierung der Anwendung konzentrieren kann. Infolgedessen wird die Markteinführungszeit für die Entwicklung verkürzt.

Als Bonus erhalten wir eine automatische Skalierung der Last und zahlen nur für die verwendeten Ressourcen und nur zu dem Zeitpunkt, zu dem sie verwendet werden.

Serverless hat wie jede Technologie Nachteile.

Ein solcher Nachteil kann beispielsweise eine Kaltstartzeit sein (durchschnittlich bis zu 1 Sekunde für Sprachen wie JavaScript, Python, Go, Java, Ruby).

Einerseits hängt die Zeit eines Kaltstarts von vielen Variablen ab: der Sprache, in der die Funktion geschrieben ist, der Anzahl der Bibliotheken, der Codemenge, der Kommunikation mit zusätzlichen Ressourcen (denselben Datenbanken oder Authentifizierungsservern). Da der Entwickler diese Variablen steuert, kann er die Startzeit verkürzen. Andererseits kann der Entwickler die Startzeit des Containers nicht steuern - alles hängt vom Anbieter ab.

Ein Kaltstart kann sich in einen Warmstart verwandeln, wenn die Funktion den vom vorherigen Ereignis gestarteten Container wiederverwendet. Diese Situation tritt in drei Fällen auf:

• wenn Kunden den Service häufig nutzen und die Anzahl der Aufrufe der Funktion zunimmt;
• wenn der Anbieter, die Plattform oder das Framework es Ihnen ermöglicht, einen Teil der Container ständig laufen zu lassen;
• wenn der Entwickler Timer-Funktionen ausführt (z. B. alle 3 Minuten).

Für viele Anwendungen ist ein Kaltstart kein Problem. Hier müssen Sie auf dem Typ und den Aufgaben des Dienstes aufbauen. Ein verzögerter Start für eine Sekunde ist für eine Geschäftsanwendung nicht immer kritisch, kann jedoch für medizinische Dienstleistungen kritisch werden. In diesem Fall ist der Ansatz ohne Server wahrscheinlich nicht mehr geeignet.

Der nächste Nachteil von Serverless ist die kurze Lebensdauer der Funktion (das Zeitlimit, für das 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 anderer Technologie.

Nicht alle Systeme können nach dem Serverless-Schema arbeiten.

Einige Anwendungen speichern weiterhin Daten und Status zur Laufzeit. Einige Architekturen bleiben monolithisch und einige Funktionen sind langlebig. Serverless ist jedoch (wie früher Cloud-Technologien und dann Container) eine Technologie mit großer Zukunft.

In diesem Sinne möchte ich reibungslos auf das Problem der Anwendung des Ansatzes ohne Server eingehen.

Auf der Anwendungsseite

Im Jahr 2018 stieg der Prozentsatz der serverlosen Nutzung um das Eineinhalbfache . Unter den Unternehmen, die die Technologie bereits in ihren Diensten implementiert haben, befinden sich Marktriesen 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 bestimmten Reihe von Aufgaben:

• Reduzieren Sie Ausfallzeiten. Sie müssen die virtuelle Maschine nicht ständig unter Diensten halten, auf die nicht viel zugegriffen wird.
• "On the fly" verarbeitet die Daten. Komprimieren Sie Bilder, schneiden Sie den Hintergrund aus, ändern Sie die Videokodierung, arbeiten Sie mit IoT-Sensoren und führen Sie mathematische Operationen durch.
  
• Andere Dienstleistungen zusammenkleben. Git-Repository mit internen Programmen, Chat-Bot in Slack mit Jira und mit einem Kalender.
• Last ausgleichen. Hier werden wir näher darauf eingehen.

Nehmen wir an, es gibt einen Service, zu dem 50 Personen kommen. Darunter befindet sich eine virtuelle Maschine mit schwacher Hardware. In regelmäßigen Abständen steigt die Belastung des Dienstes erheblich an. Dann kommt das schwache Eisen nicht zurecht.

Sie können einen Balancer in das System aufnehmen, der die Last beispielsweise auf drei virtuelle Maschinen verteilt. Zu diesem Zeitpunkt können wir die Last nicht genau vorhersagen, sodass wir eine bestimmte Menge an Ressourcen „in Reserve“ halten. Und Überzahlung für Ausfallzeiten.

In dieser Situation können wir das System durch einen hybriden Ansatz optimieren: Für den Load Balancer verlassen wir eine virtuelle Maschine und stellen eine Verknüpfung zu Serverless Endpoint mit Funktionen her. Wenn die Last den Schwellenwert überschreitet, startet der Balancer Instanzen von Funktionen, die einen Teil der Anforderungsverarbeitung übernehmen.


Somit kann Serverless dort eingesetzt werden, wo es nicht zu oft vorkommt, sondern um eine große Anzahl von Anfragen intensiv zu verarbeiten. In diesem Fall ist es rentabler, mehrere Funktionen 15 Minuten lang auszuführen, als ständig eine virtuelle Maschine oder einen virtuellen Server zu halten.

Bei allen Vorteilen von Serverless Computing sollten Sie vor der Implementierung zunächst die Anwendungslogik bewerten und verstehen, welche Aufgaben Serverless in einem bestimmten Fall lösen kann.

Serverless und Selectel

Bei Selectel haben wir die Arbeit mit Kubernetes in einer virtuellen privaten Cloud bereits über unser Control Panel vereinfacht . Jetzt bauen wir unsere eigene FaaS-Plattform. Wir möchten, dass Entwickler ihre Probleme mit Serverless über eine bequeme, flexible Oberfläche lösen können.

Möchten Sie den Entwicklungsprozess der neuen FaaS-Plattform verfolgen? Abonnieren Sie den Selectel-Newsletter „Cloud Functions“ auf der Serviceseite . Wir werden über den Entwicklungsprozess sprechen und die geschlossene Version von Cloud-Funktionen bekannt geben.

Wenn Sie Ideen haben, was eine ideale FaaS-Plattform sein sollte und wie Sie Serverless in Ihren Projekten verwenden möchten, teilen Sie diese in den Kommentaren mit. Wir werden Ihre Wünsche bei der Entwicklung der Plattform berücksichtigen.

Im Artikel verwendete Materialien:

• 1,5-fache serverlose Auslastung (vollständiger RightScale-Bericht)
• Wie die Kaltstartzeit ist, hängt von der Anwendungssprache ab