Ankündigung der Einführung von S2

 (s2.dev)
1 Punkte von GN⁺ 2024-12-22 | 1 Kommentare | Auf WhatsApp teilen
  • S2 ist eine Preview eines serverlosen Stream Store, der dauerhafte Echtzeit-Streams so einfach wie Object Storage handhabbar machen soll, und will Logs und Streams zu einem Grundbaustein von Cloud Storage machen
  • Datensätze werden an das Tail eines Streams angehängt, und selbst wenn mehrere Writer gleichzeitig schreiben, übernimmt S2 die dauerhafte Reihenfolge und unterstützt sowohl das Lesen historischer Daten als auch Echtzeit-Tailing
  • Das Basin von S2 fungiert wie ein Bucket als Namespace für Streams und ermöglicht Modellierungen wie Streams pro Benutzer – ohne Begrenzung der Anzahl von Streams oder der Aufbewahrungsdauer
  • Die Storage-Klassen starten mit Standard und Express und trennen die Wahl zwischen Latenz und Kosten mit Zielwerten von jeweils unter 500 ms und unter 50 ms p99-Latenz
  • Derzeit werden eine gRPC-API, ein Rust-SDK und eine CLI bereitgestellt; REST-API, Kafka-Protokoll-Kompatibilität, Multi-Region-Basins und Latenzen unter 5 ms sind die nächsten Schritte

Das von S2 vorgeschlagene Modell für Stream Storage

  • S2 zielt auf einen serverlosen Stream Store für Streaming-Daten im Cloud-Zeitalter
  • Die Kernidee ist, dass auch Logs oder Streams wie Objekte zu einem Grundelement von Cloud Storage werden können
  • Object Storage konzentriert sich bei benannten Objekten auf PUT / GET / DELETE sowie auf Blobs und Byte-Ranges und eignet sich für ruhende Daten
  • Der Stream Storage von S2 bietet für benannte Streams APPEND / READ / TRIM und verwendet Datensätze und Sequenznummern als Grundeinheit
  • Schreibvorgänge werden an das Tail eines Streams angehängt; auch wenn mehrere Writer gleichzeitig schreiben, ordnet S2 alle Datensätze und garantiert Dauerhaftigkeit
  • Das Lesen kann bei seconds ago bis years beginnen, und auch Echtzeit-Tailing, das mit S3-Blobs schwierig ist, ist möglich
  • Ein Basin fungiert für Streams als Namespace, so wie ein Bucket für Objekte als Namespace dient
    • Basin und Stream können ohne Begrenzung ihrer Anzahl verwendet werden
    • Auch für die Datenaufbewahrungsdauer gibt es keine Begrenzung
    • Auch eine Modellierung mit Streams pro Benutzer ist möglich, ohne sich wie bei Kafka mit Cluster-Grenzen oder Infrastruktur-Tuning befassen zu müssen
  • Unterstützt werden auch die Prüfung des Stream-Tails mit starker Konsistenz sowie Concurrency Control beim Schreiben
    • Ein pessimistischer Ansatz mit Fencing Token ist möglich
    • Ein optimistischer Ansatz mit erwarteter Sequenznummer ist möglich
    • Dieses Design zielt auf Durable Offloading und die Trennung von Compute und Storage, wie sie von Datenbanken wie MemoryDB und Neon genutzt werden

