Serverless und Space-Based Architecture

Zwei Antworten auf die Kapazitätsfrage

Jeder Stil in diesem Kapitel ging bisher davon aus, dass jemand Server betreibt und für die Last dimensioniert. Dieser Abschnitt behandelt zwei Stile, die die Kapazitätsfrage gegensätzlich beantworten. Serverless-Architektur überlässt die Server vollständig einem Cloud-Anbieter und zahlt pro Nutzung, was zu Arbeit passt, die klein, ereignisgesteuert und oft untätig ist. Space-Based Architecture hält alles, was eine stark belastete Anfrage braucht, im Arbeitsspeicher, verteilt auf viele identische Einheiten, sodass die Datenbank nicht mehr auf dem Hot Path liegt; das passt zu extremen und plötzlichen Spitzen wie einem Ticket-Vorverkaufsstart. Beide sind Spezialwerkzeuge; beide werden oft aus den falschen Gründen gewählt.

Serverless: Funktionen und verwaltete Backends

Serverless bedeutet nicht, dass es keine Server gibt; es bedeutet, dass das Team keine Server bereitstellt, patcht, dimensioniert oder für ungenutzte Server zahlt. Mike Roberts’ viel zitierter Artikel von 2018 unterscheidet zwei Zutaten. Function as a Service (FaaS) führt kleine Stücke des eigenen Codes des Teams als Reaktion auf Ereignisse aus, in Containern, die der Anbieter erzeugt, skaliert und wieder abbaut und die womöglich nur für einen einzigen Aufruf existieren. AWS Lambda, im November 2014 angekündigt und seit April 2015 allgemein verfügbar, machte das Modell zum Mainstream; Azure Functions, Google Cloud Run functions und Cloudflare Workers sind weitere Beispiele. Backend as a Service (BaaS) ersetzt serverseitige Komponenten durch vollständig verwaltete Dienste Dritter, die der Client oder die Funktion direkt aufruft: Authentifizierung (Auth0, Amazon Cognito), Datenbanken (Firebase, DynamoDB), Objektspeicher, E-Mail und Queues.

Eine Serverless-Anwendung ist meist eine Kombination: Funktionen enthalten die Geschäftslogik, die für die Organisation spezifisch ist, und alles andere, einschließlich des gesamten dauerhaften Zustands, liegt in verwalteten Diensten. Der Anbieter kümmert sich um Kapazität, Verfügbarkeit über Zonen hinweg und das Betriebssystem. Das Team bleibt verantwortlich für seinen Code, seine Daten, seine Konfiguration und seine Sicherheitseinstellungen, wie das Modell der geteilten Verantwortung in Server und die Cloud erklärt.

Wie Funktionen sich verhalten: die Eigenschaften, die den Entwurf prägen

Ereignisauslöser. Funktionen laufen als Reaktion auf Ereignisse: eine HTTP-Anfrage über ein Gateway, eine Nachricht in einer Queue oder einem Stream, eine Datei, die im Objektspeicher landet, eine Datenbankänderung oder einen Zeitplan. Auslöser, die die Funktion asynchron aufrufen, etwa Queues und Speicherbenachrichtigungen, stellen typischerweise mindestens einmal zu und wiederholen bei Fehlern; Handler müssen daher idempotent sein, genau wie in ereignisgesteuerte Architektur.

Auf null und in die Breite skalieren. Ohne Verkehr läuft keine Instanz, und für Rechenleistung wird nichts berechnet. Wenn Ereignisse eintreffen, startet die Plattform parallel weitere Instanzen, bis zu einem Konto- oder Funktionslimit für Nebenläufigkeit; bei AWS Lambda liegt das regionale Standardlimit zum Zeitpunkt der Erstellung bei 1000 gleichzeitigen Ausführungen und lässt sich auf Antrag anheben. Schnelles Hochskalieren ist Feature und Gefahr zugleich: Tausend gleichzeitige Funktionen können tausend Datenbankverbindungen öffnen und eine relationale Datenbank überfordern, die für einige hundert ausgelegt ist; deshalb gibt es Verbindungsproxys und Nebenläufigkeitsgrenzen pro Funktion.

Abrechnung pro Aufruf. Die Kosten bestehen meist aus einer kleinen Gebühr pro Anfrage plus einer Gebühr für Arbeitsspeicher multipliziert mit der Ausführungszeit (Gigabyte-Sekunden). Code, der untätig auf eine langsame nachgelagerte API wartet, zahlt also fürs Warten.

Kaltstarts. Die erste Anfrage an eine neue Instanz muss warten, während die Plattform einen Container startet, die Laufzeitumgebung lädt und den Initialisierungscode ausführt: von einigen zehn Millisekunden bis zu mehreren Sekunden, je nach Sprache, Paketgröße und Netzwerkkonfiguration. Instanzen werden für spätere Anfragen wiederverwendet, solange sie warm sind; Kaltstarts treffen daher seltenen Verkehr und plötzliche Lastspitzen am härtesten. Gegenmittel sind kleinere Deployment-Pakete, leichtere Laufzeitumgebungen, Initialisierung außerhalb des Handlers und das Bezahlen dafür, Instanzen vorinitialisiert zu halten (AWS nennt das Provisioned Concurrency), was teilweise wieder Kosten für Dauerbetrieb einführt.

