Amazon S3, future « lingua franca » du stockage objet ?

Stockage objet

Dans Amazon S3, le concept d’objet décrit une donnée sans format spécifique. Il peut s’agir d’une image, d’un log, d’un fichier ou de tout type de données non structurée. Ces données sont associées à un ensemble de métadonnées – utilisées pour les décrire. Dans le cas d’Amazon S3, chaque objet peut se voir associer jusqu’à 2Ko de métadonnées.

En tant que service de stockage opéré par Amazon AWS, Amazon S3 est sans doute le plus grands des services publics de stockage objet, avec ceux de Microsoft et de Google, qui utilisent leurs propres protocoles de stockage. S3 a fait ses débuts en 2006 et il stocke aujourd’hui des dizaines de billions d’objets, dont la taille varie de quelques kilooctets à plusieurs Teraoctets.

Ces objets sont organisés par leurs possesseurs en collections nommées « Buckets » (littéralement des « seaux »), auxquelles on peut associer des droits d’accès spécifiques. Si l’on excepte le concept de « Buckets », l’organisation des données dans S3 se fait « à plat » et n’a absolument rien de commun avec les notions hiérarchiques de structures telles qu’une arborescence de fichiers.

Des commandes simples

S3 est à la fois le nom du service de stockage en cloud d’Amazon et celui de la collection de protocoles et API utilisés pour accéder au service. Amazon fournit plusieurs méthodes d’accès dont une API RESTful et une API SOAP HTTPS (qui est toutefois en voie d’obsolescence).

Le service S3 peut aussi être accédé via un certain nombre de SDK dont ceux pour Java, .NET, PHP et Ruby.

Dans un stockage objet comme S3, les objets sont stockés et retrouvés via des commandes simples. PUT est utilisé pour stocker des données, GET pour les retrouver et DELETE pour les effacer. Les mises à jour sont également effectuées via des requêtes de type PUT. Mais selon la nature du bucket, le PUT écrase l’objet préexistant ou crée une nouvelle version (si le versioning est activé sur le « bucket »). L’API S3 inclut aussi des commandes comme COPY (par exemple pour copier des objets entre « buckets ») ou LIST (pour lister des buckets, par exemple).

Dans S3, les objets sont référencés par un identifiant unique choisi par l’utilisateur. Ceci peut être le nom d’un fichier ou une série aléatoire de caractères. Par exemple, « videos/2014/birthday/video1.wmv » ou « mes_photos_2015/janv/Bogota.jpg » sont des identifiants acceptables, tout comme « AE28B3648527645C3B48F65A32A26 ».

La possibilité d’utiliser ses propres identifiants « en clair » est un vrai différenciateur face à d’autres plates-formes de stockage objet qui retournent un identifiant alphanumérique arbitraire chaque fois que l’on stocke un nouvel objet. Elle rend S3 plus flexible et plus simple à utiliser.

Les classes de stockage dans S3

Il y a trois classes de stockage dans Amazon S3, chacune associée à des caractéristiques d’accès, de disponibilité et des coûts différents. Chaque objet stocké dans Amazon S3 peut se voir individuellement associer l’une de ces trois classes :

• Standard : l’offre générique d’Amazon S3
• Standard (Infrequent Access) : une version dégradée de l’offre Standard pour les données qui n’ont pas besoin d’une disponibilité optimale et dont les accès ne sont pas fréquents.
• Glacier : Glacier est conçu pour l’archivage de données à long terme et est associé à des critères dégradés en matière d’accès (il faut un minimum de 4 heures pour retrouver un objet stocker dans Glacier).

À chaque classe de stockage est associé un tarif différent. Par exemple, en Europe, le prix par défaut pour la classe standard est de 0,03 $/Go, alors que la classe Standard Infrequent Access est facturée 0,0125$/Go. Stocker des données dans Glacier revient à 0,007$/Go. À ces coûts nominaux, s’ajoutent des frais de transferts de données (notamment pour les données sortantes) ainsi que des coûts en fonction du nombre de requêtes en lecture.

S3 reste une boîte noire pour ses utilisateurs

Amazon AWS ne fournit pas de détails techniques sur la façon dont S3 est construit. Le fournisseur se borne à fournir quelques indications qui permettent d’en savoir un peu plus sur son fonctionnement.

Amazon Web Services opère ses services depuis 12 régions géographiques (le nombre s’accroît régulièrement). Ces régions sont découpées en zones de disponibilités qui réunissent un ou plusieurs datacenters (actuellement 33). Ces zones de disponibilités (ou Availability Zones) fournissent la résilience et dans le cas de S3, les données sont distribuées entre de multiples zones avec des copies multiples dans chaque zone.

