AWS S3: 1 PB/s auf langsamen HDDs

AWS S3-Architektur: Petabyte-Geschwindigkeit auf HDD

AWS S3 verarbeitet über 400 Billionen Objekte, 150 Millionen Anfragen pro Sekunde und Spitzenverkehr von mehr als 1 Petabyte pro Sekunde. Im Kern stehen Festplatten – trotz ihrer Beschränkungen bei IOPS (ca. 120) und Latenz bis zu 16 ms bei zufälligen Lesevorgängen von 0,5 MB. Die Wirtschaftlichkeit von HDDs ermöglicht die Speicherung von Exabytes an Daten zu den niedrigsten möglichen Kosten: Die Kapazität ist um das 7,2-Millionenfache gestiegen, während der Preis pro Byte um einen beeindruckenden Faktor von 6 Milliarden gesunken ist.

Die Physik von HDDs bestimmt die Leistung: Die durchschnittliche Suchzeit beträgt 8–9 ms, die Rotationslatenz liegt bei 4 ms und die Übertragungszeit bei 2,5 ms. Bei sequenziellen Zugriffen ist die Effizienz hoch (bis zu 300 MB/s), doch zufällige Zugriffe sind aufgrund mechanischer Kopfbewegungen auf 32 MB/s pro Laufwerk begrenzt.

Parallelität durch Erasure Coding

S3 überwindet die Einschränkungen von HDDs mithilfe massiver Parallelität. Daten werden mittels eines Erasure-Coding-Schemas von 5 aus 9 in Shards aufgeteilt: 5 Datenshards plus 4 Paritäts-Shards. Dies führt zu einem Overhead von 1,8x statt 3x bei Replikation, bietet Resilienz gegenüber 4 Ausfällen und ermöglicht 5 Lesequellen für verbesserte Durchsatzleistung.

Vorteile des Erasure Codings:

• Lastverteilung über 9 Shards minimiert Hotspots.
• Parallel-Lesung aus 5 Shards beschleunigt den Zugriff.
• Sharding ermöglicht hedged Queries, um Latenzverzögerungen zu umgehen.

Eine 1-TB-Datei auf einer einzelnen HDD erreicht 300 MB/s; auf 20.000 Laufwerken skaliert sie auf Terabyte pro Sekunde durch Aggregation der Bandbreite.

Parallelität über alle Ebenen

Parallelität wird auf drei Ebenen implementiert:

• Client-Frontend: HTTP-Verbindungspools verteilen Anfragen über mehrere Endpunkte und vermeiden Überlastung von Proxies und Caches.
• Frontend-Backend: EC-Shards verteilen Objekte über Tausende von Platten im ShardStore (einem LSM-Baum auf Basis logstrukturierter Speicherung).
• PUT/GET-Operationen: Multipart-Uploads für Schreibvorgänge, Byte-Range-GETs für Lesevorgänge – aufgeteilt in über 100 Streams à 10 MB/s statt eines einzigen Gigabit-Streams.

Schreibvorgänge sind sequenziell (logartig), während Lesevorgänge eine Zufalls-Sharding-Strategie erfordern, um Warteschlangenbildung zu vermeiden.

Bekämpfung von Hotspots

Bei zehn Millionen Laufwerken und hunderten Millionen Shards pro Sekunde ist eine gleichmäßige Lastverteilung entscheidend. Ein einzelnes Laufwerk mit maximal 32 MB/s wird schnell zur Engstelle, verstärkt durch die Überlastung beim Umverteilen.

S3-Strategie:

• Zufallsgenerierung: Hashing bei Sharding sorgt für gleichmäßigen Ressourcenverbrauch.
• Umverteilung: kontinuierliche Datenmigration ohne Ausfallzeiten.
• Horizontale Skalierung: Hinzufügen von Laufwerken ohne Beeinträchtigung der Verfügbarkeit.

Die LSM-basierte ShardStore-Struktur ist optimiert für append-only-Logs – PUTs sind schnell, GETs nutzen parallele Indexsuchen.

Schlüssel-Erkenntnisse

• S3 erreicht 1+ PB/s auf HDDs mit 5/9-EC und Parallelität über 100+ Streams.
• Durchschnittliche zufällige I/O-Latenz: 16 ms pro 0,5 MB, gemildert durch 5 Lesequellen.
• Wirtschaftlichkeit: 1,8x-EC-Overhead gegenüber 3x-Replikation spart Exabytes an Speicherkosten.
• Zufallsgenerierung + Umverteilung verhindern Kaskadeneffekte durch Hotspots.
• Backend-LSM-Baum maximiert die sequenzielle Leistung von HDDs.

— Editorial Team