Grenzen. Funktionen laufen unter harten Grenzen für Ausführungszeit, Arbeitsspeicher, Payload-Größe und temporären Speicherplatz; für AWS Lambda zum Zeitpunkt der Erstellung 15 Minuten, 128 MB bis 10.240 MB Arbeitsspeicher (mit proportional zugeteilter CPU) und 6 MB für eine synchrone Anfrage oder Antwort. Lange Jobs müssen in Schritte zerlegt und große Payloads per Referenz auf den Objektspeicher übergeben werden.

Zustandslosigkeit. Nichts im Arbeitsspeicher oder auf der lokalen Festplatte einer Instanz überlebt garantiert bis zum nächsten Aufruf. Caching im Arbeitsspeicher zwischen Aufrufen ist eine Optimierung, die trifft oder auch nicht, nie ein Ort für Daten, auf die es ankommt.

Wohin der Zustand kommt

Weil Funktionen nichts behalten, verlagert sich die Architekturarbeit auf die Wahl, wo jede Art von Zustand liegt. Dauerhafte Geschäftsdaten kommen in eine verwaltete Datenbank, oft eine, die viele kurzlebige Verbindungen gut verkraftet (Key-Value- oder Dokumentspeicher oder eine relationale Datenbank hinter einem Verbindungsproxy). Große Objekte kommen in den Objektspeicher und werden zwischen Funktionen per Schlüssel übergeben. Kurzlebiger gemeinsamer Zustand, etwa Zähler für Rate Limiting, kommt in einen verwalteten Cache. Der Fortschritt eines mehrstufigen Prozesses kommt in einen Workflow-Dienst (AWS Step Functions, Azure Durable Functions oder Ähnliches), der als dauerhafter Saga-Orchestrator fungiert, wie in Sagas beschrieben. Benutzersitzungen kommen in Tokens, die der Client hält, oder in einen Session Store.

Die Folge: Ein Serverless-System ist von seiner Bauart her ein verteiltes System, mit allen Anliegen dieses Kapitels: Netzwerklatenz zwischen jeder Funktion und ihren Daten, Teilausfälle, doppelte Ereignisse, Eventual Consistency und der Bedarf an verteiltem Tracing. Eine einzige Geschäftsaktion kann ein Gateway, drei Funktionen, eine Queue und zwei Datenbanken durchlaufen. Observability (siehe Observability) ist nicht optional.

Anbieterkopplung: der Preis dafür, keine Server zu betreiben

Serverless koppelt ein System enger an seinen Anbieter als das Mieten virtueller Maschinen oder der Betrieb von Containern. Ereignisformate, Auslöserkonfiguration, Identitäts- und Berechtigungsmodelle, Workflow-Definitionen und die verwalteten Dienste selbst sind allesamt anbieterspezifisch. Eine ausgereifte Serverless-Anwendung in eine andere Cloud zu bringen, ähnelt eher einer Neuentwicklung als einer Migration.

Fachleute sind uneins, wie sehr das zählt. Die eine Sicht lautet, Lock-in sei der Preis für eine große Entlastung im Betrieb, und die meisten Organisationen wechselten nie die Cloud, sodass die Optimierung auf Portabilität Aufwand verschwende. Die andere hält dagegen, dass Preisänderungen, regulatorische Anforderungen oder Übernahmen sehr wohl einen Wechsel erzwingen und dass tiefe Kopplung Verhandlungsmacht nimmt. Ein Mittelweg besteht darin, Kopplung an den Rändern zu akzeptieren und im Kern einzudämmen: Halten Sie die Geschäftslogik in einfachen Modulen hinter Ports, mit schlanken Funktions-Handlern als Adapter (der Ansatz der hexagonalen Architektur), pflegen Sie Infrastructure as Code, und halten Sie die Kopplung als explizite Entscheidung fest. Kosten und Lock-in werden in FinOps und Lock-in weiter erörtert.

Wann Serverless passt und wann nicht

Serverless passt zu sprunghaften, unvorhersehbaren oder geringvolumigen Workloads, bei denen das Bezahlen ungenutzter Server Verschwendung ist; zu ereignisgesteuertem Glue-Code, etwa der Reaktion auf Uploads, Queue-Nachrichten und Datenbankänderungen; zu geplanten Jobs und Backoffice-Automatisierung; zu Prototypen und neuen Produkten, bei denen das Team seine Zeit in das Produkt statt in die Infrastruktur stecken sollte; und zu Teams ohne Plattform- oder Betriebskapazität.

