Amazon S3 ist 15 Jahre alt geworden Vom E-Commerce-Laden zum Storage-Riesen

Am 14. März 2006 wurde Amazons Simple Storage Service S3 gestartet. Der Tag wird auch „Pi-Tag“ genannt, weil er in US-amerikanischer Schreibweise 3/14 formuliert wird – und das ist der Anfang der Zahl Pi. Wie sähe die Welt heute ohne S3 aus? Viele Dienste würden nicht mehr funktionieren, und mit Sicherheit wäre Datenspeicherung zum Preis von Cents pro Gigabyte (oder mehr) pro Monat um etliche Größenordnungen teurer.

Anbieter zum Thema

Vogel IT-Medien GmbH

Fujitsu Technology Solutions GmbH

Cohesity GmbH

Amazon Web Services Germany GmbH

Die Dimensionen von S3 sprengen die Vorstellungskraft. Jeff Barr, der technische Chefblogger bei AWS, gibt als jüngste Größe an, dass in S3 hundert mal zehn hoch 14 oder 100 Billionen Objekte gespeichert seien und dass es regelmäßig zehn Millionen Zugriffe gebe – pro Sekunde. Das seien mehr als 13.000 Objekte pro Mensch oder 50 Objekte für jede der ungefähr zwei Billionen Galaxien im Universum, gemäß einer jungen Schätzung.

„Unsere Kunden verwenden Amazon S3 für die unterschiedlichsten Anwendungsfälle“, berichtet Constantin Gonzalez, Principal Solutions Architect bei Amazon Web Services (AWS): „Web-Seiten, Texte, Bilder, Backups, Software-Distribution, Finanzmodelle, Forschungsdaten, Internet of Things, Machine-Learning-Modelle, Archive und noch viele mehr. In meiner täglichen Arbeit bei AWS gibt es kein Kundenprojekt, das nicht in irgendeiner Form Amazon S3 verwendet.“

Wie alles begann

15 Jahre kommen uns heute wie eine kleine Ewigkeit vor, und in der Tat fühlt sich eine Rückblende auf das Jahr 2006 wie eine Reise in die digitale Steinzeit an. Es gab noch kein iPhone, kaum Facebook, keine Likes und keine Tweets. Weder von Uber noch von Lieferando hatte man je gehört, wohl aber von einem E-Commerce-Laden, der sich kühn „Amazon.com“ nannte. Seine Größe betrug zwar nur zwei Prozent der heutigen Dimensionen, aber selbst dieser Kern wuchs schneller, als ihn die traditionelle Storage-IT unterstützen konnte.

Werner Vogels, Chief Technology Officer und Vizepräsident von Amazon.com.

Die Amazon-Plattform benötigte für ihre Fotos, Videos und Audio-Files vor allem Object Storage und Key-Value Storage, doch nur Block- und File-Storage waren der Standard. Also musste die Amazon-IT das meiste selbst entwickeln, das sie benötigte: Zuverlässigkeit mit 99,99 Prozent Verfügbarkeit, Skalierbarkeit in jeder Hinsicht, Geschwindigkeit, kostengünstige Infrastruktur und schließlich Einfachheit in der Handhabung für jede beliebige Anwendung. Diese konnte durch die entsprechende API auf S3 zugreifen. Alle diese Anforderungen unter einen Hut zu bringen, war nicht einfach, wie CTO Werner Vogels in seinem entsprechenden Blog-Post schreibt.

Um die Dauerhaftigkeit zu erreichen, welche die Grundlage für Zuverlässigkeit und Verfügbarkeit ist, führte das Vogels-Team die elf Neunen ein: 99,999999999 Prozent Dauerhaftigkeit – also Wiederherstellbarkeit – sollte nicht nur erreicht, sondern garantiert werden. Wie Vogels nicht müde wird zu konstatieren: „Everything fails all the time.“ Laufwerke fallen aus, Racks und Rechnerknoten, ganze Cluster, ja ganze Rechenzentren und möglicherweise sogar komplette „Availability Zones“ – nichts darf die Daten gefährden. Deshalb repliziert AWS Daten und Services über viele Rechenzentren hinweg, die beispielsweise in der Region Frankfurt in drei vollständig getrennte Availability Zones aufgeteilt sind. Und weil die Erde permanent von geladenen Teilchen aus der Sonne bombardiert wird, kann es nicht ausbleiben, dass auch Bits mit der Zeit korrumpiert werden. Deshalb laufen stetig kleine „Bots“ über die Laufwerke, um Cyclic Redundancy Checks (CRC) durchzuführen und notfalls fehlerhafte Bits zu reparieren.

DevGraph CloudFix

Tool zur automatisierten Kosteneinsparung auf AWS

Intelligent Tiering

