Een ontwikkelaar wiste in de kerstvakantie vitale hostfiles van de clouddienst Amazon, waardoor de dienst bijna een dag haperde. Deze oorzaak bleef uren onopgemerkt en een recoverypoging mislukte.
De clouddienst Amazon Web Service (AWS) heeft op de dag voor Kerstmis bijna 24 uur gehaperd en het bedrijf legt in een uitgebreide verklaring uit wat de oorzaak was. Een ontwikkelaar die toegang heeft tot een beperkt deel van de dienst wiste per ongeluk belangrijke data, waardoor diverse API's begonnen te sputteren. Het duurde even voor de technici doorkregen wat het probleem was.
Hostfiles gewist
Een ontwikkelaar had niet door dat hij ELB-data wiste, melden de ontwikkelaars van Amazons AWS-team. Elastic Load Balancing (ELB) organiseert de load balancing en zonder correcte ELB state data, loopt de dataverdeling in de soep. Deze data omvat onder meer hostfiles die aangeven waar het dataverkeer naartoe moet worden geleid door elke load balancer. Daarom werden nieuwe taakverdelers niet correct geconfigureerd.
Op het dieptepunt van de cloudcrash werkte zo'n 7 procent van de load balancers niet correct. De crisis op 24 december duurde bijna 24 uur en zorgde voor storingen bij diverse diensten. Een opeenstapeling van missers zorgde ervoor dat de storing maar bleef voortduren. Het zomaar wissen van deze belangrijke data had procedureel niet mogen gebeuren en de wisactie bleef onopgemerkt. Vervolgens faalde een recoverypoging van de technici.
Diensten onderuit
Amazon betreurt het ongelukkige tijdstip van de storing, waardoor op kerstavond bijvoorbeeld de streamingsdienst Netflix onderuit werd gehaald. Netflix vertrouwt op Amazon om efficiënt te kunnen streamen in de VS. De flexibele EC2-servers van Amazon's cloud zorgen er namelijk voor dat pieken in het dataverkeer, die per tijdzone verschillen, kunnen worden verdeeld over verschillende regio's.
Het resultaat van de verdwenen ELB-data was dat diverse API's begonnen te haperen en latency-issues ondervonden. Het technische team van Amazon richtte zich op deze API's, zonder zich te realiseren dat er een onderliggend probleem was. Toen de oorzaak was gevonden, probeerde Amazon een back-up terug te plaatsen van vóór de verwijdering, maar die snapshot bleek niet bruikbaar.
Amazon dempt put
De getroffen load balancers werden door technici handmatig geconfigureerd, terwijl de snapshot werd teruggezet. Dit proces duurde enkele uren en omdat de snapshot niet bruikbaar was, werd er daarna gewerkt aan 'een alternatief recovery-proces', aldus het AWS-team. Toen er eenmaal een goede snapshot werd teruggezet, konden de load balancers weer correct worden geconfigureerd.
Als maatregel heeft Amazon er nu voor gezorgd dat wijzigingen als het wissen van ELB-data enkel kan gebeuren via de ITIL-procedure Change Management. "De toegang [die ontwikkelaars hadden] was verkeerd ingesteld op permanent, in plaats van autorisatie per aanvraag", schrijft het AWS-team. Daarnaast is het recoveryproces volgens de Amazon-ontwikkelaars aangepast om ervoor te zorgen dat in de toekomst snapshots sneller en correct kunnen worden teruggeplaatst.
