Réinvention continue : une brève histoire du stockage en mode bloc chez AWS
(allthingsdistributed.com)- AWS EBS a démarré comme un stockage en mode bloc connecté au réseau pour EC2, avant de devenir une flotte SSD distribuée issue d’un service reposant sur des HDD partagés, capable de traiter plus de 14 billions d’opérations par jour
- Les premières limites de performance venaient non seulement des 120 à 150 IOPS et de la latence moyenne de 6 à 8 ms des HDD, mais aussi du problème de noisy neighbor provoqué par le partage d’un même disque entre plusieurs charges de travail clientes
- Avec l’adoption des SSD, les volumes Provisioned IOPS ont offert en 2012 jusqu’à 1 000 IOPS avec une latence moyenne d’environ 2 à 3 ms, mais les goulets d’étranglement se sont déplacés vers le réseau, l’hyperviseur et les files logicielles
- L’équipe EBS a instrumenté l’ensemble du chemin des E/S et amélioré chaque couche, des files Xen au déchargement Nitro, en passant par le traitement matériel du chiffrement, le réglage TCP et le protocole de transport SRD
- Les gains de performance ont été obtenus non par une réécriture massive, mais via des migrations sans interruption, des changements indépendants menés par de petites équipes et une amélioration incrémentale continue, mesurée et réversible
Du stockage en mode bloc pour EC2 à une flotte SSD à grande échelle
- EBS est né le 20 août 2008, environ deux ans après la bêta d’EC2, à partir de l’idée de fournir un stockage en mode bloc connecté au réseau pour les instances EC2
- À l’époque, l’équipe comptait un ou deux spécialistes du stockage et quelques ingénieurs en systèmes distribués, qui ont commencé à bâtir le service à partir de leurs connaissances des systèmes informatiques et des réseaux
- Depuis, EBS est passé d’un produit sur HDD partagés à un service capable de fournir des centaines de milliers d’IOPS à une seule instance EC2
- Aujourd’hui, le nombre d’IOPS pouvant être fourni à une seule instance dépasse ce que l’ensemble d’une Availability Zone recevait à l’époque des HDD
- Dans son ensemble, EBS traite plus de 14 billions d’opérations par jour sur une flotte SSD distribuée
- La charge principale est celle des disques système des instances EC2, dans une forme proche d’un disque dur de serveur physique fourni comme stockage réseau
- Les clients accordent de l’importance à la durabilité, mais les performances et la disponibilité, directement liées à l’expérience EC2, sont tout aussi essentielles
- Les volumes io2 Block Express et les snapshots de volumes fournissent les fondations nécessaires pour atteindre une forte durabilité
- Les performances et la disponibilité des volumes EBS se répercutent presque directement sur l’expérience des applications basées sur EC2
Les premières limites imposées par les files d’attente et les HDD
- Dans un système informatique, les requêtes de stockage sont traitées en traversant plusieurs files d’attente entre le CPU, le bus et les périphériques
- Dans le stockage réseau, plusieurs files apparaissent entre le noyau du système d’exploitation, l’adaptateur de stockage, la fabric de stockage, l’adaptateur de stockage cible et le support de stockage
- Quand EBS a été créé en 2008, le marché du stockage reposait principalement sur les HDD, et la latence était dominée par le support lui-même
- Le disque dur est un dispositif mécanique, avec des limites physiques
- Pendant des décennies, les performances des HDD sont restées autour de 120 à 150 opérations par seconde, avec une latence d’E/S moyenne de 6 à 8 ms
- À cause des files d’attente et du réordonnancement interne des commandes, la latence de queue pouvait monter à plusieurs centaines de ms
- À l’époque, la latence end-to-end d’EBS se mesurait en dizaines de ms, si bien que les quelques dizaines de microsecondes ajoutées par le réseau représentaient une faible part de la latence totale
- Les performances des HDD étaient fortement affectées par les autres opérations accumulées dans les files
- De petites requêtes aléatoires dispersées sur le support mettaient plus de temps à être localisées et servies que plusieurs grosses requêtes proches les unes des autres
- Répartir les clients sur plusieurs disques réduisait les pics de latence extrêmes des charges les plus chaudes, mais propageait aussi davantage de comportements irréguliers à plus de clients
- Le noisy neighbor, où une charge de travail en affecte une autre, est devenu un problème métier important
- AWS estimait qu’une forte isolation des performances était nécessaire pour améliorer la qualité de l’expérience client
- Les changements d’algorithmes d’ordonnancement disque et la répartition des charges sur davantage de plateaux n’ont apporté que de petites améliorations incrémentales
Après l’arrivée des SSD, l’importance de l’instrumentation devient évidente
- Vers 2011, les SSD se sont démocratisés davantage et ont commencé à être disponibles à des capacités qu’AWS pouvait envisager
- Les SSD n’ont pas de bras mécanique à déplacer pour localiser les données, gèrent les requêtes aléatoires presque aussi vite que les séquentielles et disposent de plusieurs canaux entre le contrôleur et les puces NAND
- EBS a d’abord créé un nouveau type de serveur de stockage basé sur SSD et un nouveau type de volume appelé Provisioned IOPS
- Le lancement de ce nouveau type de volume n’a pas été un petit chantier, et les charges capables d’en tirer parti restaient limitées
- Contrairement à l’idée selon laquelle remplacer les HDD par des SSD résoudrait presque tous les problèmes, le noisy neighbor n’a pas disparu automatiquement
- Lancé en août 2012, Provisioned IOPS fournissait jusqu’à 1 000 IOPS
- Soit 10 fois plus que les volumes EBS standard existants
- La latence moyenne tombait à environ 2 à 3 ms, une amélioration de 5 à 10 fois
- Le contrôle des valeurs extrêmes s’améliorait aussi nettement
- À ce stade, EBS ne disposait que d’une télémétrie basique, et il fallait une instrumentation plus fine pour savoir quoi corriger
- L’équipe a construit un moyen de suivre chaque E/S à plusieurs points
- L’initiateur client EBS
- La pile réseau
- Le moteur de durabilité du stockage
- Le système d’exploitation
- En plus de la surveillance des charges clientes, l’équipe a créé des tests canary pour vérifier en continu les effets positifs et négatifs des changements sur des charges bien connues
Un travail d’amélioration partagé entre matériel et logiciel
- La nouvelle télémétrie a clairement montré où investir en premier
- Il fallait réduire le nombre de files dans l’ensemble du système
- Il existait une marge pour diminuer la complexité du chemin d’E/S de l’hyperviseur Xen utilisé par EC2
- Des optimisations du logiciel réseau étaient nécessaires
- Le moteur central de durabilité devait faire évoluer l’organisation des données sur disque, l’optimisation des cache lines et l’adoption d’un modèle de programmation asynchrone
- Chez AWS, les problèmes de performance système traversent souvent simultanément plusieurs couches de la pile matérielle et logicielle
- EBS a fait avancer en parallèle l’équipe des serveurs de stockage et l’équipe cliente, avec la participation des ingénieurs de l’hyperviseur EC2 et du groupe interne AWS chargé de la performance réseau
- L’organisation de développement a elle aussi été découpée selon une logique de divide and conquer, comme un système logiciel
- L’équipe monolithique de développement du serveur de stockage a été réorganisée en petites équipes par domaine, comme la réplication des données, la durabilité ou l’hydratation des snapshots
- Chaque équipe pouvait itérer et déployer ses changements de manière indépendante, sur la base de tests rigoureux
- Le plan directeur établi en 2013 ne ressemblait pas encore à l’EBS d’aujourd’hui, mais il donnait une direction
- À l’époque, personne n’anticipait qu’Amazon construirait un jour ses propres SSD et disposerait d’une pile technologique adaptée aux besoins d’EBS
De Xen à Nitro puis à SRD : éliminer les goulets d’étranglement
- Jusqu’à la fin 2017, toutes les instances EC2 fonctionnaient sur l’hyperviseur Xen
- Le chemin des périphériques Xen comprenait une ring queue dans laquelle le domaine invité et le domaine pilote privilégié dom0 partageaient des informations, et le client EBS s’exécutait comme un périphérique bloc du noyau dans dom0
- Avant même de sortir de l’hôte EC2, une requête d’E/S traversait plusieurs files
- La file du périphérique bloc de l’instance
- Le ring Xen
- La file du périphérique bloc du noyau de dom0
- La file réseau du client EBS
- L’équipe EBS a écrit plusieurs périphériques loopback afin d’isoler l’impact de chaque file
- Même lorsque la latence du pilote de périphérique dans dom0 était quasi nulle, il a été constaté que le débit effectif de l’ensemble du système chutait lorsque plusieurs instances généraient des E/S en même temps
- EC2 avait été lancé avec le nombre par défaut de files de périphériques bloc Xen et le nombre par défaut d’entrées dans ces files
- Ces valeurs par défaut avaient été définies en fonction du matériel de stockage limité des anciens environnements de développement Xen
- Le nombre de requêtes d’E/S en attente était limité à 64 pour l’ensemble de l’hôte, et non par périphérique
- En 2013, le développement de la première carte de déchargement Nitro, dédiée au réseau, était en cours
- Elle déplaçait le traitement du réseau software-defined de VPC depuis le noyau Xen dom0 vers un pipeline matériel dédié
- En séparant le data plane de traitement des paquets de l’hyperviseur, il n’était plus nécessaire d’utiliser les cycles CPU des instances clientes pour traiter le trafic réseau
- La même approche a ensuite été appliquée au stockage EBS
- Davantage de traitement a été déplacé vers le matériel afin de réduire les files du système d’exploitation dans l’hyperviseur
- Le déchargement des traitements fondés sur les interruptions a réduit le temps passé par l’hyperviseur à traiter les requêtes
- La deuxième carte Nitro intégrait aussi des fonctions matérielles permettant de gérer les volumes EBS chiffrés sans impact sur les performances
- Les éléments de clé de chiffrement étaient séparés de l’hyperviseur, ce qui renforçait encore la protection des données clients
- Une fois EBS déplacé sur Nitro, le goulet d’étranglement s’est reporté sur le réseau lui-même
- Les paramètres récents de tuning TCP de datacenter et les algorithmes de contrôle de congestion ont été revus
- Dans certains cas, l’ajout d’un petit délai aléatoire aux requêtes adressées aux serveurs de stockage réduisait la latence moyenne et les valeurs extrêmes grâce à un effet de lissage sur le réseau
- Ce type d’ajustement n’a pas duré indéfiniment à mesure que les performances et l’échelle du système continuaient de croître, et des mesures ainsi qu’une surveillance continues sont restées nécessaires pour éviter les régressions
- En 2014, les travaux ont commencé sur Scalable Reliable Datagram (SRD), avec l’objectif de faire mieux que TCP
- L’article associé est A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- Les exigences incluaient une meilleure reprise sur incident, de meilleures capacités de contournement et une plus grande facilité de déchargement matériel
- Deux observations ont été essentielles dans la conception de SRD
- Il était possible de se concentrer sur l’architecture réseau des datacenters AWS, plutôt que sur l’Internet public
- Dans le stockage, l’ordre d’exécution des requêtes d’E/S en vol pouvait être réorganisé
- Il devenait ainsi possible d’éviter le coût de l’in-order delivery strict de TCP et d’envoyer différentes requêtes sur plusieurs chemins réseau pour les exécuter à leur arrivée
- SRD est utilisé non seulement pour le stockage, mais aussi pour le réseau
- Dans Elastic Network Adapter(ENA) Express, SRD améliore les performances de la pile TCP du guest
- L’utilisation de plusieurs chemins réseau et la réduction des débordements ainsi que des files dans les équipements intermédiaires permettent d’obtenir une utilisation réseau plus élevée
Cache SSD et migrations sans interruption
- EBS ne voulait pas se satisfaire d’une situation où seuls certains volumes et certains clients bénéficiaient de meilleures performances, et cherchait à étendre plus largement les avantages des SSD
- À l’époque, des millions de volumes clients non Provisioned IOPS tournaient sur des milliers de serveurs de stockage
- Certains de ces volumes existent encore aujourd’hui
- Jeter et remplacer tout le matériel aurait eu un coût élevé
- Il restait de l’espace libre dans les châssis des serveurs, mais l’emplacement qui ne perturbait pas le flux d’air de refroidissement se situait entre la carte mère et les ventilateurs
- Les SSD étaient petits et légers, mais ne devaient pas bouger dans le châssis ; après tâtonnements et avec l’aide de spécialistes des matériaux, l’équipe a trouvé un ruban de fixation auto-agrippant industriel résistant à la chaleur
- Pendant quelques mois en 2013, EBS a ajouté un SSD à la main dans chacun de plusieurs milliers de serveurs
- Un petit changement logiciel a permis de faire du staging des nouvelles écritures sur le SSD, de renvoyer leur achèvement à l’application, puis de les flush de façon asynchrone vers le HDD plus lent
- Ce travail a été mené sans interruption pour les clients
- EBS a été conçu dès le départ en tenant compte des opérations de maintenance sans interruption
- Il était possible de retarget un volume EBS vers un nouveau serveur de stockage, puis de mettre à jour ou reconstruire le serveur libéré
- La capacité à déplacer des volumes clients vers de nouveaux serveurs de stockage s’est révélée utile à de nombreuses reprises par la suite
- Elle a servi lors de l’introduction de structures de données plus efficaces pour le format on-disk
- Elle a aussi été utilisée pour remplacer de vieux matériels par de nouveaux
- Certains volumes créés dans les premiers mois du lancement d’EBS en 2008 sont encore actifs
- Ces volumes ont probablement traversé des centaines de serveurs différents et plusieurs générations de matériel
- La mise à jour et la reconstruction de la flotte ont été réalisées sans impact sur ces charges de travail
Un style de leadership adapté à l’extension des performances
- L’échelle d’EBS différait, sur le plan organisationnel autant que technique, de celle d’une petite entreprise ou d’une startup
- Si les experts système devaient participer à toutes les escalades, toutes les revues de commit et toutes les modifications de conception, ils devenaient un goulet d’étranglement de performance pour l’organisation
- Pour résoudre ce problème, l’expérimentation a porté non seulement sur le code, mais aussi sur les modes de collaboration
- L’outil le plus représentatif a été le peer debugging
- Plusieurs ingénieurs examinaient ensemble le code et le terminal pour suivre un problème
- Cela a permis d’identifier un cas où la position et la manière de faire le locking lors de la mise à jour d’une structure de données critique posaient problème
- En temps normal, le souci restait invisible, mais il ralentissait parfois les réponses aux requêtes ; le corriger a supprimé l’une des causes de jitter
- Donner aux ingénieurs les moyens d’expérimenter en sécurité, réduire les obstacles tout en conservant des garde-fous, pouvait produire de meilleurs résultats
L’amélioration continue plutôt qu’une grande réécriture
- L’amélioration d’EBS s’est faite non par un changement monumental unique, mais par une suite d’améliorations incrémentales sur la durée
- Cette approche a permis d’apporter plus vite de la valeur aux clients et d’ajuster la direction à mesure que les charges clientes évoluaient et que de nouveaux enseignements apparaissaient
- L’expérience de latence d’EBS est passée d’un niveau moyen de plus de 10 ms par opération d’E/S à des E/S submilliseconde cohérentes sur les volumes io2 Block Express les plus performants
- Ce changement a été obtenu sans mettre le service hors ligne pour introduire une nouvelle architecture
- Les clients continuent de demander toujours plus de performances, et cette exigence reste le moteur des innovations et des itérations d’EBS
1 commentaires
Avis sur Hacker News
Je suis vraiment content de voir cet article ici. Si vous vous intéressez ne serait-ce qu’un peu aux systèmes à grande échelle, il vaut vraiment la lecture.
Sur des charges de travail séquentielles, les disques magnétiques modernes peuvent dépasser les 100 Mo/s en lecture/écriture, mais sur une charge totalement aléatoire en 4 ko, ils peuvent tomber à 400 ko/s. Même si la mise en file d’attente et l’ordonnancement permettent d’éviter le pire, les performances réelles varient de plus de 100× selon la charge de travail, ce qui est très difficile à gérer pour un système multitenant. En particulier, pour les lectures, il n’existe pas de solution de contournement du type « écrire simplement ailleurs ».
Ce que Marc m’a le plus appris, c’est que pour savoir ce qui est cassé, il faut d’abord bien l’observer. Il créait des visualisations de latence, comme les séries temporelles d’histogrammes de l’article, puis s’en servait pour raconter une histoire qui changeait complètement la façon dont l’équipe voyait ce qu’elle devait faire. Chaque pic de l’histogramme avait sa propre cause et son propre travail d’optimisation, et investir dans l’examen approfondi des données de performance sous plusieurs angles révèle des gains d’efficacité et des opportunités invisibles autrement.
Le projet de retrofit de 2013, qui consistait à ajouter un SSD à chacun de plusieurs milliers de serveurs, est l’un de mes exemples préférés dans l’histoire d’AWS. Cela a été possible parce que, dès le départ, EBS avait été conçu avec des opérations de maintenance sans interruption en tête : on pouvait réassigner les volumes EBS à de nouveaux serveurs de stockage, puis mettre à jour ou reconstruire les serveurs vidés. C’est un bon exemple du fait que les systèmes distribués ne servent pas seulement à passer à l’échelle : ils permettent aussi de tolérer naturellement les pannes de serveurs et de déplacer les données sans perte, rendant ainsi possible l’exploitation à grande échelle.
Dick Lyon, chez Google, a adopté la même approche sur les serveurs de stockage de Google et, à partir de la diapositive 62 de https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers...., a identifié plusieurs files d’attente et de la contention sur les ressources comme principaux goulots d’étranglement du stockage bloc.
Ça me rappelle de vieux souvenirs. Reddit faisait partie des premiers utilisateurs d’EBS en 2008, et nous nous croyions très malins après avoir découvert qu’en faisant du RAID logiciel avec 5 volumes EBS, on pouvait augmenter les IOPS.
À l’époque, les performances de chaque volume étaient très irrégulières, donc on en lançait 7 ou 8, on leur faisait subir une charge de lecture/écriture, puis on choisissait les 5 plus performants pour les assembler avec le RAID logiciel de Linux. Quand ça marchait bien, on obtenait l’effet voulu, avec parfois plus de 5 fois les IOPS d’un seul nœud ; mais quand ça se passait mal, c’était vraiment horrible.
Nous ne savions pas qu’en RAID logiciel, si un nœud est lent, tout le RAID avance à la vitesse du volume le plus lent, et le résultat donnait l’impression que la base de données était en train de se corrompre. Il nous a fallu du temps pour comprendre que la cause était le RAID, et retirer le mauvais nœud était également difficile. Le RAID logiciel ne voulait pas le lâcher tant qu’il n’avait pas terminé les écritures sur ce volume lent.
Il fallait ajouter un nouveau volume EBS et reconstruire la grappe, ce qui n’était pas fameux non plus, car on se retrouvait limité par les IOPS du nouveau volume. Par la suite, nous avons arrêté d’utiliser ce RAID logiciel, et chez Netflix nous n’utilisions quasiment pas EBS. Je racontais à tous ceux qui voulaient bien l’entendre les erreurs que nous avions commises chez Reddit, et Netflix s’était déjà standardisé sur l’utilisation exclusive de disques locaux avant même mon arrivée.
Anecdote amusante : lors de la grande panne EBS d’AWS, je travaillais chez Reddit et je regardais Netflix en attendant qu’EBS revienne pour pouvoir réparer les bases de données. Pendant mon entretien chez Netflix, j’ai demandé : « Comment avez-vous tenu pendant la panne EBS ? » et on m’a répondu : « Ah, nous n’utilisons tout simplement pas EBS. »
J’ai apprécié la lecture de cet article.
Ce qui est intéressant, c’est que, pendant la période couverte par l’article, AWS a connu, si je me souviens bien, une panne d’environ 4 jours à cause d’EBS, qui a affecté EC2, EBS et RDS. Cette panne a fortement ébranlé la confiance envers AWS.
Il s’en est suivi une réorganisation, avec un investissement beaucoup plus profond dans EBS en tant que service indépendant. Cette période coïncidait aussi avec l’arrivée d’Apple comme client, ainsi qu’avec la forte croissance d’AWS dans son ensemble grâce à l’adoption par des startups comme Netflix, Zynga et Dropbox.
Ces récits techniques et opérationnels sont passionnants, mais l’innovation technologique en production est désordonnée et se déroule sur fond de besoins business réels. J’aimerais qu’on entende davantage ce genre d’histoires aussi.
Mais la roue a fini par tourner à nouveau, et l’on est revenu au développement de fonctionnalités. Je me souviendrai toujours de cette année comme de celle où il y a eu le moins d’escalades pendant tout le temps où j’y étais.
Je suis curieux à propos du passage selon lequel « ajouter une petite quantité de latence aléatoire aux requêtes des serveurs de stockage réduisait en fait la latence moyenne et les valeurs aberrantes, grâce à l’effet de lissage du réseau ». Quelqu’un peut expliquer pourquoi ?
Si cela vous intéresse, il existe une conférence de 2009 [0] sur l’architecture interne d’Amazon S3. Elle était basée sur des documents internes de l’équipe S3, et beaucoup de ces éléments ont aussi influencé la manière dont EBS a été développé.
[0]: https://vimeo.com/7330740
J’ai bien aimé le passage expliquant qu’en 2013, ils avaient ajouté manuellement des SSD à tout le matériel EBS. Sur la photo, ça ressemble pas mal à un SSD SATA Samsung
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
Ma mémoire me joue peut-être des tours, mais il me semble qu’on installait déjà des SSD dans des lames Dell bien avant ça. Vers 2010-2012, les performances I/O étaient vraiment un énorme sujet, et c’était la période où l’on passait des disques durs rotatifs à la mémoire flash
Je me souviens avoir expérimenté avec des périphériques basés sur de la flash brute, sans aucune gestion des erreurs ni nivellement de l’usure. C’était de la folie, mais tout le monde avait désespérément besoin des gains de performances I/O énormes qu’apportait le passage des disques rotatifs au silicium
La vitesse des disques a progressé tellement vite que le premier SKU était obsolète au bout de six mois. J’étais content de ne pas avoir à expliquer moi-même à l’équipe chargée des actifs pourquoi on mettait ces racks au rebut plusieurs années plus tôt que prévu. Installer des modèles nouveaux, plus denses et plus rapides donnait beaucoup plus de valeur à l’emplacement en rack
Ça me rappelle l’époque où l’on construisait une infrastructure de stockage as a service avant qu’il existe de l’open source utilisable. On est passés de Sun SAN, Fibre Channel et Solaris à GlusterFS sur des serveurs de stockage Supermicro sous Linux et NFS, et on était montés à presque 2 Po avant mon départ en 2007
Je repense aussi à l’époque où il était tout simplement logique de casser discrètement un mdraid et de le reconstruire en remplaçant des disques rotatifs par des SSD pendant que le serveur tournait. SATA prenait en charge dans une certaine mesure le hot-swap des disques. Le passage des disques rotatifs aux SSD a multiplié par 14 les IOPS du système le plus critique de la plateforme
Au début de ma carrière, j’ai travaillé sur l’ensemble des systèmes d’une entreprise Internet dont l’échelle était énorme sur le plan technique et opérationnel, pas forcément en nombre d’employés. Le nombre de leçons apprises en peu de temps était absurde. Après avoir quitté cette entreprise, j’ai compris que la plupart des gens ne rencontrent quasiment jamais ce genre de problèmes au cours de leur carrière, et n’apprennent donc pas ces leçons
C’est pourquoi je pense qu’il devrait exister un système de qualification professionnelle. Exiger un apprentissage auprès d’ingénieurs expérimentés permettrait d’acquérir en peu de temps des connaissances et des compétences très précieuses qui ne s’apprennent que par l’expérience, puis de travailler ensuite de façon bien plus efficace. Pour quelqu’un qui fait passer des entretiens, des preuves d’expérience et une recommandation du mentor auraient aussi beaucoup de valeur
J’ai aimé cette phrase
« L’idéal très célébré de l’ingénieur full-stack a de la valeur, mais dans des systèmes profonds et complexes, il est souvent plus précieux de constituer un groupe de spécialistes capables de collaborer et de travailler de façon créative à la fois sur l’ensemble de la stack et dans leurs domaines d’expertise respectifs »
Le premier diagramme de l’article est inexact ou assez daté. Sur les ordinateurs modernes, la plupart des lignes PCIe sont connectées directement au hub I/O du CPU ou à la zone Uncore, sans passer par un PCH séparé comme auparavant
C’est une évolution importante à la fois pour le débit I/O et pour la latence. À part ça, c’est un excellent article, et il montre bien qu’au final, tout est une file d’attente
Je préciserai dans la légende de l’image qu’il s’agit de l’architecture de cette époque