Dr. Werner Vogels zur Geschichte der Availability Zones

Rückblick auf 10 Jahre Verfügbarkeitszonen bei AWS

| Autor / Redakteur: Dr. Werner Vogels / Florian Karlstetter

Die AWS Cloud umfasst Stand Ende August 2018 weltweit 55 Availability Zones innerhalb von 18 geografischen Regionen und einer lokalen Region. Ein Rückblick auf 10 Jahre Verfügbarkeitszonen bei AWS.
Die AWS Cloud umfasst Stand Ende August 2018 weltweit 55 Availability Zones innerhalb von 18 geografischen Regionen und einer lokalen Region. Ein Rückblick auf 10 Jahre Verfügbarkeitszonen bei AWS. (Bild: Amazon Web Services)

Die Availability Zones für Amazon EC2 wurden am 26. März 2018 zehn Jahre alt. Das Konzept veränderte die Infrastrukturarchitektur maßgeblich und steht heute für die Zuverlässigkeit der AWS-Dienste. In seiner Funktion als CTO und Vordenker von Amazon erklärt Dr. Werner Vogels die Entstehungsgeschichte und die Funktionen der Verfügbarkeitszonen.

Dazu als Hintergrund: die virtuellen Instanzen der AWS-Cloud befinden sich stets in physischen Rechenzentren mit physischen AWS-Servern. Jedes Rechenzentrum verfügt über eine redundante, zuverlässige Stromversorgung, einschließlich USV und Generatoren. Trotzdem kann es zu Unterbrechungen oder Störungen kommen.

Availability Zones dämmen das Ausmaß und die Dauer solcher Unterbrechungen und Ausfälle ein. So dürfen bei zwei Zonen keine Low-Level-Core-Abhängigkeiten entstehen, etwa bei der Stromversorgung oder einem Core-Netzwerk. Verschiedene Zonen dürfen sich außerdem nicht im selben Gebäude befinden.

Wir starteten mit drei autonomen Verfügbarkeitszonen in der Region US East (N. Virginia). Durch die Verwendung von Zonen und Failover-Mechanismen, wie beispielsweise Elastic IP-Adressen und Elastic Load Balancing, können Kunden ihre Infrastruktur somit redundant versorgen. Wenn sich zwei Instanzen in verschiedenen Zonen befinden und beispielsweise die eine von einem Low-Level-Ausfall betroffen ist, bleibt die andere Instanz davon verschont.

Wie sich die Verfügbarkeitszonen im Laufe der Jahre veränderten

Verfügbarkeitszonen wurden ursprünglich für die physische Redundanz entwickelt, aber im Laufe der Zeit für immer mehr Zwecke eingesetzt. So spielen sie heute eine große Rolle dabei, wie wir Software entwickeln, implementieren und betreiben und wie wir Sicherheitskontrollen zwischen unseren größten Systemen umsetzen. Mittlerweile sind folglich viele AWS-Dienste so aufgebaut, dass innerhalb einer Verfügbarkeitszone so viel Funktionalität wie möglich gewährleistet werden kann. So werden Aufrufe innerhalb einer Zone abgewickelt: Dort können beispielsweise EC2-Instanzen gestartet und verwaltet sowie der Zustand von Instanzen hinter einem Loadbalancer betrachtetet werden.

Diese Konstruktion ist aus zwei Gründen vorteilhaft: Wenn eine Verfügbarkeitszone Strom verliert, bleiben die übrigen Zonen davon verschont. Der zweite Vorteil ist noch bedeutender: Im Falle eines Softwarefehlers, verringert sich das Risiko, dass andere Zonen betroffen sind.

Das hat Folgen für die Entwicklung und Verwaltung: Obwohl wir Instanzen automatisieren und nicht von Hand verwalten, wissen unsere Entwickler, dass sie Tools oder Verfahren entwickeln müssen, die sich lediglich auf eine Verfügbarkeitszonen beschränken.

Die Verfügbarkeitszonen sind tief in unserer AWS Entwicklungs- und Betriebskultur verankert. AWS-Kunden betrachten die Zonen vermutlich als Möglichkeit, Ausfälle zu vermeiden. Bei AWS betrachten wir Zonen eher unter dem Aspekt der Isolation. Ganz nach dem Motto „Bleiben Sie so weit wie möglich innerhalb einer Verfügbarkeitszone".

Sichern Sie Ihren Datenverkehr oder nicht – Sie entscheiden

Für Kunden, die ihre Architektur innerhalb einer Verfügbarkeitszone belassen, ergeben sich weitere Vorteile. Zum einen ist die Latenz innerhalb einer Zone unglaublich gering. Heute benötigen Pakete zwischen EC2-Instanzen in der gleichen Zone nur zehn Mikrosekunden, um einander zu erreichen.

