Regatta Storage (YC F24) : transformer S3 en système de fichiers cloud POSIX aussi simple qu’un stockage local

• Regatta Storage est un service qui permet d’utiliser un stockage compatible S3 comme un système de fichiers cloud à synchronisation automatique, afin de traiter de gros volumes de données sans devoir augmenter la capacité des disques locaux
• L’objectif est de permettre aux workloads Spark, PyTorch et pandas d’accéder directement aux jeux de données sur S3, afin de réduire l’attente de téléchargement et la nécessité de préparer de grands disques locaux
• Le point de départ vient de l’expérience acquise sur Amazon EFS et dans l’exploitation du stockage chez Netflix, où malgré la simplicité et la scalabilité d’EFS, des problèmes de performances subsistaient lors du passage du disque local à NFS
• Les clients montent le système de fichiers Regatta en NFSv3, tandis que les instances de cache Regatta se connectent aux buckets S3 des clients pour fournir des performances inférieures à la milliseconde sur les lectures et écritures mises en cache
• Le service est utilisé pour des notebooks Jupyter serverless, une couche de cache distribuée au-dessus de S3 et le remplacement de volumes de démarrage Ceph thin-provisioned ; l’entreprise développe aussi un protocole de fichiers personnalisé

---

Offrir sur S3 une expérience de système de fichiers proche du local

• Regatta Storage est un système de fichiers cloud facturé à l’usage, synchronisé automatiquement avec un stockage compatible S3
• L’objectif est de permettre à Spark, PyTorch et pandas d’accéder directement à de grands jeux de données sans les télécharger au préalable sur un disque local
• Une vidéo de présentation du service est disponible sur YouTube, et il est possible de l’essayer gratuitement après création d’un compte
• S’il n’existe pas d’essai sans compte, c’est parce que l’équipe a estimé, à la lumière des retours des utilisateurs de Hacker News, qu’il n’était pas approprié de faire partager un même système de fichiers et un même bucket S3 à plusieurs utilisateurs

Un design issu de l’expérience EFS

• Le fondateur a créé Regatta en s’appuyant sur 8 années passées chez Amazon Elastic File System (EFS), ainsi que sur son expérience de conception et d’exploitation de stockage cloud à grande échelle chez Netflix et ailleurs
• EFS avait pour atout, comme S3, la simplicité et la scalabilité sans avoir à estimer à l’avance la capacité nécessaire, mais chez Netflix son adoption n’a pas été aussi large qu’attendu
  • Beaucoup d’applications avaient besoin d’un système de fichiers POSIX, et la demande en stockage pouvait être imprécise ou croître brutalement
  • Il y avait aussi de nombreux cas où un stockage devant durer plus longtemps que le cycle de vie des instances ou des conteneurs était nécessaire
  • Les disques locaux étaient souvent surprovisionnés pour couvrir un usage potentiel, ce qui engendrait des coûts même pour de l’espace de stockage inutilisé
• EFS ne convenait pas à tous les workloads
  • Le passage du disque local à NFS entraînait parfois des problèmes de performances
  • Les applications qui utilisaient le disque local comme stockage temporaire devaient nettoyer manuellement les données restantes sur le stockage persistant

Fonctionnement de Regatta et modèle de cache

• Regatta a été conçu comme un système de fichiers facturé à l’usage qui s’adapte automatiquement avec l’application
  • Il se synchronise automatiquement avec S3 dans un format de fichier natif, ce qui permet de se connecter à des jeux de données existants
  • Les données de fichiers récemment écrites peuvent aussi être utilisées directement depuis S3
  • Les données peu actives sont évacuées du cache Regatta, de sorte que seul le coût du stockage S3 backend reste à payer
• Aujourd’hui, les clients montent le système de fichiers Regatta via NFSv3 sur la flotte d’instances de cache de Regatta
  • Les instances Regatta se connectent en backend aux buckets S3 des clients
  • Elles offrent des performances inférieures à la milliseconde sur les lectures et écritures mises en cache
  • Grâce à un cache durable, elles fournissent à tous les clients de fichiers connectés une vue du système de fichiers avec cohérence forte
  • Des opérations délicates comme le renommage de répertoires sont traitées rapidement et de manière durable, puis propagées de façon asynchrone vers le bucket S3

Premiers cas d’usage et prochaine étape

• Les premiers utilisateurs emploient Regatta pour des serveurs de notebooks Jupyter serverless destinés aux chercheurs en IA, comme couche de cache distribuée à faible latence au-dessus de S3, et comme remplacement de volumes de démarrage Ceph thin-provisioned
• Le protocole de fichiers personnalisé en cours de développement vise des performances proches du local sur les workloads à petits fichiers, ainsi que des performances scale-out de type Lustre pour les traitements de données distribués

[GN⁺]

Commentaires Hacker News

• La différence entre Rclone et Regatta Storage, c’est que Regatta fournit une forte cohérence lors des opérations de modification du système de fichiers grâce à une couche de cache haute performance. Rclone ne dispose d’aucune couche garantissant la cohérence entre clients parallèles

  • Regatta Storage fournit une forte cohérence lors des opérations de modification du système de fichiers grâce à une couche de cache haute performance
  • Rclone ne dispose d’aucune couche garantissant la cohérence entre clients parallèles

• L’un des produits les plus impressionnants issus de YC, et plusieurs questions se posent sur son fonctionnement

  • Je me demande s’il y a une baisse de performance lorsqu’on traite 50 Go de données avec un disque local de 10 Go
  • Je me demande s’il est possible d’obtenir de bonnes performances sur d’autres clouds qu’AWS
  • Je m’interroge sur l’approche utilisant les montages FUSE et NFS
  • Je me demande s’il est possible d’exécuter Clickhouse ou Postgres sur un volume Regatta
  • Je me demande quelle est leur position sur l’open source
  • Je me demande s’il est possible de le monter sur plusieurs serveurs, et quelles en sont les limites

• Utilisation de GCP Filestore pour héberger DuckDB, avec une demande d’informations sur le prix et les performances de Regatta

  • Demande d’informations sur le prix et les performances d’une instance de 10 TiB

• Intérêt comme disque de sauvegarde pour SQLite/DuckDB/parquet, avec souhait de lectures mises en cache sur le stockage NVMe local de l’instance

  • Besoin de fonctionnalités de verrouillage et de mémoire partagée qu’on ne peut pas obtenir avec NFS
  • On pourrait l’implémenter directement en espace utilisateur, mais dans ce cas autant utiliser S3

• L’utilisation de NFS comme protocole semble être une bonne idée

  • Expérience chez IBM à écrire un système de fichiers chiffré fondé sur un concept similaire
  • Quand on monte le système de fichiers, le fait que toutes les données soient « simplement là » paraît magique

• Inquiétude quant à la possibilité qu’AWS copie ce produit et le propose à un prix inférieur

• Expérience d’une démonstration réussie en 2008 devant le CEO d’Adobe, où une photo prise avec un iPhone apparaissait automatiquement comme fichier sur un Mac

  • Implémentation d’un FUSE local communiquant avec le stockage d’objets distribué d’Adobe
  • Début des travaux de R&D sur les systèmes distribués avec le lancement de Dropbox

• Je me demande s’il est possible de construire un stockage SQL ACID en temps réel avec Lambda + SQLite + Regatta

• On ne voit pas clairement comment les conflits de mise à jour de fichiers sont gérés

  • Par exemple, si deux utilisateurs mettent à jour le même fichier depuis des ordinateurs différents, je me demande quel sera le fichier final

• Il existe des alternatives notables comme s3fs, rclone, goofys, etc.