Amazon je oktobra letos utrpel enega največjih izpadov svojega oblaka AWS v zgodovini. Zaradi njegove velikosti je to vplivalo na velik del interneta, nedosegljive so bile številne storitve in strani njegovih strank. Da je tako velik in vzdrževan sistem padel, se je zgodilo več nesrečnih slučajev, ki jih lahko razume vsakdo.
Kljub rednemu poudarjanju, da je internet zgrajen z imanentno redundantnostjo, smo konec oktobra videli največji izpad internetnih storitev v moderni zgodovini. V ponedeljek, 20. oktobra, zjutraj po slovenskem času je bil dobršen del interneta nedosegljiv. Padle so številne na videz nepovezane storitve, kot so Strava, Signal, Duolingo in Canva. Hitro je bilo jasno, da gre za globljo težavo, ki korenini v samem jedru modernega interneta. Sesul se je Amazonov oblak AWS, ki oskrbuje približno tretjino trga.
Četudi so v preteklosti že padali velikani, kot je Office 365, tako obširnega izpada ne pomnimo. K temu je gotovo prispevalo dejstvo, da je internet danes drugačen kot pred desetletjem ali dvema, saj še nikoli toliko spletnih strani in storitev ni gostovalo v enem izmed treh velikih oblakov. Amazonov AWS, Microsoftov Azure in Googlov Cloud skupaj obvladujejo skoraj dve tretjini trga oblačne infrastrukture, zato izpad kateregakoli močno zamaje internetno povezljivost. Tistega ponedeljka se je spotaknil prav največji, do popolne obnovitve pa je preteklo 14 ur. Inženirji so morali narediti veliko nadur.
Kaj je v Virginiji
Amazon je že tistega dne, pa čeprav se je izpad začel ob 2.48 zjutraj po lokalnem času v ameriški zvezni državi Virginiji, javnost redno obveščal o poteku incidenta in statusu oblaka. Daljše zelo tehnično poročilo so objavili štiri dni pozneje, v petek, 24. oktobra. V njem je mogoče prebrati učene izraze, kot so tekmovanje za vire (race condition), izbris zapisov za DNS (DNS records) in zakasnitve (latency), ki so pojasnjevali izpad več kot sto Amazonovih storitev. Zaporedoma so odpovedali DynamoDB, EC2 in NLB (Network Load Balancer), tako da jih je bilo treba obnoviti ročno. Kaj se je torej zgodilo?
Amazonov oblak AWS je razdeljen v 120 območij dosegljivosti (AZ – Availability Zones), ki so razporejene v 38 geografskih regijah, da ima vsaka vsaj tri AZ. Najpomembnejša, najstarejša, največja, najkompleksnejša in najbolj obremenjena regija je vzhodna obala ZDA. Velik del preostalega oblaka je odvisen od delovanja te regije, ki nosi oznako us-east-1. Če pade us-east-1, pade internet.
Sistem se je začel sesuvati 20. oktobra ob 8.48 po slovenskem času. Prve težave so se začele v storitvi DynamoDB, ki jo potrebujejo in uporabljajo tako druge Amazonove storitve kot storitve strank. DynamoDB je nerelacijska (NoSQL) podatkovna zbirka, ki vsebuje podatke v strukturi ključ-vrednost in dokumentna struktura. Zbirka DynamoDB ima, ironično, podobno zgodovino, saj je nastala po izpadu Amazonovih strežnikov decembra 2004. Tedaj so v podjetju uporabljali več podatkovnih zbirk, vsaka storitev je imela svojo, iskanje po njih pa je bilo počasno. Kasneje so zato uporabili koncept nerelacijske zbirke, ki je bila zgrajena z mislijo na hitrost. Po več iteracijah se je leta 2012 rodil DynamoDB kot nerelacijska podatkovna zbirka, kakršne uporabljajo številne storitve v AWS, vključno s sistemskimi. Amazon namreč svoje strežnike poganja na lastni programski opremi, čemur v angleščini slikovito pravijo dogfooding.
Hrošč TOCTOU
V Amazonovi kodi je tičal hrošč TOCTOU (Time-of-check to time-of-use), ki je pri razvoju programske opreme sorazmerno pogost, včasih skorajda neobhoden. Hrošč TOCTOU se lahko pojavi, ko se preverjanje stanja sistema in uporaba tega podatka ne zgodita istočasno, temveč drug za drugim.
Tak primer je preverjanje, ali ima uporabnik pravice za urejanje neke datoteke in ali ta obstaja, nato pa dejanski zapis podatkov v njo. V vmesnem času, torej med prvim in drugim sistemskim klicem, lahko napadalec izvede svoje ukaze in vpliva na sistem, denimo datoteko spremeni ali podtakne drugo pot do nje. Tako se dejanske operacije ne zgodijo tam, kjer smo pričakovali ob preverjanju stanja.
Ni nujno, da gre za napadalca, temveč jo lahko zagodejo tudi nepredvidene okoliščine, kot se je zgodilo Amazonu. Odpravljanje hroščev TOCTOU je v številnih primerih nemogoče, zato je treba k problemu pristopiti povsem drugače. Pri konkretnem primeru pisanja v datoteko se je bolje zanesti na napake, ki bi se zgodile ob nedopustnem branju, kot pa izvesti ločeno preverbo pred tem in nato rezultatu zaupati kasneje.
Storitve v AWS za delovanje potrebujejo delujoči sistem DNS, zato imajo DynamoDB in podobne storitve več tisoč vnosov DNS. Sprotno posodabljanje je ključno za uravnavanje strojnih virov, torej uporabo dodatnih kapacitet, porazdelitev prometa in soočanje z nedosegljivostjo posameznih kosov strojne opreme.
Amazon je zato razvil sistem, ki redno in samodejno upravlja zapise za DNS. Sestavljata ga komponenti DNS Planner in DNS Enactor. Prva spremlja stanje v oblaku in redno pripravlja nova pravila oziroma sezname, kateri DNS se uporabljajo in kako se razporeja promet. Druga komponenta v storitev Route53 zapisuje ustrezne spremembe, torej naslove DNS, saj je Route53 Amazonov strežnik za DNS. Za večjo zanesljivost in odpornost v treh območjih dosegljivosti tečejo nepovezane kopije DNS Enactorja (us-east-1a, us-east-1b, us-east-1c), ki posodabljajo Route53.
Tu se je začela kaskada dogodkov. Eden izmed DNS Enactorjev je postal neobičajno počasen, kjer govorimo o velikostnih razredih. Tega Amazon ni ustrezno predvidel. Spremembe, ki jih DNS Enactorji zapisujejo v Route53, so dveh vrst: dodatki in brisanja. Nastavljeni so seveda tako, da zadnjih nekaj vnosov vedno ostane, da se ne bi zgodilo, da bi pobrisali vse zapise DNS. A zgodilo se je prav to.
Prva domina
Preden DNS Enactor začne posodabljati zapise, enkrat preveri, da je novi seznam novejši od zapisanega, nato pa se loti dela. Počasni DNS Enactor je to storil in se lotil dela, ki mu je šlo nenavadno in nepojasnjeno počasi. Še preden je prišel do konca, je DNS Planner ustvaril več novih seznamov, ki jih je drugi DNS Enactor vestno in hitro zapisal. Nato se je lotil še čiščenja starejših vnosov. Medtem je počasni DNS Enactor nadaljeval svojo pot in s svojim starejšim seznamom prepisoval novejše delo hitrejšega DNS Enactorja. To se je zgodilo, ker je zgolj enkrat, tj. na začetku, preveril časovno ustreznost. Drugi, hitri DNS Enactor pa je medtem začel brisati vse starejše zapise, vključno s seznamom počasnega DNS Enactorja. Ta je odtlej zapisoval prazen zapis. To imenujemo hrošč TOCTOU (glej okvir).
Nenadoma so bile številne izhodne točke (endpoint) brez veljavnih zapisov DNS. Storitev DynamoDB je postala nedosegljiva, naslov dynamodb.us-east-1.amazonaws.com ni kazal na nobeni IP.
Druga domina
Vse druge storitve, ki potrebujejo DynamoDB, so začele klecati, med njimi pa so bile tudi lastne Amazonove storitve, ne le stranke. Amazonovi inženirji so v treh urah ponovno vzpostavili vse zapise DNS in obnovili dostopnost DynamoDB. A domine so bile že začele padati, naslednja žrtev je bil EC2 (Elastic Compute Cloud).
Storitev EC2 zagotavlja virtualne strežnike za Amazonove stranke. V ozadju so fizični strežniki, ki jih Amazon imenuje kapljice (droplets), njihovo dodeljevanje pa upravlja DropletWorkflow Manager (DWFM). Ta za delovanje potrebuje DynamoDB, sam pa preverja, ali so posamezne kapljice aktivne, torej ali se redno javljajo (heartbeat). Tako DWFM ve, katere kapljice delujejo in kam lahko dodeli posamezne instance EC2.
Ko je DynamoDB padel, DWFM ni mogel ustvarjati novih instanc EC2. Obstoječi virtualni strežniki so delovali normalno, novi pa niso mogli nastajati. To je dinamičen proces, ki mora vedno potekati, ne le, ker instance EC2 umirajo tudi zaradi fizičnih težav, temveč, ker se sproti prilagajajo potrebam in obremenjenosti storitev, ki gostujejo na njih. Predstavljajte si parkirišče, od koder lahko avtomobili le odpeljejo, ne morejo pa nanj pripeljati. Hitro bo postalo neuporabno.
DWFM običajno upravlja okrog milijon aktivnih fizičnih strežnikov, izmed katerih je manj kot desetinka odstotka neodzivnih in jih je treba ponovno vzpostavljati. Ko je bil DynamoDB nedosegljiv, se je število prekinjenih povezav oziroma zakupov (expired lease) s fizičnimi strežniki povečalo za tri velikostne razrede. Če bi jih bilo manj, bi se DWFM sčasoma izkopal iz zaostanka (backlog), a zgodilo se je nasprotno. DWFM je poskušal vzpostaviti povezave, a je bilo zahtevkov toliko, da so potekli (timeout), preden bi se uspešno zaključili. To je še povečevalo čakalne vrste, DWFM ni zmogel popraviti težav in je pokleknil pod obremenitvijo (congestive collapse). Tudi ko je DynamoDB že normalno deloval, je bil DWFM neoperativen. AWS zato ni mogel ustvarjati novih instanc EC2. Fizičnih strežnikov za gostovanje virtualnih strežnikov ni bilo moč vpreči.
Tej težavi z DWFM pravimo metastabilno stanje (metastable failure) in je že nekaj let znan problem v velikih razpršenih sistemih. Amazon ni imel izdelanega avtomatiziranega sistema za obnovitev DWFM po takšni napaki, zato so morali inženirji ponovno zagnati DWFM in začeti stopenjsko obnavljanje.
Tretja domina
Ko se vzpostavi nova instanca EC2, torej nov virtualni strežnik, Network Manager objavi to informacijo in omogoči komunikacijo z drugimi instancami EC2. Ko so šest ur po začetku incidenta obnovili DWFM, se je v škripcih znašel Network Manager. Zaradi velikega števila novih instanc EC2 je imel toliko zaostalega dela (backlog), da ni zmogel dohajati hitrosti ustvarjanja novih instanc EC2. Tako so nove EC2, ki so se uspešno vzpostavile, ostale brez omrežne povezljivosti, ki bi jo moral zagotoviti Network Manager. Tega so inženirji uspešno obnovili dobrih 10 ur po začetku incidenta, tako da so vmes začasno omejili hitrost klicev v EC2, torej vzpostavljanja novih virtualnih strežnikov, in v nekatere druge storitve.
Posledice je čutil tudi NLB (Network Load Balancer), ki skrbi za razporejanje prometa in obremenitev. NLB je trpel v sklepnem delu incidenta, ko so instance EC2 že lahko nastajale, a niso imele povezljivosti zaradi nedelujočega Network Managerja. NLB ima rutino za preverjanje operativnosti instanc EC2 (health check), ki je takšne virtualne strežnike brez ustrezne povezljivosti včasih označila kot neoperativne, drugič pa kot delujoče. To je povečalo obremenitev tega preverjanja, zaradi česar so bile v številnih primerih odstranjene zdrave instance EC2. Inženirji so zato začasno izključili ta del NLB, da so se lahko postavile vse instance EC2 in da jih je Network Manager uspešno razglasil, s tem pa zagotovil povezljivost. Nato so ponovno zagnali NLB, da je po korakih prepoznal, da so instance EC2 zdrave.
Incident se je zaključil ob 23.20 po slovenskem času, torej 14 ur po začetku. V vmesnem času so bolj ali manj trpele tudi druge storitve, ki so se zanašale na AWS. Ko je kapaciteta AWS upadla zaradi nezmožnosti ustvarjanja novih virtualnih strežnikov prek EC2, je zmanjkalo virov za najemnike. Tudi storitve, kot je varni in šifrirani Signal, morajo uporabljati neko oblačno storitev. Ker je bil to ravno AWS, so bile ta čas nedosegljive. Ker pa je us-east-1 primarno vozlišče za celoten AWS, je posledice občutil ves svet. Precej drugače bi bilo, če bi padel Amazonov podatkovni center ap-southeast-6 na Novi Zelandiji.
Amazon ni za odmet
Ob incidentih je mikavno iskati glavni vzrok, a je to pogosto jalovo početje. Je bil za izpad kriv hrošč TOCTOU? Zagotovo. Je bil kriv izključno hrošč TOCTOU? Ne. Nesreče so vedno posledica več dejavnikov, ki so se morali zgoditi in izmuzniti varnostnim protokolom. Model švicarskega sira za vzroke nesreč, ki se uporablja za obvladovanje tveganj, ponazarja nujnost večplastne zaščite. Noben sloj zaščite ne more preprečiti vseh mogočih vzrokov nesreč, zato jih potrebujemo več.
Tudi iskanje primarnega razloga je pogosto obsojeno na neuspeh. Če DNS Enactor ne bi bil tako zelo počasen, se celotna veriga dogodkov ne bi zgodila. A vprašamo se lahko, zakaj je bil DNS Enactor tako počasen. In če bi poznali odgovor na to vprašanje, bi se še vedno lahko vprašali, kaj je povzročilo ta vzrok.
AWS ostaja eden najstabilnejših oblakov na svetu, kjer so večji izpadi tako redki, da jih lahko v vsej njegovi zgodovini preštejemo na prste ene roke. Analiza vsakega je zato posebej zanimiva in vredna širše pozornosti, nikakor pa to ne pomeni, da je AWS nekakovostna storitev. Z razlogom so največji ponudnik računalniškega oblaka in daleč največji generator dobička za celotno divizijo Amazon. Podobno kot je letalski promet po vsaki nesreči malce varnejši, bo tudi AWS zaradi oktobrskega fiaska nekoliko zanesljivejši.
Časovnica incidenta, 20. oktobra po slovenskem času
8.48 Začetek incidenta.
8.48 Pobrisani DNS vnosi za DynamoDB, ki postane nedosegljiv.
9.38 Identificiran vzrok izpada DynamoDB.
10.15 Delna povezljivost internih storitev z DynamoDB obnovljena.
11.25 DNS vnosi za DynamoDB obnovljeni, začne se vzpostavljanje novih virtualnih strežnikov.
11.25 DWFM začne obnavljati povezave do fizičnih strežnikov, zaradi preobremenitve zapade v nefunkcionalno metastabilno stanje.
11.32 DynamoDB normalno dosegljiv.
13.14 Omejeni ponovni zagon DWFM in ročno vzpostavljanje po korakih z omejitvami (throttling).
14.28 DWFM ponovno deluje, vzpostavljanje EC2.
14.28 Network Manager začne razglašati povezljivosti novih virtualnih strežnikov.
15.21 Network Manager ima velik zaostanek in velike zakasnitve, novi virtualni strežniki nimajo povezljivosti.
15.52 Network Load Balancer zaradi nepovezanosti novih virtualnih strežnikov te označuje kot nedosegljive.
18.36 Nadzorovani izklop preverjanja zdravja virtualnih strežnikov v Network Load Balancerju.
19.36 Network Manager začne delovati normalno.
20.23 Začnejo odpravljati omejevanje (throttling).
23.09 Network Load Balancer ponovno v celoti aktivirajo.
23.20 Konec incidenta.
