Το βράδυ της 7ης Μαΐου, η ψύξη αστόχησε σε ένα data hall μιας availability zone στην us-east-1, τα racks έχασαν ρεύμα, και το blast radius της AWS έκανε αυτό που υπόσχεται η τεκμηρίωση: η ζημιά έμεινε μέσα στην use1-az4. Κάθε άλλη ζώνη συνέχισε να εξυπηρετεί. Οι εταιρείες που έπεσαν εκείνο το βράδυ έπεσαν μέσα στη δική τους αρχιτεκτονική, και το ξέρουμε με ασυνήθιστη ακρίβεια επειδή η Coinbase δημοσίευσε ένα postmortem τη Δευτέρα που το λέει με τα ίδια της τα λόγια. Το trading ήταν, με τη δική τους διατύπωση, "unavailable or degraded for roughly eight hours, with full recovery of all systems taking another twelve", κατά τη διάρκεια ενός συμβάντος στο οποίο το όριο ζώνης της πλατφόρμας λειτούργησε.

Αυτό είναι το Μέρος 1 του Nothing Fails Alone, μιας σειράς για το κενό ανάμεσα στη διαθεσιμότητα που αγοράζετε από έναν cloud provider και στη διαθεσιμότητα που πραγματικά χτίζετε πάνω της. Κάθε μέρος παίρνει ένα πραγματικό συμβάν, εξάγει τον αρχιτεκτονικό ισχυρισμό που δοκιμάζει, και παραδίδει ένα μικρό lab που μπορείτε να τρέξετε πάνω στον δικό σας λογαριασμό. Τα labs ζουν σε ένα συνοδευτικό repo, το nothing-fails-alone στο GitHub, και καθένα από αυτά είναι read-only.

Τι πραγματικά συνέβη στην use1-az4

Η πρώτη αναφορά συμβάντος στο AWS Health Dashboard είχε χρονοσήμανση 5:25 PM PDT στις 7 Μαΐου, και καθώς το επιλυμένο συμβάν έχει έκτοτε φύγει από το dashboard, η διατύπωση παρακάτω είναι όπως την παρέθεσε το The Register εκείνη τη στιγμή: προβλήματα στην availability zone use1-az4 της us-east-1. Μια μεταγενέστερη ενημέρωση δήλωσε τον μηχανισμό ξεκάθαρα: "EC2 instances and EBS volumes hosted on impacted hardware are affected by the loss of power during the thermal event." Μέχρι τις 6:47 PM PDT, η AWS είπε ότι εργαζόταν για να επαναφέρει τις θερμοκρασίες σε κανονικά επίπεδα και προειδοποίησε ότι και άλλες υπηρεσίες που εξαρτώνται από τα επηρεασμένα EC2 instances και EBS volumes σε εκείνη τη ζώνη μπορεί επίσης να υποβαθμιστούν.

Το postmortem της Coinbase συμπληρώνει τη φυσική αιτία: πολλαπλές μονάδες chiller αστόχησαν ταυτόχρονα σε ένα data hall, και η απώλεια ψύξης πυροδότησε ένα thermal-safety shutdown των επηρεασμένων racks. Αυτό σημαίνει στην πράξη το "loss of power during the thermal event". Τα racks δεν καταστράφηκαν, απενεργοποιήθηκαν σκόπιμα επειδή το να τρέχει compute χωρίς ψύξη το καταστρέφει. Τα EC2 instances και τα EBS volumes σε εκείνα τα racks βγήκαν εκτός λειτουργίας μαζί, σε ένα κτίριο, σε μία ζώνη.

