S3 Files et l’évolution de S3

• Pour réduire l’inefficacité des transferts de données à grande échelle, S3 Files a été introduit afin de permettre un accès direct aux données S3 comme à un système de fichiers
• Cette fonctionnalité intègre Amazon EFS et S3 afin de permettre, depuis EC2, des conteneurs, Lambda, etc., de monter un bucket S3 en NFS pour lecture et écriture
• En interne, elle utilise une structure stage et commit pour répercuter périodiquement les changements dans S3, tout en prenant en charge la synchronisation bidirectionnelle entre fichiers et objets
• Avec S3 Tables et S3 Vectors, S3 Files joue un rôle de composant clé pour étendre S3 en plateforme de données unifiée
• S3 évolue désormais au-delà d’un simple espace de stockage, vers un espace de travail unifié centré sur les données, fournissant aux développeurs une base leur permettant d’exploiter directement les données

---

L’évolution de S3 et la conception de S3 Files

• Les difficultés du déplacement de données et le point de départ de S3 Files

  • Le transfert de grands volumes de données reste une source persistante d’inefficacité dans des secteurs très variés, de la recherche scientifique au machine learning
  • Dans le cas des recherches en génomique à l’UBC, les chercheurs consacraient beaucoup de temps à copier des données entre S3 et le système de fichiers local
  • Cette friction des données (data friction) provient du fait que les outils accèdent aux données de façons différentes
  • S3 Files a été conçu pour réduire cette friction en permettant un accès direct aux données S3 comme à un système de fichiers

• Développement orienté agents et importance des données

  • Les progrès des outils agentiques (agentic tooling) accélèrent fortement la vitesse et la diversité du développement applicatif
  • À mesure que la barrière à l’écriture de code diminue, les experts métier peuvent construire eux-mêmes des applications
  • Le cycle de vie des applications se raccourcit, tandis que les données émergent comme actif clé à long terme
  • Le stockage ne doit pas être un simple dépôt, mais une couche d’abstraction permettant de séparer les données des applications pour les exploiter durablement

Les nouveaux primitifs de données de S3

• S3 Tables

  • Pour traiter les données structurées, S3 a introduit S3 Tables basé sur Apache Iceberg
  • Tout en conservant les fonctions d’Iceberg, il fournit la protection de l’intégrité des données, la compaction automatique et la réplication inter-région, entre autres
  • Plus de 2 millions de tables sont actuellement stockées dans S3 Tables, et diverses applications sont construites sur cette base

• S3 Vectors

  • Avec les progrès de l’IA, la demande pour les index vectoriels augmente
  • Les bases de données vectorielles classiques stockent les index en mémoire ou sur SSD, ce qui présente des limites de coût et de scalabilité
  • S3 Vectors fournit un index vectoriel totalement élastique avec un profil coût/performance/durabilité similaire à celui des objets S3
  • Il peut s’étendre de quelques centaines à plusieurs milliards d’enregistrements, et fournit des endpoints API pour la recherche de similarité scalaire (scalar similarity search)

L’arrivée de S3 Files

• Vue d’ensemble

  • S3 Files intègre Amazon EFS à S3 pour permettre un accès direct aux données S3 comme à un système de fichiers réseau (NFS)
  • Depuis EC2, des conteneurs, Lambda, etc., il est possible de monter un bucket S3 ou un préfixe et de le lire ou de l’écrire comme un fichier
  • Les changements sont automatiquement répercutés dans S3, avec prise en charge de la synchronisation bidirectionnelle entre fichiers et objets

• Les défis de conception

  • Le système de fichiers et le stockage objet reposent sur des modèles de données fondamentalement différents
  • Au départ, l’idée était de simplement combiner EFS et S3, mais cela n’a laissé que des « compromis inacceptables (unpalatable compromises) »
  • Les fichiers prennent en charge les modifications fines et les accès concurrents, tandis que les objets supposent l’immuabilité et des mises à jour de l’objet entier
  • Le système de notifications d’événements de S3 traite plus de 300 milliards de notifications par jour et fonctionne sur la base de modifications au niveau des objets

Principes de conception Stage and Commit

• Transformer la frontière en fonctionnalité

  • Au lieu de masquer la différence entre fichiers et objets, celle-ci est conçue comme une frontière explicite
  • Les changements sont stagés (stockage temporaire) dans EFS, puis committés (commit) dans S3 à intervalles réguliers
  • Inspirée des concepts de gestion de versions de Git, cette approche permet de contrôler les transferts de données en fonction du temps et de politiques

