Regatta Storage (YC F24): S3 in ein POSIX-Cloud-Dateisystem mit lokalem Gefühl verwandeln

• Regatta Storage ist ein Dienst, der S3-kompatiblen Storage wie ein automatisch synchronisiertes Cloud-Dateisystem nutzbar macht, um große Datenmengen ohne Erweiterung lokaler Festplatten zu verarbeiten
• Er soll Spark-, PyTorch- und pandas-Jobs direkten Zugriff auf Datensätze in S3 ermöglichen und so Wartezeiten für Downloads sowie den Aufwand für große lokale Festplatten reduzieren
• Ausgangspunkt waren Erfahrungen mit Storage-Betrieb bei Amazon EFS und Netflix; trotz der Einfachheit und Skalierbarkeit von EFS blieben beim Wechsel von lokalen Festplatten zu NFS Performance-Probleme bestehen
• Kunden mounten das Regatta-Dateisystem über NFSv3; Regatta-Caching-Instanzen sind mit dem S3-Bucket des Kunden verbunden und liefern bei gecachten Lese- und Schreibvorgängen Performance im Sub-Millisekundenbereich
• Eingesetzt wird es für serverlose Jupyter-Notebooks, eine verteilte Caching-Schicht auf S3 und als Ersatz für thin-provisioned Ceph-Boot-Volumes; künftig wird außerdem ein Custom File Protocol entwickelt

---

Ein Dateisystem-Erlebnis wie lokal auf S3 bieten

• Regatta Storage ist ein Cloud-Dateisystem mit nutzungsbasierter Abrechnung und automatischer Synchronisierung mit S3-kompatiblem Storage
• Ziel ist ein Workflow, bei dem große Datensätze in Spark, PyTorch und pandas direkt genutzt werden können, ohne sie auf lokale Festplatten herunterzuladen
• Ein Überblicksvideo zum Dienst ist auf YouTube verfügbar; nach der Kontoerstellung kann man ihn kostenlos ausprobieren
• Dass es keine Demo ohne Konto gibt, liegt daran, dass man es für ungeeignet hielt, Hacker-News-Nutzer ein einzelnes Dateisystem und einen S3-Bucket gemeinsam verwenden zu lassen

Design-Hintergrund aus Erfahrungen mit EFS

• Der Gründer entwickelte Regatta auf Basis von 8 Jahren Erfahrung bei Amazon Elastic File System (EFS) sowie beim Aufbau und Betrieb von groß angelegtem Cloud-Storage bei Netflix und anderswo
• EFS bot wie S3 den Vorteil von Einfachheit und Skalierbarkeit, ohne vorab die benötigte Kapazität abschätzen zu müssen, wurde bei Netflix aber nicht so stark genutzt wie erwartet
  • Viele Anwendungen benötigten ein POSIX-Dateisystem, und der Storage-Bedarf war oft unklar oder konnte sprunghaft steigen
  • Häufig wurde Storage benötigt, der länger bestehen bleibt als die Lebensdauer von Instanzen oder Containern
  • Lokale Laufwerke wurden für die potenzielle Nutzung überprovisioniert, sodass auch ungenutzter Speicherplatz Kosten verursachte
• EFS passte nicht zu allen Workloads
  • Beim Wechsel von lokalen Festplatten zu NFS traten teils Performance-Probleme auf
  • Anwendungen, die lokale Festplatten wie temporären Storage verwendeten, mussten Daten, die im persistenten Storage zurückblieben, manuell bereinigen

Funktionsweise von Regatta und Cache-Modell

• Regatta ist als automatisch mit Anwendungen skalierendes Dateisystem mit nutzungsbasierter Abrechnung konzipiert
  • Es synchronisiert sich im nativen Dateiformat automatisch mit S3 und kann an bestehende Datensätze angebunden werden
  • Auch kürzlich geschriebene Dateidaten lassen sich direkt aus S3 nutzen
  • Nicht aktiv genutzte Daten werden aus dem Regatta-Cache entfernt, sodass nur die Kosten für den Backend-S3-Storage anfallen
