S3 Express One Zone : AWS adapte son stockage objet à l’ère de l’IA

Sous le capot de S3 Express One Zone

Le service EOZ fonctionne différemment du niveau S3 Standard. Il profite d’une nouvelle classe de stockage, Express One Zone.

Pour cette classe de stockage, l’équipe derrière Amazon S3 a développé le Directory Bucket. Celui-ci permet d’augmenter le nombre de transactions par seconde. Il fournit ce qu’Andy Warfield appelle une authentification basée sur la session, éliminant de multiples vérifications de métadonnées.

Pour l’occasion, les ingénieurs ont modifié l’implémentation du protocole REST de S3 afin d’émettre des requêtes sous l’égide de cette session. « Nous conservons la même posture de sécurité, mais nous pouvons mettre en cache les informations d’identification à l’intérieur de la session côté serveur. Nous supprimons ainsi une grande partie de la latence », affirme-t-il auprès du MagIT.

En conséquence, la documentation d’AWS précise que les API de zones et de régions associées à S3 EOZ sont différentes de celles de S3 Standard.

Les services de stockage en blocs et en fichiers d’AWS surpassent toujours EOZ dans des circonstances idéales. Cependant, EOZ et Amazon Elastic File System (EFS) offrent des performances équivalentes pour la plupart des charges de travail. Selon M. Warfield, avec Express One Zone, AWS vise une latence de 3 à 10 millisecondes, tandis qu’EFS atteint une latence de 2 à 5 ms. AWS Elastic Block Store General Purpose arrive en tête du trio avec une latence de 1 à 2 ms.

Bien que toujours derrière EFS et EBS, EOZ offre une meilleure latence que le service S3 Standard, qui se situe entre 10 et 200 ms. « Express One Zone est environ 10 fois plus rapide que le S3 régional. Je suis donc presque sûr qu’EOZ est le service de stockage objet le plus rapide du marché », vante Andy Warfied, auprès du MagIT.

Une rapidité qui s’explique également par l’utilisation du stockage flash en lieu et place de disques durs traditionnellement déployés pour animer les instances de stockage objet, selon Dave Raffo, analyste chez Futurum Group. Une information confirmée par Andy Warfield auprès du MagIT.

Outre un nouveau type de bucket, les performances d’EOZ s’expliquent par une révision de la doctrine de conception de S3.

Originellement, S3 a été conçu pour assurer la redondance régionale entre les zones de disponibilité, choisies par les clients d’AWS pour stocker leurs données. Si cette conception doit assurer la cohérence des performances et la disponibilité du service, elle impose une limite.

« Il y a beaucoup d’allers-retours internes dans S3 pour s’assurer que le système est fonctionnel au niveau d’une région cloud », explique Andy Warfield.

Performance contre résilience

Comme son nom l’indique, Express One Zone ne dépend que d’une seule zone de disponibilité (Availability Zone, ou AZ en VO) choisie par le client. Pour éviter les pertes de données, les objets sont redondés sur « plusieurs équipements » au sein de la zone sélectionnée et AWS assure automatiquement le failover. « Si le dispositif existant tombe en panne, S3 Express One Zone transfère automatiquement les requêtes vers de nouveaux dispositifs au sein d’une zone de disponibilité », lit-on dans la documentation. Cela impacte forcément le niveau de service proposé par le fournisseur. Quand S3 standard est fourni avec un niveau de disponibilité de 99,99 %, celui d’EOZ dispose d’un SLA de 99,5 %. En revanche, la durabilité des données est identique (99,999999999 %).

Il y a toutefois un risque majeur, prévient AWS. Si la zone de disponibilité – c’est-à-dire le data center sous-jacent – est endommagée, les données peuvent être partiellement ou totalement perdues. « Cela veut dire que l’on peut y stocker des données reproductibles ou mettre en place une solution de backup », indique Seth Markle, Senior Principal Engineer Amazon S3, chez AWS, dans une session « deep dive ».

Selon Andy Warfield, si cela semble être une régression fonctionnelle en matière de redondance, les clients peuvent y colocaliser leurs capacités de calcul pour des besoins de haute performance.

Plus précisément, au moment de créer un directory bucket, il est possible de spécifier la même région et la même zone de disponibilité où se trouve une instance EKS (Elastic Kubernetes Service), ECS (Amazon Elastic Container Service) ou EC2 (Elastic Elastic Compute Cloud) qui servira à exécuter des traitements.

« Évidemment, ce bucket unizone demeure accessible depuis n’importe quelle AZ », précise-t-il.  

La démocratisation du stockage objet, un héritage d’Hadoop

