VAST Data: Cloud-Event-Broker kostet deutlich weniger als Confluent Cloud

Ein Kafka-kompatibler Broker im VAST AI Operating System

VAST on Cloud (VoC) integriert den VAST Event Broker nach Angaben von VAST Data in das VAST AI Operating System. Dieses läuft auf speicheroptimierten virtuellen Maschinen, die als virtuelle EBoxes (Everything Boxes) bereitgestellt werden. Der Broker verwendet das Kafka-Protokoll. Bestehende Client-Bibliotheken, APIs und Tools funktionieren daher laut dem Unternehmen weiterhin.

Anstatt Partitionsprotokolle auf einzelnen Broker-Knoten zu speichern, werden Nachrichtenthemen nativ als Tabellen in VAST DataBase abgelegt. JSON-Nutzdaten werden bereits beim Eintreffen in abfragbare Spalten aufgeteilt. Abfrage-Engines wie Trino, Presto und Apache Spark können diese Thementabellen über native VAST-Konnektoren lesen. Dadurch entfallen laut VAST ETL-Pipelines oder ein separates analytisches Lakehouse.

Shared-Nothing-Kafka versus disaggregiertes Shared-Everything

VAST stellt sein Design dem klassischen Apache Kafka gegenüber, bei dem Broker die Führung von Partitionen koordinieren und den lokalen Log-Status verwalten. Um einen Replikationsfaktor von drei zu erreichen, werden Schreibvorgänge auf Follower-Broker in getrennten Verfügbarkeitszonen repliziert. VAST argumentiert, dass dies Broker-Speicher, CPU und bandbreitenintensiven Ost-West-Netzwerkverkehr verbraucht. Zudem erzeugt das Neuausbalancieren von Partitionen nach einem Knotenausfall oder bei wachsender Aufnahme-Last Datenverkehr zwischen den Brokern, der mit den Schreibvorgängen der Producer und den Lesevorgängen der Clients konkurriert.

Das Unternehmen räumt ein, dass verwaltete Dienste wie Confluent Cloud einige dieser Einschränkungen verringern. Die Kora-Engine von Confluent nutzt laut VAST lokalen NVMe-Speicher für aktive Log-Segmente, repliziert über Availability Zones hinweg und lagert geschlossene Segmente in Objektspeicher wie Amazon S3 aus. VAST weist jedoch darauf hin, dass das partitionenzentrierte Ausführungsmodell von Kafka erhalten bleibt.

Im virtuellen EBox-Modell von VAST teilen sich die CNode-Datendienste und die DNode-Speicherfunktionen eine virtuelle Maschine. Jede EBox führt drei Container aus: einen CNode und zwei DNodes. Jeder CNode kann auf die gemeinsam genutzten Backend-Daten des Clusters zugreifen. Event-Nachrichten werden als Zeilen in der Tabelle des Themas eingefügt, wobei der Kafka-Offset als Zeilen-ID dient. VAST zufolge gewährleistet dies die Reihenfolge innerhalb jeder Partition und bewahrt Schlüssel, Wert, Header und Zeitstempel als Spalten. Kapazität wird durch das Hinzufügen von EBox-VMs erweitert, ohne Partitionsprotokolle zwischen Brokern migrieren zu müssen.

Datenschutz und Kostenvergleich

VAST zufolge führt die Dreifachreplikation auf Kafka-basierten Plattformen zu einem Mehraufwand von 200 % bei der Datenkapazität. VAST on Cloud verwendet stattdessen Erasure Coding über mehrere EBoxes. Dies erfordert laut dem Unternehmen je nach Anzahl der VMs und Resilienztyp zwischen 2,7 % und 20 % Paritäts-Overhead.

Auf AWS und Microsoft Azure fügt Cloud-HA eine persistente Ebene hinzu. Metadaten und Schreibpuffer werden synchron auf anbindbaren Blockspeicher geschrieben, während neue Daten kontinuierlich in den Objektspeicher gestreamt werden. Nach dem vollständigen Ausfall einer Availability Zone werden Block-Volumes an neue VM-Instanzen angehängt. Das dauert laut VAST je nach Clustergröße 3 bis 15 Minuten. Zudem wendet VAST vor dem Schreiben der Daten in den Flash-Speicher eine Ähnlichkeits-basierte Datenreduzierung an.

Die der Analyse zugrunde liegende Last besteht aus einem kontinuierlichen Eingangsdatenstrom von 4.000 MB/s, einem Fanout-Verhältnis von 2,0, einer Aufbewahrungsdauer von fünf Tagen (120 Stunden) und durchschnittlich 1,0 KB großen Events über einen Monat mit 730 Stunden. Das entspricht 10.025,02 TB eingelesenen und 20.050,05 TB ausgehenden Daten pro Monat sowie einem logisch gespeicherten Event-Volumen von 1.647,95 TB.

Unter diesen Bedingungen veranschlagt VAST VAST on Cloud mit 238.387 US-Dollar pro Monat beziehungsweise 23,78 US-Dollar pro eingelesenem Terabyte. Confluent Cloud Enterprise kommt laut dem Unternehmen auf 1.106.530 US-Dollar pro Monat beziehungsweise 110,38 US-Dollar pro eingelesenem Terabyte. Ausschlaggebend seien der Datenausgang über mehrere Verbraucher und Speicherkosten nach der Replikation.

VAST ergänzt, dass ein Enterprise-Cluster auf 32 eCKUs (1.920 MB/s Eingangsdaten) begrenzt ist. Für die Last seien daher mindestens drei Enterprise-Cluster erforderlich. Da die Analyse diese als einen einzigen Pool bepreist, sei der Confluent-Wert laut VAST eine Untergrenze.

Bedeutung für Streaming-Teams

Die Analyse ist ein vom Anbieter erstelltes Modell, und der veröffentlichte Text behandelt ausschließlich die oben beschriebene konfigurierte Last. Teams mit Streaming-Anwendungen mit hohem Durchsatz, mehreren Verbrauchern und einer Aufbewahrung über mehrere Tage sind laut der Darstellung von VAST am stärksten von den Kosten für Datenausgang und replizierten Speicher betroffen. Wer die Aussage bewerten möchte, muss sie gegen das eigene Profil bei Durchsatz, Aufbewahrungsdauer und Fanout testen.