- AWS S3 est un service de stockage d’objets multitenant à grande échelle qui offre une haute disponibilité et une forte durabilité à faible coût
- Bien qu’il s’appuie sur des HDD anciens et lents (≈120 IOPS), il maximise l’économie de supports de stockage très bon marché et de très grande capacité
- S3 conçoit sa couche de stockage interne (ShardStore) selon une structure log-structured (LSM) afin d’aligner le chemin d’écriture sur les E/S séquentielles, tandis que le chemin de lecture compense les limites de performance grâce au codage d’effacement (5-of-9) et à une parallélisation massive
- Du client au frontend puis au stockage, S3 réduit la latence de queue et additionne les débits grâce au multipart upload, aux GET par plage d’octets, aux pools de connexions et aux hedged requests
- Avec une distribution aléatoire, le Power of Two Random Choices, le rééquilibrage continu et la décorrélation qui aplanit la charge à mesure que l’échelle augmente, S3 évite les hotspots et atteint au final un débit de >1 PB/s
L’architecture de stockage à grande échelle d’AWS S3
- Tout le monde sait ce qu’est AWS S3, mais peu de personnes mesurent à quel point S3 fonctionne à une échelle gigantesque et quelles innovations ont été nécessaires pour y parvenir
- S3 est un service de stockage d’objets multitenant extensible qui permet de stocker et de récupérer des objets via une API, tout en offrant une très haute disponibilité et une forte durabilité à un coût relativement faible
-
L’échelle de S3
- Plus de 400 000 milliards d’objets stockés
- 150 millions de requêtes traitées par seconde
- Plus de 1 PB/s de trafic au pic
- Des dizaines de millions de disques durs en exploitation
- Une haute disponibilité et une durabilité (“11 nines” comme objectif de conception), avec un coût relativement bas, sont posées comme prérequis de l’expérience utilisateur
- S3 s’est même étendu jusqu’à devenir la couche de stockage de base des lacs de données pour l’analytique et le machine learning
- L’objectif de conception est de supporter des modèles d’accès aléatoire et une concurrence massive tout en restant efficient en coût
- S3 part du principe d’une charge de travail collective en accès aléatoire, où chaque tenant accède à des tailles et offsets arbitraires
Technologie de base : les disques durs (HDD)
- L’impressionnante scalabilité et les performances de S3 reposent sur un support de stockage traditionnel : le HDD
- Le HDD est une technologie ancienne : très durable, mais limitée en IOPS (entrées/sorties par seconde) et en latence à cause de mouvements physiques
- La rotation (par ex. 7200 RPM) et le seek de l’actionneur sont des mouvements mécaniques indispensables, ce qui rend la latence structurellement élevée et inévitable
- Demi-seek moyen ≈4 ms, demi-rotation moyenne ≈4 ms, transfert de 0,5 MB ≈2,5 ms → lecture aléatoire moyenne de 0,5 MB ≈11 ms, soit un débit aléatoire d’un disque unique d’environ ≈45 MB/s
- Contrairement au SSD, le HDD conserve une économie “très bon marché / très grande capacité” grâce à une tendance de long terme capacité↑·prix↓, ce qui lui permet d’être encore utilisé pour le stockage à grande échelle
- Prix : baisse de 6 milliards de fois par octet (corrigé de l’inflation)
- Capacité : multipliée par 7,2 millions
- Taille : divisée par 5 000
- Poids : divisé par 1 235
- En revanche, depuis 30 ans, les IOPS stagnent autour de 120, et les performances ainsi que la latence en accès aléatoire se sont peu améliorées
- Les SSD sont meilleurs pour les E/S aléatoires, mais moins avantageux en coût total de possession (TCO) à l’échelle péta- et exa-octet
Un chemin d’écriture optimisé pour les E/S séquentielles
- Les HDD sont optimisés pour l’accès séquentiel : lorsqu’on lit ou écrit des octets contigus, les plateaux tournent naturellement et permettent de traiter les données rapidement
- Les structures de données orientées journal (log-structured) exploitent cette caractéristique séquentielle
- ShardStore, la couche de stockage interne de S3, adopte une LSM log-structured pour traiter les écritures comme des append séquentiels sur disque
- De façon similaire, le traitement par lots permet de maximiser le débit séquentiel du disque
Parallélisation et codage d’effacement pour le chemin de lecture aléatoire
- Les lectures impliquent des sauts vers des positions arbitraires (aléatoires) selon les requêtes utilisateur, ce qui confronte directement le système aux limites physiques (latence moyenne des E/S aléatoires d’environ 11 ms)
- Un HDD ne peut traiter au maximum qu’environ 45 MB/s en E/S aléatoires
- Ainsi, les HDD sont très rentables pour stocker de gros volumes, mais peu performants en accès aléatoire
- Pour surmonter cette limite physique, S3 sharde les données sur de nombreux disques et adopte une parallélisation massive afin d’augmenter le débit agrégé par lecture simultanée
- Les données sont réparties sur d’innombrables HDD, et les E/S de chaque disque sont exploitées en parallèle pour accroître fortement le débit global
- Par exemple, si un fichier de 1 TB est réparti sur 20 000 HDD, on peut atteindre une lecture de l’ordre du TB/s en additionnant le débit de tous les disques
Codage d’effacement (Erasure Coding)
- Dans un système de stockage, garantir la redondance est indispensable
- S3 utilise le codage d’effacement (EC) en divisant les données en K fragments de données et M fragments de parité
- Il suffit d’avoir n’importe quels K fragments parmi les K+M pour reconstituer les données
- S3 adopte une structure en 9 fragments (5 fragments de données, 4 fragments de parité) pour un codage d’effacement 5-of-9, comme point d’équilibre
- 5 données + 4 parités = 9 fragments
- Le système tolère la perte de jusqu’à 4 shards et permet de reconstruire l’original avec n’importe quels 5 fragments, offrant ainsi une tolérance aux pannes
- La surcharge de stockage est de ≈1,8x, donc plus efficace en capacité qu’une réplication triple (3x)
- En même temps, cela fournit 5 chemins de lecture parallèles, favorables à la parallélisation par shard et à l’évitement des stragglers
- S3 surmonte ainsi cette limite physique tout en fournissant un accès aléatoire à des volumes massifs de données
Architecture de traitement parallèle
- S3 utilise trois grandes formes de parallélisation
- 1. Les utilisateurs découpent les données en plusieurs chunks pour les téléverser et les télécharger
- 2. Le client envoie des requêtes simultanées à plusieurs serveurs frontend
- 3. Les serveurs répartissent les objets sur plusieurs serveurs de stockage
-
1. Parallélisation au niveau des serveurs frontend
- Utilisation de pools de connexions HTTP internes pour se connecter simultanément à plusieurs endpoints distribués
- Cela évite de surcharger certains nœuds d’infrastructure ou caches
-
2. Parallélisation entre disques durs
- Grâce à l’EC, les données sont réparties en petits shards sur plusieurs HDD
-
3. Parallélisation des requêtes PUT/GET
- Le client découpe les données en plusieurs parties pour les téléverser en parallèle
- PUT : le multipart upload maximise la parallélisation à l’écriture
- GET : prise en charge des GET par plage d’octets (lecture d’une partie seulement d’un objet)
- Une fois réparti en parallèle, atteindre par exemple 1 GB/s en upload ne pose pas de difficulté particulière
Prévention des hotspots
- S3 fonctionne avec des dizaines de millions de disques, des centaines de millions de requêtes par seconde et des centaines de millions de shards en parallèle
- Si la charge se concentre sur un disque ou un nœud particulier, le risque est une dégradation des performances de l’ensemble du système
- Les stratégies clés pour l’éviter :
- 1. Distribution aléatoire de l’emplacement des données
- 2. Rééquilibrage continu
- 3. Augmentation de l’échelle du système
-
1. Shuffle sharding & Power of Two
- L’emplacement initial des données est distribué de manière aléatoire
- Application de l’algorithme Power of Two Random Choices :
- choisir le moins chargé entre deux nœuds tirés au hasard permet un équilibrage de charge efficace
-
2. Rééquilibrage
- Température des données : comme les données récentes sont plus chaudes (plus souvent accédées), un rééquilibrage périodique permet de redistribuer l’espace et les E/S
- plus les données vieillissent, plus leur fréquence d’accès diminue, ce qui augmente la marge de manœuvre en E/S sur l’ensemble du stockage
- S3 redistribue les données froides afin de maximiser l’utilisation de l’espace et des ressources
- Lors de l’ajout de nouveaux racks (par ex. 20 PB/rack, 1000×20 TB), une distribution proactive vers la capacité vide est nécessaire
-
3. Chill@Scale
- Effet d’échelle : plus les charges sont indépendantes, plus la concurrence des pics diminue, ce qui entraîne une décorrélation qui aplanit la charge agrégée
- Plus le système est grand, plus il bénéficie d’un écart réduit entre pic et moyenne et d’une meilleure prévisibilité
- Autrement dit, même si les usages alternent entre poussées et périodes d’inactivité, ils se compensent à grande échelle pour maintenir une charge prévisible
Culture opérationnelle, fiabilité et autres techniques
- Le shuffle sharding au niveau DNS vise l’isolation entre tenants et une répartition homogène dès la couche de résolution de noms
- Les déploiements logiciels sont eux aussi effectués de manière progressive et sans interruption, à la façon de l’EC, et la transition vers ShardStore s’est faite sans impact sur le service
- Culture de la durabilité : détection continue des défaillances, chain of custody, modélisation des menaces sur la durabilité, vérification formelle, etc., pour assurer la fiabilité par les processus
Pourquoi c’est important : les tendances d’infrastructure de données bâties sur S3
- Avec la généralisation des architectures stateless, un modèle se répand où les nœuds applicatifs externalisent l’état et délèguent à S3 la persistance, la réplication et l’équilibrage de charge
- Exemples : Kafka Diskless (KIP-1150), SlateDB, Turbopuffer, Lucene on S3, intégration du stockage objet dans ClickHouse/OpenSearch/Elastic, etc.
- Les avantages sont une scalabilité élastique, une simplification des opérations et une réduction des coûts ; l’inconvénient possible est une hausse de la latence, ce qui impose de concevoir selon le compromis entre latence, coût et durabilité selon la charge de travail
Résumé
- AWS S3 est un service de stockage multitenant à grande échelle qui surmonte les limites de supports lents grâce à une parallélisation massive, à l’équilibrage de charge et au sharding des données
- Il garantit stabilité et performance grâce au codage d’effacement, à la distribution aléatoire, au rééquilibrage continu et aux hedged requests
- Initialement centré sur la sauvegarde et les médias, il a évolué vers un stockage principal pour l’analytique de données et le machine learning
- Les architectures fondées sur S3 permettent une scalabilité stateless et délèguent efficacement à AWS les problèmes de durabilité, de réplication et d’équilibrage de charge
- Cela apporte aussi une réduction des coûts cloud et une meilleure efficacité opérationnelle
2 commentaires
Sans une bonne technologie, j’ai l’impression que ce ne serait pas rentable.
Commentaire Hacker News
Il y a quelques erreurs factuelles, mais elles n’affectent pas vraiment le fil de l’article. Par exemple, l’affirmation selon laquelle S3 utiliserait un schéma de sharding 5:9 : en réalité, S3 utilise divers schémas de sharding et, à ma connaissance, le 5:9 n’en fait pas partie. Le ratio de 1,8 octet physique pour 1 octet logique est vraiment mauvais du point de vue du coût HDD. Il existe en fait des moyens de réduire davantage ce ratio, tout en élargissant le parallélisme et en améliorant la disponibilité. Par exemple, il faut se demander combien de shards peuvent être perdus avant qu’un objet devienne impossible à récupérer par GET quand une AZ entière tombe
J’ai compris à 42:20 de cette vidéo YouTube que S3 utilisait ce schéma de sharding. Si tu en sais plus, ça m’intéresse
Réduire le ratio à 1,8x tout en augmentant la disponibilité ne me paraît pas intuitif. Avec moins de réplicas, le risque de perte de données n’augmente-t-il pas en cas de panne d’AZ ? Je pensais qu’AWS fournissait des réplicas complètement indépendants sur 3 AZ. Et l’idée que, pour lire un chunk de 16MB, il soit en fait plus rapide de lire 4MB sur 5 disques durs différents continue de me surprendre
VAST Data utilise un schéma 146+4. (lien)
J’ai pris plaisir à lire cet article, mais la réponse à la question du titre me semble trop évidente : le parallélisme
En temps normal, je pense rarement au débit d’I/O stockage à une telle échelle. Il fut un temps où j’utilisais du RAID0 pour écrire plus vite sur disque, mais c’était il y a longtemps. Au départ, je m’attendais à des approches intéressantes comme du caching ou de la hiérarchisation. Ce n’est qu’après lecture que j’ai réalisé que le parallélisme était évidemment la réponse, mais je n’avais pas pensé aux détails de l’implémentation de S3 ni à sa manière de gérer la correction d’erreurs. Le mot-clé est « parallélisme », mais les détails apportaient de vrais enseignements. Je suppose que MinIO raconte une histoire de scalabilité similaire : là aussi, c’est du parallélisme
Je trouve le titre de l’article un peu trompeur, car il se concentre seulement sur le débit de pointe global de S3. La vraie question intéressante serait plutôt : « comment obtenir un débit GET supérieur au débit maximal d’un HDD ? » Avec une simple réplication, on peut paralléliser les GET sur plusieurs HDD et augmenter le débit vu à l’échelle de S3, mais on reste au final limité à débit par HDD * nombre de requêtes GET. Le point secret et intéressant, c’est que S3 n’a pas cette limite
En agrégeant des millions de disques durs, on obtient une bande passante d’E/S énorme
Ça sonne comme une logique du genre : « la manière d’aller sur la Lune est évidente : voyager »
Sur les disques récents, un seek complet est plus proche de 25ms que de 8ms. Pour le tester toi-même, si tu as un disque dur et les droits root, tu peux utiliser fio avec l’option --readonly et alterner des lectures aux deux extrémités du disque. Il existe aussi un bon article (ici) expliquant pourquoi la valeur de 1/3 n’est pas exacte sur les disques modernes. Si tu as d’autres questions sur la mécanique ou les performances des disques, je peux répondre
Quand la tête se déplace entre les pistes, il y a une phase d’accélération. Plus la distance est courte, plus la vitesse de pointe est faible, et il existe aussi une latence fixe (temps de stabilisation, etc.), donc on peut effectivement arriver à une moyenne réelle de 4ms
Comme le plateau est circulaire, il ne faut pas utiliser une distribution uniforme sur [0, 1] mais sur le cercle unité [0, 2π], et comme le plateau ne tourne que dans un seul sens, la distance doit toujours être calculée dans le sens horaire.
Si on simplifie le problème avec un point de départ à 0° et une cible aléatoire, quelle est la distance moyenne ? Les arcs 0-180° et 180-360° ont la même longueur, donc la distance moyenne est de 180°. Autrement dit, un half-platter seek est exactement la moitié d’un full-platter seek
On peut probablement estimer si S3 utilise encore des HDD pour son service de base en regardant les prix et en les ramenant aux IOPS. Les frais par requête GET/PUT de S3 sont suffisamment élevés pour qu’AWS puisse se permettre de laisser une partie de la capacité disque inutilisée pour les tenants à fortes performances. Mais pas au point d’aller beaucoup au-delà d’un léger surcoût
Je me demande si une partie de S3 tourne sur SSD. Je pensais que le S3 standard était lui aussi basé sur SSD, et que seuls les tiers plus lents utilisaient des HDD ou des systèmes plus lents
Le KeyMap Index de S3 utilise des SSD. À l’heure actuelle, il est probable que des SSD soient déjà utilisés pour le cache des objets chauds ou pour une partie des nouvelles offres one zone
Les données effectivement stockées sont probablement presque toutes sur HDD. En revanche, les métadonnées, index, etc. utilisent sans doute du stockage flash beaucoup plus rapide. C’est généralement aussi le cas des serveurs MDS dans de petits clusters Ceph, et S3 est à une toute autre échelle
Comme mentionné plus haut, sur le tier standard, le prix des requêtes est assez élevé pour que le ratio IOPS/TB de certains clients reste rentable même si une partie de la capacité disque est laissée inutilisée. Mais au-delà, ce ne serait plus intéressant. Les HDD récents stockent environ 30TB et, même si on ne sait pas combien AWS les paie réellement, on peut estimer quelque chose comme 300 à 500 dollars. C’est bien moins cher qu’un SSD de 30TB. On peut aussi monter ces HDD dans des systèmes à haute densité (par exemple 100 disques en 4U), pour seulement environ 25 % de coût supplémentaire sur le coût total. En revanche, les châssis capables de supporter beaucoup de SSD coûtent nettement plus cher par slot
J’imagine que S3 Express One Zone est basé sur SSD. Cela dit, Amazon ne semble pas le dire publiquement
Je m’attendrais clairement à ce que les métadonnées soient stockées sur SSD. Et il est aussi probable que les objets hot, souvent lus, soient mis en cache sur SSD
Je trouve étonnant que, même si le prix des HDD a continué à baisser, les tarifs de S3 soient restés identiques pendant au moins 8 ans. Faute de vraie concurrence sur les baisses de prix, ils ont pu conserver une grille tarifaire élevée. On peut imaginer les profits que cela rapporte à AWS
La politique tarifaire d’AWS est similaire sur tous ses services. Par exemple, une instance EC2 m7a.medium coûte 50 dollars par mois en on-demand, ou 35 dollars avec une réservation d’un an. Même comparé à des offres similaires chez d’autres fournisseurs, ce n’est pas très compétitif
Il faut aussi tenir compte de l’inflation : même si le tarif nominal est resté identique, le prix réel a donc baissé. Mais je suis d’accord sur le fait que l’inflation reflète beaucoup plus lentement que le progrès technique
Je ne pense pas que la réduction des coûts soit l’objectif des incitations. Quand on regarde des entreprises comme Splunk ou CrowdStrike, qui stockent d’énormes volumes de données sur AWS, on voit énormément de données répétitives, qui sont refacturées telles quelles aux clients avec seulement une déduplication très simple. Réduire les coûts créerait au contraire une incitation à accroître encore une consommation déjà inutile
Je me demande dans quelle mesure le prix des HDD baisse encore vraiment. Ces dernières années, la baisse du prix par Go des disques durs a beaucoup ralenti, au point qu’on peut imaginer que les SSD finissent bientôt par les rattraper
Comme lecture encore plus intéressante sur S3, je recommande "Building and operating a pretty big storage system called S3"
Je serais curieux de connaître les performances réelles de rustfs
En voyant la mention de dizaines de millions de HDD utilisés, on peut estimer que, si les HDD enterprise font entre 10 et 20TB, la capacité totale d’AWS S3 se situe dans les centaines d’exaoctets. C’est probablement l’un des plus gros systèmes de stockage au monde, voire le plus gros
Si le matériel a été renouvelé depuis 2013, un certain datacenter de l’Utah pourrait dépasser cette capacité (article lié)
Les HDD enterprise actuels sont à 30TB, et devraient bientôt pouvoir aller jusqu’à 50TB
J’aimerais connaître un service open source optimisé pour les HDD et capable d’atteindre des performances comparables. Les grands projets (MinIO, Swift, Ceph+RadosGW, SeaweedFS) recommandent tous des déploiements flash-only. Je regarde en ce moment un projet récent, Garage, mais sa conception est assez différente, notamment parce qu’il n’utilise pas d’EC
Ceph+RadosGW fonctionne aussi très bien avec des HDD. Il faut simplement mettre le pool d’index sur SSD et avoir une vision réaliste du nombre d’IOPS qu’on peut espérer d’un pool HDD. Côté client, les IOPS se multiplient en pratique plusieurs fois, et S3 résout justement ce problème avec un très grand nombre de HDD. Pour du stockage massif en streaming 4MB, ce n’est pas un gros problème, mais si on fait beaucoup de lectures/écritures aléatoires sur de petites clés, ou beaucoup d’accès distribués sur une même clé, alors les performances du backend deviennent cruciales
Lustre/ZFS peut aussi atteindre des vitesses comparables. Mais si on a besoin de beaucoup d’IOPS, il faut du flash pour le MDS dans le cas de Lustre, et un SSD de log dédié dans le cas de ZFS
Tous ces services ont besoin de très nombreux disques de niveau datacenter pour atteindre les mêmes performances. Très peu de déploiements ont cette échelle. C’est aussi pour cela que le flash est plus efficace pour l’accès rapide du point de vue espace/coût
SeaweedFS a beaucoup progressé ces dernières années, avec l’ajout du support RDMA et de l’EC
Dans un ancien poste, nous exploitions du stockage objet basé sur SwiftStack, avec les métadonnées sur SSD et les données objet sur HDD standard. Cela fonctionnait très bien