Am Abend des 7. Mai fiel in einem Datensaal einer Availability Zone in us-east-1 die Kühlung aus, Racks verloren Strom, und der Blast Radius von AWS tat, was die Dokumentation verspricht: Der Schaden blieb innerhalb von use1-az4. Jede andere Zone lieferte weiter aus. Die Unternehmen, die in dieser Nacht ausfielen, fielen innerhalb ihrer eigenen Architektur aus, und wir wissen das mit ungewöhnlicher Präzision, weil Coinbase am Montag ein Postmortem veröffentlichte, das genau das mit eigenen Worten sagt. Der Handel war, in ihrer Formulierung, "unavailable or degraded for roughly eight hours, with full recovery of all systems taking another twelve", während eines Ereignisses, bei dem die Zonengrenze der Plattform funktionierte.

Dies ist Teil 1 von Nothing Fails Alone, einer Serie über die Lücke zwischen der Verfügbarkeit, die du bei einem Cloud-Provider kaufst, und der Verfügbarkeit, die du tatsächlich darauf aufbaust. Jeder Teil nimmt einen realen Incident, extrahiert die architektonische Behauptung, die er testet, und liefert ein kleines Lab, das du gegen deinen eigenen Account laufen lassen kannst. Die Labs liegen in einem begleitenden Repo, nothing-fails-alone auf GitHub, und jedes von ihnen ist read-only.

Was in use1-az4 tatsächlich geschah

Der erste Incident-Report auf dem AWS Health Dashboard trug den Zeitstempel 5:25 PM PDT am 7. Mai, und da das aufgelöste Ereignis inzwischen vom Dashboard verschwunden ist, stammt der Wortlaut unten aus dem, was The Register damals zitierte: Probleme in der Availability Zone use1-az4 von us-east-1. Ein Folge-Update benannte den Mechanismus unumwunden: "EC2 instances and EBS volumes hosted on impacted hardware are affected by the loss of power during the thermal event." Um 6:47 PM PDT sagte AWS, man arbeite daran, die Temperaturen wieder auf normale Werte zu bringen, und warnte, dass auch andere Services, die von den betroffenen EC2-Instances und EBS-Volumes in dieser Zone abhängen, beeinträchtigt sein könnten.

Coinbases Postmortem liefert die physische Ursache nach: Mehrere Kühlaggregate fielen gleichzeitig in einem einzigen Datensaal aus, und der Kühlungsverlust löste eine thermische Sicherheitsabschaltung der betroffenen Racks aus. Genau das bedeutet "loss of power during the thermal event" in der Praxis. Die Racks wurden nicht zerstört; sie wurden bewusst heruntergefahren, weil Compute ohne Kühlung zu betreiben es zerstört. EC2-Instances und EBS-Volumes auf diesen Racks gingen gemeinsam offline, in einem Gebäude, in einer Zone.

Die Wiederherstellung verlief schrittweise und war ehrlich darüber, schrittweise zu sein. Um 10:11 PM PDT in dieser Nacht meldete AWS zusätzliche Kühlkapazität online und einige wiederhergestellte Racks, weitere sollten "in a controlled and safe manner" folgen. Die Kühlkapazität war um 1:50 PM PDT am 8. Mai wieder auf dem Stand von vor dem Incident, rund zwanzig Stunden nach dem ersten Report, wobei die Instance-Wiederherstellung der Kühlungswiederherstellung hinterherhinkte. Wenn dein mentales Modell eines AZ-Ereignisses ein fünfzehnminütiger Aussetzer ist, kalibriere neu: Ein thermisches Ereignis wird in Stunden gemessen, weil die Physik es ist, und Racks kommen Rack für Rack zurück, nicht alle auf einmal.

Was nicht geschah

Die anderen Availability Zones in us-east-1 blieben gesund. Das ist der Teil dieses Incidents, der mehr Aufmerksamkeit verdient, als er bekommt, denn es ist der Teil, den AWS tatsächlich versprochen hat. Availability Zones sind physisch getrennte Einrichtungen mit unabhängiger Strom- und Kühlungsversorgung, und am 7. Mai wurde diese Unabhängigkeit von einem echten Einrichtungsausfall getestet und hielt stand. Die Failure Domain war ein Datensaal; der Blast Radius blieb innerhalb einer Zone.

