Amazon avslöjar orsaken till förra veckans stora AWS-avbrott

Utlösaren för tjänstavbrottet var ett litet kapacitetstillskott till Amazon Kinesis, men problemet snöade därifrån.

Bild: Getty Images/iStockphoto

Förra veckans enorma AWS-avbrott som knäckte en mängd Internet of Things (IoT)-enheter och onlinetjänster orsakades av ett problem med en Amazon-tjänst som heter Kinesis. Med uppgiften att samla in och analysera strömmande data i realtid på AWS, hickade Kenesis efter att Amazon började lägga till en liten kapacitet till den. Även om det påverkade ett brett utbud av enheter och tjänster, inträffade störningen specifikt vid AWS-anläggningen i Amazons norra Virginia, US-East-1, region.

SER: Hantera multimolnet (ZDNet/TechRepublic specialfunktion) | Ladda ner den kostnadsfria PDF-versionen (TechRepublic)

Moln: Måste läsa täckning

I sin långa och komplexa förklaring hänvisade Amazon till det lilla tillskottet av kapacitet till Kinesis som utlösaren men inte grundorsaken till problemet. Företaget beskrev sökvägen som användes för denna tjänst och sa att Kinesis använder en rad “back-end” cellkluster som bearbetar strömmar.

Dessa strömmar sprids över baksidan genom en skärningsmekanism som ägs av en “front-end”-flotta av servrar. Frontändens jobb är att hantera autentisering, strypning och förfrågningsdirigering till rätt strömskärvor på back-end-klustren. Den extra kapaciteten gjordes till denna front-end-flotta.

Varje server i front-end-flottan cachar viss data, inklusive medlemsinformation och shard-ägande för back-end-klustren. Varje front-end-server skapar operativsystemtrådar för var och en av de andra servrarna i front-end-flottan. När ny kapacitet läggs till tar de servrar som redan ingår i flottan så lång tid som en timme att lära sig om eventuella nya deltagare.

De första varningsklockorna ringde klockan 5:15 PT dagen före Thanksgiving den 25 november, vilket indikerar fel med Kinesis-posterna. Den nya kapaciteten var troligen misstänkt för felen, vilket fick Amazon att börja ta bort den men samtidigt undersöka andra potentiella orsaker.

Vid 09:39 PST hade Amazon spikat sin boven och upptäckt att den nya kapaciteten hade fått alla servrar i flottan att överskrida det maximala antalet trådar som tillåts av en operativsystemkonfiguration. Eftersom denna gräns fortsatte att överskridas, fortsatte cachekonstruktionen att misslyckas, och så kunde front-end-servrarna inte dirigera förfrågningar till back-end-kluster.

För att lösa problemet startade Amazons ingenjörer om front-end-servrarna efter att den extra kapaciteten som startade kollapsen togs bort. Den första gruppen servrar lades till klockan 10:07 PST. Därifrån lade Amazon långsamt till servrar, bara några hundra per timme. När trafiken gradvis lades till började felfrekvensen sjunka stadigt, vilket lämnade Kinesis helt uppe och återställde som normalt kl. 22:23 PST.

Som med alla typer av serviceavbrott finns det lärdomar och korrigeringar som måste göras. Amazon ber om ursäkt för påverkan på sina AWS-kunder och beskrev flera åtgärder för att säkerställa att den här typen av händelser inte kommer att hända igen.

Först kommer företaget att flytta Kinesis till större CPU- och minnesservrar för att minska det totala antalet servrar som krävs. För det andra sa företaget att det lägger till finkornig alarm för trådförbrukning i tjänsten. För det tredje planerar Amazon att öka gränserna för antal trådar när de nödvändiga testerna är klara. För det fjärde gör företaget ändringar för att förbättra kallstartstiden för front-end-flottan, som att flytta front-end-servercachen till en dedikerad flotta och flytta stora AWS-tjänster som CloudWatch till en separat front-end-flotta.

Att varna kunderna om problemet var också en uppgift som inte gick så bra.

“Utöver serviceproblemen upplevde vi vissa förseningar i att kommunicera servicestatus till kunder under den tidiga delen av detta evenemang,” sa Amazon och påpekade att man använder sin Service Health Dashboard för att uppmärksamma kunder om breda driftsproblem och sin Personal Health Dashboard att kommunicera direkt med berörda kunder.

I den här typen av händelser gör Amazon vanligtvis inlägg på sin Service Health Dashboard. Det här verktyget kunde dock inte uppdateras på vanligt sätt eftersom det använder en tjänst som heter Cognito, som själv påverkades av avbrottet. Även om företaget använde en manuell säkerhetskopieringsmetod för att uppdatera den här instrumentpanelen, försenades uppdateringarna eftersom Amazons supporttekniker inte var tillräckligt bekanta med detta verktyg.

“Framöver har vi ändrat vår supportutbildning för att säkerställa att våra supporttekniker regelbundet utbildas i säkerhetskopieringsverktyget för att skicka inlägg till Service Health Dashboard,” tillade Amazon.

Eftersom fler organisationer och individer förlitar sig på molnet för att använda viktiga enheter och tjänster, påverkar en händelse som denna oundvikligen ett växande antal människor. AWS-kunder är särskilt mottagliga eftersom Amazons molnprodukt är bland de mest populära och vanligaste. Detta innebär att organisationer måste förbereda sig för onlinestörningar precis som de skulle förbereda sig för problem med tjänster på plats. Och det kräver en korrekt dataskydds- och återställningsplan för att säkerställa att ditt eget företag inte lider när problem uppstår i molnet.