Außerdem ist vorteilhaft, dass sich redundante Zonen-Architekturen leichter von komplexen Problemen erholen – etwa solchen, die sich erst aus dem Zusammenspiel verschiedener Systeme ergeben. Wenn alle Aufrufe eines Dienstes innerhalb einer Verfügbarkeitszone bleiben, können sie bei Problemen schnell behoben werden – und zwar, indem die gesamte Zone aus dem Dienst genommen wird, ohne, dass der Auslöser des Problems identifiziert werden muss.

Viele Kunden verwenden diese Art von „Silo"-Muster auch in ihrer eigenen Architektur. So wird Amazon Route 53 oder Elastic Load Balancing verwendet, um eine Verfügbarkeitszone zu wählen, um eine Anfrage zu bearbeiten, aber auch um nachfolgende interne Anfragen und Abhängigkeiten innerhalb derselben Zone zu halten. Das ist nur wegen der starken Abgrenzung sowie der Trennung zwischen den Zonen sinnvoll.

Ergänzendes zum Thema
 
Kurzbiografie Dr. Werner Vogels

Regionale Isolierung

Nicht allzu lange nach der Einführung der Verfügbarkeitszonen haben wir auch unsere zweite Region, EU (Irland), aus der Taufe gehoben. Zu Beginn planten wir ein nahtloses globales Netzwerk mit offenen Verbindungen zwischen den Instanzen in jeder Region. Dienste wie S3 hätten sich als ein einziges großes S3 verhalten, mit Schlüsseln und Daten, die von jedem Ort aus zugänglich und veränderbar gewesen wären.

Je mehr wir über dieses Konzept nachdachten, desto mehr erkannten wir, worin die potenzielle Gefahr besteht: Probleme und Fehler zwischen den Regionen hätten sich ausbreiten können und damit womöglich größere Unterbrechungen zur Folge gehabt. Das hätte gleichzeitig unsere wichtigsten Ziele zunichte gemacht:

  • Höchste Verfügbarkeit zu gewährleisten
  • Den Regionen die Möglichkeit geben, gegenseitig als Standby-Standorte zu fungieren
  • Geographische Vielfalt und geringere Latenzzeiten für die Endanwender

Unsere Erfahrung mit Availability Zones führte dazu, dass wir stattdessen die Abschottung verdoppelten und beschlossen, Regionen voneinander zu isolieren. Seitdem arbeiten unsere Dienste autonom in jeder Region, mit vielen S3-Stacks, DynamoDB, Amazon RDS und allem anderen.

Viele unserer Kunden möchten immer noch Workloads ausführen und global auf Daten zugreifen können. Für unsere Edge-Services wie Amazon CloudFront, Amazon Route 53 und AWS Lambda@Edge betreiben wir über 100 Points of Presence. Jede stellt eine eigene Verfügbarkeitszone mit eigener Abschottung dar.

Bei der Entwicklung und Auslieferung unserer Dienste, die sich über Regionen erstrecken, wie S3-übergreifende Objektreplikation, globale Amazon DynamoDB-Tabellen und Amazon VPC interregionales Peering, achten wir sehr darauf, dass die Abhängigkeiten und Aufrufmuster zwischen Regionen asynchron sind. Dabei verhindern Sicherheitsmechanismen, dass sich Fehler weiter verbreiten.

Hohe Verfügbarkeit durch starke Abschottung

Viele unserer Dienste werden seit einiger Zeit in Service Stacks betrieben, die sogar innerhalb einzelner Zonen abgeschottet sind. So ist AWS HyperPlane – der interne Dienst, der NAT-Gateways, Network Load Balancer und AWS PrivateLink bereitstellt – intern in Zellen unterteilt, die jeweils eine bestimmte Anzahl von Kunden bedienen. Wenn es Probleme mit einer Zelle gibt, beschränkt sich die Auswirkung nicht nur auf eine Verfügbarkeitszone, sondern auch auf die Kunden innerhalb dieser Zone. Natürlich treten alle Arten von Automatisierung sofort in Kraft, um jegliche Auswirkungen auf diese Kundengruppe abzumildern.

Zehn Jahre nach der Einführung von Availability Zones arbeiten wir immer noch mit Hochdruck daran, die Auswirkungen potenzieller Probleme zu reduzieren. Wir sind der festen Überzeugung, dass dies eine der wichtigsten Strategien ist, um unsere obersten Ziele in Bezug auf Sicherheit und Verfügbarkeit zu erreichen. Wir haben jetzt 55 Verfügbarkeitszonen in 18 geografischen Regionen und 12 weitere angekündigt. Über dieses geografische Wachstum hinaus werden wir das Konzept der Abschottung, das den Verfügbarkeitszonen zugrunde liegt, immer weiter ausbauen, um effektiver zu sein.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45455311 / Virtualisierung)