Kontinuierliche Innovation: Eine kurze Geschichte des AWS-Block-Storage

Kontinuierliche Innovation: Eine kurze Geschichte des AWS-Block-Storage

• Einführung

  • Marc Olson arbeitet seit mehr als 10 Jahren im Elastic Block Store (EBS)-Team.
  • EBS hat sich von einem einfachen Block-Storage-Service zu einem groß angelegten Netzwerk-Storage-System entwickelt, das täglich mehr als 140 Billionen Operationen verarbeitet.
  • Dieser Beitrag teilt den Entwicklungsweg von EBS und wichtige Erkenntnisse daraus.

• Die frühe Geschichte von EBS

  • EBS wurde am 20. August 2008 eingeführt und begann mit der einfachen Idee, netzwerkgebundenen Block Storage für EC2-Instanzen bereitzustellen.
  • Anfangs wurden gemeinsam genutzte Hard Disk Drives (HDDs) verwendet; heute kann EBS einer einzelnen EC2-Instanz mehrere Hunderttausend IOPS bereitstellen.
  • EBS verarbeitet heute über eine verteilte SSD-Flotte täglich mehr als 140 Billionen Operationen.

• Queuing-Theorie

  • Die Art und Weise, wie Computersysteme mit Storage interagieren, hat sich grundlegend nicht verändert.
  • Die CPU stellt Anfragen in eine Queue, und das Storage-Gerät holt die Daten aus dem CPU-Speicher und speichert sie auf einem dauerhaften Medium oder überträgt die Daten umgekehrt in den CPU-Speicher.
  • Die Queuing-Theorie spielt eine wichtige Rolle beim Verständnis dieses Prozesses.

• Der Übergang von HDD zu SSD

  • Frühes EBS nutzte HDDs, deren Leistung durch physische Grenzen eingeschränkt war.
  • Mit dem Aufkommen von SSDs konnten auch zufällige Anfragen fast so schnell wie sequentielle Anfragen verarbeitet werden.
  • 2012 wurden ein neuer Storage-Server-Typ mit SSDs sowie ein neuer EBS-Volume-Typ namens Provisioned IOPS eingeführt.

• Messung und Betrieb

  • 2012 verfügte EBS nur über grundlegende Telemetrie.
  • Um die Systemleistung zu verbessern, musste zuerst herausgefunden werden, was genau das Problem war, und es musste nach Priorität behoben werden.
  • Es wurden Verfahren aufgebaut, um IO in mehreren Subsystemen zu messen, und durch kontinuierliches Monitoring wurden Veränderungen erkannt.

• Divide and Conquer in der Organisation

  • Das EBS-Storage-Server-Team wurde in kleine Teams umstrukturiert, die sich auf bestimmte Bereiche wie Datenreplikation, Haltbarkeit und Snapshot-Hydration konzentrierten.
  • Jedes Team konnte Änderungen unabhängig iterieren und committen.

• Annahmen hinterfragen

  • Es wurde entdeckt, dass die Standardeinstellungen des Xen-Hypervisors die Leistung begrenzten.
  • Mithilfe der Nitro-Offload-Karte wurden Netzwerk- und Storage-Verarbeitungsaufgaben auf Hardware ausgelagert.

• Experimente zur Netzwerkoptimierung

  • Mit der Migration von EBS auf Nitro nahm der Overhead des Netzwerks selbst zu.
  • Zur Verbesserung der Netzwerkleistung wurde anstelle von TCP das Protokoll SRD (Scalable Relatable Diagram) entwickelt.

• Beschränkungen fördern Innovation

  • Um allen Kunden die Vorteile von SSDs zu bieten, wurden SSDs hinzugefügt, ohne die bestehende Hardware auszutauschen.
  • SSDs wurden manuell in die Server eingebaut, neue Schreibvorgänge zunächst auf SSDs gespeichert und anschließend asynchron auf HDDs geflusht.

• Rückblick auf die Skalierung der Performance

  • Eine persönliche Wachstumsgeschichte: der Übergang von der Kultur eines kleinen Unternehmens zu einer großen Organisation.
  • Durch gemeinschaftliche Debugging-Sessions wurden Probleme gelöst und die Effizienz des Teams gesteigert.

