4 Du Portable Operating System for Unix Filesystems (POSIX), apparu en 1988, au Simple Storage Service (S3) d’Amazon Web Services, lancé en 2006, la persistance des données vit une révolution. En 2013, AWS a annoncé que sa plateforme S3 hébergeait plus de 2 000 milliards d’objets, un nombre qui doublait chaque année. On en serait donc à quelque 16 000 milliards d’objets stockés ; en supposant une taille moyenne de seulement 256 Ko par objet, la plateforme hébergerait aujourd’hui bien plus d’un exaoctet, soit environ 1 % de toutes les données numériques du monde, probablement davantage. C’est sans doute la plus grande plateforme de stockage de données au monde. Le succès d’AWS et de sa plateforme de stockage ne peut plus être ignoré, mais S3 a-t-il du sens pour l’avenir ? Il est intéressant de revenir sur les raisons pour lesquelles AWS a introduit un tel protocole, et sur sa pertinence. Nous ne pouvons pas savoir tout ce qu’Amazon avait en tête en lançant ce protocole, mais les contraintes des systèmes de fichiers traditionnels sont bien connues. AWS a été conçu pour fournir une infrastructure IT à la demande, ce qu’on appelle aujourd’hui l’IaaS. Pouvoir démarrer et arrêter des services à la demande était formidable, mais les informations créées devaient être rendues persistantes. Le système de persistance des données devait avoir des propriétés particulières, notamment : une évolutivité infinie : aucune limite à la croissance du système un protocole adapté au WAN une sécurité simple et fiable une haute disponibilité et une grande robustesse un stockage adapté à un monde de plus en plus centré sur le web. Les systèmes de fichiers POSIX sont le pilier du stockage depuis leur apparition, et leur modèle d’organisation hiérarchique est bien compris des humains. Ils ont néanmoins des contraintes qui rendent leur montée en charge difficile, voire impossible, à mesure que leur taille augmente. Bien des administrateurs du stockage ont surveillé le nombre d’inodes (les identifiants uniques des fichiers et répertoires) comme le lait sur le feu, sachant qu’au-delà de certaines limites le système devient instable. Les utilisateurs de systèmes de fichiers POSIX sont aussi très exigeants : une cohérence totale est attendue sur toute l’arborescence. Toute modification d’un fichier ou de la structure des répertoires doit être communiquée simultanément à tous les utilisateurs. Les mécanismes de gestion d’erreurs des applications n’envisagent même pas qu’il puisse en être autrement. Le système de fichiers POSIX doit reconnaître publiquement tout écart aux règles en renvoyant une redoutée erreur d’E/S. On comprend sans peine qu’AWS devait enfreindre les règles d’une façon ou d’une autre pour atteindre l’échelle vertigineuse d’aujourd’hui, et quel meilleur moyen que de changer tout simplement les règles ? En introduisant un protocole entièrement nouveau, AWS a pu établir de nouvelles règles et conventions qui lui ont permis de monter en charge et de proposer des services plus pertinents pour ses clients. En voici un aperçu : S3 n’est pas hiérarchique : les objets sont stockés par nom dans une collection appelée bucket. Le bucket est indexé et peut être listé par recherche sur préfixe. Un net avantage pour la montée en charge : le domaine de cohérence se limite à un seul bucket, au lieu de toute l’arborescence comme avec POSIX. Le bucket offre une cohérence à terme garantie. L’application doit accepter qu’un objet tout juste mis à jour n’apparaisse pas forcément tout de suite dans la liste ni avec les dernières informations : la plateforme fait au mieux pour être immédiatement cohérente. Avec le temps, le système a montré que les données sont en général totalement cohérentes, mais cette liberté architecturale d’assouplir la contrainte apporte de réels avantages en performances et en évolutivité. Les requêtes sont de type REST et autonomes, une méthode très bien adaptée aux échanges sur WAN. Les requêtes sont signées avec un secret partagé et transmises via une connexion SSL, ce qui protège contre les attaques de l’homme du milieu et évite de transmettre des mots de passe dans les requêtes. Le contenu d’un bucket peut être présenté selon un modèle d’hébergement virtuel, sous la forme https://bucket.s3.amazonaws.com/object_name. Un bucket AWS S3 peut ainsi se comporter directement comme un site web statique. En raison de ce modèle d’hébergement virtuel, les noms de buckets doivent respecter les conventions de nommage DNS, sont uniques sur toute la plateforme AWS et limités à 100 buckets par utilisateur. Ces contraintes ont conduit à un modèle où les applications utilisent généralement un seul bucket contenant des milliers ou des millions d’objets. Les systèmes de fichiers hiérarchiques sont souvent émulés par des préfixes ressemblant à des chemins de répertoires, comme /foo/bar/foo/object. Si cela permet aux applications graphiques de donner l’impression de parcourir une arborescence, le stockage S3 est avant tout utilisé par des applications, et non par des utilisateurs Des droits d’accès permanents ou temporaires peuvent être accordés sur des objets ou des buckets entiers à tout utilisateur identifié de la plateforme ou à des utilisateurs anonymes. Une facturation très fine est proposée en fonction de la quantité de données stockées et de la fréquence d’accès. Dans le prochain volet, nous verrons comment les applications utilisent le stockage AWS S3 et les nombreuses améliorations apportées au modèle en 10 ans d’existence. Nous verrons aussi comment le backend de stockage objet de Scality, leader du secteur, s’approprie cette révolution de la persistance des données. Lire le communiqué de presse de RING 6.0 Découvrir les nouveautés de RING 6.0
