Regatta Storage (YC F24): convierte S3 en un sistema de archivos POSIX en la nube que se siente local

• Regatta Storage permite usar almacenamiento compatible con S3 como si fuera un sistema de archivos en la nube con sincronización automática, para manejar grandes volúmenes de datos sin ampliar discos locales
• Busca permitir acceso directo a datasets en S3 desde trabajos de Spark, PyTorch y pandas, reduciendo la espera por descargas y la carga de preparar grandes discos locales
• Parte de la experiencia en operación de almacenamiento en Amazon EFS y Netflix, y aunque EFS ofrecía simplicidad y escalabilidad, seguían existiendo problemas de rendimiento al pasar de disco local a NFS
• Los clientes montan el sistema de archivos de Regatta vía NFSv3, y las instancias de caché de Regatta se conectan al bucket S3 del cliente para ofrecer rendimiento de menos de un milisegundo en lecturas y escrituras cacheadas
• Se está usando para notebooks Jupyter serverless, una capa de caché distribuida sobre S3 y como reemplazo de volúmenes de arranque Ceph con thin provisioning; además, están desarrollando un protocolo de archivos personalizado

---

Una experiencia de sistema de archivos sobre S3 que se siente local

• Regatta Storage es un sistema de archivos en la nube con cobro por uso y sincronización automática con almacenamiento compatible con S3
• Apunta a un flujo donde Spark, PyTorch y pandas puedan acceder directamente a grandes datasets sin descargarlos a disco local
• Se puede ver un video general del servicio en YouTube, y se puede probar gratis después de crear una cuenta
• La razón por la que no ofrecen una demo sin cuenta es que consideraron que no era adecuado que usuarios de Hacker News compartieran un mismo sistema de archivos y bucket S3

Contexto de diseño surgido de la experiencia con EFS

• El fundador creó Regatta basándose en 8 años en Amazon Elastic File System (EFS) y en experiencia construyendo y operando almacenamiento en la nube a gran escala en lugares como Netflix
• EFS tenía como ventaja la simplicidad y escalabilidad de no requerir estimar capacidad por adelantado como en S3, pero en Netflix no se usó tanto como se esperaba
  • Muchas aplicaciones necesitaban un sistema de archivos POSIX, y la demanda de almacenamiento podía ser incierta o dispararse repentinamente
  • También había muchos casos donde se necesitaba almacenamiento que durara más que la vida de una instancia o contenedor
  • Los discos locales se sobreaprovisionaban para cubrir el uso potencial, lo que generaba costos incluso por espacio de almacenamiento vacío
• EFS no encajaba en todas las cargas de trabajo
  • Al mover cargas de trabajo de disco local a NFS, en algunos casos aparecían problemas de rendimiento
  • Las aplicaciones que usaban discos locales como almacenamiento temporal tenían que limpiar manualmente los datos remanentes en almacenamiento persistente

Cómo funciona Regatta y su modelo de caché

• Regatta fue diseñado como un sistema de archivos con cobro por uso que escala automáticamente junto con la aplicación
  • Se sincroniza automáticamente con S3 en formatos de archivo nativos, por lo que puede conectarse a datasets ya existentes
  • Incluso los datos de archivos escritos recientemente pueden usarse directamente desde S3
  • Los datos con poco uso se eliminan de la caché de Regatta, de modo que solo se paga el costo del almacenamiento S3 de backend
• Actualmente, los clientes montan el sistema de archivos de Regatta conectándose por NFSv3 al fleet de instancias de caché de Regatta
  • Las instancias de Regatta se conectan en backend al bucket S3 del cliente
  • Ofrecen rendimiento de menos de un milisegundo para lecturas y escrituras cacheadas
  • Mediante una caché duradera, proporcionan una vista del sistema de archivos con consistencia fuerte para todos los clientes de archivos conectados
  • Manejan de forma rápida y duradera operaciones complicadas como renombrar directorios, y luego las propagan de forma asíncrona al bucket S3

Casos de uso iniciales y siguientes pasos

• Los primeros usuarios están usando Regatta para servidores de notebooks Jupyter serverless para investigadores de IA, una capa de caché distribuida de baja latencia sobre S3 y como reemplazo de volúmenes de arranque Ceph con thin provisioning
• El protocolo de archivos personalizado que están desarrollando apunta a ofrecer rendimiento cercano a local en cargas de trabajo con archivos pequeños, y rendimiento scale-out tipo Lustre en trabajos de datos distribuidos

[GN⁺]

Opiniones de Hacker News

• La diferencia entre Rclone y Regatta Storage es que, al modificar el sistema de archivos, Regatta usa una capa de caché de alta velocidad para ofrecer consistencia fuerte. Rclone no tiene una capa que garantice consistencia entre clientes paralelos

  • Regatta Storage usa una capa de caché de alta velocidad para ofrecer consistencia fuerte al modificar el sistema de archivos
  • Rclone no tiene una capa que garantice consistencia entre clientes paralelos

• Parece uno de los productos más geniales que han salido de YC, y hay varias preguntas sobre cómo funciona

  • Hay curiosidad por saber si hay degradación de rendimiento al manejar datos en el rango de 50GB con un disco local de 10GB
  • Hay curiosidad por saber si también puede lograr altas velocidades en otras nubes además de AWS
  • Hay dudas sobre el enfoque de usar montajes FUSE y NFS
  • Hay curiosidad por saber si se puede ejecutar Clickhouse o Postgres sobre un volumen de Regatta
  • Hay curiosidad por saber qué piensan sobre el open source
  • Hay curiosidad por saber si se puede montar en varios servidores y cuáles serían las limitaciones

• Alguien está alojando DuckDB con GCP Filestore y pide información sobre el precio y el rendimiento de Regatta

  • Pide información sobre el precio y el rendimiento de una instancia de 10 TiB

• Hay interés en usarlo como disco de respaldo para SQLite/DuckDB/parquet, con lecturas cacheadas desde almacenamiento NVMe local de la instancia

  • Se necesitan funciones de bloqueo y memoria compartida que no se pueden obtener con NFS
  • Se podría implementar directamente en espacio de usuario, pero en ese caso mejor usar S3

• Se considera que usar NFS como protocolo es una buena idea

  • Alguien tiene experiencia en IBM escribiendo un sistema de archivos cifrado con un concepto similar
  • Se siente casi mágico que, al montar el sistema de archivos, todos los datos “simplemente estén ahí”

• Hay preocupación de que AWS pueda copiar este producto y ofrecerlo a un precio más bajo

• Alguien cuenta que en 2008 hizo con éxito una demo frente al CEO de Adobe en la que una foto tomada con un iPhone aparecía automáticamente como archivo en una Mac

  • Implementó un FUSE local que se comunicaba con el almacenamiento distribuido de objetos de Adobe
  • Comenzó a hacer I+D en sistemas distribuidos con el lanzamiento de Dropbox

• Hay curiosidad por saber si se puede construir almacenamiento SQL ACID en tiempo real usando Lambda + SQLite + Regatta

• No está claro cómo manejan los conflictos al actualizar archivos

  • Por ejemplo, si dos usuarios actualizan el mismo archivo desde computadoras distintas, hay curiosidad por saber cómo queda el archivo final

• Hay alternativas destacables como s3fs, rclone y goofys