Vom ersten Tag an hörte das Vogels-Team darauf, was seine Kunden wollten. Und Amazon selbst ist einer von vielen großen Kunden. Die Kunden wollten erstens Kostenoptimierung und zweitens Planbarkeit. Da Speichermedien unterschiedliche Preise aufweisen, lassen sich den preisgünstigsten Medien „kalte“ Daten zuweisen, auf die wenig oder selten zugegriffen wird, und den teuersten Medien „heiße“ Daten, auf die – zumindest zu Beginn – am häufigsten zugegriffen wird.

Die preisgünstigsten Speichermöglichkeiten sind oft langsamer, während der schnelle Zugriff auf Daten eine höhere Belastung und damit höhere Kosten bedeutet. Der Kunde muss also abwägen. Diese Schichtung (oder dieses Tiering) lässt sich mit logischen Regeln programmieren und implementieren. Sobald die Regeln gelten, lässt sich auch vorhersagen, was bei Änderungen an den maßgeblichen Parametern – etwa Volumen oder Zugriffsgeschwindigkeit – passieren würde.

Bildergalerie

2018 wurde Intelligent Tiering als Speicherklasse von S3 eingeführt. Die Kunden würden ohne Leistungseinbußen und Verwaltungsaufwand ihre Datenzugriffe auf Speichereinheiten optimieren lassen können – denn natürlich arbeitet S3 automatisch. Im November 2012 und 2020 führte AWS die Speicherklassen „Glacier“ beziehungsweise „Glacier Deep Archive“ ein, um auch Speicher anzubieten, auf den selten oder sehr selten zugegriffen wird, der aber mitunter – etwa bei Versicherungen – sehr lange aufbewahrt werden muss. Die Gebühren sind entsprechend niedrig.

S3-Replikation

Nicht nur AWS repliziert ständig Daten, sondern auch die Kunden tun das. Sie nutzen Cross-Region- und Same-Region-Replikation, Replikation an mehrere Zielpunkte, nutzen die Metriken von CloudWatch und vieles mehr. Diesen Kunden bietet AWS als Dienstgüte (SLA) an, dass sie ihre Daten binnen maximal 15 Minuten zwischen zwei AWS-Regionen replizieren können.

Solch ein Versprechen macht man nicht leichtfertig, und tatsächlich erforderte es nach Vogels’ Angaben eine Menge technischer Arbeit und Ingenieursschweiß, die Leitungsgüte (Bandbreite, Datendurchsatz, Qualität) und den Datendurchsatz gewährleisten zu können. Nicht nur die Übertragung muss überwacht werden, sondern jeder beliebige Zugriffspunkt für jeden S3-Bucket.

Durch Machine Learning dem Virus auf der Spur

AWS unterstützt offene Covid-19-Plattform mit ML-Funktionen

Umso erstaunlicher wirkt angesichts dieser Herausforderungen, dass AWS im Jahr 2019 den Service Replication Time Control (RTC) für S3 einführte. Für mache Nutzer wie etwa die Aktienmärkte sind 15 Minuten eine kleine Ewigkeit; daher sollten die Kunden gegen eine entsprechende Gebühr bestimmen können, wie lang die Replikationsdauer betragen dürfe. Dafür muss das System nicht nur alle Endpunkte und Übertragungsbedingungen überwachen, sondern auch die Übertragung selbst priorisieren und den Zeitpunkt berechnen, zu dem der Kunde mit dem Eintreffen des Replikats rechnen kann, und das für jeden individuellen Kunden.

Data Lakes

Data Lakes, die auf S3 basieren, sammeln verschiedenartige Daten, die sich die Nutzer teilen können. Diese Daten können aus ganz verschiedenen Abteilungen eines Kundenunternehmens kommen, so etwa von Data Scientists, Geschäftsanalytikern, Controllern, Sacharbeitern und vielen mehr.

Constantin Gonzales, Principal Solutions Architect bei Amazon Web Services (AWS).

„Data Lakes auf Amazon S3“, berichtet Gonzalez, „sind für unsere Kunden ein wichtiges Thema, weil sie damit zum ersten Mal unternehmensweit einen sicheren, umfassenden, kostengünstigen, zuverlässigen und einfach zu verwaltenden Zugriff auf ihre wertvollen Geschäftsdaten haben. Das ist für viele Unternehmen die Grundlage, neue Geschäftsideen zu entwickeln und bestehende Prozesse besser zu unterstützen.“

Der HealthLake, den AWS Ende 2020 vorstellte, ist beispielsweise eine zweck- und branchenorientierte Ausformung eines solchen Data Lakes für Behörden und Unternehmen aus dem Gesundheitssektor.

Weil Innovation zur DNA von Amazon Web Services gehört, dürfen sich die Kunden auch auf die kommenden 15 Jahre S3 freuen.

Vom Hybrid- zu einem „All-in-Cloud“-Modell

Die hybride Cloud als Brücke zwischen neuer und traditioneller IT

(ID:47502711)