Es gab genau eine ehrliche Einschränkung, und sie ist zitierenswert, weil sie später in dieser Serie eine Rolle spielt. AWS leitete Traffic von der betroffenen Zone weg, riet Kunden, Workloads in die anderen us-east-1 Zonen zu verlagern, und räumte dann ein: "Customers may experience longer than usual provisioning times." Natürlich können sie das. Wenn eine Zone stirbt, beginnt jede korrekt gebaute Multi-AZ-Architektur in dieser Region gleichzeitig, Kapazität in den überlebenden Zonen zu ersetzen. Die Zonengrenze hielt, aber die überlebenden Zonen sind ein gemeinsamer Pool, und Massen-Failover ist ein Thundering Herd gegen diesen Pool. Behalte diese Einschränkung im Hinterkopf; Teil 3 dieser Serie handelt davon, was dein Recovery-Plan mit dem Recovery-Plan aller anderen teilt.

Coinbases eigene Worte

Postmortems von börsennotierten Unternehmen sind meist bis zur Bedeutungslosigkeit glattgeschliffen. Dieses ist es nicht, weshalb es sich lohnt, es vollständig zu lesen. Zwei Sätze tragen die gesamte Architekturgeschichte. Erstens: "Our matching engine was pinned to a single building." Zweitens die Erklärung des Wie: Die Matching Engine von Coinbase Exchange "runs as a Raft-based replicated cluster inside an AWS Cluster Placement Group". Und dann der Satz, der aus einem Zonen-Ereignis einen achtstündigen Ausfall macht: "There was no automated cross-zone failover."

Eine Cluster Placement Group ist von Konstruktion her Single-AZ. Das ist keine Einschränkung, die AWS verbirgt; es ist das Produkt. Der Sinn der Cluster-Strategie ist es, Instances auf Hardware zu packen, die physisch eng beieinander liegt, im selben Netzwerksegment mit hoher Bandbreite, sodass die Latenz von Node zu Node so niedrig ist, wie EC2 sie machen kann. Das und Zonentrennung kannst du nicht gleichzeitig haben, denn Zonentrennung ist Distanz und Distanz ist Latenz. Für eine Matching Engine, wo Mikrosekunden an Node-zu-Node-Latenz das Produkt sind, ist eine Cluster Placement Group die richtige Wahl, und Coinbase sagt genau das: "We make this choice deliberately."

Das Problem ist, was darin lebte. Raft existiert, um den Verlust einer Minderheit von Nodes zu überstehen. Steck fünf Raft-Nodes in eine Cluster Placement Group, und du hast ein Konsensprotokoll gebaut, dessen Mitglieder sich ein Gebäude teilen, was bedeutet, dass sie sich eine Failure Domain teilen, was bedeutet, dass das Protokoll die eine Sache, für die es existiert, nicht mehr tun kann. Als AWS um 9:29 PM ET EC2-Instances innerhalb von Coinbases Placement Group beendete, gingen drei von fünf Matching-Engine-Nodes gemeinsam aus, und das Quorum war weg. Ein Quorum, das sich einen Datensaal teilt, ist kein Quorum; es ist ein Ausfall mit fünf Namen.

Ohne automatisiertes Cross-Zone-Failover dahinter wurde die Wiederherstellung zu einem manuellen Prozess. Sie erforderte eine Notfall-Codeänderung, während des Incidents ausgeliefert, um eine Startannahme zu entfernen, dass alle fünf Cluster-Nodes auflösbar seien. Die Matching Engine kam um 2:25 AM ET am 8. Mai im Cancel-only-Modus zurück, der volle Handel wurde um 3:49 AM ET wieder aufgenommen, die Retail-Site und die Mobile-App waren um 9:53 AM ET vollständig wiederhergestellt, und der Rückstau an Event-Streaming-Topics war um 2:00 PM ET abgearbeitet. Rund acht Stunden Ausfall, weitere zwölf bis zur vollständigen Wiederherstellung, während eines Ereignisses, das AWS auf eine Zone eingrenzte.