• Fazit

  • EBS hat sich nicht durch eine einzelne große Veränderung entwickelt, sondern durch eine Reihe schrittweiser Verbesserungen.
  • Die Anforderungen der Kunden werden weiter steigen, und genau das treibt fortlaufende Innovation und Iteration an.

# Zusammenfassung von GN⁺

• Dieser Beitrag bietet die Insider-Perspektive darauf, wie sich AWS EBS entwickelt hat.
• Er behandelt verschiedene technische Herausforderungen und Lösungsansätze wie Queuing-Theorie, die Einführung von SSDs und Netzwerkoptimierung.
• Er betont die Bedeutung kontinuierlicher Messung und Steuerung zur Verbesserung der Performance.
• Ähnliche Produkte sind Google Cloud Persistent Disk und Microsoft Azure Disk Storage.

[GN⁺]

Hacker-News-Kommentare

• Wenn man sich für große Systeme interessiert, lohnt es sich, diesen Artikel zu lesen

  • Die Leistung von Festplatten hängt von anderen Transaktionen in der Warteschlange ab
  • Bei zufälligen 4-kB-Operationen kann die Leistung stark einbrechen
  • Queueing und Scheduling helfen, aber die tatsächliche Leistung kann sich je nach Workload um mehr als den Faktor 100 unterscheiden
  • In Multi-Tenant-Systemen ist das besonders bei Lesevorgängen schwierig

• Um ein Problem zu lösen, muss man wissen, was falsch läuft

  • Die wichtigste Lektion, die ich von Marc gelernt habe, war, die Perspektive des Teams durch Visualisierung zu verändern
  • Wenn man Performancedaten auf verschiedene Arten analysiert, kann man verborgene Effizienzgewinne und Chancen entdecken

• Das Projekt, 2013 SSDs in EBS-Server einzubauen, ist eine der interessanten Geschichten von AWS

  • Das System wurde von Anfang an mit Blick auf nicht-destruktive Wartungsereignisse entworfen
  • Wenn man ein verteiltes System aufbaut, wird Betrieb in großem Maßstab möglich

• Der ungefähr viertägige Ausfall von AWS wurde durch EBS verursacht und erschütterte das Vertrauen in AWS

  • Das führte zu höheren Investitionen in EBS
  • Es fiel mit der Zeit zusammen, in der Apple Kunde wurde

• Reddit war 2008 einer der frühen Nutzer von EBS

  • Man versuchte, mit Software-RAID die IOPS zu erhöhen, aber die Leistung war nicht konsistent
  • Es dauerte eine Weile, die Probleme mit RAID zu lösen
  • Netflix nutzte EBS nicht

• Das Hinzufügen zufälliger Latenz kann den Effekt haben, die durchschnittliche Latenz und Ausreißer zu verringern

• Durch die Arbeit bei großen Internetunternehmen wurden viele Lektionen gelernt

  • Über eine Art Lehrzeit kann man sich wichtiges Wissen und Fähigkeiten schnell aneignen
  • Bei Bewerbungsgesprächen sind Erfahrung und Empfehlungen von Mentoren sehr hilfreich

• Der Teil, in dem 2013 manuell SSDs in alle EBS-Einheiten eingebaut wurden, war interessant

  • Zwischen 2010 und 2012 war I/O-Performance ein wichtiges Thema

• 2009 wurde ein Vortrag über das Innenleben von Amazon S3 gehalten

  • Dieser Vortrag beeinflusste die Entwicklung von EBS

• In den frühen Tagen der Cloud wurde General-Purpose-Hardware verwendet, heute wird für einzelne Services spezialisierte Hardware eingesetzt

  • AWS nutzt Graviton-, Inferentia- und Tranium-Chips
  • Google nutzt TPU und die Titan-Sicherheitskarte
  • Azure nutzt FPGA und Sphere

• Das erste Diagramm ist falsch oder veraltet

  • Bei modernen Computern sind die meisten PCIe-Lanes direkt mit der CPU verbunden
  • Das ist ein wichtiger Fortschritt für I/O-Durchsatz und Latenz

• Es wird nach dem besten Weg gesucht, einem neuen EC2-Instance ein schnelles 256-GB-Dataset-Verzeichnis bereitzustellen

  • Es werden EBS-Volumes verwendet, aber Updates sind umständlich
  • EFS ist zu langsam
  • SSD-Instance-Storage ist flüchtig
  • FSx Lustre wurde noch nicht ausprobiert