Η αποκατάσταση ήταν σταδιακή και ειλικρινής για το ότι ήταν σταδιακή. Στις 10:11 PM PDT εκείνο το βράδυ, η AWS ανέφερε επιπλέον χωρητικότητα ψύξης σε λειτουργία και ανάκτηση κάποιων racks, με περισσότερα να ανακτώνται "in a controlled and safe manner". Η χωρητικότητα ψύξης επέστρεψε στα προ του συμβάντος επίπεδα στις 1:50 PM PDT στις 8 Μαΐου, περίπου είκοσι ώρες μετά την πρώτη αναφορά, με την ανάκτηση των instances να ακολουθεί την αποκατάσταση της ψύξης. Αν το νοητικό σας μοντέλο για ένα συμβάν AZ είναι ένα δεκαπεντάλεπτο τρεμόπαιγμα, βαθμονομήστε ξανά: ένα thermal event μετριέται σε ώρες επειδή έτσι είναι η φυσική, και τα racks επιστρέφουν rack προς rack, όχι όλα μαζί.

Τι δεν συνέβη

Οι άλλες availability zones στην us-east-1 παρέμειναν υγιείς. Αυτό είναι το κομμάτι αυτού του συμβάντος που θα έπρεπε να τραβήξει περισσότερη προσοχή από όση τραβάει, επειδή είναι το κομμάτι που η AWS όντως υποσχέθηκε. Οι availability zones είναι φυσικά ξεχωριστές εγκαταστάσεις με ανεξάρτητο ρεύμα και ψύξη, και στις 7 Μαΐου αυτή η ανεξαρτησία δοκιμάστηκε από μια πραγματική αστοχία εγκατάστασης και άντεξε. Το failure domain ήταν ένα data hall, το blast radius έμεινε μέσα σε μία ζώνη.

Υπήρχε ακριβώς μία ειλικρινής επιφύλαξη, και αξίζει να την παραθέσουμε επειδή έχει σημασία αργότερα σε αυτή τη σειρά. Η AWS μετέφερε την κίνηση μακριά από την πληγείσα ζώνη, συμβούλεψε τους πελάτες να μετακινήσουν τα workloads στις άλλες ζώνες της us-east-1, και μετά παραδέχτηκε: "Customers may experience longer than usual provisioning times." Φυσικά και μπορεί. Όταν μια ζώνη πεθαίνει, κάθε σωστά χτισμένη multi-AZ αρχιτεκτονική σε εκείνη την περιοχή αρχίζει να αντικαθιστά χωρητικότητα στις εναπομείνασες ζώνες ταυτόχρονα. Το όριο ζώνης άντεξε, αλλά οι εναπομείνασες ζώνες είναι ένα κοινό pool, και το μαζικό failover είναι ένα thundering herd εναντίον αυτού του pool. Κρατήστε αυτή την επιφύλαξη στο μυαλό σας, το Μέρος 3 αυτής της σειράς αφορά το τι μοιράζεται το δικό σας σχέδιο ανάκαμψης με το σχέδιο ανάκαμψης όλων των άλλων.

Τα ίδια τα λόγια της Coinbase

Τα postmortems από εισηγμένες εταιρείες συνήθως λειαίνονται μέχρι να μη μείνει τίποτα. Αυτό δεν λειαίνεται, γι' αυτό και αξίζει να διαβαστεί ολόκληρο. Δύο προτάσεις κουβαλούν όλη την ιστορία της αρχιτεκτονικής. Πρώτη: "Our matching engine was pinned to a single building." Δεύτερη, η εξήγηση του πώς: η matching engine του Coinbase Exchange "runs as a Raft-based replicated cluster inside an AWS Cluster Placement Group". Και μετά η πρόταση που μετατρέπει ένα συμβάν ζώνης σε μια οκτάωρη διακοπή: "There was no automated cross-zone failover."

Ένα cluster placement group είναι single-AZ εκ κατασκευής. Αυτό δεν είναι περιορισμός που κρύβει η AWS, είναι το ίδιο το προϊόν. Το νόημα της στρατηγικής cluster είναι να στοιβάζει instances σε hardware που βρίσκεται φυσικά κοντά, στο ίδιο high-bandwidth network segment, ώστε το latency από κόμβο σε κόμβο να είναι όσο χαμηλό μπορεί να το κάνει το EC2. Δεν μπορείτε να έχετε αυτό και διαχωρισμό ζωνών ταυτόχρονα, επειδή ο διαχωρισμός ζωνών είναι απόσταση και η απόσταση είναι latency. Για μια matching engine, όπου τα microseconds latency από κόμβο σε κόμβο είναι το προϊόν, ένα cluster placement group είναι η σωστή επιλογή, και η Coinbase το λέει καθαρά: "We make this choice deliberately."