Multi-AZ ist etwas, das du kaufst, und etwas, das du baust

Die allgemeine Form dieses Incidents ist keine Coinbase-Geschichte. Es ist die Lücke zwischen dem Kauf von Multi-AZ-Infrastruktur und dem Bau eines Multi-AZ-Systems, und diese Lücke hat eine kleine Zahl wiederkehrender Formen. Jede davon ist eine Konfiguration, die auf dem Architekturdiagramm redundant aussieht und es nicht ist:

  • Die Single-Subnet Auto Scaling Group. Die ASG ersetzt ausgefallene Instances bereitwillig ewig weiter, in dieselbe Zone, weil die Subnetzliste, die du ihr gegeben hast, auf eine AZ auflöst. Wenn diese Zone degradiert, kann die Desired Capacity nicht erreicht werden, bis ein Mensch die Gruppe bearbeitet. Selbstheilung, die in den Ausfall hinein heilt, ist keine Selbstheilung.
  • RDS ohne Multi-AZ. Kein synchroner Standby bedeutet, dass Zonenverlust kein Failover ist, sondern ein Restore: aus einem Snapshot, in Stunden gemessen, mit Datenverlust bis zum letzten Backup-Punkt. Der DR-Plan daneben nimmt meist ein Failover im Subminutenbereich an, weil jemand die Multi-AZ-Dokumentation gelesen und niemand das Flag in der Console geprüft hat.
  • Das Quorum in einer Cluster Placement Group. Das Coinbase-Muster: drei, fünf oder sieben Nodes von Raft, etcd oder ZooKeeper, gepackt in eine Gruppe, die per Definition Single-AZ ist. Die Konsensschicht meldet sich als gesund und fehlertolerant, bis genau zu dem Moment, in dem das Gebäude widerspricht.
  • Die Cross-AZ-NAT-Abhängigkeit. Ein privates Subnetz in Zone B, dessen Default-Route auf ein NAT Gateway in Zone A zeigt. Der Ausfall von Zone A legt den ausgehenden Traffic von Instances lahm, deren eigene Zone völlig gesund ist. Diese ist auf jedem Diagramm unsichtbar, weil der Pfeil auf "NAT" zeigt, nicht auf eine Zone.

Nichts davon ist exotisch. Alle bestehen einen Lasttest, einen Game Day, der nur Instances killt, und die meisten Architecture Reviews, denn jede einzelne fällt nur aus, wenn eine ganze Zone ausfällt, und ganze Zonen fallen selten genug aus, dass die Annahme jahrelang ungetestet bleibt.

Das Lab: ein Detektor für Single-AZ-Konzentration

Behauptungen sollten testbar sein, deshalb liefert dieser Teil ein Lab: 01-single-az-detector, eine einzelne Python-Datei, die den aktuellen Account und die aktuelle Region auf die obigen Muster und drei weitere scannt. Es ist read-only im strengen Sinne: Jeder API-Aufruf, den es macht, ist ein Describe*. Es führt sieben Checks aus: Single-AZ Auto Scaling Groups, Cluster Placement Groups, quorumgroße Cluster innerhalb von Placement Groups, Single-AZ RDS-Instances, RDS-Cluster, deren Mitglieder alle in einer Zone sitzen, ElastiCache-Replikationsgruppen ohne Multi-AZ und private Subnetze, deren Default-Route Zonen überquert, um ein NAT Gateway zu erreichen.

$ python3 detect.py
SEVERITY | RESOURCE                      | AZ                    | WHY
--------------------------------------------------------------------------...
CRITICAL | placement-group/matching-prod | us-east-1a (use1-az4) | 3 instances in cluster placement group 'matching-prod': a quorum-sized cluster in a group that is single-AZ by construction. ...
HIGH     | asg/api-workers               | us-east-1c (use1-az2) | Auto Scaling group spans exactly one AZ. Every replacement instance lands in the same zone ...
HIGH     | rds-cluster/orders            | us-east-1a (use1-az4) | All members of DB cluster 'orders' sit in one AZ. Aurora failover needs a reader in a different zone ...
MEDIUM   | subnet-0a1b2c3d -> nat-0e4f5a6b | us-east-1b (use1-az6) -> us-east-1a (use1-az4) | Private subnet in us-east-1b (use1-az6) routes 0.0.0.0/0 through a NAT gateway in us-east-1a (use1-az4) ...

