Périphériques d’E/S et latence
(planetscale.com)- Le stockage non volatil a évolué de la bande au HDD, au SSD puis au stockage réseau cloud, mais la localisation et la disposition des données continuent de déterminer la latence d’E/S
- Les lecteurs de bande excellent en lecture/écriture séquentielle, mais lire des données éloignées peut prendre plusieurs dizaines de secondes, ce qui les rend inadaptés aux bases de données transactionnelles à fort trafic
- Les HDD ont fortement réduit la latence par rapport aux bandes, mais à cause des plateaux rotatifs et du déplacement de la tête, la lecture aléatoire se situe généralement autour de 1 à 3 ms, avec de fortes variations selon l’ordre des requêtes
- Les SSD fonctionnent avec de la mémoire flash NAND sans pièces mécaniques, ce qui permet de faire descendre la lecture aléatoire jusqu’à 16 μs, mais la disposition des données reste cruciale à cause du parallélisme et du garbage collection
- La séparation stockage/compute dans le cloud facilite la montée en charge et la gestion des pannes, mais ajoute des allers-retours réseau et des limites d’IOPS ; PlanetScale Metal cherche à réduire ce coût avec des SSD NVMe en attachement direct et de la réplication
Les bases qui déterminent la latence du stockage
- Le stockage non volatil conserve les données même lorsque l’alimentation est coupée, et sert de fondation pour stocker des données comme les photos, les e-mails, les soldes bancaires ou les dossiers médicaux
- Les stockages volatils comme les registres CPU, le cache CPU et la RAM sont plus rapides, mais nécessitent une alimentation continue
- Les performances du stockage ne dépendent pas seulement de la capacité, mais aussi de la manière d’atteindre les données, de l’unité de lecture/écriture, de la mise en file, du parallélisme et de l’éventuelle présence d’un aller-retour réseau
- Avec le lancement de PlanetScale Metal, PlanetScale a indiqué que Metal exécute des bases de données cloud sur des disques NVMe locaux plutôt que sur du stockage connecté au réseau
Stockage sur bande : fort en accès séquentiel, faible en accès aléatoire
- Les ordinateurs utilisent des lecteurs de bande comme stockage numérique non volatil depuis les années 1950
- Une cartouche de bande est composée de plusieurs pistes et de nombreuses cellules, l’état de polarisation magnétique de chaque cellule représentant des données binaires
- Quand on insère la cartouche dans un lecteur et qu’on fait défiler la bande avec un moteur, la tête d’E/S lit les données qui passent
- Si l’emplacement à lire ou écrire est proche de la tête, c’est rapide ; s’il est éloigné, la latence augmente fortement
- Même dans les systèmes de bande modernes, il peut être nécessaire de dérouler plusieurs centaines de mètres pour atteindre des données lointaines
- Dans ce cas, la lecture peut prendre plusieurs dizaines de secondes
- Avec le même nombre d’opérations de lecture/écriture, des données dispersées demandent bien plus de temps qu’une disposition séquentielle
- L’exemple de l’article montre qu’une série de lectures/écritures dispersées peut prendre environ 7 fois plus de temps pour la même charge
- La bande a une mauvaise latence en lecture/écriture aléatoire, mais reste adaptée aux longues lectures/écritures séquentielles
- Son coût par Go est inférieur à celui des SSD et des HDD, et sa durée de conservation est longue
- Le CERN gère plus de 400 Po de données dans un entrepôt de stockage sur bande
- AWS propose également un service d’archivage sur bande
- La bande n’est pas adaptée aux bases de données transactionnelles à fort trafic
HDD : le compromis des disques rotatifs et de la mise en file des commandes
- Un HDD stocke les données non pas sur une bande, mais sur des plateaux métalliques circulaires
- Les plateaux tournent rapidement dans un boîtier ; l’exemple donné cite 7 200 RPM comme vitesse courante
- Les pistes d’un HDD sont circulaires, et un seul disque peut contenir plus de 100 000 pistes
- Chaque piste comprend des centaines de milliers de pages, et chaque page contient environ 4 KB de données
- Le HDD aligne la position de lecture/écriture par déplacement de la tête et rotation du plateau
- Contrairement à une bande, tous les bits de la surface restent accessibles en permanence
- Il n’est pas nécessaire de faire défiler la bande jusqu’à ce que les données voulues apparaissent
- Une lecture aléatoire typique peut être effectuée en 1 à 3 ms
- L’ordre des requêtes a un impact majeur sur les performances
- Les lectures/écritures fortement séquentielles se terminent rapidement
- Même avec 6 opérations identiques, si leur ordre est mélangé, le temps d’attente augmente jusqu’à ce que le plateau revienne à la bonne position
- Les disques magnétiques prennent en charge la mise en file des commandes depuis longtemps
- SCSI propose ce type de fonctions depuis les années 1980, et SATA depuis les années 2000
- L’OS peut envoyer plusieurs commandes afin qu’elles soient exécutées en parallèle ou dans un ordre différent
- Le contrôleur du disque peut exploiter une file de tâches pour planifier les lectures/écritures en fonction de la structure du disque
- Les HDD ont amélioré la situation par rapport aux bandes, mais peuvent encore rester lents, en particulier pour les lectures/écritures aléatoires
SSD : les variables de performance qui subsistent sans pièces mécaniques
- Les SSD, ou stockage flash, ont été inventés dans les années 1980, mais ne sont devenus grand public qu’à partir des années 2000
- Les SSD ne dépendent pas de pièces mécaniques pour lire les données
- Ils utilisent des transistors non volatils appelés mémoire flash NAND
- Les 1 et les 0 sont lus, écrits et effacés sous forme de signaux électriques, sans déplacement de pièces physiques
- Un SSD se compose d’une ou plusieurs targets, chaque target contenant plusieurs blocks, eux-mêmes composés de plusieurs pages
- Un SSD lit et écrit à l’échelle de la page
- Même si seule une partie des données est nécessaire, l’unité de requête du disque reste la page
- Dans la configuration d’exemple, si une page fait 4096 bits, un block 16K pages, un target 16K blocks, et l’appareil 8 targets, on obtient
4k * 16k * 16k * 8 = 8,796,093,022,208bits, soit 8 To - La lecture aléatoire sur SSD peut descendre jusqu’à 16 μs selon le modèle
- Même sans pièces mécaniques, la disposition des données reste importante
- Parmi les facteurs de performance d’un SSD figurent le parallélisme et le garbage collection
Parallélisme des SSD : la répartition entre targets change le débit
- En général, chaque target dispose d’une ligne dédiée reliée à l’unité de contrôle
- Chaque ligne traite les lectures/écritures, mais ne peut transférer qu’une seule page à la fois
- Le transfert d’une page est très rapide, mais prend tout de même un certain temps
- Si 8 écritures sont réparties sur 4 targets, 4 lignes peuvent être utilisées en parallèle et l’écriture se fait en deux tranches de temps
- Si les 8 écritures se concentrent sur un seul target, une seule ligne est utilisée et les autres restent inactives
- L’ordre des lectures/écritures et la disposition des données influencent donc aussi les performances des SSD
- Lorsqu’on conçoit un logiciel comme MySQL, il faut prêter attention à la structure de stockage des données et à leur disposition sur disque
Garbage collection sur SSD : le coût de l’effacement avant écriture
- Une page SSD peut être lue plusieurs fois, mais une page déjà écrite ne peut pas être écrasée par de nouvelles données tant que les anciennes n’ont pas été explicitement effacées
- On ne peut pas effacer une page individuellement ; il faut effacer tout le block
- Les SSD ont besoin d’algorithmes internes pour gérer les pages empty, in-use et dirty
- Une dirty page est une page qui a été écrite, dont les données ne sont plus nécessaires, et qui est prête à être effacée
- Il faut parfois réorganiser les données pour accepter de nouvelles écritures ; l’algorithme qui gère cela est le garbage collector
- S’il reste suffisamment de pages inutilisées, les nouvelles données peuvent être écrites directement
- S’il manque de pages inutilisées et qu’il y a beaucoup de dirty pages, il faut d’abord lancer le garbage collection
- Dans l’exemple, 2 pages non dirty sont déplacées ailleurs afin de pouvoir écrire 5 nouvelles pages
- Ensuite, toutes les pages de ce target passent à l’état dirty pour pouvoir être effacées
- Ces étapes supplémentaires peuvent fortement ralentir les performances en écriture
- Sur un SSD très sollicité, avec beaucoup de lectures, d’écritures et de suppressions, le garbage collection peut ralentir les autres opérations
Ce que le cloud a changé : séparation du stockage et du compute
- Le passage de la bande au HDD puis au SSD a fortement amélioré les performances durables des E/S
- Le passage au cloud a introduit un autre changement dans les performances d’E/S
- AWS est présenté comme le service qui, depuis son lancement en 2006, a fortement accéléré la migration vers le cloud
- Dans un environnement cloud, l’utilisateur loue des serveurs virtualisés exécutés sur du matériel arbitraire dans de grands datacenters
- Un serveur peut s’arrêter à tout moment pour de multiples raisons : panne matérielle, remplacement, coupure réseau, etc.
- Construire un système sur une infrastructure cloud louée impose donc de mieux tolérer des pannes plus fréquentes
- Ces contraintes, combinées au besoin de volumes de stockage extensibles dynamiquement, ont conduit à la séparation du storage et du compute
Les avantages et le coût du stockage connecté au réseau
- Traditionnellement, les serveurs, desktops, laptops et téléphones ont un stockage non volatil directement attaché
- On utilise pour cela des câbles SATA, des interfaces PCIe, ou une intégration dans le même SoC
- Le stockage en attachement direct est rapide, mais présente deux limites
- Si le serveur tombe, les données deviennent elles aussi indisponibles
- La taille du stockage est fixe
- Les serveurs applicatifs s’accommodent généralement bien d’environnements éphémères, et une grande partie de leur travail se fait en mémoire, donc ce problème est limité
- Une base de données ne doit pas perdre ses données si le serveur tombe, et la taille des données peut augmenter rapidement jusqu’à atteindre les limites du stockage
- De nombreux fournisseurs cloud permettent donc d’attacher aux instances de compute un stockage réseau configurable séparément
- La configuration par défaut d’EC2 consiste généralement à attacher un volume de stockage réseau EBS
- Des services de base de données comme Amazon RDS, Amazon Aurora, Google Cloud SQL et PlanetScale reposent aussi sur des systèmes où le compute et le storage sont séparés par le réseau
- Cette approche permet d’ajuster dynamiquement la taille du volume de stockage en fonction de l’évolution des données
- Si le serveur tombe, les données restent en sécurité et peuvent être rattachées à un autre serveur
- En contrepartie, elle introduit un coût de performance : l’aller-retour réseau et les limites d’IOPS
Différence de latence entre NVMe local et stockage réseau
- Un SSD NVMe en attachement direct utilise la spécification d’interface Non-Volatile Memory Host Controller Interface pour fournir des vitesses d’E/S et une bande passante élevées
- L’aller-retour entre le CPU et la RAM est donné à environ 100 ns
- L’aller-retour entre le CPU et un SSD NVMe localement connecté est d’environ 50 000 ns, soit 50 μs
- Un volume de stockage connecté au réseau nécessite un court aller-retour réseau à l’intérieur du datacenter
- Pour un stockage réseau comme EBS, le temps d’aller-retour est présenté comme étant d’environ 250 000 ns, soit 250 μs ou 0,25 ms
- Même avec le même SSD moderne, la connexion réseau allonge donc d’un ordre de grandeur le temps de traitement de chaque requête de lecture/écriture
- Sur de gros flux d’E/S séquentiels, on peut réduire l’impact négatif, mais pas l’éliminer
- Le stockage réseau ajoute donc une latence supplémentaire à chaque accès au système de stockage
Limites d’IOPS et différence avec le stockage en attachement direct
- De nombreux fournisseurs cloud, dont AWS et Google Cloud, limitent dans le modèle de stockage réseau le nombre d’opérations d’E/S pouvant transiter sur le lien
- Une instance Amazon GP3 EBS autorise par défaut 3 000 IOPS
- Il est possible de monter plus haut, mais avec un coût supplémentaire
- Les anciens volumes GP2 EBS fonctionnaient en accumulant un pool d’IOPS pour autoriser des bursts occasionnels
- Quand le stockage est directement attaché à l’instance de compute, il n’existe pas de limitation artificielle du nombre d’opérations d’E/S
- En attachement direct, on peut lire et écrire autant que le matériel le permet
Préserver la durabilité et l’extensibilité
- Pour le problème n°1 des SSD en attachement direct, la durabilité des données, on peut recourir à la réplication
- L’approche classique consiste à désigner un serveur primary qui reçoit toutes les écritures, puis 2 serveurs supplémentaires ou plus qui répliquent les données
- Si les données existent à trois endroits, la probabilité de perte diminue fortement
- Avec l’hypothèse d’un taux de panne serveur mensuel de 1 % :
- sur un seul serveur, la probabilité de perte de données est de 1 % par mois
- sur trois serveurs, elle tombe à
1% × 1% × 1% = 0.0001%, soit une chance sur un million
- PlanetScale détecte automatiquement les nœuds défaillants, les remplace et sauvegarde fréquemment les données des bases de manière fiable
- Le problème n°2, l’extensibilité des disques, demande davantage d’intervention manuelle
- Il faut de la supervision et des alertes quand un disque approche de sa limite de capacité
- Il faut aussi des outils permettant d’augmenter facilement la capacité quand nécessaire
L’approche de PlanetScale Metal
- Metal propose des clusters de bases de données utilisant des SSD NVMe en attachement direct
- Chaque instance de base de données s’exécute sur un SSD NVMe en attachement direct
- Un cluster Metal est composé par défaut d’un primary et de 2 replicas
- Les clusters de bases de données pris en charge sont Vitess ou Postgres
- Lorsqu’on atteint la limite de stockage, il est possible de passer en quelques clics à un serveur équipé d’un disque plus grand
- En interne, un nouveau nœud est lancé puis les données sont migrées de l’instance existante vers la nouvelle, avec un processus en zero downtime
- Les bases de données Metal n’ont pas de plafond artificiel d’IOPS
- Les utilisateurs peuvent exécuter des opérations d’E/S à faible latence et exploiter autant que le matériel le permet, sans payer les classes d’IOPS coûteuses du fournisseur cloud ni subir de throttling
1 commentaires
Avis de Hacker News
Je suis l’auteur du blog. J’ai vraiment pris beaucoup de plaisir à écrire cet article, et c’est de loin le plus complexe que j’aie produit jusqu’ici.
J’ai littéralement écrit des milliers de lignes de JavaScript pour créer les visualisations interactives, donc j’espère que tout le monde les trouvera intéressantes.
En revanche, la formulation « 1 sur 1 million » à propos de la durabilité me semble trop pessimiste si l’on tient compte du fait que la durée de panne, avant qu’un nouveau serveur arrive et que les données soient répliquées à nouveau, est courte.
Par exemple, si la restauration prend 10 minutes, même en supposant que trois serveurs tombent forcément en panne une fois par mois chacun, la probabilité qu’ils tombent tous en panne en même temps me semble déjà de l’ordre de 1 sur 2 millions ; et si la probabilité de panne mensuelle est de 1 %, la probabilité que les trois pannes se chevauchent devient extrêmement faible.
Je le précise parce que, avec 1 million de clients, 1 sur 1 million n’est pas un chiffre si bon que ça.
Je sais bien que le temps passé à taper au clavier et celui passé à y réfléchir sont assez différents.
Le sujet m’est très familier, donc je n’ai rien à ajouter sur le fond, et en le parcourant ça a l’air très bien. Mais je suis en train de concevoir des animations pour mon propre blog, et plusieurs bibliothèques que j’ai essayées récemment ne m’ont pas plu.
Cela fait un moment que je pousse la combinaison SQLite+NVMe. Personnellement, j’y vois un nouveau pattern qui permet d’aller beaucoup plus loin que d’habitude, et dans certains cas de tenir jusqu’au bout sans scaling horizontal.
En matière de performances, la latence est reine, surtout lorsqu’il faut traiter des éléments en série. Faire tourner SQLite sur du NVMe apporte un avantage de latence qu’aucun autre fournisseur ne peut offrir.
Pour la plupart des cas d’usage réalistes, je ne pense pas non plus que l’exécution en mémoire soit tellement meilleure qu’un stockage persistant sur NVMe.
Sur un seul hôte, c’est peut-être un peu plus rapide, mais dès que l’on passe d’un serveur web à deux, et que les deux doivent écrire dans la base de données, on dirait que l’on se complique soi-même la vie.
Dire que la latence est importante peut aussi prêter à confusion. Sans cohérence, les performances n’ont pas de sens, et dès que l’on a plusieurs serveurs web, il faut résoudre soi-même cette cohérence.
En plus, la latence de la base de données est généralement bien inférieure à un aller-retour Internet, et cette latence Internet elle-même est faible comparée à la « latence » liée à l’attente du chargement des ressources d’une page, comme les images ou les bibliothèques de code.
Dès le départ, il faut éviter autant que possible les requêtes de base de données en série, utiliser des jointures quand c’est possible, et, quand ça ne l’est pas, lancer autant que possible les requêtes de manière asynchrone et simultanée afin qu’elles s’exécutent en parallèle.
Pour éviter les problèmes d’écritures parallèles, au-delà du fait de configurer un mode de fonctionnement spécifique et un peu rustique, on peut utiliser dans l’application l’astuce d’un thread unique dédié aux écritures.
Cela rend généralement un code parallèle déjà complexe un peu plus complexe encore. Avec un seul thread d’écriture, SQLite fonctionne vraiment très bien.
fsync()sur un fichier d’un système de fichiers ext4 sur un ordinateur de bureau, on mesure encore une latence de 1 à 2 ms, même sur un disque NVMe.Sur un système plus récent, c’était environ 800 µs.
La quantité d’informations était tellement bonne que j’ai complètement oublié, en lisant, qu’il s’agissait d’une promotion produit. Les visualisations et l’interaction sont excellentes.
L’animation des entrées/sorties disque m’a fait penser à Melvin Kaye.
Même lorsque le lent Flexowriter avait besoin d’un délai entre les caractères en sortie, Mel n’utilisait pas de boucle d’attente.
À la place, il ajustait la position des instructions sur le tambour pour que, chaque fois que l’instruction suivante devenait nécessaire, la tête de lecture vienne tout juste de la dépasser ; le tambour devait alors faire un tour complet de plus pour retrouver l’instruction suivante.
https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...
Metal a vraiment l’air génial, mais quand j’ai utilisé les SSD locaux d’instance de GCP dans mon précédent emploi, nous avons eu de sérieux problèmes de fiabilité, avec par exemple des blocs du périphérique qui perdaient des données.
Je me demande si la situation a changé depuis, et quels types de machines vous utilisez.
À l’époque, la solution de contournement était celle-ci : https://discord.com/blog/how-discord-supercharges-network-di...
Cela dit, nous exploitons un système redondant avec réplication semi-synchrone MySQL, de sorte que toutes les écritures soient persistées sur deux machines dans des zones de disponibilité différentes avant d’être confirmées au client.
Un opérateur Kubernetes et le processus
vtorcde Vitess fonctionnent ensemble pour détecter et remplacer activement les réplicas en échec ou suspects.Sur GCP, nous avons obtenu les meilleurs résultats avec des machines n2d-highmem, et sur AWS nous utilisons à peu près tous les types de dernière génération disposant d’un stockage d’instance.
Très bon article. En général, le stockage cloud a aussi le problème d’être particulièrement lent
Cela a déjà été traité ailleurs, mais cet article résume bien le problème : http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
Récemment, https://github.com/feldera/feldera a ajouté la prise en charge du stockage d’index incrémentaux sur S3/stockage objet, mais NVMe était pris en charge depuis plus longtemps en raison des avantages évidents de performance évoqués dans l’article précédent
Ce serait bien que quelqu’un vienne bousculer ce domaine avec une meilleure manière de proposer le service
Il y a un aspect du stockage distribué qui n’est pas suffisamment évalué dans cet article
Premièrement, certains systèmes n’intègrent pas la réplication par défaut. Un cluster Cassandra ou MySQL peut faire de la réplication maître-esclave, mais beaucoup de systèmes ne le peuvent pas
Deuxièmement, utiliser du stockage NVMe dans le cloud rend l’exploitation beaucoup plus difficile, car il faut gérer les fenêtres de maintenance et les drains déclenchés par le cloud
Si vous ne vous intégrez pas à ces systèmes pour évacuer les données vers d’autres nœuds, elles disparaissent
En séparant stockage et calcul, l’opérateur cloud peut vider et déplacer le calcul quand il en a besoin ; les données sont indépendantes du calcul, et comme l’opérateur cloud gère aussi ce système de données et les drains, il peut ajuster le placement des workloads sans intervention du client
Un stockage répliqué connecté au réseau, qui ressemble à une API de système de fichiers « local », est un moyen puissant d’apporter de la durabilité à des systèmes qui, comme le nôtre, n’ont pas de réplication intégrée
Vraiment excellent, et PlanetScale Metal a aussi l’air assez solide. J’aime particulièrement voir la latence chuter fortement dans la release : https://planetscale.com/blog/upgrading-query-insights-to-met...
Pendant des années, je n’ai pas compris pourquoi les bases de données répliquées s’accrochaient toujours à EBS et acceptaient cette latence. Puisqu’il y a déjà de la réplication, pourquoi ne pas utiliser franchement des disques locaux ?
Dans une organisation précédente, quand nous exploitions Elasticsearch comme stockage temporaire de logs/indicateurs, j’ai proposé de faire cela, car les exigences de fiabilité n’étaient pas très élevées, mais je n’ai pas réussi à convaincre, et nous avons finalement utilisé AWS Elasticsearch, qui était pire
Je sais que la capacité des disques locaux est finie, mais le ratio cœurs/mémoire/disque me semble suffisant pour la plupart des cas d’usage. Il existe aussi beaucoup d’instances à disques locaux avec des ratios différents, donc on peut trouver un bon équilibre
On pourrait même implémenter du stockage hot/cold avec des instances à disques durs locaux de plus de 20 To
Je tiens à féliciter chaleureusement l’équipe PlanetScale, qui fait enfin quelque chose qui a du sens. Même AWS ne fait pas tourner Elasticsearch sur des disques locaux ; imaginez plutôt faire tourner ClickHouse ou Cassandra entièrement sur des disques locaux
Le problème central était que les disques sont effacés après un événement stop-start. Même si le reste du cluster va bien et qu’il existe un réplica disponible, SQL Server ne sait pas gérer cela automatiquement
Comme il ne restaure pas automatiquement un nœud réinitialisé, les scripts et les tests nécessaires pour contourner le problème sont difficiles à assumer en production, sauf pour les organisations les plus audacieuses et compétentes
Nous exploitons des centaines de clusters ClickHouse avec ce modèle. Redimensionner pour résoudre des problèmes de performance est beaucoup plus fréquent que le faire à cause de pannes
Par exemple, si un tenant rencontre un problème de performance un dimanche matin aux États-Unis, la solution la plus simple est de passer temporairement à une VM plus grosse pour le week-end, puis de laisser l’équipe principale analyser la cause racine le lundi matin
Le coût supplémentaire est faible, et cela permet d’éviter un burn-out des employés, bien plus coûteux
Vraiment excellent article, et la visualisation des écritures aléatoires est très bien faite
J’ai quelques questions, peut-être idiotes, sur les limites d’IOPS du stockage connecté au réseau
Premièrement, je me demande si la limite d’« IOPS » est bien une limitation de débit sur un type précis de trafic réseau, à savoir le trafic vers et depuis un volume EBS. En gros, je demande si « IOPS » signifie « trafic réseau du volume EBS »
Deuxièmement, je me demande si cette approche permet de réduire les coûts. Si oui, est-ce dû à une étrange opportunité d’arbitrage tarifaire chez AWS, ou à des gains d’efficacité liés au fait de moins utiliser le réseau EBS ?
Il semble clair que placer le stockage et le calcul sur la même machine apporte structurellement l’avantage de supprimer un saut en termes de latence, mais j’aimerais savoir si c’est aussi avantageux en débit par dollar
Je vois plutôt cela comme un autre modèle. Un volume EBS n’est pas une partie d’une carte physique branchée sur un bus PCIe, mais une part dans un vaste système distribué composé de nombreux disques physiques, plus proche d’un SAN disposant d’une capacité réseau dédiée vers et depuis le calcul
Cela peut permettre d’économiser, mais au final c’est un ensemble de compromis