Réinvention continue : brève histoire du stockage en mode bloc chez AWS

Réinvention continue : brève histoire du stockage en mode bloc chez AWS

• Introduction

  • Marc Olson travaille depuis plus de 10 ans dans l’équipe Elastic Block Store (EBS).
  • EBS est passé d’un simple service de stockage en mode bloc à un système de stockage réseau à grande échelle traitant plus de 140 billions d’opérations par jour.
  • Cet article partage l’évolution d’EBS et les enseignements importants qui en ont été tirés.

• Les débuts d’EBS

  • EBS a été lancé le 20 août 2008, à partir d’une idée simple : fournir un stockage en mode bloc connecté au réseau pour les instances EC2.
  • À ses débuts, il utilisait des disques durs partagés (HDD) ; aujourd’hui, il peut fournir plusieurs centaines de milliers d’IOPS à une seule instance EC2.
  • EBS traite désormais plus de 140 billions d’opérations par jour via une flotte distribuée de SSD.

• Théorie des files d’attente

  • La manière dont les systèmes informatiques interagissent avec le stockage n’a pas fondamentalement changé.
  • Le CPU place les requêtes dans une file, puis le périphérique de stockage récupère les données depuis la mémoire du CPU pour les enregistrer sur un support durable, ou transfère les données en sens inverse vers la mémoire du CPU.
  • La théorie des files d’attente joue un rôle clé pour comprendre ce processus.

• Passage du HDD au SSD

  • Au départ, EBS utilisait des HDD, dont les performances étaient limitées par des contraintes physiques.
  • Avec l’arrivée des SSD, même les requêtes aléatoires ont pu être traitées presque aussi vite que les requêtes séquentielles.
  • En 2012, AWS a lancé un nouveau type de serveur de stockage basé sur des SSD ainsi qu’un nouveau type de volume EBS appelé Provisioned IOPS.

• Mesure et gestion

  • En 2012, EBS ne disposait que d’une télémétrie de base.
  • Pour améliorer les performances du système, il fallait d’abord identifier les problèmes, puis les traiter par ordre de priorité.
  • Des méthodes de mesure des IO ont été mises en place dans plusieurs sous-systèmes, avec une surveillance continue pour détecter les changements.

• Diviser pour mieux régner dans l’organisation

  • L’équipe des serveurs de stockage EBS a été réorganisée en petites équipes focalisées sur des domaines précis comme la réplication des données, la durabilité ou l’hydratation des snapshots.
  • Chaque équipe pouvait itérer et valider ses changements de manière indépendante.

• Remettre en cause les hypothèses

  • Il a été découvert que les réglages par défaut de l’hyperviseur Xen limitaient les performances.
  • Les cartes d’offload Nitro ont permis de déporter vers le matériel le traitement réseau et stockage.

• Expériences de tuning réseau

  • Lors de la migration d’EBS vers Nitro, la surcharge propre au réseau a augmenté.
  • Pour améliorer les performances réseau, AWS a développé le protocole SRD (Scalable Relatable Diagram) à la place de TCP.

• Les contraintes favorisent l’innovation

  • Pour faire bénéficier tous les clients des avantages du SSD, des SSD ont été ajoutés sans remplacer le matériel existant.
  • Les SSD ont été ajoutés manuellement aux serveurs ; les nouvelles écritures y étaient stockées avant d’être vidées de façon asynchrone vers les HDD.

• Réflexion sur la montée en performance

  • Un récit de croissance personnelle : le passage d’une culture de petite entreprise à une organisation de grande taille.
  • Des sessions de debugging entre collègues ont permis de résoudre les problèmes et d’améliorer l’efficacité de l’équipe.

• Conclusion

  • EBS a évolué non pas grâce à un unique grand changement, mais via une série d’améliorations progressives.
  • Les besoins des clients continueront d’augmenter, ce qui restera un moteur pour poursuivre l’innovation et l’itération.

# Résumé de GN⁺

• Cet article offre le point de vue d’un insider sur la façon dont l’EBS d’AWS a évolué.
• Il couvre divers défis techniques et leurs solutions, notamment la théorie des files d’attente, l’adoption des SSD et le tuning réseau.
• Il souligne l’importance d’une mesure et d’une gestion continues pour améliorer les performances.
• Parmi les produits aux fonctionnalités similaires figurent Google Cloud Persistent Disk et Microsoft Azure Disk Storage.

[GN⁺]

Commentaires Hacker News

• Si les grands systèmes vous intéressent, cet article vaut la lecture

  • Les performances d’un disque dur varient en fonction des autres transactions dans la file d’attente
  • Sur des opérations aléatoires de 4 kB, les performances peuvent fortement chuter
  • La mise en file d’attente et l’ordonnancement aident, mais les performances réelles peuvent varier de plus d’un facteur 100 selon la charge de travail
  • Dans les systèmes multi-locataires, c’est particulièrement difficile, surtout pour les opérations de lecture

• Pour résoudre un problème, il faut savoir ce qui ne va pas

  • La plus grande leçon apprise de Marc a été de changer la perspective de l’équipe grâce à la visualisation
  • Analyser les données de performance de plusieurs façons permet de découvrir des gains d’efficacité et des opportunités invisibles autrement

• Le projet consistant à installer des SSD sur les serveurs EBS en 2013 est l’une des histoires intéressantes d’AWS

  • Le système a été conçu dès le départ en tenant compte des événements de maintenance non destructifs
  • Construire un système distribué permet une exploitation à grande échelle

• La panne d’environ 4 jours d’AWS a été causée par EBS, ce qui a ébranlé la confiance envers AWS

  • Cela a entraîné une hausse des investissements dans EBS
  • Cela coïncidait avec la période où Apple devenait client

• Reddit a été l’un des premiers utilisateurs d’EBS en 2008

  • Ils ont tenté d’augmenter les IOPS avec du RAID logiciel, mais les performances n’étaient pas cohérentes
  • Il a fallu du temps pour résoudre les problèmes liés au RAID
  • Netflix n’utilisait pas EBS

• Ajouter une latence aléatoire a pour effet de réduire la latence moyenne et les valeurs aberrantes

• Travailler dans une grande entreprise de l’Internet a permis d’en tirer beaucoup d’enseignements

  • Un apprentissage sur le terrain permet d’acquérir rapidement des connaissances et compétences importantes
  • Lors des entretiens, l’expérience et la recommandation d’un mentor sont très utiles

• La partie sur l’installation manuelle de SSD dans toutes les unités EBS en 2013 était intéressante

  • Entre 2010 et 2012, les performances d’I/O étaient un enjeu majeur

• En 2009, une présentation a été donnée sur l’interne d’Amazon S3

  • Cette présentation a influencé le développement d’EBS

• Au début du cloud, on utilisait du matériel générique, mais désormais on utilise du matériel spécialisé pour chaque service

  • AWS utilise les puces Graviton, Inferentia et Tranium
  • Google utilise les TPU et la carte de sécurité Titan
  • Azure utilise les FPGA et Sphere

• Le premier schéma est incorrect ou obsolète

  • Dans les ordinateurs modernes, la plupart des lignes PCIe sont directement connectées au CPU
  • Il s’agit d’une avancée importante pour le débit I/O et la latence

• Je cherche la meilleure façon de fournir à de nouvelles instances EC2 un répertoire de dataset rapide de 256 GB

  • J’utilise des volumes EBS, mais les mises à jour sont pénibles
  • EFS est trop lent
  • Les SSD de stockage d’instance sont éphémères
  • Je n’ai pas encore essayé FSx Lustre