AWS S3 : 1 PB/s sur des HDD lents

Architecture AWS S3 : Des performances à la vitesse du pétabyte avec des disques durs

AWS S3 gère plus de 400 billions d'objets, 150 millions de requêtes par seconde et des pics de trafic dépassant 1 pétabyte par seconde. Au cœur de cette infrastructure, on trouve des disques durs — malgré leurs limites en IOPS (autour de 120) et une latence pouvant atteindre 16 ms pour des lectures aléatoires de 0,5 Mo. L'économie du stockage sur disque dur permet de conserver des exaoctets de données au coût le plus bas possible : la capacité a augmenté 7,2 millions de fois, tandis que le coût par octet a diminué de façon spectaculaire de 6 milliards de fois au fil des décennies.

La physique des disques durs dicte les performances : le temps moyen de recherche sur piste est de 8 à 9 ms, la latence de rotation s'élève à 4 ms, et le temps de transfert à 2,5 ms. L'accès séquentiel est efficace (jusqu'à 300 Mo/s), mais l'accès aléatoire est limité à 32 Mo/s par disque en raison du mouvement mécanique de la tête.

Parallélisme grâce au codage par éradication

S3 surmonte ces contraintes grâce à un parallélisme massif. Les données sont divisées en fragments via un schéma de codage par éradication (EC) 5 sur 9 : 5 fragments de données + 4 fragments de parité. Cela donne un surcoût de 1,8x au lieu de 3x avec la réplication, assure une résilience face à 4 défaillances et offre 5 sources de lecture pour améliorer le débit.

Avantages du codage par éradication :

• Répartition de charge sur 9 fragments, minimisant les points chauds.
• Lecture parallèle sur 5 fragments accélérant l'accès.
• Fragmentation permettant des requêtes hedgées pour contourner les retards de latence.

Un fichier de 1 To sur un seul disque dur atteint 300 Mo/s ; sur 20 000 disques, il scale jusqu’à plusieurs téraoctets par seconde grâce à l’agrégation du bande passante.

Parallélisme à tous les niveaux

Le parallélisme est mis en œuvre sur trois plans :

• Frontend client : des pools de connexions HTTP distribuent les requêtes sur plusieurs points d’accès, évitant la surcharge des proxies et caches.
• Backend frontend : les objets sont répartis sur des milliers de disques dans ShardStore (un arbre LSM construit sur un stockage structuré en journal).
• Opérations PUT/GET : téléversements multipartites pour les écritures, requêtes par plage d’octets pour les lectures — divisées en plus de 100 flux de 10 Mo/s au lieu d’un seul flux gigabit.

Les écritures sont séquentielles (de type journal), tandis que les lectures nécessitent une randomisation du fragment pour éviter les embouteillages dans les files d’attente.

Combat des points chauds

Avec des dizaines de millions de disques et des centaines de millions de fragments par seconde, maintenir une répartition uniforme de la charge est crucial. Un disque limité à 32 Mo/s devient rapidement un goulot d’étranglement, aggravé par le surcoût de rééquilibrage.

Stratégie de S3 :

• Randomisation : hachage des fragments garantissant une consommation équilibrée des ressources.
• Rééquilibrage : migration continue des données sans interruption de service.
• Mise à l’échelle horizontale : ajout de disques sans impact sur la disponibilité.

La structure ShardStore basée sur LSM est optimisée pour les journaux uniquement en écriture — où les PUT sont rapides et les GET utilisent des recherches parallèles dans les index.

Points clés

• S3 atteint 1+ PB/s sur disques durs grâce au EC 5/9 et au parallélisme sur plus de 100 flux.
• Latence moyenne pour I/O aléatoire : 16 ms par 0,5 Mo, atténuée par 5 sources de lecture.
• Économie : 1,8x de surcoût EC contre 3x pour la réplication, économisant des exaoctets en coûts de stockage.
• Randomisation + rééquilibrage empêchent les défaillances en cascade dues aux points chauds.
• Arbre LSM backend maximise les performances séquentielles des disques durs.

— Editorial Team