Construire et exploiter l’immense système de stockage qu’est S3
(allthingsdistributed.com)- Amazon S3 est parti, lors de son lancement le 14 mars 2006, d’un stockage objet basé sur une API HTTP REST, pour devenir un service à grande échelle exploité conjointement par des centaines de microservices et plusieurs équipes dédiées
- L’échelle de S3 ne s’explique pas seulement par le code : c’est un système où disques durs, firmware, datacenters, organisation d’exploitation et workloads clients s’imbriquent et évoluent en permanence
- Les HDD ont fortement progressé en capacité et en efficacité coût, mais leurs performances en accès aléatoire restent contraintes par des limites mécaniques ; S3 traite donc comme un problème central la gestion de la chaleur I/O et le placement des données sur des millions de disques
- La réplication et l’erasure coding basé sur Reed-Solomon améliorent non seulement la durabilité, mais contribuent aussi à gérer les performances et la tail latency en détournant les requêtes des disques surchargés
- L’exploitation de S3 est conçue pour maintenir à la fois un développement rapide et des exigences élevées de durabilité grâce aux revues de durabilité, à ShardStore basé sur Rust, à une vérification formelle légère et à l’ownership au niveau des équipes
Voir S3 comme un immense système de service
- S3 est un service de stockage objet composé d’une API HTTP REST, d’une flotte front-end, d’un service d’espace de noms, d’une flotte de stockage basée sur des disques durs et d’une flotte de tâches en arrière-plan
- Chaque grand composant correspond à un domaine distinct au sein de l’organisation S3, avec ses responsables et plusieurs équipes ; les composants plus internes disposent eux aussi de leurs propres flottes et équipes
- Aujourd’hui, S3 est composé de centaines de microservices, et les interactions entre équipes ressemblent à des contrats au niveau des API
- Si la modularité est mal conçue, les interactions entre équipes peuvent elles aussi devenir inefficaces et maladroites ; les corriger fait donc partie du processus de conception conjointe du logiciel et des équipes
Le système, ce n’est pas le logiciel, mais l’ensemble du service
- Les clients de S3 n’achètent pas un logiciel packagé, mais une expérience de service, avec l’attente d’une qualité continue et prévisible
- Les frontières du système S3 ne s’arrêtent pas au code
- Le code exécuté près des disques
- Les techniciens qui installent de nouveaux racks de stockage dans les datacenters
- Les applications clientes qui optimisent leurs performances
- Le matériel, la finance et les organisations d’ingénierie
- S3 ressemble davantage à un système vivant où logiciel, matériel et humains grandissent et changent ensemble en continu
- Un simple schéma d’architecture sur tableau blanc masque les services étendus et l’échelle à l’intérieur de chaque boîte, ce qui conduit à sous-estimer le système réel
L’impact des limites physiques des HDD sur la conception de S3
- S3 est un très grand système qui utilise des millions de disques durs, et les caractéristiques des HDD constituent l’une des contraintes centrales de sa conception
- Depuis l’IBM 350 disk storage unit de 1956, les HDD ont énormément évolué
- Le plus grand HDD mentionné aujourd’hui est le Western Digital Ultrastar DC HC670 26 To
- Depuis RAMAC, la capacité a été multipliée par 7,2 millions
- La taille physique a été divisée par 5 000
- Le coût par octet, corrigé de l’inflation, a été divisé par 6 milliards
- Mais le seek time ne s’est amélioré que d’un facteur 150, et les performances de lecture/écriture aléatoires restent autour de 120 opérations par seconde
- Ce niveau de performance était déjà similaire au lancement de S3 en 2006, et ne différait pas beaucoup de celui d’une décennie plus tôt
- Un HDD étant un dispositif mécanique, il faut attendre le déplacement du bras et la rotation des plateaux ; les performances d’accès aléatoire ne progressent donc pas au même rythme que la capacité
- Les feuilles de route de l’industrie indiquent un chemin vers des HDD de 200 To dans les dix prochaines années ; à ce niveau, en supposant un accès aléatoire équitable à l’ensemble des données, cela revient à n’autoriser qu’1 I/O par seconde pour 2 To de données sur disque
- S3 n’utilise pas encore de disques de 200 To, mais prévoit d’utiliser ces disques ainsi que toutes les tailles intermédiaires
Gestion de la chaleur : placement des données et performances
- Dans S3, la heat désigne le nombre de requêtes arrivant sur un disque à un instant donné
- Une mauvaise gestion de la chaleur concentre les requêtes sur certains disques et crée des hotspots, dégradant les performances globales des requêtes qui dépendent de ces disques
- Un hotspot ne met pas immédiatement le système à l’arrêt ; il crée plutôt des files d’attente et détériore l’expérience client
- Les requêtes qui attendent un disque occupé sont retardées
- Ce retard est amplifié vers les couches supérieures de la pile de stockage via des I/O dépendantes, comme les consultations de métadonnées ou l’erasure coding
- Certaines requêtes subissent une latence élevée : ce sont des stragglers
- Les hotspots sur des HDD individuels se traduisent par de la tail latency et, s’ils ne sont pas traités, peuvent affecter la latence de l’ensemble des requêtes
- S3 ne peut pas savoir, au moment où les données sont écrites, quand ni comment elles seront consultées ; les décisions de placement à l’écriture sont donc difficiles
- À petite échelle, prévoir et gérer la heat I/O est très difficile, mais l’échelle et la multitenance de S3 font apparaître d’autres propriétés
- Les workloads individuels sont souvent inactifs la plupart du temps puis connaissent soudainement des pics, mais en agrégeant des millions de workloads, la demande globale devient lisse et prévisible
- Au-delà d’une certaine échelle, il devient difficile, voire impossible, pour un workload individuel d’influencer le pic global
La réplication et l’erasure coding traitent à la fois durabilité et performances
- Les mécanismes de redondance d’un système de stockage protègent les données contre les pannes matérielles, mais contribuent aussi à la répartition de la chaleur
- La réplication place des copies sur plusieurs disques afin de tolérer les pannes de disque et de permettre de servir les requêtes de lecture depuis n’importe laquelle des copies
- Du point de vue de la capacité, la réplication est coûteuse, mais du point de vue des I/O en lecture, elle est efficace
- Pour éviter de payer le surcoût de réplication sur toutes les données, S3 utilise aussi l’erasure coding
- Un exemple de méthode utilise des algorithmes comme Reed-Solomon
- L’objet est découpé en k identity shards
- m parity shards supplémentaires sont générés
- Tant que k shards parmi les k+m au total sont disponibles, l’objet peut être lu
- Cette approche réduit le surcoût de capacité tout en tolérant le même nombre de pannes
Stratégie de placement des données et isolation des workloads clients
- Les mécanismes de redondance divisent les données en plus de fragments que le nombre nécessaire pour les lectures, ce qui permet d’acheminer les requêtes en évitant les disques surchargés
- S3 place largement les nouveaux objets sur l’ensemble de la flotte de disques afin de réduire davantage la chaleur
- Un objet individuel peut être encodé sur des dizaines de disques, et des objets différents sont placés sur des ensembles de disques différents
- Répartir les objets de chaque bucket sur de nombreux disques apporte deux avantages
- La part des données d’un client sur un disque donné devient très faible, ce qui rend difficile pour un workload individuel de créer un hotspot sur un disque précis
- Un workload individuel peut burster jusqu’à une échelle de disques qu’il serait difficile et coûteux de construire dans un système indépendant
- Le burst d’un client en analyse génomique effectuant une analyse parallèle depuis des milliers de fonctions Lambda peut être servi par plus d’un million de disques individuels
- Aujourd’hui, S3 compte des dizaines de milliers de clients dont les buckets sont répartis sur des millions de disques
- Ce qui distingue S3 n’est pas seulement l’échelle du système de stockage lui-même, mais le fait que l’échelle d’agrégation des clients et des workloads peut changer la nature même du système
Revues de durabilité et garde-fous
- Amazon accorde de l’importance à permettre aux ingénieurs et aux équipes d’échouer rapidement et en sécurité
- Pour fournir un stockage très durable tout en avançant vite, S3 utilise un processus de durability review
- La durability review n’est pas un mécanisme intégré au modèle statistique des 11 9, mais elle est traitée comme importante dans l’exploitation de S3
- Lorsqu’un changement d’ingénierie peut affecter l’état de durabilité, une durability review est réalisée
- Ce processus emprunte l’idée de threat model à la recherche en sécurité
- Rédiger un résumé du changement
- Établir une liste complète des menaces
- Décrire comment le changement résiste à ces menaces
- La durability review joue deux rôles
- Amener l’auteur et les relecteurs à réfléchir de manière critique aux risques contre lesquels il faut se protéger
- Séparer les risques et les contre-mesures afin de pouvoir discuter de chacun indépendamment
- Lorsqu’il s’agit de trouver des contre-mesures, on préfère des garde-fous simples et robustes qui bloquent de larges familles de risques plutôt que d’associer une mitigation spécifique à chaque risque détaillé
ShardStore, Rust et vérification formelle légère
- Il y a quelques années, S3 a lancé un projet de réécriture complète de la couche la plus basse de la pile de stockage, c’est-à-dire la partie qui gère les données sur chaque disque individuel
- Cette nouvelle couche de stockage s’appelle ShardStore
- L’un des garde-fous adoptés lors de la reconstruction de ShardStore est la vérification formelle légère
- L’équipe a déplacé le langage d’implémentation vers Rust afin de détecter les bugs plus tôt
- Exploiter la sûreté de typage
- Exploiter le support structuré du langage
- Écrire des bibliothèques qui étendent la sûreté de typage aux structures on-disk
- Côté vérification, un modèle simplifié de la logique de ShardStore a été écrit en Rust et placé dans le même dépôt que l’implémentation de production réelle de ShardStore
- Ce modèle sert de spécification exécutable en retirant la complexité de la couche de stockage on-disk réelle et des HDD
- Le modèle représentait environ 1 % de la taille du système réel, mais permettait des tests d’un niveau irréaliste face à un disque dur de 120 IOPS
- Ce travail a aussi été publié sous forme d’article SOSP, Using lightweight formal methods to validate a key-value storage node in Amazon S3
- Ensuite, des outils et des techniques existantes comme le property-based testing ont été utilisés pour vérifier que le comportement de l’implémentation correspondait à la spécification
- Le point essentiel est d’avoir industrialisé des techniques de recherche en vérification formelle sous forme de code maintenable par des ingénieurs ordinaires et d’outils exécutés à chaque commit
- Les garde-fous de vérification ont donné à l’équipe la confiance nécessaire pour développer plus vite, et ont continué à être maintenus même après l’arrivée de nouveaux ingénieurs
Traiter les problèmes de passage à l’échelle des équipes et des individus par l’ownership
- Chez Amazon, l’ownership désigne le fait de rendre clairement responsable une personne ou une équipe unique de la réussite d’une tâche ou d’un service jusqu’au bout
- Dans S3, pour avancer vite tout en maintenant des standards élevés de qualité, les équipes doivent être propriétaires
- Elles possèdent les contrats d’API avec les autres systèmes
- Elles sont responsables de la durabilité, des performances et de la disponibilité
- Si un bug inattendu affecte la disponibilité, elles le corrigent même à 3 h du matin
- Après correction du bug, elles améliorent le système pour éviter que la même chose ne se reproduise
- L’ownership implique une grande responsabilité, mais exige aussi de la confiance
- Pour qu’une personne ou une équipe possède un service, elle doit disposer d’une marge de décision sur la manière de le fournir
- L’expérience des projets de recherche en master ou doctorat montre aussi que les étudiants s’investissent plus profondément lorsqu’ils sentent qu’une idée est la leur et qu’ils peuvent la développer eux-mêmes
- Dans un rôle d’ingénieur très senior, il est plus efficace de bien définir le problème et d’aider l’équipe à s’approprier la solution que de présenter directement une solution comme si on la déployait soi-même
- Pour un problème admettant plusieurs solutions, permettre de choisir la solution appropriée revient à donner à quelqu’un l’ownership de la solution
Conclusions tirées de S3
- L’échelle technique de S3 n’est pas simplement celle d’un petit système devenu plus grand : ses workloads, sa structure et son mode d’exploitation sont fondamentalement différents
- Le « système » inclut non seulement le logiciel, mais aussi l’exploitation du service, l’organisation opérationnelle et le code client qui fonctionne avec ce service
- L’organisation fait elle aussi partie du système ; elle possède donc ses propres problèmes de passage à l’échelle et ses propres opportunités d’innovation
- Pour réussir dans un rôle individuel, il faut formuler clairement les problèmes plutôt que les solutions, et aider de fortes équipes d’ingénierie à s’approprier réellement ces solutions
2 commentaires
Commentaires sur Hacker News
L’une des conversations dont je me souviens quand j’étais chez AWS, c’est que même un événement à une chance sur un milliard se produit tous les jours à l’échelle de S3.
Ce qu’on écarterait d’ordinaire parce que c’est trop improbable pour mériter qu’on s’en préoccupe doit impérativement être pris en compte et traité.
Je suis content de voir des approches comme ShardStore, en particulier la vérification formelle et les tests basés sur les propriétés. Les services des générations précédentes avaient beaucoup de bugs, au point de bien illustrer les risques d’une croissance organique, mais ils étaient au moins conçus pour tomber en panne « en sécurité », afin d’éviter les pertes de données, et les ingénieurs S3 étaient obsédés par ce point.
Et S3 n’est pas le seul dans ce cas. Par exemple, lors du Prime Day 2022, DynamoDB est monté à plus de 105 millions de requêtes par seconde rien que pour les workloads d’Amazon : https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
Dans l’article, Andy parle aussi des méthodes formelles légères et de l’adoption de Rust par l’équipe ; à une échelle où même les événements à probabilité extrêmement faible deviennent courants, il faut investir dans plusieurs couches d’outils et de processus pour garantir la correction.
Je lui ai expliqué qu’en atteignant notre objectif de 500k TPS, cela ferait 30 fois par minute, puis je lui ai demandé : « tu veux être d’astreinte cette semaine-là ? ». Dans cette stack, « insister sur les standards les plus élevés » prend un sens très différent de celui qu’on lui donne dans la plupart des organisations.
Heureusement, l’algorithme était bon, et le matériel d’aujourd’hui est aussi beaucoup plus fiable.
J’ai aussi dans un coin de la tête une petite voix un peu cynique, prête à sortir le popcorn si j’ai la chance d’assister aux conséquences de la première grosse collision de hachage cryptographique.
En travaillant dans la génomique, j’ai beaucoup manipulé de dépôts de données à l’échelle du pétaoctet au cours des dix dernières années.
Après avoir utilisé AWS S3, GCP GCS et des systèmes de stockage pour matériel en colocation (Ceph, Gluster, et un système HP dont j’ai effacé le nom de ma mémoire), j’ai développé un profond respect pour l’effort nécessaire à l’exploitation de tels systèmes.
Il est aussi difficile de sous-estimer l’avantage de partager les I/O disque avec une multitude d’autres clients. Je n’avais jamais entendu le terme « heat » employé dans l’article, mais sur un système unique, c’est vraiment difficile à atténuer. Sur notre cluster en colocation, pour gérer correctement les I/O entre de gros jobs, nous avons dû modifier le système de batch afin de traiter les I/O comme une ressource allouable, au même titre que la RAM ou le CPU. S3 et GCP sont très chers, mais leurs performances valent parfois ce prix.
Ce genre d’article, c’est ce que HN a de meilleur.
Du point de vue du stockage cloud, le meilleur client est celui qui stocke énormément de données mais les lit très rarement. C’est un peu comme louer des disques durs, sauf que si l’on ne remplit qu’une partie de chaque disque avec des données « froides », on peut continuer à utiliser toute la capacité d’I/O de ce même disque pour traiter des workloads chauds.
En équilibrant très soigneusement quelles données placer sur quels disques, on peut continuer à exploiter tous les disques même si la majorité des données ne sont pas utilisées. C’est pour cela que le stockage est relativement bon marché et la lecture relativement chère.
Même quand ils prennent S3 en charge, leurs performances sont souvent bien en dessous de ce qui serait possible.
C’est difficile, et je suis désolé que la disponibilité en lecture ne soit que d’environ 99,95 %.
Si S3 avait défini un simple protocole basé sur OAuth2 pour déléguer l’accès en lecture/écriture, on aurait pu construire beaucoup de choses
Le monde a besoin d’un protocole basé sur HTTP permettant à une application d’accéder aux données au nom de l’utilisateur. Google Drive est ce qui s’en rapproche le plus, mais il n’y a qu’un seul fournisseur et il a aussi d’autres problèmes[0]. Dommage que remoteStorage ne se soit pas imposé. J’espère que Solid réussira, mais ça me paraît trop complexe. Mon approche de ce problème est https://gemdrive.io/, mais elle est quasiment à l’arrêt en ce moment, car je me concentre sur d’autres parties de ma stack self-hosted
[0] : https://gdrivemusic.com/help
Aujourd’hui, le faire correctement est extrêmement difficile. J’ai fini par créer toute une application CLI pour résoudre le problème consistant à « émettre des identifiants AWS n’ayant accès qu’à ce bucket précis », mais je n’ai pas envie de demander aux utilisateurs d’installer et d’exécuter ce genre de chose : https://s3-credentials.readthedocs.io/en/stable/
En pratique, ce qu’il faudrait, ce serait une bibliothèque avec un minimum de dépendances côté client, qui monte un répertoire local correspondant au bucket S3 de l’utilisateur
Parce qu’un concurrent pourrait à tout moment débarquer via une interopérabilité hostile
C’est vraiment dommage que tous les projets qui voulaient, ou veulent encore, créer une souveraineté des données utilisateur aient dérivé vers des trucs bizarres liés aux cryptomonnaies
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
Modification : je crois avoir mal lu le commentaire. J’avais compris que l’application voulait déléguer les données utilisateur au client, alors qu’en réalité il semble que l’utilisateur veuille déléguer ses propres données à l’application. Ce sont deux cas d’usage différents
Les spécifications de l’IBM RAMAC indiquent une capacité de stockage de 3,75 Mo et environ 9 200 dollars par téraoctet, mais ça ne peut pas être correct
Si l’on multiplie le coût par la capacité de stockage, le prix du disque revient à 3 centimes
Ce site[1] dit qu’il « stockait environ 2 000 bits par pouce carré et que le prix d’achat était d’environ 10 000 dollars par mégaoctet »
Donc la spécification devrait probablement être de 9 200 dollars par mégaoctet. Dans ce cas, le prix du disque serait de 34 500 dollars, ce qui est plus vraisemblable
[1] : https://www.historyofinformation.com/detail.php?entryid=952
Il s’agissait de 30 millions de bits, et le chiffre ne compte que les 6 bits de données, sans la parité. Mais comme c’était loué 3 000 dollars par mois, il n’y avait pas de coût fixe équivalent à l’achat comptant du disque physique. De ce point de vue, c’est assez proche du modèle de S3
Ce que la plupart des gens ne réalisent pas, c’est que la magie ne réside pas dans le traitement du système lui-même, mais dans le fait de donner l’impression que l’autorisation ne coûte rien
Dans un système distribué, l’autorisation est extrêmement difficile. À l’échelle d’AWS, c’est pratiquement de la magie. AWS dispose d’un modèle d’autorisations riche, et les changements de droits se propagent sans doute à toute l’infrastructure en moins d’une milliseconde, tout en traitant des milliers de milliards de requêtes
Cette partie, ainsi que la journalisation et le rapprochement pour la facturation, sont les deux éléments magiques d’AWS sur lesquels j’aimerais lire des articles
S3 gère le contrôle d’accès différemment des autres services : les permissions sont attachées aux ressources. Probablement pour des raisons de vitesse
L’une des raisons pour lesquelles l’approche bucket/clé est particulière, c’est que ce modèle était déjà en place quand IAM est arrivé
S’il a été conservé par la suite, c’est probablement parce que supprimer le modèle existant aurait risqué de casser la configuration de nombreux clients, ce qui en ferait une tâche difficile
« En tant qu’ingénieur vraiment senior dans l’entreprise, j’ai évidemment des opinions fortes et un agenda technique. Mais quand on interagit avec des ingénieurs, si l’on se contente de leur distribuer des idées, il devient difficile que tout le monde réussisse. Il est beaucoup plus difficile de s’investir dans une idée dont on n’a pas la propriété. Donc, quand je travaille avec une équipe, j’ai adopté une stratégie qui consiste à faire en sorte que mes meilleures idées deviennent des idées proposées par d’autres, plutôt que par moi. Je passe consciemment beaucoup plus de temps à développer le problème et à l’exprimer très clairement qu’à vendre une solution. Il y a souvent plusieurs façons de résoudre un problème, et choisir la bonne, c’est faire en sorte que quelqu’un s’approprie la solution. »
« J’ai appris que, pour vraiment réussir dans mon rôle, je devais me concentrer sur la formulation claire du problème plutôt que de la solution, et trouver des façons d’aider une équipe d’ingénierie solide à réellement s’approprier cette solution. »
J’ai vraiment aimé ce passage. Ça rappelle un peu l’effet Ikea. Pour donner à quelqu’un de l’enthousiasme pour ce qu’il fait, il faut encourager le sentiment de propriété, et une bonne façon d’y parvenir est de faire en sorte que ce soit « son idée ».
Au bout du compte, les gens voient souvent différemment ce qu’est le « problème » dès le départ.
Heureusement, tous les problèmes ne sont pas comme ça. Mais si l’on prend par exemple les discussions autour du « problème du packaging » de Python, il s’agit en réalité d’environ six problèmes différents, que les gens décrivent de façons très différentes, et ce phénomène y apparaît de manière assez néfaste.
Andy Warfield, si tu lis ceci — et tu le lis probablement — j’ai une question. Quand on développe un problème, quelle valeur y a-t-il à esquisser des solutions possibles ? Si l’on formule clairement le problème, quelques solutions possibles viennent naturellement à l’esprit ; cela vaut-il la peine de les partager pour lancer la réflexion de celles et ceux qui pourraient s’en emparer ? Ou vaut-il mieux se concentrer uniquement sur le problème et laisser l’espace des solutions complètement ouvert ?
Et, en plus, existe-t-il des ressources à lire sur la façon de fonctionner de ce type de contributeur individuel très senior ?
À mes oreilles, ça sonne comme : « Manant ! Je n’ai pas le temps de me soucier de tes problèmes. Si tu n’apportes que des problèmes, je ne pourrai pas obtenir une promotion grâce à ton travail. »
Pour pouvoir résoudre un problème, il faut d’abord être capable de le comprendre et de reconnaître qu’il existe.
Dans les situations où il n’y a pas d’autorité ou d’expertise reconnue au préalable — c’est-à-dire le contexte où émergent la plupart des problèmes du quotidien —, si l’on monopolise un canal de discussion à double sens avec une description longue, détaillée et soigneusement structurée du problème, on risque facilement de passer pour quelqu’un qui se contente de parler sans vouloir agir, ou qui ne veut pas chercher une solution avec les autres.
C’est agréable de voir des employés d’Amazon pouvoir parler publiquement du fonctionnement interne de S3.
J’aimerais aussi en savoir plus sur le fonctionnement de Glacier. À ma connaissance, ils n’ont jamais révélé quel était le support de stockage sous-jacent, ce qui a donné lieu à toutes sortes de suppositions : bande, HDD hors ligne, HDD custom, etc.
Mais tout le monde n’est pas d’accord. Cela reste un mystère.
J’aimerais qu’AWS nous raconte tout à ce sujet, ainsi que tout le parcours associé. C’est un objet vraiment fascinant.
Il suffirait qu’un ingénieur se saoule et se mette à trop parler. Dans un domaine autrement plus critique, un militaire du Massachusetts a divulgué des informations de sécurité nationale sur Discord pour impressionner ses amis gamers, et risque une très lourde peine de prison. Je pensais que les détails de Glacier seraient déjà sortis depuis le temps.
« Imaginez une tête de disque dur comme un 747 volant au-dessus d’une pelouse à 75 miles par heure. L’espace d’air entre le dessous de l’avion et le sommet de l’herbe est de l’épaisseur de deux feuilles de papier. Si l’on mesurait les bits du disque en brins d’herbe, la largeur d’une piste serait de 4,6 brins d’herbe, et la longueur d’un bit serait d’un brin d’herbe. Si l’avion survolait la pelouse en comptant les brins d’herbe, il n’en manquerait qu’un seul tous les 25 000 tours de la Terre. »
La partie sur la répartition de charge me rappelle l’époque de KeyMap dans S3 et le moment où l’on essayait de migrer l’implémentation initiale vers ce système.
Ce que nous avons appris, c’est qu’une fois identifié l’objet/la partition/le bucket le plus chaud, on ne peut pas simplement le déplacer et considérer que c’est terminé. Il fallait tout trier. La vraie solution consistait à trier, puis à diviser la charge des partitions de l’hôte en quartiles, et à déplacer les partitions du deuxième quartile vers l’hôte le moins chargé.
Si l’on essayait de déplacer le bucket le plus chaud, c’est-à-dire le premier quartile, on surchargeait les membres restants et cela continuait d’échouer.
Autre effet secondaire : le taux d’erreur est passé d’environ 1 % stable à plusieurs jours sans erreur, ce qui nous a ensuite conduits à durcir nettement les seuils d’alerte. C’était vers 2009, à peu près.
Moi aussi, j’avais un parcours universitaire à l’UM, mais j’ai rejoint S3 au lieu de faire un doctorat. Et ça rime.
S3 est plus qu’un stockage, c’est un standard.
J’aime le fait qu’on puisse utiliser du stockage compatible S3 à plusieurs endroits, généralement avec quelques réserves. Je ne sais pas à quel point le standard est ouvert, ni s’il faut payer Amazon pour pouvoir dire « compatible S3 », mais c’est plutôt chouette.
Par exemple, il y a E2 d’iDrive, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage, Backblaze B2.
Édit : après vérification, il semble qu’Azure n’en ait vraiment pas :-/
Avis Hacker News
En travaillant dans le domaine de la génomique, j’ai géré de nombreux stockages de données de plusieurs pétaoctets au cours des dix dernières années.
Ce que nous pourrions construire si S3 utilisait un protocole basé sur OAuth2 pour déléguer les accès en lecture/écriture.
Gérer l’authentification dans un système distribué est extrêmement difficile.
C’est agréable de voir des employés d’Amazon parler ouvertement du fonctionnement interne de S3.
Le passage qui explique la tête de disque dur en la comparant à un Boeing 747.
En revenant à l’époque de S3 KeyMap, nous avons appris que même après avoir identifié les objets/partitions/buckets les plus chauds, on ne pouvait pas simplement les déplacer pour résoudre le problème.
S3 n’est pas qu’un simple stockage, c’est un standard.