En termes de disponibilité, Amazon garantit une disponibilité standard de 99.99 % des données (99.9 % pour Standard Infrequent Access) et une durabilité de 99.999999999 % (indicative du risque de perte de données).

Utiliser S3 dans ses applications

Amazon S3 fournit pour l’essentiel une capacité illimitée de stockage sans avoir à déployer en interne l’infrastructure nécessaire pour stocker les données et sans avoir à l’administrer ou à la supporter. Toutefois, le service n’a rien de magique et il y a des points essentiels à connaître lorsqu’on souhaite l’utiliser comme support à ses applications :

• Éventuellement consistant : le modèle de consistance de données de S3 est « éventuellement consistant » lors des mises à jour de données ou des effacements d’objet. Par cela, on entend que lorsqu’un objet est modifié, il y a une chance qu’une opération de relecture de cet objet retourne sa version antérieure. Il faut en effet un certain temps pour que la réplication de cet objet se fasse entre les zones de disponibilités d’une même région. Il est possible de se protéger contre ce risque, mais il faut alors coder la logique adaptée dans ses applications.
• Conformité : dans Amazon S3, les données sont stockées dans un nombre limité de pays, ce qui peut éventuellement être source de problèmes réglementaires. Par exemple, il n’y a pas de région « France » chez Amazon AWS, mais deux régions Europe (Ouest et Centrale) dont les datacenters sont respectivement basés en Irlande et à Francfort, ce qui peut poser des soucis pour certains métiers. C’est ce qui rend aussi intéressant le fait que certains systèmes de stockage objet « on-premises » adoptent l’API S3 car cela ouvre la voie à des applications en mode hybride utilisant alternativement le stockage en cloud public ou un stockage objet privé. Le tout s’appuyant sur un même protocole d’accès.
  • Sécurité : S3 permet de sécuriser les accès aux données en s’appuyant sur les mécanismes de clés d’authentification d’AWS. Pour accéder à S3, il est possible de s’appuyer sur les clés d’accès du compte (même si cela n’est pas recommandé). L’approche préconisée est celle qui consiste à s’appuyer sur les mécanismes de gestion d’identification et d’authentification (IAM) d’Amazon AWS, ce qui permet de créer des comptes pour chaque employé devant accéder aux données et d’assigner les permissions adéquates (il est aussi possible de s’appuyer sur les mécanismes de fédération d’identité pour générer des identifiants temporaires).
    Dans la compatibilité avec S3, la gestion de ces mécanismes d’IAM est un point clé pour les fournisseurs de plates-formes de stockage objet tierces comme Scality ou Cloudian.
    A ces considérations d’accès, S3 ajoute des considérations de sécurité. Il est possible de chiffrer les données avec des clés de chiffrement fournies par l’utilisateur (ce qui requiert toutefois que l’utilisateur gère ses clés de façon appropriée).
    Enfin, S3 offre la possibilité de loguer l’ensemble des actions effectuées via l’API S3 en s’appuyant sur un autre produit d’AWS, CloudTrail. Cette capacité de traçage est primordiale pour les entreprises qui ont besoin d’auditer leur infrastructure à des fins de conformité ou de sécurité. Il est à noter que CloudTrail est un service payant et que ses données sont stockées dans un bucket S3, dont le coût vient s’ajouter à l’ensemble).
  • Verrouillage : S3 ne fournit aucune fonction permettant de sérialiser l’accès aux données. C’est à l’application utilisant le service qu’il revient de s’assurer que de multiples requêtes PUT simultanées n’entrent pas en conflit. Cela requiert de développer la logique applicative qui contrôlera les processus de lecture de modification et d’écriture dans les environnements où les objets sont fréquemment mis à jour.
  • Coût : Le coût d’utilisation d’Amazon S3 peut croître de façon importante si les accès aux données sont fréquents. Chaque accès est en effet facturé, de même que les transferts de données associés (en tout cas si les données quittent les services d’Amazon AWS). Et c’est sans compter les investissements à prévoir dans la bande passante pour s’assurer des performances d’accès correctes au service.
    C’est aussi ce qui peut rendre intéressant la mise en œuvre d’un stockage objet compatible S3 en interne. On bénéficie des avantages du protocole et de capacités de cloud hybride, tout en pouvant s’appuyer sur une infrastructure interne performante pour les données accédées très fréquemment. Bien sûr, il faut alors accepter de gérer des composants d’infrastructure de stockage en interne.