Performance, Preise, aktuell verfügbare Funktionen und Roadmap

  • S2 bietet auf Basis der Skalierbarkeit und Dauerhaftigkeit von Object Storage eine serverlose API in Form eines Multi-Tenant-Service
  • An der Dauerhaftigkeit wird nicht gerüttelt; die Wahl zwischen Latenz und Kosten wird pro Stream über die Storage-Klasse gesteuert
    • Standard: basiert auf AWS S3 Standard; da es bei allen Public-Cloud-Anbietern entsprechende Produkte gibt, geht man davon aus, es mit dem Wachstum in allen Cloud-Regionen anbieten zu können
    • Express: basiert auf einem Quorum aus drei AWS S3 Express One Zone Buckets; für Azure gibt es ein regionales Pendant, und auch bei GCP wird Potenzial gesehen
  • Die Performance-Ziele und anfänglichen Einschränkungen sind wie folgt
    • Standard bietet eine End-to-End-p99-Latenz von unter 500 ms
    • Bei Express sind Latenzen von unter 50 ms zu erwarten
    • Alle Writes werden vor dem Acknowledgement mit regionaler Dauerhaftigkeit sicher in S3 gespeichert
    • Der Durchsatz unterstützt mehrere hundert MB pro Sekunde pro Stream
    • Das Lesen kürzlich geschriebener Daten verursacht dank In-Memory-Caching nur geringen Overhead
    • Verzögerte Reader werden direkt aus Object Storage bedient und unterliegen keinem Cap
    • Anfangs sind Writes auf 125 MiBps pro Stream und Reads aktueller Writes auf 500 MiBps pro Stream begrenzt
  • Während der Preview ist S2 kostenlos verfügbar; mit der Veröffentlichung des intended pricing wird ein Preisniveau angestrebt, das deutlich unter dem üblichen Niveau von Cloud-Streaming-Systemen liegt
  • Es gibt keine Fixkosten wie Instanzen oder Cluster-Einheiten
  • Aktuell verfügbare Entwickler-Interfaces sind
  • Das System läuft auf bewährter Cloud-Infrastruktur, und die Rust-Codebasis wird mit deterministic simulation testing geprüft
    • Da das System noch jung ist, kann es noch Probleme geben
    • Es wird derzeit in Richtung General Availability und eines in der Produktion verlässlich nutzbaren SLA weiter gereift
  • Die nächste Roadmap lässt sich in drei Achsen zusammenfassen
    • Kafka protocol compatibility: soll als Open-Source-Schicht bereitgestellt werden; einige Funktionen wie Key-based Compaction sollen direkt in S2 integriert werden
    • Multi-region basins: nach der Ausweitung auf mehr Cloud-Regionen wird auch die Möglichkeit von Basins über Regionen und Clouds hinweg gesehen
    • Under 5 millisecond latencies: durch die strukturelle Flexibilität der Storage-Klasse wird gegenüber Express eine weitere Verbesserung um den Faktor 10 für möglich gehalten
  • Wenn vor allem die „low-level“-APIs von Kafka oder Kinesis genutzt werden, zielt S2 direkt auf Anforderungen wie keine Begrenzung der Stream-Anzahl, 10- bis 100-fach höheren geordneten Durchsatz und Concurrency Control ab

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-22
Meinungen auf Hacker News

  • Ich bin kein Jurist, aber ein Produkt S2 zu nennen und in der Einführung zu sagen, es sei eine Technologie, die AWS S3 verbessert, scheint ziemlich wahrscheinlich Marken-/Urheberrechtsansprüche von Amazon nach sich zu ziehen.
    Da es im selben Bereich liegt, kann es offensichtlich auch zu Verwechslungen bei Verbrauchern kommen. Ob die Marke eingetragen ist, wurde sicher geprüft, aber: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • Lustiger Fakt: Auf Spanisch klingen S2 und EC2 beide gleich, nämlich wie „ese dos“.
      EC2 und S3 sind schon schwer per Gehör auseinanderzuhalten, und nun kommt noch eines dazu.
    • Fairerweise müsste man es wohl S4 nennen, wenn das Ziel ist, S3 zu verbessern.
    • Zumindest Cloudflares R2 hat eine Begründung für den Namen.
      IBM versus HAL, also eine Namensgebung im Stil von „2001: A Space Odyssey“.
    • Ich weiß nicht, ob sie mit einem schlechten Markenanwalt gesprochen haben oder gar nicht, aber so teuer wäre das nicht gewesen.
      Ich habe kürzlich den Prozess einer Markenanmeldung gestartet, und es lag in etwa bei den Kosten, auf einer Domain-Registrar-Website eine Domain wie s4.dev zu kaufen. Nach dem Launch ein Rebranding zu machen, ist viel schmerzhafter, als den Namen vor dem Launch zu ändern.
    • Amazon könnte auch einfach dasselbe bauen, es S3 Streams nennen und S2 ignorieren.
      Vielleicht machen sie sogar ein Übernahmeangebot; dass es bis zu einer Klage kommt, erscheint sehr unwahrscheinlich.

  • Die Idee ist wirklich gut, die API ist elegant, und ich würde sie gern in meinem Projekt einsetzen, aber ich habe überhaupt kein Vertrauen, dass dieses Startup in seiner aktuellen Form lange durchhält.
    Wenn es erfolgreich ist, wird AWS eine bessere und günstigere interne Version bauen; umgekehrt ist die Wahrscheinlichkeit groß, dass es am Markt keine Traction bekommt. Viel sinnvoller wäre es gewesen, als Endnutzerprodukt mit Dashboard à la Papertrail herauszukommen, statt als eng an AWS gebundene „Cloud-Baustein“-API. Wenn man dazu noch eigene S3-kompatible Backends wie DigitalOcean Spaces einbinden könnte, wäre das ein großartiges und langlebiges, cloudneutrales Produkt.

    • Aus Sicht des Gründers planen sie Multi-Cloud und starten derzeit einfach mit AWS.
      Die interne Architektur ist nicht an AWS gebunden, sondern als Interface-Struktur ausgelegt, die sich für andere Cloud-Systeme implementieren lässt.
    • Es wäre ziemlich ironisch, wenn das Ganze bereits auf AWS läuft.
      Es gibt unzählige Startups, die bestehende Open-Source-Software als Service verpacken und als günstiger als AWS-Produkte vermarkten, während sie selbst auf AWS laufen.
    • Gegen Aptible(https://aptible.com) wurde derselbe Einwand immer wieder vorgebracht, aber auch nach über zehn Jahren ist es weiterhin eine sehr erfolgreiche PaaS.
    • Wenn man Cloud-Infrastruktur macht, wird AWS zwar versuchen, preislich zu unterbieten, aber bei der Developer Experience/User Experience werden sie nie besser sein.
      Deshalb sollte man sich meiner Meinung nach nicht von Beezus aufhalten lassen.
    • AWS hat bereits etwas Ähnliches gemacht: https://news.ycombinator.com/item?id=42211280
      „Amazon S3 now supports the ability to append data to an object“ wurde vor 30 Tagen angekündigt, und Azure hatte mit Append Blobs schon lange dieselbe Funktion. Es ist noch deutlich roher als S2 und hat kein Record-Konzept, aber der Schritt, dass Cloud-Anbieter das nativ anbieten, ist sehr klein. Wenn man noch ein Record-Konzept hinzufügt, ist man im Grunde nahe an einer Message Queue, und dieser Wettbewerbsraum ist ebenso groß; Ähnliches gilt für Lösungen zur Log-Speicherung.

  • Ich möchte es verstehen: Wenn es auf AWS aufgebaut ist und AWS für Internet-Egress 0,09 $ pro GB verlangt, heißt das, dass sie hier Internet-Egress mit 0,05 $ pro GB abrechnen?
    Das klingt so, als würden sie die AWS-Egress-Kosten subventionieren. Oder können sie nicht veröffentlichte Egress-Tarife nutzen?

    • Aus Sicht des Gründers wird während der Preview nicht abgerechnet.
      Wenn sie eine relevante Größenordnung erreichen, wollen sie das lösen, und dahinter stecken offensichtlich einige Annahmen.
    • Selbst nach Listenpreis sind es ab 150 TB 0,05 $ pro GB, und bei großen Volumina noch weniger.
    • Sie scheinen darauf zu setzen, dass die meisten Nutzer innerhalb von AWS sind und daher nur 1–2 Cent Transferkosten anfallen.
    • Wer genügend Skalierung hat, zahlt für Datentransfer keine Retail-Preise.
    • Es sieht so aus, als hätten sie es jetzt auf 0,08 $ pro GB geändert.
      Damit verlieren sie bei 50 TB höchstens 300 $ pro Monat, und danach verdienen sie Geld.

  • Ist das im Grunde WarpStream, nur ohne direkt auf Kafka-Kompatibilität zu gehen und stattdessen mit einer niedrigeren API-Ebene?
    Wenn sich das langfristig durchsetzt, wirkt eine Basis-API auf S3-Niveau für Streaming wirklich wertvoll.

    • Aus Sicht des Gründers ist das eine einigermaßen passende Zusammenfassung.
      Allerdings unterscheidet sich der architektonische Ansatz von WarpStream, weshalb sie deutlich geringere Latenzen bieten können. Im System gibt es auch keine Disks.

  • Diese Leute haben sich bewusst dafür entschieden, für den Rest ihrer Karriere zu erklären: „Eigentlich sind wir nicht S3.“

    • Aus Sicht des Gründers könnte man sagen, dass 50 % des Namens anders sind.
    • Wie viele solcher Buchstabe-plus-Zahl-Speicherdienste gibt es inzwischen? S3, B2, R2, S2 ...
    • Oder auch das hier: https://github.com/google/s2geometry
    • Immerhin besser, als erklären zu müssen, dass man keine paramilitärische Organisation ist, die unbeschreibliche Kriegsverbrechen begangen hat.
      Das ist kein Witz.
    • Müssen sie das nicht vielleicht auch vor Gericht oder gegenüber Anwälten so erklären? Ich bin kein Jurist, aber das wirkt wie eine Einladung an Amazon zu behaupten, sie hätten die Marke „S3“ absichtlich ausgenutzt und Verwirrung erzeugt, um ihre eigene Marke aufzubauen.
      Persönlich halte ich diese Argumentation für zutreffend, und im Text wirkt sie auch ziemlich transparent.

  • Sieht gut aus, aber gibt es kein Java SDK?
    Die Unternehmen, in denen ich persönlich gearbeitet habe, waren in 90 % der Fälle bei Kafka-Produktion/-Konsum stark von Spring oder dem Standard-Client abhängig. Damit wird selbst ein leichtgewichtiges Proof of Concept praktisch blockiert.

    • Aus Sicht des S2-Teams stehen künftig ein Java/Kotlin SDK und ein Python SDK auf der Liste.
      Aktuell gibt es ein Rust SDK und eine CLI (https://s2.dev/docs/quickstart). Da der Kerndienst ebenfalls in Rust geschrieben ist, fühlte sich Rust wie ein guter Ausgangspunkt an.

  • Das gefällt mir. Als Nächstes würde ich mir wünschen, dass jemand darauf aufbauend Stream-„Events“ als zu einem bestimmten Zeitpunkt abfragbare Repräsentation anwendet.
    Im Grunde ist das die andere Hälfte, um etwas Datomic-Ähnliches zu bauen. Statt einer konkreten Datenbank wäre wohl ein Pattern oder Framework besser, um konkret abfragbare In-Memory-Daten zu erstellen. Es sind viele Ansätze denkbar: auf lokales Sqlite anwenden, auf Basis des MySQL-binlog auf eine lokale abfragbare Instanz anwenden und zu einem bestimmten Zeitpunkt zurückspulen, oder anwendungsspezifische Apply-/Undo-Events auf lokalen Zustand anwenden.

  • Vor etwa 10 Jahren habe ich Gazette gestartet [0].
    Gazette liegt architektonisch zwischen Kafka und WarpStream/S2. Es bietet unendliche byteorientierte Log-Streams mit S3 als Backend, aber die Broker verwenden lokale Scratch-Disks für initiale Replikation/Dauerhaftigkeitsgarantien und zur Reduzierung der Append-/Read-Latenz. Dadurch liegt p99 nicht über 500 ms, sondern unter 5 ms, und es garantiert, dass alle Dateien in S3 landen, zusammen mit Komfortfunktionen wie konfigurierbaren Zielgrößen, Komprimierung und Latenzgrenzen. Clients, die historische Daten lesen, holen Inhalte direkt aus S3 und wechseln danach zum Live-Tailing sehr aktueller Appends.
    Gazette begann als internes Tool eines früheren Startups. Als wir das heutige Unternehmen gründeten, haben wir ganz kurz erwogen, es als Raw Service anzubieten [1], sind dann aber zu einer umfassenden Plattform für Datenbewegung [2] übergegangen, die Gazette als internes Implementierungsdetail nutzt. Das Market Positioning eines solchen Dienstes ist extrem eng. Entweder man macht ihn API-kompatibel mit dem, was die Zielkunden bereits verwenden, und senkt die Versuchskosten auf 0 (WarpStream hat das gut gemacht), oder man bewegt sich im Application Stack weiter nach oben und löst direkter das Problem, das Kunden tatsächlich lösen wollen.
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • Aus Sicht des S2-Gründers: Glückwunsch zum Erfolg von Estuary.
      Du bist nicht der Erste, der sagt, dass dieser Markt nicht existiert oder sehr klein ist. Aber als du auf HN Validierung gesucht hast, hast du wohl auch gedacht, dass da etwas dran ist. Auf S2 könnten wir deutlich mehr anbieten, etwa Kafka-Kompatibilität, aber der zentrale Grundbaustein ist wichtig. Ich wollte ihn persönlich auch haben und habe gesehen, wie er in allen möglichen Kontexten neu gebaut und in Form von Systemen, die ihren ursprünglichen Charakter verloren hatten, ineffizient wiederverwendet wurde. Allein diese Überzeugung reichte, um Gründer zu werden. Ich verstehe den Hintergrund des Ratschlags, kenne die kommenden Schwierigkeiten und danke für den Rat.

  • Ein sehr nützliches Servicemodell, aber wenn alle Writes vor der Bestätigung in S3 persistiert werden, ist das Wertversprechen etwas verwirrend.
    Die Autoren könnten Record-Bündel batchen, bevor sie sie als größere Blobs schreiben, und ein Hintergrundprozess könnte Compaction durchführen, aber ist das nicht immer noch ein Streaming-Dienst auf Basis von Object Storage? AWS hat, etwa beim Schritt von RDS zu Aurora, grundsätzlich gezeigt, dass es bereit ist, protokollkompatible Dienste zu implementieren, und es scheint, als könnten sie dasselbe für eine Kafka-Neuimplementierung tun.

    • Aus Sicht des S2-Teams ist das im Wesentlichen genau der Ansatz.
      Wenn man die Chunks, die vor der Bestätigung von Writes in Object Storage geschrieben werden, multitenant auslegt und Records aus verschiedenen Streams gemeinsam darin unterbringt, kann man häufig schreiben und dennoch für S3 Standard und Express PUT jeweils eine hinsichtlich Preis/Performance ideale Blob-Größe anpeilen.

  • Die Technologie sieht wirklich beeindruckend aus. Schade nur, dass sie nicht source-available ist.
    Vielleicht ist das eine Minderheitsmeinung, aber wenn die Kerntechnologie unter einer Lizenz wie FSL offen verfügbar wäre und vollständig unterstütztes Self-Hosting möglich wäre, würde ich den kommerziellen Dienst durchaus in Betracht ziehen. Andernfalls ist es schwer, die Abhängigkeit gegenüber etwas wie Kafka zu rechtfertigen.

    • Aus Sicht des Gründers wären alternative Implementierungen der S2 API willkommen.
      Wir prüfen auch einen In-Memory-Emulator, den wir selbst als Open Source veröffentlichen könnten. Die API selbst ist nicht besonders komplex. Wenn man die Kafka API beibehalten und zugleich Funktionen wie S2s Storage-Klassen, sehr viele Topics/Partitions und hohen Durchsatz pro Partition erhalten möchte, planen wir eine self-hostbare Open-Source-Kafka-kompatible Schicht. Auch Funktionen wie clientseitige Verschlüsselung sollen hinzukommen, um mehr Sicherheit zu geben.