Express One Zone n’est donc ni plus rapide ni plus résilient que les services de stockage en fichiers et blocs disponibles sur AWS. D’ailleurs, ceux-là bénéficient également d’améliorations afin d’améliorer leur rapport performance-prix.

Non. Le développement d’Express One Zone s’explique par l’évolution de l’usage du stockage objet par les clients, qui est toujours plus simple d’accès, selon Andy Warfield.

« Nous constatons que les clients rapprochent S3 de leurs applications. C’est devenu un service de stockage de première classe, alors que par le passé, il était plutôt utilisé pour archiver des données », relate-t-il.

Le développement et la croissance des frameworks analytiques, il y a près de dix ans, ont lancé la tendance à utiliser le stockage S3 dans le cadre du flux de travail analytique et de la pile d’applicative. Par exemple, les utilisateurs de Hadoop, un framework de traitement de données open source, et de son système de fichiers distribués (HDFS), ont créé des services de connexion S3 pour utiliser directement le stockage, indique M. Warfield.

« L’équipe S3 a toujours considéré le service comme l’une des facettes d’une API REST », avance-t-il. « Nous avons vu les analystes, comme la communauté Hadoop, changer et écrire S3A, qui était un connecteur permettant d’utiliser S3 de la même manière que HDFS dans les clusters d’entreprise, afin de pouvoir exécuter ces grosses charges de travail analytiques sur S3 ».

L’action Hadoop a peut-être poussé l’équipe S3 à réexaminer la gamme de produits, mais la demande des clients pour des performances élevées et rentables des services AWS dans le sillage de l’IA générative et du machine learning a conduit les décisions d’AWS au cours des dernières années.

Convertir S3 à l’IA générative et aux grosses charges de travail de machine learning

« Historiquement, si vous déployez un système de stockage plus rapide sous une charge de travail, cette dernière n’en profite pas forcément », souligne Andy Warlfield. « Par exemple, de nombreuses charges de travail analytiques sont conçues pour masquer la latence du stockage. Pendant des années, les sources ont été lentes et les outils analytiques sont donc optimisés pour cela », explique-t-il.

« Ce que nous constatons cependant, c’est lorsque nous passons à des charges de travail GPU, les temps d’exécution ne sont pas toujours optimaux et les dépendances des données – vous devez lire une chose avant de pouvoir en lire une autre – provoquent des goulets d’étranglement en matière d’accès au stockage ».

EOZ permettrait d’accélérer les traitements « de l’ordre de 40 à 50 % au niveau applicatif ». « Qui plus est, parce que le stockage est plus rapide, vous pouvez réduire le temps d’allocation d’une instance de calcul GPU. Ce sont les ressources de calcul qui sont coûteuses, pas le stockage. Nous constatons donc des réductions de coûts significatives pour ces charges de travail ».

Le lancement de S3 EOZ s’est accompagné de nombreux autres lancements de services et de produits de stockage, notamment de mises à jour des services de stockage en fichiers et en blocs. Andy Warfield a mis l’accent sur d’autres produits déjà lancés en novembre ou qui commencent tout juste à être disponibles, tels que le pilote Mountpoint for S3 Container Storage Interface (CSI) et le connecteur Amazon S3 pour PyTorch, un framework open source consacré au machine learning et au deep learning.

Le pilote Mountpoint for S3 CSI ajoute la possibilité d’accéder aux objets S3 par le biais d’une interface de système de fichiers spécifique au stockage de conteneurs, principalement pour prendre en charge les applications Kubernetes.

« Avec le connecteur PyTorch, vous pouvez attacher une URL à votre framework PyTorch pour charger des données et les points de contrôle (checkpoints en VO) de modèles [des éléments utilisés pour inférer un modèle, N.D.L.R.] directement depuis S3 », relate Andy Warfield.

Le chargement des checkpoints serait « jusqu’à 40 % plus rapide » que dans le stockage d’instances Amazon EC2.

Un résultat qui a d’abord surpris Andy Warfield et son équipe, mais qui serait dû à l’utilisation de CRT (AWS Common RunTime), une collection de librairies open source écrites en C pour optimiser l’usage des services AWS. Le CRT permettrait de saturer le réseau. Or, les voies PCIe des instances SSD EC2 contrôlées par l’hyperviseur Nitro « atteignent un plafond », alors que « les voies PCIe du NIC associé à Amazon S3 sont plus larges ».

À l’avenir, M. Warfield souhaite que les services de stockage d’AWS développent soient davantage interopérables, afin de permettre aux clients de choisir le type de stockage qui convient le mieux à une application, en fonction des besoins.

« Je veux m’assurer que la décision de travailler des données stockées dans une modalité ou dans une autre n’exclut pas les usages ultérieurs », conclut-il.