Το πρόβλημα είναι τι ζούσε μέσα του. Το Raft υπάρχει για να επιβιώνει από την απώλεια μιας μειοψηφίας κόμβων. Βάλτε πέντε κόμβους Raft σε ένα cluster placement group και έχετε χτίσει ένα consensus protocol του οποίου τα μέλη μοιράζονται ένα κτίριο, που σημαίνει ότι μοιράζονται ένα failure domain, που σημαίνει ότι το protocol δεν μπορεί πια να κάνει το ένα πράγμα για το οποίο υπάρχει. Όταν η AWS τερμάτισε EC2 instances μέσα στο placement group της Coinbase στις 9:29 PM ET, τρεις από τους πέντε κόμβους της matching engine έπεσαν μαζί και το quorum χάθηκε. Ένα quorum που μοιράζεται ένα data hall δεν είναι quorum, είναι μία αστοχία με πέντε ονόματα.

Χωρίς αυτόματο cross-zone failover από πίσω, η αποκατάσταση έγινε διαδικασία ανθρώπων. Απαίτησε μια επείγουσα αλλαγή κώδικα, που βγήκε κατά τη διάρκεια του συμβάντος, για να αφαιρεθεί μια υπόθεση εκκίνησης ότι και οι πέντε κόμβοι του cluster ήταν επιλύσιμοι. Η matching engine επέστρεψε σε cancel-only mode στις 2:25 AM ET στις 8 Μαΐου, το πλήρες trading ξανάρχισε στις 3:49 AM ET, ο ιστότοπος λιανικής και η mobile εφαρμογή ανακτήθηκαν πλήρως μέχρι τις 9:53 AM ET, και η συσσώρευση των event-streaming topics εκκαθαρίστηκε μέχρι τις 2:00 PM ET. Περίπου οκτώ ώρες εκτός, άλλες δώδεκα μέχρι την πλήρη αποκατάσταση, κατά τη διάρκεια ενός συμβάντος που η AWS περιόρισε σε μία ζώνη.

Το Multi-AZ είναι κάτι που αγοράζετε και κάτι που χτίζετε

Το γενικό σχήμα αυτού του συμβάντος δεν είναι ιστορία της Coinbase. Είναι το κενό ανάμεσα στην αγορά υποδομής multi-AZ και στο χτίσιμο ενός συστήματος multi-AZ, και αυτό το κενό έχει έναν μικρό αριθμό επαναλαμβανόμενων σχημάτων. Καθένα από αυτά είναι μια διαμόρφωση που δείχνει πλεονάζουσα στο διάγραμμα αρχιτεκτονικής και δεν είναι:

  • Το Auto Scaling group ενός μόνο subnet. Το ASG θα αντικαθιστά ευχαρίστως τα instances που αστοχούν επ' άπειρον, στην ίδια ζώνη, επειδή η λίστα subnet που του δώσατε επιλύεται σε μία AZ. Όταν εκείνη η ζώνη υποβαθμίζεται, η επιθυμητή χωρητικότητα δεν μπορεί να καλυφθεί μέχρι να επεξεργαστεί το group ένας άνθρωπος. Η αυτοθεραπεία που θεραπεύει μέσα στην αστοχία δεν είναι αυτοθεραπεία.
  • RDS χωρίς Multi-AZ. Η απουσία σύγχρονου standby σημαίνει ότι η απώλεια ζώνης δεν είναι failover, είναι restore: από ένα snapshot, μετρημένο σε ώρες, με απώλεια δεδομένων μέχρι το τελευταίο σημείο backup. Το σχέδιο DR δίπλα του συνήθως υποθέτει failover κάτω του λεπτού, επειδή κάποιος διάβασε την τεκμηρίωση του Multi-AZ και κανείς δεν έλεγξε το flag στην κονσόλα.
  • Το quorum σε ένα cluster placement group. Το μοτίβο της Coinbase: τρεις, πέντε ή επτά κόμβοι Raft, etcd ή ZooKeeper στοιβαγμένοι σε ένα group που είναι single-AZ εξ ορισμού. Το επίπεδο consensus αναφέρει τον εαυτό του ως υγιή και ανθεκτικό σε σφάλματα μέχρι ακριβώς τη στιγμή που το κτίριο διαφωνεί.
  • Η cross-AZ εξάρτηση από NAT. Ένα private subnet στη ζώνη B του οποίου η προεπιλεγμένη διαδρομή δείχνει σε ένα NAT gateway στη ζώνη A. Η αστοχία της ζώνης A ρίχνει την εξερχόμενη κίνηση instances των οποίων η δική τους ζώνη είναι απολύτως υγιής. Αυτή είναι αόρατη σε κάθε διάγραμμα επειδή το βέλος δείχνει στο "NAT", όχι σε μια ζώνη.