4 finding(s).

Der Check, der den Schweregrad CRITICAL verdient, ist QUORUM_IN_ONE_AZ: eine Cluster Placement Group mit genau 3, 5 oder 7 laufenden Instances. Diese Zahlen sind nicht willkürlich; sie sind die Form eines Raft-, etcd- oder ZooKeeper-Quorums, und ein quorumförmiger Workload, konzentriert in einer Zone, ist genau die Konfiguration, die Coinbase lahmlegte. Eine Placement Group mit einer anderen Instance-Anzahl wird ebenfalls markiert, aber als HIGH: Es ist eine Latenzoptimierung, von der jemand bestätigen sollte, dass sie bewusst gewählt wurde.

Zwei Verhaltensweisen sind bewusst. Erstens der Exit-Code: Der Scan beendet mit 0, wann immer er durchläuft, Findings hin oder her, denn dies ist ein Report, kein Gate. Wenn IAM einen der APIs verweigert, wird dieser Check mit einer einzeiligen Warnung auf stderr übersprungen, die übrigen Checks laufen weiter, und der Exit-Code bleibt 0; Exit-Code 2 bekommst du nur, wenn der Scan überhaupt nicht laufen kann, keine Credentials, keine Region, kein boto3. Prüfe stderr, bevor du einer sauberen Tabelle traust. Zweitens meldet jedes Finding die Zone sowohl als Name als auch als ID, zum Beispiel us-east-1a (use1-az4). Der Name ist ein Alias, den AWS pro Account randomisiert; die ID ist die physische Zone. Das Health Dashboard nannte use1-az4, und ohne die ID kannst du nicht sagen, ob das dein us-east-1a war. Diese Unterscheidung sieht heute wie eine Nebensächlichkeit aus. Teil 2 handelt von dem Incident, bei dem sie aufhört, eine Nebensächlichkeit zu sein.

Failure Modes und worauf zu achten ist

Der Trade-off unter all dem ist legitim, also benenne ihn, statt ihn wegzureden. Single-AZ-Platzierung erkauft Latenz, Cross-AZ-Datentransfer kostet Geld, und synchrone Replikation über Zonen hinweg kostet Schreiblatenz. Coinbase stolperte nicht in eine Placement Group; sie planten sich hinein und akzeptierten ein Risiko. Der Fehler war nicht die Entscheidung, sondern dass die Konsequenz der Entscheidung, kein automatisierter Weg aus der Zone heraus, um 9:29 PM während des Incidents entdeckt wurde, statt in einem Design Review davor entschieden zu werden.

Worauf du in deinem eigenen Account achten solltest, über das Laufenlassen des Detektors hinaus: Quorum-Arithmetik, nicht nur Quorum-Ort, denn zwei von drei etcd-Nodes in einer Zone sind derselbe Defekt mit einer freundlicheren Tabellenzeile. ASGs, die mehrere Subnetze auflisten, die alle auf dieselbe Zone auflösen, weshalb der Detektor VPCZoneIdentifier-Subnetze auflöst, statt der AZ-Liste zu trauen. Caches ohne Replikas: Ein Zonenverlust macht ElastiCache kalt, und der resultierende Miss-Sturm landet zum denkbar schlechtesten Zeitpunkt auf deiner Datenbank. Und das Bereitstellen von Kapazität während eines echten Zonen-Ereignisses, das eine Sache, die der Detektor nicht sehen kann, weil es eine Eigenschaft der Architektur aller anderen ist, nicht deiner. AWS hat es dir selbst gesagt, mitten im Incident: longer than usual provisioning times. Die Zonengrenze ist real, und sie hielt. Was du darauf aufbaust, gehört dir.

Lies das als Nächstes

Für Consulting zu AWS, Cloud-Architektur, Resilience Reviews und Plattform-Arbeit, starte auf ercanermis.com.

Referenzen