Aufbau und Betrieb eines riesigen Speichersystems namens S3
(allthingsdistributed.com)- Amazon S3 begann als objektbasierter Speicher auf Basis einer HTTP-REST-API, der am 14. März 2006 eingeführt wurde, und ist zu einem groß angelegten Service herangewachsen, der von Hunderten Microservices und mehreren spezialisierten Teams gemeinsam betrieben wird
- Die Größenordnung von S3 lässt sich nicht allein durch Code erklären; es ist ein System, in dem sich Festplatten, Firmware, Rechenzentren, Betriebsorganisation und Kunden-Workloads fortlaufend gegenseitig beeinflussen und verändern
- HDDs haben sich bei Kapazität und Kosteneffizienz stark verbessert, ihre Random-Access-Leistung bleibt jedoch durch mechanische Grenzen beschränkt; deshalb behandelt S3 die Verwaltung von I/O-Hitze und die Datenplatzierung über Millionen von Festplatten als zentrales Problem
- Replikation und Reed-Solomon-basierte Erasure Coding erhöhen nicht nur die Dauerhaftigkeit, sondern helfen auch bei Performance und tail latency, indem Anfragen an überlasteten Festplatten vorbeigeleitet werden
- Der Betrieb von S3 ist mit Durability Reviews, dem Rust-basierten ShardStore, leichtgewichtiger formaler Verifikation und teamweiser Ownership so gestaltet, dass schnelle Entwicklung und hohe Standards bei der Dauerhaftigkeit zugleich erhalten bleiben
S3 als ein einziges riesiges Service-System betrachten
- S3 ist ein Objektspeicher-Service und besteht aus einer HTTP-REST-API, einer Frontend-Flotte, einem Namespace-Service, einer speicherbasierten Flotte mit Festplatten sowie einer Flotte für Hintergrundaufgaben
- Für jede große Komponente gibt es innerhalb der S3-Organisation einen eigenen Bereich mit Führung und mehreren Teams; auch tiefer liegende Komponenten werden mit eigenen Flotten und Teams betrieben
- Heute besteht S3 aus Hunderten Microservices, und die Interaktion zwischen Teams entspricht weitgehend Verträgen auf API-Ebene
- Wenn Modularität schlecht entworfen ist, können auch die Interaktionen zwischen Teams ineffizient und unnatürlich werden; deren Korrektur gehört ebenfalls zum Prozess, Software und Teams gemeinsam zu gestalten
Nicht die Software allein, sondern der gesamte Service ist das System
- S3-Kunden kaufen keine paketierte Software, sondern eine Service-Erfahrung und erwarten kontinuierliche, vorhersehbare Qualität
- Die Systemgrenzen von S3 enden nicht beim Code
- Code, der in der Nähe der Festplatten ausgeführt wird
- Techniker, die neue Storage-Racks im Rechenzentrum installieren
- Kundenanwendungen, die Performance abstimmen
- Hardware-, Finanz- und Engineering-Organisationen
- S3 ähnelt eher einem lebenden System, in dem Software, Hardware und Menschen gemeinsam ständig wachsen und sich verändern
- Ein einfaches Architekturdiagramm auf dem Whiteboard verdeckt die erweiterten Services und die Größenordnung innerhalb der einzelnen Kästen und führt dadurch dazu, das reale System zu unterschätzen
Wie die physikalischen Grenzen von HDDs das Design von S3 beeinflussen
- S3 ist ein sehr großes System mit Millionen von Festplatten, und die Eigenschaften von HDDs gehören zu den zentralen Einschränkungen des Designs
- Seit der IBM 350 disk storage unit von 1956 haben sich HDDs stark weiterentwickelt
- Die aktuell genannte größte HDD ist die Western Digital Ultrastar DC HC670 mit 26 TB
- Seit RAMAC hat sich die Kapazität um das 7,2-Millionenfache verbessert
- Die physische Größe wurde um den Faktor 5.000 reduziert
- Inflationsbereinigt sind die Kosten pro Byte um den Faktor 6 Milliarden gesunken
- Doch die seek time hat sich nur um den Faktor 150 verbessert, und die Leistung bei zufälligen Lese- und Schreibzugriffen liegt weiter bei ungefähr 120 Operationen pro Sekunde
- Dieser Leistungswert war schon beim Start von S3 im Jahr 2006 ähnlich und unterschied sich auch zehn Jahre davor nicht wesentlich
- Weil HDDs mechanische Geräte sind, muss auf die Bewegung des Arms und die Rotation der Platten gewartet werden; die Leistung für Random Access steigt daher nicht im gleichen Tempo wie die Kapazität
- Die Roadmap der Branche zeigt für die kommenden zehn Jahre einen Weg zu 200-TB-HDDs; auf diesem Niveau würde bei gleichmäßig zufälligem Zugriff auf alle Daten nur etwa 1 I/O pro Sekunde je 2 TB an Daten auf einer Festplatte erlaubt sein
- S3 verwendet noch keine 200-TB-Laufwerke, geht aber davon aus, diese und alle dazwischenliegenden Laufwerksgrößen zu nutzen
Heat-Management: Datenplatzierung und Performance
- In S3 bezeichnet heat die Anzahl der Anfragen, die zu einem bestimmten Zeitpunkt auf eine einzelne Festplatte treffen
- Wenn Heat schlecht verwaltet wird, konzentrieren sich Anfragen auf bestimmte Festplatten und es entstehen Hotspots, die die Gesamtleistung der von ihnen abhängigen Anfragen verschlechtern
- Hotspots legen das System in der Regel nicht sofort lahm, sondern erzeugen Anfrageschlangen und verschlechtern die Kundenerfahrung
- Anfragen, die auf ausgelastete Festplatten warten, verzögern sich
- Diese Verzögerung verstärkt sich in höhere Ebenen des Storage-Stacks über abhängige I/Os wie Metadatenabfragen oder Erasure Coding
- Es entstehen hohe Latenzen bei einem Teil der Anfragen, also Straggler
- Hotspots einzelner HDDs führen zu tail latency und beeinflussen, wenn sie nicht behandelt werden, schließlich auch die gesamte Anfrageverzögerung
- Beim Schreiben von Daten kennt S3 weder den späteren Zugriffszeitpunkt noch die Zugriffsart, weshalb Entscheidungen zur Datenplatzierung beim Schreiben schwierig sind
- In kleinem Maßstab ist die Vorhersage und Steuerung von I/O-Heat sehr schwierig, aber bei der Größenordnung und Multi-Tenancy von S3 zeigen sich andere Eigenschaften
- Einzelne Workloads sind meist die meiste Zeit inaktiv und zeigen dann plötzlich Spitzen, aber wenn Millionen Workloads zusammenkommen, wird die Gesamtnachfrage flach und vorhersagbar
- Ab einer bestimmten Größenordnung wird es für einen einzelnen Workload schwierig oder unmöglich, den Gesamtscheitelpunkt spürbar zu beeinflussen
Replikation und Erasure Coding behandeln Dauerhaftigkeit und Performance gemeinsam
- Die Art der Redundanz in einem Speichersystem schützt Daten nicht nur vor Hardwareausfällen, sondern hilft auch bei der Verteilung von Heat
- Replikation legt Kopien auf mehrere Festplatten, sodass Festplattenausfälle toleriert werden können und Leseanfragen von beliebigen dieser Kopien bedient werden können
- Aus Kapazitätssicht ist Replikation teuer, aus Sicht der Lese-I/O jedoch effizient
- Damit S3 nicht für alle Daten den Overhead der Replikation zahlen muss, verwendet es auch Erasure Coding
- Ein Beispielansatz nutzt Algorithmen wie Reed-Solomon
- Ein Objekt wird in k Identity Shards aufgeteilt
- Zusätzlich werden m Parity Shards erzeugt
- Ein Objekt kann gelesen werden, solange beliebige k der insgesamt k+m Shards verfügbar sind
- Dieser Ansatz reduziert den Kapazitäts-Overhead und toleriert dabei dieselbe Anzahl an Ausfällen
Strategien zur Datenplatzierung und Isolation von Kunden-Workloads
- Das Redundanzverfahren teilt Daten in mehr Fragmente auf, als für die erforderliche Anzahl von Lesezugriffen nötig wären, sodass Anfragen überlastete Festplatten umgehen können
- S3 platziert neue Objekte breit über die gesamte Festplattenflotte, um Heat weiter zu verringern
- Einzelne Objekte können über Dutzende Laufwerke hinweg codiert werden, und verschiedene Objekte werden auf unterschiedlichen Laufwerksmengen platziert
- Wenn Objekte innerhalb jedes Buckets über viele Festplatten verteilt werden, entstehen zwei Vorteile
- Der Anteil der Kundendaten auf einer einzelnen Festplatte wird extrem klein, sodass einzelne Workloads kaum einen Hotspot auf einer bestimmten Festplatte erzeugen können
- Einzelne Workloads können bis zu einer Festplattengrößenordnung burst-en, die als eigenständiges System nur schwer aufzubauen und teuer wäre
- Ein Burst eines Genomanalyse-Kunden, der parallele Analysen über Tausende Lambda-Funktionen ausführt, kann von mehr als einer Million einzelner Festplatten verarbeitet werden
- In S3 gibt es heute Zehntausende Kunden, deren Buckets über Millionen Laufwerke verteilt sind
- Das Besondere an S3 ist nicht nur die Größe des Speichersystems selbst, sondern auch, dass die Größenordnung der Aggregation von Kunden und Workloads den Charakter des Systems verändern kann
Durability Reviews und Guardrails
- Amazon legt großen Wert darauf, dass Engineers und Teams schnell und sicher scheitern können
- Um sich schnell weiterzuentwickeln und gleichzeitig hochdauerhaften Storage bereitzustellen, verwendet S3 einen Prozess namens Durability Review
- Ein Durability Review gehört zwar nicht zu den Mechanismen des statistischen 11-9s-Modells, wird im Betrieb von S3 aber als wichtig angesehen
- Wenn Änderungen durch Engineers den Zustand der Dauerhaftigkeit beeinflussen können, wird ein Durability Review durchgeführt
- Dabei wird die Idee des Threat Model aus der Sicherheitsforschung übernommen
- Es wird eine Zusammenfassung der Änderung erstellt
- Es wird eine umfassende Liste von Bedrohungen erstellt
- Es wird dokumentiert, wie die Änderung diesen Bedrohungen standhält
- Das Durability Review erfüllt zwei Funktionen
- Autor und Reviewer werden dazu gebracht, kritisch über die zu schützenden Risiken nachzudenken
- Risiken und Gegenmaßnahmen lassen sich voneinander trennen und separat diskutieren
- Bei der Suche nach Gegenmaßnahmen bevorzugt man eher einfache, grobe Guardrails, die breite Risikoklassen blockieren, statt für jedes Detailrisiko eine eigene punktuelle Minderung anzubringen
ShardStore, Rust und leichtgewichtige formale Verifikation
- S3 startete vor einigen Jahren ein Projekt, um die unterste Schicht des Storage-Stacks, also den Teil, der die Daten einzelner Festplatten verwaltet, von Grund auf neu zu schreiben
- Die neue Storage-Schicht heißt ShardStore
- Einer der Guardrails, die beim Neuaufbau von ShardStore übernommen wurden, ist leichtgewichtige formale Verifikation
- Das Team wechselte zu Rust als Implementierungssprache, um Bugs früher zu finden
- Nutzung von Typsicherheit
- Nutzung strukturierter Sprachunterstützung
- Entwicklung von Bibliotheken, die Typsicherheit auf On-Disk-Strukturen ausweiten
- Für die Verifikation wurde ein vereinfachtes Modell der ShardStore-Logik in Rust geschrieben und im selben Repository wie die tatsächliche Produktionsimplementierung von ShardStore abgelegt
- Dieses Modell dient als ausführbare Spezifikation, die die Komplexität der realen On-Disk-Storage-Schicht und der HDDs entfernt
- Das Modell war nur etwa 1 % so groß wie das reale System, ermöglichte aber ein Testniveau, das gegenüber Festplatten mit 120 IOPS unrealistisch hoch wäre
- Diese Arbeit wurde auch als SOSP-Paper veröffentlicht: Using lightweight formal methods to validate a key-value storage node in Amazon S3
- Anschließend wurde mit Werkzeugen und etablierten Verfahren wie Property-based Testing geprüft, ob das Verhalten der Implementierung mit der Spezifikation übereinstimmt
- Der Kernpunkt ist, dass Forschungsansätze aus der formalen Verifikation industrialisiert wurden – als Code, den gewöhnliche Engineers warten können, und als Werkzeuge, die auf jeden Commit angewendet werden
- Diese Verifikations-Guardrails gaben dem Team das Vertrauen, schneller entwickeln zu können, und blieben auch nach dem Einstieg neuer Engineers erhalten
Mit Ownership die Skalierungsprobleme von Teams und Einzelnen angehen
- Bei Amazon bezeichnet Ownership das Prinzip, klar festzulegen, welche einzelne Person oder welches Team die Verantwortung dafür trägt, dass eine bestimmte Aufgabe oder ein bestimmter Service erfolgreich ist
- Um sich in S3 schnell zu bewegen und zugleich hohe Qualitätsstandards zu halten, müssen Teams Eigentümer sein
- Sie besitzen die API-Verträge mit anderen Systemen
- Sie tragen Verantwortung für Dauerhaftigkeit, Performance und Verfügbarkeit
- Wenn ein unerwarteter Bug die Verfügbarkeit beeinträchtigt, beheben sie ihn auch um 3 Uhr morgens
- Nach dem Bugfix verbessern sie das System so, dass sich derselbe Vorfall nicht wiederholt
- Ownership erfordert neben großer Verantwortung auch Vertrauen
- Damit Einzelpersonen oder Teams einen Service besitzen können, brauchen sie Spielraum, selbst zu entscheiden, wie sie ihn bereitstellen
- Auch aus Erfahrungen mit Forschungsprojekten im Graduiertenstudium zeigt sich, dass Menschen sich stärker engagieren, wenn sie das Gefühl haben, es sei ihre eigene Idee und sie könnten sie selbst weiterentwickeln
- In sehr seniorigen Engineering-Rollen ist es oft wirkungsvoller, Probleme klar zu definieren und Teams dabei zu helfen, die Lösung zu besitzen, statt Lösungen direkt wie ein Deployment vorzugeben
- Bei Problemen mit mehreren möglichen Lösungen bedeutet die Auswahl einer angemessenen Lösung, jemandem Ownership über die Lösung zu geben
Fazit aus S3
- Die technische Größenordnung von S3 ist nicht einfach nur größer als die kleinerer Systeme; auch Workloads, Struktur und Betriebsweise unterscheiden sich grundlegend
- Ein „System“ umfasst nicht nur Software, sondern auch den Service-Betrieb, die Betriebsorganisation und sogar den Kundencode, der zusammen mit dem Service arbeitet
- Auch die Organisation ist Teil des Systems und hat ihre eigenen Skalierungsprobleme und Innovationsmöglichkeiten
- Um in einer individuellen Rolle erfolgreich zu sein, muss man eher Probleme klar formulieren als Lösungen vorzugeben und starke Engineering-Teams dabei unterstützen, die Lösungen tatsächlich zu besitzen
2 Kommentare
Meinungen auf Hacker News
Eine der Gespräche, an die ich mich aus meiner Zeit bei AWS erinnere, war, dass selbst ein Ereignis mit einer Wahrscheinlichkeit von eins zu einer Milliarde bei der Größenordnung von S3 täglich auftritt.
Dinge, die man normalerweise als so unwahrscheinlich abtun würde, dass sie keine Sorge wert sind, müssen zwingend berücksichtigt und behandelt werden.
Es freut mich, Ansätze wie ShardStore zu sehen, insbesondere formale Verifikation und Property-based Testing. Die Services früherer Generationen hatten genug Bugs, um die Risiken organischen Wachstums deutlich zu zeigen, aber sie waren zumindest so entworfen, dass Ausfälle „sicher“ passieren und Datenverlust verhindert wird; die S3-Engineers waren darauf geradezu fixiert.
Und das gilt nicht nur für S3. Am Prime Day 2022 etwa kam DynamoDB allein mit Amazon-Workloads auf über 105 Millionen Requests pro Sekunde: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
In dem Beitrag behandelt Andy auch leichtgewichtige formale Methoden und die Einführung von Rust im Team; in einer Größenordnung, in der selbst extrem unwahrscheinliche Ereignisse häufig werden, muss man für Korrektheit in mehrere Schichten von Werkzeugen und Prozessen investieren.
Ich erklärte, dass das bei unserem Ziel von 500k TPS 30 Mal pro Minute wäre, und fragte: „Willst du in dieser Woche On-Call sein?“ In diesem Stack bedeutet „höchste Standards einhalten“ etwas völlig anderes als in den meisten Organisationen.
Zum Glück war der Algorithmus gut, und heutige Hardware ist auch deutlich zuverlässiger.
In meinem Kopf gibt es auch eine leicht schräge Stimme, die mit Popcorn bereitsteht, falls ich das Nachbeben der ersten großen kryptografischen Hash-Kollision zufällig miterleben darf.
Ich arbeite in der Genomik und habe in den letzten 10 Jahren viel mit Datenspeichern im Petabyte-Bereich zu tun gehabt.
Durch die Nutzung von AWS S3, GCP GCS und Speichersystemen für Colocation-Hardware (Ceph, Gluster, ein HP-System, dessen Namen ich aus meinem Gedächtnis gelöscht habe) habe ich großen Respekt vor dem Aufwand bekommen, der in den Betrieb solcher Systeme fließt.
Auch der Vorteil, Disk-I/O mit sehr vielen anderen Kunden zu teilen, ist schwer zu unterschätzen. Den im Artikel verwendeten Begriff „heat“ hatte ich vorher nicht gehört, aber in einem einzelnen System ist das wirklich schwer abzufedern. In unserem Colocation-Cluster mussten wir das Batch-System anpassen, um I/O zwischen großen Jobs richtig zu verwalten, und I/O als zuteilbare Ressource wie RAM oder CPU behandeln. S3 und GCP sind sehr teuer, aber manchmal ist die Performance ihren Preis wert.
Genau solche Beiträge sind für mich das Beste an HN.
Aus Sicht eines Cloud-Speichers ist der beste Kunde jemand, der riesige Datenmengen speichert, sie aber kaum liest. Es ist ähnlich wie beim Mieten von Festplatten, aber wenn man jede Disk nur teilweise mit „kalten“ Daten füllt, kann man die gesamte I/O-Kapazität derselben Disk weiter für die Verarbeitung heißer Workloads nutzen.
Wenn man sehr sorgfältig ausbalanciert, welche Daten auf welchem Laufwerk liegen, kann man alle Laufwerke weiter auslasten, auch wenn der Großteil der Daten nicht verwendet wird. Deshalb ist Speichern vergleichsweise günstig und Lesen vergleichsweise teuer.
Selbst wenn sie S3 unterstützen, ist die Performance oft viel langsamer, als sie sein könnte.
Das ist schwierig, und es tut mir leid, dass die Leseverfügbarkeit nur bei etwa 99,95 % liegt.
Wenn S3 ein einfaches OAuth2-basiertes Protokoll für die Delegation von Lese-/Schreibzugriff spezifiziert hätte, hätte man vieles darauf aufbauen können.
Die Welt braucht ein HTTP-basiertes Protokoll, mit dem Apps im Namen von Nutzern auf Daten zugreifen können. Google Drive kommt dem am nächsten, aber es gibt nur einen Anbieter und auch andere Probleme[0]. Schade, dass sich remoteStorage nicht durchgesetzt hat. Ich hoffe, dass Solid erfolgreich wird, aber für mich fühlt es sich zu kompliziert an. Mein Ansatz für dieses Problem ist https://gemdrive.io/, liegt derzeit aber weitgehend auf Eis, weil ich mich auf andere Teile meines Self-Hosting-Stacks konzentriere.
[0]: https://gdrivemusic.com/help
Das richtig umzusetzen, ist derzeit extrem schwierig. Ich habe eine ganze CLI-App gebaut, um das Problem „AWS-Zugangsdaten ausstellen, die nur auf diesen einen bestimmten Bucket zugreifen dürfen“ zu lösen, aber ich möchte Nutzer nicht dazu anleiten müssen, so etwas zu installieren und auszuführen: https://s3-credentials.readthedocs.io/en/stable/
Eigentlich wäre eine Bibliothek schön, die mit minimalen clientseitigen Abhängigkeiten ein lokales Verzeichnis mountet, das in Wirklichkeit der S3-Bucket des Nutzers ist.
Denn ein Wettbewerber könnte jederzeit über adversariale Interoperabilität einsteigen.
Es ist wirklich schade, dass Projekte, die Datensouveränität für Nutzer schaffen wollten oder wollen, alle in eine seltsame Kryptowährungsrichtung abgedriftet sind.
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
Edit: Ich glaube, ich habe den Kommentar falsch gelesen. Ich hatte verstanden, dass die App Nutzerdaten an den Client delegieren will; tatsächlich scheint es darum zu gehen, dass Nutzer ihre eigenen Daten an die App delegieren wollen. Das sind unterschiedliche Use Cases.
In den Spezifikationen des IBM RAMAC stehen 3,75 MB Speicherkapazität und etwa 9.200 Dollar pro Terabyte; das kann nicht stimmen.
Wenn man die Kosten mit der Speicherkapazität multipliziert, käme man auf einen Laufwerkspreis von 3 Cent.
Diese Seite[1] sagt, er habe „etwa 2.000 Bit pro Quadratzoll gespeichert und der Kaufpreis lag bei etwa 10.000 Dollar pro Megabyte“.
Vermutlich müsste die Angabe also 9.200 Dollar pro Megabyte lauten. Dann ergäbe sich ein Laufwerkspreis von 34.500 Dollar, was plausibler ist.
[1]: https://www.historyofinformation.com/detail.php?entryid=952
Es waren 30 Millionen Bit, wobei Parität herausgerechnet wurde und nur 6 Datenbits gezählt wurden. Allerdings wurde er für 3.000 Dollar im Monat vermietet, es gab also keine festen Kosten wie beim einmaligen Kauf eines physischen Laufwerks. In dieser Hinsicht ist das dem S3-Modell sogar ziemlich ähnlich.
Was die meisten nicht erkennen: Die Magie liegt nicht darin, das System selbst zu betreiben, sondern darin, Autorisierung so aussehen zu lassen, als wäre sie kostenlos.
Autorisierung in verteilten Systemen ist unglaublich schwierig. In der Größenordnung von AWS ist sie praktisch Magie. AWS hat ein reichhaltiges Berechtigungsmodell, und Berechtigungsänderungen verbreiten sich offenbar mit Submillisekunden-Latenz über die gesamte Infrastruktur, während vermutlich Billionen von Requests verarbeitet werden.
Dieser Teil sowie Logging/Abrechnung für Billing sind die zwei magischen Elemente bei AWS, über die ich gern einmal etwas lesen würde.
S3 behandelt Zugriffskontrolle anders als andere Services: Berechtigungen hängen an der Ressource. Vermutlich aus Geschwindigkeitsgründen.
Einer der Gründe, warum der Bucket/Key-Zugriffsansatz besonders ist, dürfte sein, dass dieses Modell bereits etabliert war, als IAM kam.
Dass es danach beibehalten wurde, liegt wahrscheinlich daran, dass das Entfernen des bestehenden Modells eine Menge Kundensetups kaputtmachen könnte und daher schwierig wäre.
„Als wirklich seniorer Engineer im Unternehmen hat man natürlich starke Ansichten und eine technische Agenda. Aber wenn man in der Interaktion mit Engineers einfach nur Ideen verteilt, ist es schwer, dass alle erfolgreich sind. Es ist viel schwieriger, sich für Ideen zu engagieren, die einem nicht gehören. Deshalb habe ich bei der Arbeit mit Teams die Strategie verfolgt, dass meine besten Ideen nicht von mir stammen, sondern zu Ideen anderer werden. Ich verbringe bewusst viel mehr Zeit damit, das Problem weiterzuentwickeln und sehr gut zu formulieren, statt eine Lösung zu verkaufen. Es gibt oft mehrere Wege, ein Problem zu lösen, und den richtigen Weg zu wählen bedeutet, jemanden die Lösung wirklich besitzen zu lassen.“
„Ich habe gelernt: Wenn ich in meiner Rolle wirklich erfolgreich sein will, muss ich mich darauf konzentrieren, nicht die Lösung, sondern das Problem klar zu formulieren, und Wege finden, starke Engineering-Teams dabei zu unterstützen, diese Lösung wirklich zu besitzen.“
Dieser Teil hat mir wirklich gut gefallen. Er erinnert ein Stück weit an den Ikea-Effekt. Wenn man will, dass jemand Leidenschaft für eine Aufgabe entwickelt, muss man Ownership fördern; ein guter Weg ist, dafür zu sorgen, dass die Aufgabe „die Idee dieser Person“ wird.
Schließlich sehen Menschen schon oft sehr unterschiedlich, was überhaupt das „Problem“ ist.
Zum Glück ist das nicht bei allen Problemen so. Aber wenn man sich zum Beispiel Diskussionen über das „Packaging-Problem“ von Python ansieht, beschreiben die Leute in Wirklichkeit ungefähr sechs verschiedene Probleme auf sehr unterschiedliche Weise, und dieses Phänomen zeigt sich dort ziemlich unschön.
Falls Andy Warfield mitliest – was er vermutlich tut –, habe ich eine Frage: Wie wertvoll ist es, beim Ausarbeiten eines Problems mögliche Lösungen zu skizzieren? Wenn man das Problem klar formuliert, ergeben sich wahrscheinlich ganz natürlich einige mögliche Lösungen. Lohnt es sich, diese zu teilen, um das Denken potenzieller Owner anzustoßen? Oder ist es besser, sich nur auf das Problem zu konzentrieren und den Lösungsraum vollständig offen zu lassen?
Außerdem: Gibt es empfehlenswerte Lektüre dazu, wie solche sehr senioren Individual Contributors arbeiten?
Für mich klingt das wie: „Du einfacher Untertan! Ich habe keine Zeit, mich um dein Problem zu kümmern. Wenn du nur ein Problem bringst, kann ich mit deiner Arbeit ja nicht befördert werden.“
Um ein Problem lösen zu können, muss man es zuerst verstehen und seine Existenz anerkennen können.
In Situationen ohne vorab anerkannte Autorität oder Expertise – also in den Kontexten, in denen die meisten Alltagsprobleme sichtbar werden – wirkt man schnell wie jemand, der mit einer langen, detaillierten und sorgfältig ausgearbeiteten Problembeschreibung den bidirektionalen Gesprächskanal allein belegt, nur redet und nicht arbeiten will, oder wie jemand, der keine Lust hat, gemeinsam mit anderen nach einer Lösung zu suchen.
Schön zu sehen, dass Amazon-Mitarbeitende inzwischen öffentlich darüber sprechen können, wie S3 intern funktioniert.
Ich würde auch gern mehr darüber hören, wie Glacier funktioniert. Soweit ich weiß, wurde nie offengelegt, welches Speichermedium darunterliegt, weshalb es alle möglichen Spekulationen gab: Tape, Offline-HDDs, Custom-HDDs usw.
Andere stimmen dem allerdings nicht zu. Es bleibt weiterhin ein Rätsel.
Ich wünschte, AWS würde alles darüber und die ganze Entstehungsgeschichte erzählen. Es ist wirklich ein faszinierendes Thema.
Es bräuchte ja nur einen Engineer, der betrunken aus dem Nähkästchen plaudert. In einem deutlich wichtigeren Bereich hat ein Soldat aus Massachusetts nationale Sicherheitsinformationen auf Discord geleakt, um vor seinen Gamer-Freunden cool zu wirken, und steht nun vor einer langen Haftstrafe. Ich hätte erwartet, dass Details zu Glacier inzwischen längst bekannt wären.
„Stellt euch einen Festplattenkopf wie eine 747 vor, die mit 75 Meilen pro Stunde über einen Rasen fliegt. Der Luftspalt zwischen dem Flugzeugboden und den Grasspitzen ist so dick wie zwei Blatt Papier. Misst man die Bits auf der Platte in Grashalmen, ist eine Spur 4,6 Grashalme breit und ein Bit einen Grashalm lang. Wenn das Flugzeug über den Rasen fliegt und Grashalme zählt, verpasst es nur einen einzigen Grashalm alle 25.000 Erdumrundungen.“
Der Abschnitt zur Lastverteilung erinnert mich an die Zeit von S3 KeyMap und an den Versuch, von der frühen Implementierung dorthin zu migrieren.
Eine Lektion war: Selbst wenn man das heißeste Objekt, die heißeste Partition oder den heißesten Bucket identifiziert hatte, konnte man ihn nicht einfach verschieben und fertig. Man musste alles sortieren. Die eigentliche Lösung bestand darin, zu sortieren, dann die Partitionslast eines Hosts in Quartile aufzuteilen und Partitionen aus dem zweiten Quartil auf den am wenigsten belasteten Host zu verschieben.
Wenn man versuchte, den heißesten Bucket, also das erste Quartil, zu verschieben, wurde die verbleibende Gruppe stärker belastet, und es schlug immer wieder fehl.
Ein weiterer Nebeneffekt war, dass sich die Fehlerrate von stabilen etwa 1 % zu mehreren Tagen ganz ohne Fehler änderte; daraufhin haben wir die Alarmgrenzen deutlich strenger gesetzt. Das war ungefähr 2009.
Ich hatte ebenfalls einen akademischen Hintergrund an der UM, bin aber statt einer Promotion zu S3 gegangen. Reimt sich sogar.
S3 ist mehr als Storage, es ist ein Standard.
Ich finde es gut, dass man an einigen Stellen S3-kompatiblen Storage nutzen kann, meist mit ein paar Einschränkungen. Ich weiß nicht, wie offen der Standard ist oder ob man Amazon bezahlen muss, um „S3 compatible“ sagen zu dürfen, aber es ist ziemlich cool.
Beispiele sind iDrive E2, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage und Backblaze B2.
Edit: Nachgesehen – bei Azure scheint es tatsächlich keine zu geben :-/
Hacker-News-Kommentare
Ich arbeite in der Genomik und habe in den letzten zehn Jahren mit vielen Petabyte-Datenspeichern zu tun gehabt.
Was man alles bauen könnte, wenn S3 ein OAuth2-basiertes Protokoll verwenden würde, um Lese-/Schreibzugriffe zu delegieren.
Authentifizierung in verteilten Systemen zu behandeln, ist extrem schwierig.
Es ist schön zu sehen, dass Amazon-Mitarbeiter öffentlich über die internen Funktionsweisen von S3 sprechen.
Der Teil, in dem Festplattenköpfe mit einer 747 verglichen werden.
Wenn man in die Zeit der S3-KeyMap zurückgeht, hat man gelernt, dass sich die heißesten Objekte/Partitionen/Buckets auch nach ihrer Identifikation nicht einfach durch Verschieben beheben ließen.
S3 ist nicht einfach nur Speicher, sondern ein Standard.