Schlecht passt es zu gleichmäßigem, hochvolumigem Verkehr, bei dem die Preise pro Anfrage die dauerhaft laufende Kapazität übertreffen (wie im ausgearbeiteten Beispiel); zu lang laufenden oder zustandsbehafteten Prozessen, etwa Videotranscoding über das Zeitlimit hinaus oder WebSocket-Servern mit vielen Verbindungen; zu strengen Anforderungen an niedrige Tail-Latenz, die Kaltstarts verletzen würden; zu Workloads, die Spezialhardware oder feine Kontrolle über die Laufzeitumgebung brauchen; und zu feingranularen Entwürfen, in denen viele Funktionen einander synchron aufrufen, was bei jedem Schritt Netzwerk-Hops, Kosten und Fehlerquellen hinzufügt. Kapitel 1 beschrieb, wie Amazon Prime Video 2023 einen Monitoring-Service von verteilten Serverless-Schritten auf einen einzigen Prozess umstellte und eine Senkung der Infrastrukturkosten um über 90 % meldete (Warum Architektur zählt): kein Urteil über Serverless, aber eine Erinnerung daran, dass Passung mehr zählt als Mode.

Space-Based Architecture: die Datenbank vom Hot Path nehmen

Die meisten Architekturen skalieren Web- und Anwendungsschicht problemlos, stoßen aber irgendwann an die Datenbank, die jede Anfrage berührt. Mehr Server davor verlagern die Warteschlange nur zur Datenbank. Space-Based Architecture, wie Mark Richards und Neal Ford sie in Fundamentals of Software Architecture beschreiben, nimmt die Datenbank ganz aus dem synchronen Pfad. Jede Anfrage wird vollständig im Arbeitsspeicher von einer von vielen identischen Processing Units bearbeitet, und die Datenbank wird asynchron im Hintergrund aktualisiert.

Der Name stammt vom Tuple Space, einem gemeinsamen assoziativen Speicher, den David Gelernters Koordinationssprache Linda 1985 einführte: Prozesse kommunizieren, indem sie Tupel in einen gemeinsamen Raum schreiben und passende Tupel lesen oder herausnehmen, ohne voneinander zu wissen. Suns JavaSpaces brachte die Idee Ende der 1990er-Jahre zu Java, und kommerzielle Plattformen bauten darauf verteilte, replizierte Spaces auf, aus denen sich die heutigen In-Memory Data Grids wie Hazelcast, Apache Ignite und Oracle Coherence entwickelten.

Datenkollisionen und andere Kosten

Replizierte Kopien in vielen Einheiten bringen die Konsistenzprobleme aus den vorigen Abschnitten in den Arbeitsspeicher. Bei einem replizierten Cache hat jede Einheit eine vollständige Kopie, und Änderungen werden asynchron kopiert; das ergibt schnelle lokale Lesezugriffe, aber zwei Einheiten können dasselbe Element aktualisieren, bevor die Replikation nachgezogen hat. Richards und Ford nennen das eine Datenkollision und schätzen ihre Rate als Zahl der Einheiten mal Quadrat der Update-Rate, geteilt durch die Zahl der Elemente, mal Replikationslatenz. Bei 5 Einheiten, 20 Updates pro Sekunde, 50.000 Elementen und 100 ms Latenz sind das 5 × 400 ÷ 50.000 × 0,1 = 0,004 pro Sekunde, etwa 115 Kollisionen an einem Achtstundentag; eine Senkung der Latenz auf 1 ms bringt das auf etwa eine.

Für Daten, die niemals kollidieren dürfen, etwa den letzten Platz in einer Reihe, gibt es zwei Alternativen: einen verteilten Cache, in dem jedes Element in einer Partition liegt und jede Einheit es dort liest und schreibt (konsistent, aber jeder Zugriff ist ein Netzwerkaufruf, und die Partitionen des Grids müssen verfügbar bleiben), oder das Routing aller Anfragen für eine Veranstaltung oder einen Block an dieselbe Einheit, sodass nur eine einzige Einheit diese Plätze je ändert. Die meisten realen Entwürfe kombinieren beides: Sie partitionieren die heißen, umkämpften Daten nach Schlüssel und replizieren überwiegend gelesene Daten wie Saalpläne und Preise.

Die übrigen Kosten sind erheblich. Daten im Arbeitsspeicher sind durch dessen Größe begrenzt und müssen nach einem vollständigen Neustart wieder aufgebaut werden. Die Datenbank ist mit dem Grid nur letztendlich konsistent, sodass Reporting und andere Systeme Änderungen verspätet sehen, und der Verlust eingereihter Änderungen ist ein reales Risiko, das die Dauerhaftigkeit der Pumps abdecken muss. Tests unter realistischer Spitzenlast sind teuer und schwierig. Und der Stil ist komplex und kostspielig im Aufbau: Richards und Ford bewerten ihn niedrig bei Einfachheit und Testbarkeit und hoch bei den Kosten. Er lohnt sich nur, wenn sich die Last wirklich nicht mit Caching, Lesereplikaten und einer gut abgestimmten Datenbank bedienen lässt.