- Die Zukunft von Cloud-Datendiensten liegt in einer „groß angelegten, mandantenfähigen“ Struktur
- Der Grund, warum führende SaaS-Dienste wie S3 Einfachheit, Zuverlässigkeit, Haltbarkeit, Skalierbarkeit und niedrige Preise bieten, ist, dass die Technologien dieser Dienste strukturell genau dafür ausgelegt sind
- Die Bereitstellung von Diensten für Kunden über große Ressourcenpools gewährleistet Effizienz- und Zuverlässigkeitsvorteile durch Skalierung
[Definition serverloser mandantenfähiger Systeme]
Definition von „Multi-Tenancy“
- Multi-Tenancy bezieht sich auf das Teilen von Ressourcen, indem Workloads gemeinsam auf gemeinsamer Hardware platziert werden
- Der Aufbau eines Systems in der Cloud bedeutet, dass mehrere Mandanten Dienste über gemeinsam genutzte Compute-Instanzen (z. B. Amazon EC2 oder Google Compute) oder gemeinsam genutzte PaaS-Services (z. B. Cloud-Objektspeicher) erhalten
- Multi-Tenancy wird definiert als „die Bereitstellung von Diensten für mehrere Mandanten auf gemeinsam genutzten Ressourcen (virtualisierte Server, Laufwerke und PaaS-Baustein-Services usw.)“
- Es können mehrere Modelle der gemeinsamen Ressourcennutzung verwendet werden, und manche Systeme kombinieren über verschiedene Komponenten hinweg mehrere Shared-Resource-Modelle
- Geteilter Prozess: Derselbe Softwareprozess bedient mehrere Mandanten. Daten- und Sicherheitsisolierung erfolgen logisch
- Container: Ausführung eines Single-Tenant-Knotens und Verpackung mehrerer Container pro Host. Dies geschieht typischerweise über Kubernetes, bei dem ein bestimmter K8s-Knoten die Pods zahlreicher Mandanten hostet
- Virtualisierung: Ausführung eines Single-Tenant-Knotens in einer VM (z. B. QEMU) oder microVM (z. B. Firecracker) und Verpackung mehrerer VMs pro Host. Kubernetes kann über Kata Containers auch mit VMs verwendet werden
- Es gibt auch eine V8-Isolationsmethode, bei der Mandanten denselben V8-Prozess in getrennten leichtgewichtigen Kontexten gemeinsam nutzen können, aber in Datensystemen habe ich das bisher noch nicht gesehen
Definition von Serverless
- Kunden wählen keinen Servertyp aus und spezifizieren Hardware nicht explizit
- Diese Systeme beruhen auf einem gewissen Maß an Elastizität und Mobilität, damit sie die Nachfrage aller Workloads bewältigen können, ohne dass Kunden die Hardwaregröße explizit anpassen müssen
- Elastizität: Die Fähigkeit, einen Dienst je nach Bedarf des Workloads hoch- oder herunterzuskalieren
- Mobilität: Die Fähigkeit eines Dienstes, Workloads intern zu verschieben und auszugleichen, um Leistungs- und Zuverlässigkeitsanforderungen zu erfüllen
- Das Serverless-Modell verwendet verbrauchsbasierte Abrechnung, die für Kunden immer wichtiger wird
- Viele Kunden möchten keine großen Vorabzusagen machen und bevorzugen es, einfach nur für die tatsächliche Nutzung zu zahlen
- Verbrauchsbasierte Abrechnung hat viele Ausprägungen, die je nach Workload und zugrunde liegender Systemimplementierung stark variieren
- Zahlung pro (Million) Operationen
- Zahlung für CPU- und Speichernutzung des Workloads
- Zahlung pro GB Speicher
- Zahlung für virtuelle Leistungs-/Kapazitätseinheiten, die mit Ressourcen und Arbeitsrate zusammenhängen (z. B. RCU/WCU bei DynamoDB)
- Hybridmodelle, bei denen Kunden für eine gewisse Basiskapazität zahlen und darüber hinausgehende Nutzung zusätzlich berechnet wird („Grundgebühr plus Bezahlung für Spitzenlast“)
[Gemeinsame Herausforderungen]
Arbeiten innerhalb der vom Workload auferlegten Einschränkungen
- Die vielen Einschränkungen, die durch den Workload eines bestimmten Datensystems auferlegt werden, sind wichtige Treiber der zugrunde liegenden Architektur
- Anforderungen an Latenz/Verfügbarkeit
- Anforderungen an Konsistenz
- Korrelationen/Abhängigkeiten zwischen Anfragen und Daten
- Sequentielle Zugriffsmuster versus zufällige Zugriffsmuster
- Vielfalt der pro Anfrage ausgeführten Arbeit
- Datengröße
- Sitzungs- versus anfrageorientierte Protokolle, Push- versus Pull-Mechanismen
- Rechenintensität der Arbeit
- Lockerere Anforderungen an Latenz und Konsistenz geben Engineers mehr Freiheitsgrade
- Ein gutes Beispiel ist die Nutzung der Vorteile von Cloud-Objektspeicher mit niedrigen Kosten und hoher Haltbarkeit, da in Systemen mit niedriger Latenz Einschränkungen bei der Einführung von Komponenten mit hoher Latenz bestehen
- Eventually-consistent-Systeme können dieses Dilemma vermeiden, indem sie Daten asynchron in den Objektspeicher schreiben, ohne ihn in den synchronen Data-Hot-Path einzubeziehen
- Systeme mit niedriger Latenz und starker Konsistenz haben diese Art Joker nicht
- Wenn Einschränkungen wie geringe Latenz zusammenkommen, kann die räumliche und zeitliche Lokalität des Workloads architektonische Entscheidungen beeinflussen
- Zum Beispiel profitieren Workloads mit sequentiellen Scans davon, zusammenhängende Datenbereiche gemeinsam zu halten, um schnelle und effiziente Scans auf der Festplatte zu ermöglichen
- Die weitere Unterteilung dieser Bereiche in kleinere Teilbereiche hilft beim Hotspot-Management, aber diese beiden Ziele stehen in einem Spannungsverhältnis, sodass ein Gleichgewicht gefunden werden muss
- Zufällige Zugriffsmuster mit kaum Korrelation zwischen einzelnen Anfragen können von einem flachen Adressraum profitieren, der sich gleichmäßig und fein über viele Server verteilen lässt
- Sitzungsorientierte Protokolle, die permanente Verbindungen aufbauen, sind im Allgemeinen schwieriger als anfrageorientierte Protokolle, bei denen jede Anfrage unabhängig von der vorherigen ist
- Permanente Verbindungen können Connection Pooling erfordern, und bei Störungen wie Rolling Nodes und Daten-Balancing kann dies für Clients nach außen hin sichtbar werden
- Es gibt Systeme mit einfachen Storage-APIs wie Objektspeicher oder der Kafka API, und es gibt rechenintensive Systeme wie SQL-Datenbanken
- Das führt zum Thema Vorhersagbarkeit und Variabilität des Arbeitsaufwands, der zur Verarbeitung jeder Anfrage nötig ist
- Ein Extrembeispiel sind Datenstreaming-APIs wie Kafka, bei denen einfach ein fortlaufender Block von Datensätzen abgerufen werden muss; am anderen Ende steht SQL, wo sich der Arbeitsaufwand je nach Query stark unterscheiden kann
Mandantenisolierung
- Gemeinsame Ressourcennutzung erhöht die Hardwareauslastung, kann aber Ressourcenkonflikte verursachen, bei denen der Workload eines Mandanten andere Mandanten beeinflusst
- In mandantenfähigen Systemen muss sichergestellt werden, dass Mandanten, die auf gemeinsam genutzter Hardware bedient werden, so behandelt werden, als würden sie ihren eigenen dedizierten Dienst nutzen
Trennung von Storage und Compute
- Die Trennung von Storage und Compute ist ein zentrales Designprinzip, das alle bisher untersuchten Systeme in gewissem Maß umgesetzt haben
- Aufgrund von Hardware-Trends wird diese Trennung immer praktikabler, auch weil das Netzwerk nicht mehr denselben Flaschenhals wie früher darstellt
- Die Netzwerkbandbreite steigt, doch mit der zentralen Rolle von Cloud-Objektspeicher entstehen weiterhin neue Herausforderungen bei dieser Trennung
- Cloud-Objektspeicher hat nach wie vor relativ hohe Latenz, hohe Haltbarkeit und niedrige Kosten
- Für typischerweise latenzsensitive Workloads wie OLTP-Datenbanken kann seine Einführung jedoch schwierig sein
- Außerdem benachteiligt das ökonomische Modell von Cloud-Objektspeicher Designs, die auf vielen kleinen Objekten beruhen; Daten müssen in größeren Objekten mit weniger Requests gesammelt werden, was das Leben latenzarmer Systeme zusätzlich erschwert
- Engineers können Objektspeicher in Systeme mit niedriger Latenz einbeziehen, indem sie dem langsamen Objektspeicher einen haltbaren, fehlertoleranten Write-Cache sowie einen prädiktiven Read-Cache vorschalten, um die Latenzprobleme des Objektspeichers abzufedern
- Dieser haltbare Write-Cache ist im Grunde ein Servercluster, das ein Replikationsprotokoll implementiert und Daten in Block Storage schreibt
- Im Hintergrund lädt der Cluster Daten asynchron in den Objektspeicher hoch, in einem wirtschaftlichen Muster mit weniger, dafür größeren Dateien
- Ein fehlertoleranter Write-Cache unterstützt Schreibvorgänge mit niedriger Latenz sehr gut
- Problematisch in dieser Architektur kann der Read-Cache sein
- Für sequentielle Workloads wie Event Streaming ist das einfach und sehr effektiv
- Solange Aggregate Prefetching mit der Nachfrage Schritt hält, sollten Lesevorgänge immer den lokalen Read-Cache treffen
- Datenbanken haben es wegen schwer vorhersehbarer Random-Access-Muster schwerer, aber Table Scans profitieren weiterhin von Read-Ahead
- Die Implementierung eines verteilten fehlertoleranten Write-Caches mit einem Replikationsprotokoll ist keineswegs einfach, und in einer Multi-AZ-Umgebung können zusätzliche Kosten wie Cross-AZ-Gebühren anfallen
- Derzeit gibt es jedoch keine Alternative für Systeme mit niedriger Latenz, die günstigen und haltbaren Objektspeicher als primären Datenspeicher nutzen wollen
- Andere Systeme mit niedriger Latenz sollten den Einsatz von Cloud-Objektspeicher ganz vermeiden und vor allem vorhersehbar niedrige Latenzen bevorzugen
- Cloud Storage ist weit verbreitet, aber wegen dieser Latenz-Trade-offs nicht universell einsetzbar
Heat Management
- Heat Management bedeutet, Last möglichst gleichmäßig über mehrere Storage-Knoten zu verteilen, um Hotspots zu vermeiden, die extern sichtbare Leistungsprobleme wie Latenzspitzen oder einen Rückgang der Operationen pro Sekunde verursachen können
- Man könnte dies auch Load Balancing nennen, aber normalerweise wird der Begriff Load Balancer für zustandslose Knoten verwendet
- In zustandsbehafteten Systemen können Hotspots entstehen, wenn stark nachgefragte Objekte auf bestimmten Storage-Knoten gruppiert sind und dadurch Konflikte verursachen
- Ein Load Balancer kann Last mit einfachen Strategien wie Random, Least Connections oder einer FIFO-Variante gleichmäßig auf eine Menge zustandsloser Knoten verteilen, aber zustandsbehaftete Systeme müssen Anfragen abhängig davon an Knoten routen, wo sich die Daten befinden
- Das Verschieben von Daten zur Lastumverteilung wird häufig Rebalancing genannt
- Komplexer wird das Problem dadurch, dass sich die Lastverteilung im Zeitverlauf ändern kann
- Datenverteilung wird zu einem dynamischen Prozess, der alles bewältigen muss: von kurzfristigen Peaks auf kleinen Datenteilmengen bis hin zu größeren Lastverschiebungen durch tägliche Muster oder saisonale Ereignisse über mehrere Mandanten hinweg
- Große Datensätze wie umfangreiche Datenbanken oder Event Streams mit hohem Durchsatz müssen geshardet werden, um Last effektiv zu verteilen
- Rebalancing bedeutet dann Rebalancing von Shards, und das System kann Shards je nach veränderter Lastverteilung auch aufteilen und zusammenführen
- Allerdings gibt es Zielkonflikte, etwa in Bezug auf Datenlokalität sowie Anzahl und Größe der Shards
- Einerseits macht eine stärkere Ko-Lokation von Daten Abrufe effizienter
- Andererseits können die Kosten von Compute-Arbeit, die Daten aus zu vielen Shards holen muss, den Vorteil übersteigen, der durch eine Lastverteilung über mehr Server entsteht
- Heat Management kann auch in Single-Tenant-Systemen notwendig sein und ist daher kein ausschließliches Multi-Tenant-Problem
- In MT-Datensystemen ist Heat Management jedoch noch wichtiger, damit Mandanten keine Schwankungen in der Servicequalität erleben
Hohe Ressourcenauslastung erreichen
- Eine der Hauptmotivationen für die Umsetzung einer serverlosen mandantenfähigen Architektur ist es, durch effizientere Nutzung der zugrunde liegenden Hardware-Ressourcen bessere ökonomische Ergebnisse zu erzielen
- Die Erhöhung der Ressourcenauslastung durch Resource Pooling ist von zentraler Bedeutung, aber dies gleichzeitig mit Mandantenisolierung und vorhersehbarer Performance zu erreichen, ist eine schwierige Aufgabe
Cold Starts
- Serverless-Systeme, die Ressourcen pro Mandant auf null herunterskalieren, können beim Wiederaufnehmen eines Workloads durch einen Mandanten auf das Problem von Cold Starts stoßen
- Cold Starts standen seit Beginn im Fokus von Serverless und können auch einige serverlose Datensysteme betreffen
- In manchen Systemen treten Cold Starts überhaupt nicht auf, während sie in anderen Systemen aufgrund der Architektur und eines Scale-to-Zero-Produktangebots unvermeidbar sein können
- In allen Fällen, die ich gesehen habe, ist das Cold-Start-Problem eine Produktentscheidung, und je nach Tarif- und Preismodell kann der Umfang der Ressourcenreduktion unterschiedlich sein
- Letztlich können Kunden und Anbieter den Trade-off wählen, der ihren jeweiligen Anforderungen entspricht
Untersuchte Systeme
- Group 1 - Storage APIs (compute-light)
- Amazon DynamoDB (chapter 1)
- Kora - Serverless Kafka engine inside Confluent Cloud (chapter 2)
- Backblaze B2 (planned)
- Group 2 - SQL OLTP databases (compute-heavy)
- Neon - serverless PostgreSQL (chapter 3)
- CockroachDB’s serverless multi-tenant architecture. (in progress)
- Planetscale (planned)
- Group 3 - SQL OLAP databases and data warehouses (compute-heavy)
- Google BigQuery (planned)
- ClickHouse Cloud (in progress).
- Diese Arbeit wird weiter fortgesetzt, aber für Januar/Februar 2024 ist eine Art „Fazit“-Posting geplant
Noch keine Kommentare.