Κανένα από αυτά δεν είναι εξωτικό. Όλα περνούν ένα load test, ένα game day που σκοτώνει μόνο instances, και τις περισσότερες αρχιτεκτονικές επισκοπήσεις, επειδή καθένα αστοχεί μόνο όταν αστοχεί μια ολόκληρη ζώνη, και οι ολόκληρες ζώνες αστοχούν αρκετά σπάνια ώστε η υπόθεση να μένει αδοκίμαστη για χρόνια.

Το lab: ένας ανιχνευτής συγκέντρωσης σε μία AZ

Οι ισχυρισμοί πρέπει να είναι δοκιμάσιμοι, γι' αυτό αυτό το μέρος συνοδεύεται από ένα lab: 01-single-az-detector, ένα μοναδικό αρχείο Python που σαρώνει τον τρέχοντα λογαριασμό και region για τα παραπάνω μοτίβα και άλλα τρία. Είναι read-only με τη στενή έννοια: κάθε κλήση API που κάνει είναι ένα Describe*. Τρέχει επτά ελέγχους: Auto Scaling groups μίας AZ, cluster placement groups, clusters μεγέθους quorum μέσα σε placement groups, RDS instances μίας AZ, RDS clusters των οποίων όλα τα μέλη κάθονται σε μία ζώνη, ElastiCache replication groups χωρίς Multi-AZ, και private subnets των οποίων η προεπιλεγμένη διαδρομή διασχίζει ζώνες για να φτάσει σε ένα NAT gateway.

$ 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).

Ο έλεγχος που κερδίζει τη σοβαρότητα CRITICAL είναι το QUORUM_IN_ONE_AZ: ένα cluster placement group που κρατά ακριβώς 3, 5 ή 7 running instances. Αυτοί οι αριθμοί δεν είναι αυθαίρετοι, είναι το σχήμα ενός quorum Raft, etcd ή ZooKeeper, και ένα workload σχήματος quorum συγκεντρωμένο σε μία ζώνη είναι ακριβώς η διαμόρφωση που έριξε την Coinbase. Ένα placement group με κάποιον άλλον αριθμό instances επισημαίνεται επίσης, αλλά ως HIGH: είναι μια βελτιστοποίηση latency που κάποιος πρέπει να επιβεβαιώσει ότι επιλέχθηκε σκόπιμα.

Δύο συμπεριφορές είναι σκόπιμες. Πρώτη, ο κωδικός εξόδου: η σάρωση εξέρχεται με 0 όποτε ολοκληρώνεται, με ευρήματα ή χωρίς, επειδή αυτό είναι αναφορά, όχι πύλη. Αν το IAM αρνηθεί ένα από τα API, εκείνος ο έλεγχος παραλείπεται με μια προειδοποίηση μίας γραμμής στο stderr, οι υπόλοιποι έλεγχοι εξακολουθούν να τρέχουν, και ο κωδικός εξόδου παραμένει 0, παίρνετε κωδικό εξόδου 2 μόνο όταν η σάρωση δεν μπορεί να τρέξει καθόλου, χωρίς credentials, χωρίς region, χωρίς boto3. Ελέγξτε το stderr πριν εμπιστευτείτε έναν καθαρό πίνακα. Δεύτερη, κάθε εύρημα αναφέρει τη ζώνη τόσο ως όνομα όσο και ως ID, για παράδειγμα us-east-1a (use1-az4). Το όνομα είναι ένα alias που η AWS τυχαιοποιεί ανά λογαριασμό, το ID είναι η φυσική ζώνη. Το Health Dashboard είπε use1-az4, και χωρίς το ID δεν μπορείτε να πείτε αν αυτό ήταν η δική σας us-east-1a. Αυτή η διάκριση μοιάζει με ασήμαντη λεπτομέρεια σήμερα. Το Μέρος 2 αφορά το συμβάν όπου παύει να είναι ασήμαντη.