• Cohérence et atomicité

  • Elle prend en charge à la fois les opérations atomiques du système de fichiers (rename, move) et les mises à jour de l’objet entier dans S3
  • En séparant les deux couches, elle fournit une vue unique des données tout en conservant le modèle de cohérence de chaque système

• Gestion des autorisations

  • Les politiques IAM de S3 et les permissions basées sur les inodes d’un système de fichiers diffèrent structurellement
  • S3 Files sépare les deux mécanismes via une attribution des permissions au niveau du montage
  • Les politiques IAM de S3 restent le backstop final, permettant de contrôler l’accès lorsque les frontières de données changent

• Incompatibilité des espaces de noms

  • S3 n’a pas de véritable notion de répertoire, et le séparateur de chemin (delimiter) peut aussi être défini arbitrairement
  • Pour résoudre l’écart avec le système de fichiers, les règles de nommage des deux côtés sont conservées telles quelles
  • Les objets incompatibles ne sont pas déplacés ; le système est conçu pour émettre des événements afin que les développeurs puissent les traiter

• Performance et latence

  • Le système de fichiers est optimisé pour un accès centré sur les métadonnées, tandis que S3 l’est pour un accès massif en parallèle
  • Comme la plupart des workloads n’accèdent pas simultanément aux fichiers et aux objets, il est plus réaliste de maintenir une couche de synchronisation que d’unifier totalement les deux modèles
  • La vue fichier conserve la cohérence NFS, la vue objet conserve la forte cohérence de S3, et la couche de synchronisation fait le lien entre les deux

Fonctionnement de S3 Files

• Structure de base

  • S3 Files utilise EFS comme backend pour fournir une expérience de système de fichiers
  • Lors de l’accès à un répertoire, il récupère les métadonnées S3 pour générer une vue synchronisée ; pour les fichiers de 128 KB ou moins, les données sont également chargées immédiatement
  • Les fichiers volumineux utilisent le chargement différé (lazy hydration) pour ne récupérer les données qu’en cas de besoin
  • Les changements sont committés dans S3 toutes les 60 secondes environ via un unique PUT, avec synchronisation bidirectionnelle

• Conflits et gestion

  • En cas de modification simultanée des deux côtés, S3 est considéré comme la source de vérité (source of truth)
  • Les fichiers en conflit sont déplacés vers le répertoire lost+found et enregistrés via des métriques CloudWatch
  • Les fichiers non consultés pendant 30 jours sont retirés de la vue du système de fichiers afin d’optimiser les coûts

• Optimisation des performances

  • Grâce à la fonctionnalité read bypass, lors de grandes lectures séquentielles, la lecture se fait directement depuis S3 via des requêtes GET parallèles

    • Un débit de 3 GB/s par client est atteint, avec une scalabilité au niveau du térabit sur plusieurs clients

• Limites et améliorations prévues

  • Comme S3 ne dispose pas d’une opération native de rename, renommer un répertoire nécessite une copie puis une suppression complètes
  • Un avertissement s’affiche pour les montages contenant plus de 50 millions d’objets
  • Le contrôle explicite du commit n’est pas inclus dans la version initiale
  • Certaines clés d’objet ne peuvent pas être représentées comme noms de fichier POSIX et sont donc exclues de la vue fichier

Diversité des données et évolution de S3

• Coexistence des modes d’accès aux données

  • Comme dans le cas de la recherche à l’UBC, les développeurs consacrent beaucoup de temps au déplacement, au cache et à la gestion des noms des données
  • Avec Tables, Vectors et Files, l’équipe S3 prend en charge de façon unifiée divers modes d’accès aux données
  • Plutôt que d’essayer de faire disparaître la différence entre fichiers et objets, elle reconnaît leurs caractéristiques propres et transforme leur frontière en fonctionnalité

• Le rôle élargi de S3

  • S3 évolue d’un simple stockage objet vers une plateforme de stockage unifiée prenant en charge diverses formes de données
  • Avec Tables, Vectors et Files, il devient possible d’exploiter directement les données selon le mode de travail souhaité
  • L’objectif est de faire du stockage une infrastructure de base transparente, et non un obstacle au travail
  • Des extensions comme le contrôle stage/commit et l’intégration aux pipelines sont prévues pour la suite

• Conclusion

  • S3 Files combine les avantages des deux mondes tout en conservant une frontière explicite entre fichiers et objets
  • Né il y a 20 ans comme stockage objet, S3 évolue aujourd’hui en espace de travail unifié centré sur les données
  • À l’image du message « Go build! », S3 s’impose comme une base permettant aux développeurs d’expérimenter et de construire plus vite avec les données