• Derzeit verbinden und mounten Kunden das Regatta-Dateisystem per NFSv3 mit der Flotte von Regatta-Caching-Instanzen
  • Regatta-Instanzen verbinden sich im Backend mit dem S3-Bucket des Kunden
  • Für gecachte Lese- und Schreibvorgänge bieten sie Performance im Sub-Millisekundenbereich
  • Über einen dauerhaften Cache stellen sie allen verbundenen Dateiclients eine stark konsistente Sicht auf das Dateisystem bereit
  • Schwierige Operationen wie das Umbenennen von Verzeichnissen werden schnell und dauerhaft verarbeitet und anschließend asynchron in den S3-Bucket propagiert

Frühe Einsatzfälle und nächste Schritte

• Frühe Nutzer setzen Regatta als serverlosen Jupyter-Notebook-Server für KI-Forscher, als latenzarme verteilte Caching-Schicht auf S3 und als Ersatz für thin-provisioned Ceph-Boot-Volumes ein
• Das in Entwicklung befindliche Custom File Protocol soll bei Small-File-Workloads nahezu lokale Performance liefern und bei verteilten Datenjobs Scale-out-Performance wie Lustre erreichen

[GN⁺]

Hacker-News-Kommentare

• Der Unterschied zwischen Rclone und Regatta Storage besteht darin, dass Regatta bei mutierenden Dateisystem-Operationen eine High-Speed-Caching-Schicht verwendet und dadurch starke Konsistenz bietet. Rclone hat keine Schicht, die Konsistenz zwischen parallelen Clients gewährleistet.

  • Regatta Storage verwendet bei mutierenden Dateisystem-Operationen eine High-Speed-Caching-Schicht und bietet dadurch starke Konsistenz.
  • Rclone hat keine Schicht, die Konsistenz zwischen parallelen Clients gewährleistet.

• Eines der coolsten Produkte aus YC, und ich habe einige Fragen dazu, wie es funktioniert.

  • Ich frage mich, ob es zu Leistungseinbußen kommt, wenn man auf einer lokalen 10-GB-Disk Daten im Bereich von 50 GB verarbeitet.
  • Ich frage mich, ob man auch in anderen Clouds außer AWS hohe Geschwindigkeit erreichen kann.
  • Ich bin neugierig auf die Verwendung von FUSE- und NFS-Mounts.
  • Ich frage mich, ob man Clickhouse oder Postgres auf einem Regatta-Volume betreiben kann.
  • Ich frage mich, wie ihr zu Open Source steht.
  • Ich frage mich, ob man es auf mehreren Servern mounten kann und welche Einschränkungen es dabei gibt.

• Ich hoste DuckDB mit GCP Filestore und hätte gern Informationen zu Preis und Performance von Regatta.

  • Ich hätte gern Informationen zu Preis und Performance einer 10-TiB-Instanz.

• Ich interessiere mich dafür als Backup-Disk für SQLite/DuckDB/parquet und hätte gern gecachte Reads aus dem lokalen NVMe-Storage der Instanz.

  • Ich brauche Locking- und Shared-Memory-Funktionen, die man mit NFS nicht bekommt.
  • Ich könnte das zwar direkt im User Space implementieren, aber dann würde ich eher gleich S3 verwenden.

• Ich halte es für eine gute Idee, NFS als Protokoll zu verwenden.

  • Ich habe bei IBM einmal ein ähnliches verschlüsseltes Dateisystem geschrieben.
  • Wenn man ein Dateisystem mountet und alle Daten „einfach da sind“, wirkt das wie Magie.

• Es gibt Bedenken, dass AWS dieses Produkt kopieren und zu einem niedrigeren Preis anbieten könnte.

• Ich habe 2008 vor dem CEO von Adobe erfolgreich eine Demo gezeigt, bei der ein mit dem iPhone aufgenommenes Foto automatisch als Datei auf dem Mac erschien.

  • Ich habe mit FUSE eine lokale FUSE-Implementierung gebaut, die mit dem verteilten Objektspeicher von Adobe kommunizierte.
  • Mit dem Start von Dropbox habe ich begonnen, im Bereich Research & Development für verteilte Systeme zu arbeiten.

• Ich frage mich, ob man mit Lambda + SQLite + Regatta Real-Time-ACID-SQL-Storage aufbauen kann.

• Es ist nicht klar, wie Konflikte bei Datei-Updates behandelt werden.

  • Wenn zum Beispiel zwei Nutzer dieselbe Datei auf unterschiedlichen Rechnern aktualisieren, frage ich mich, wie die endgültige Datei aussieht.

• Es gibt beachtenswerte Alternativen wie s3fs, rclone und goofys.