Τρόποι αστοχίας και τι να προσέχετε

Το trade-off κάτω από όλα αυτά είναι θεμιτό, οπότε ονομάστε το αντί να κάνετε πως δεν υπάρχει. Η τοποθέτηση σε μία AZ αγοράζει latency, η μεταφορά δεδομένων μεταξύ AZ κοστίζει χρήμα, και η σύγχρονη αναπαραγωγή μεταξύ ζωνών κοστίζει latency εγγραφής. Η Coinbase δεν έπεσε τυχαία σε ένα placement group, το σχεδίασε μηχανικά και αποδέχτηκε έναν κίνδυνο. Η αστοχία δεν ήταν η επιλογή, ήταν ότι η συνέπεια της επιλογής, καμία αυτοματοποιημένη διαδρομή εξόδου από τη ζώνη, ανακαλύφθηκε στις 9:29 PM κατά τη διάρκεια του συμβάντος αντί να αποφασιστεί σε μια επισκόπηση σχεδιασμού πριν από αυτό.

Τι να προσέχετε στον δικό σας λογαριασμό, πέρα από το να τρέξετε τον ανιχνευτή: την αριθμητική του quorum, όχι μόνο τη θέση του quorum, επειδή δύο από τους τρεις κόμβους etcd σε μία ζώνη είναι το ίδιο ελάττωμα με μια πιο φιλική γραμμή πίνακα. ASGs που παραθέτουν πολλά subnets τα οποία επιλύονται όλα στην ίδια ζώνη, γι' αυτό και ο ανιχνευτής επιλύει τα subnets του VPCZoneIdentifier αντί να εμπιστεύεται τη λίστα AZ. Caches χωρίς replicas: μια απώλεια ζώνης παγώνει το ElastiCache, και η επακόλουθη καταιγίδα από miss προσγειώνεται στη βάση δεδομένων σας τη χειρότερη δυνατή στιγμή. Και η παροχή χωρητικότητας κατά τη διάρκεια ενός πραγματικού συμβάντος ζώνης, που είναι το ένα πράγμα που ο ανιχνευτής δεν μπορεί να δει, επειδή είναι ιδιότητα της αρχιτεκτονικής όλων των άλλων, όχι της δικής σας. Η AWS σας το είπε η ίδια, στη μέση του συμβάντος: longer than usual provisioning times. Το όριο ζώνης είναι πραγματικό, και άντεξε. Αυτό που χτίζετε πάνω του είναι δικό σας.

Διαβάστε στη συνέχεια

  • Το Μέρος 2 αυτής της σειράς: Two Zones, Eighteen Hours, One Cause, όπου η διάκριση ανάμεσα σε όνομα AZ και ID AZ παύει να είναι ασήμαντη λεπτομέρεια.
  • Multi-Tenant LLM Apps: Isolating Customers on a Shared Model στο ercan.ai, το ίδιο μάθημα ένα επίπεδο πιο πάνω: η πλατφόρμα σάς δίνει ένα όριο, και η απομόνωση παραμένει δική σας δουλειά.
  • Το συνοδευτικό repo: nothing-fails-alone, όλα τα labs αυτής της σειράς, read-only εκ σχεδιασμού.

Για συμβουλευτική σε AWS, cloud αρχιτεκτονική, επισκοπήσεις ανθεκτικότητας, και platform δουλειά, ξεκινήστε από το ercanermis.com.

Αναφορές