Speaker 2 (00:00)
Det tog fem timmar att rensa köerna. Shit. Och få nätverkstrafiken att flytta normalt igen.

Speaker 1 (00:08)
Det måste

varit otroligt mycket som låg i den backlocken. Men det klart, när det har legat ner under sex timmar, tänk all datatrafik och allting som vänner.

Speaker 2 (00:18)
Ja.

Du lyssnar på Developers, podden där du får följa med oss, Sofia och Madde, på allt inom mjukvaruutveckling.

Speaker 1 (00:33)
Vi träffar spännande gäster, testar nya teknologier, söker inspiration och tar upp aktuella ämnen.

här avsnittet är sponsrat av Codescene som den 26 november klockan fyra ska hålla ett gratis webbinarium där de visar hur kodhälsomåttet rankar varje fil från hälsosam till ohälsosam kod, fångar upp teknisk skuld tidigt och hur du kan bygga in automatiska kodhälsochecks och kontinuerlig feedback direkt i flödet. Det extra viktigt nu när AI-assistenter spottar ut sig kod i rasande tempo. Du får även se hur deras AI-drivna refactoring-agent iterativt förbättrar kodhälsa.

Du får också en första titt på vad de bygger med deras MCP och hur det kommer att förbättra sättet som utvecklare och AI-agenter samarbetar kring kodkvalitet. Du kan också starta Codesyn gratis i 14 dagar och glöm inte att komma med frågor till webbinariet. Länk finns i avsnittsbeskrivningen.

Speaker 2 (01:29)
Kul! Vi har ju haft Adam som är grundare av Kodzine här som gäst. Det tycker jag också man ska lyssna på. Det var ett jättebra avsnitt.

Speaker 1 (01:37)
Ja, var många som skrev faktiskt att det var ett bra avsnitt. Och det kom säkert ett väldigt intressant webbinarium också.

Speaker 2 (01:43)
Ja, men vi har ju sett flera av deras, alltså tak som han håller. Det är alltid väldigt bra. Man går tillbaks och lyssnar på podden. Vi kan länka den i beskrivningen. Den heter Kodkvalitet någonting. Mm, min sitter på.

Speaker 1 (01:59)
Jag trodde det var du som döpte det så jag minns faktiskt inte. Jag har inte minns om det var jag ändå.

Speaker 2 (02:05)
Ja,

om jag länkar till det.

Speaker 1 (02:07)
Du, jag har en lite random fråga till dig. Alltså, finns det en sjöhäst emoji?

Speaker 2 (02:17)
Oj. Eller vad är det, retorisk fråga?

Speaker 1 (02:20)
Nej,

nej, nej men alltså jag är bara nyfiken på, alltså om du skulle säga att det finns en Sjöistermodel inte. Vad tror du?

Speaker 2 (02:27)
Jag måste tänka på den här sektionen med djur och sjö, sjödjur. Jag har nog aldrig använt den, men det känns som att det borde finnas. Det är väldigt så typiskt, sjödjur och väldigt så här speciellt.

Speaker 1 (02:44)
Jag har en väldigt tydlig bild i huvudet hur den stryter. Den är typ såhär gul och liksom så.

Speaker 2 (02:50)
Ja, och så hade tänkt mig också.

Speaker 1 (02:53)
Grejen är att det finns inte en sjöhästemorge. Det här är liksom en så jättestor mandelareffekt-grej på den här. Om man känner till mandelareffekten så är det typ när jättemånga människor minns samma sak som egentligen inte har hänt.

Speaker 2 (03:09)
Ja, och är inte det om man delas död.

Speaker 1 (03:11)
Jo, det kom från det från början att är skitmånga som tror att han dog i fingerset men han dog typ 2013 och sånt egentligen. Helt sjukt. Jag har en annan sådan sidospår också men du vet klädermärket Fruit of the Loom. Det finns också en Mandela-effekt. Vet du inte det? Det brukar vara typ i t-shirtar och sånt så är det en fruktkorg och sen så tror folk att det är en sådan här... Alltså vad heter det på svenska? Ymnighetshorn tror jag det heter.

Speaker 2 (03:38)
Nej men gud

Speaker 1 (03:42)
Om du

tänker typ såhär, nu blir det jättesedespår, typ grekiska gudar, Dionysus och sånt har ju sådant här horn som du vet det brukar ligga frukt i.

Speaker 2 (03:52)
Ja, okej. Det är geets forn. Herregud.

Speaker 1 (03:58)
Det kanske inte heter så jag kanske bara hittar på. I alla fall, den loggen har inte ens det men det jättemånga som tror. Jag ser framför mig den också.

Speaker 2 (04:05)
Ja, det finns massa sådana.

Speaker 1 (04:07)
Det finns en helt subreddit för Mandela-effekt också. Där finns det här med sjösten också. Folk tror att det kommer från en messenger eller nåt sånt. Jag vet inte. Apple har helt dementerat att det någonsin har funnits. Den finns inte som en Unicode.

Speaker 2 (04:19)
Före det fanns där, eller?

Vad konstigt att den inte finns, eller? För det finns vissa emoji som man bara, men när har någon någonsin använt typ falafel emoji, eller det vet du kanske. Men vissa är ju såhär, nej men det här måste ju vara någon som bara tog grilla upp och skrev något brev och sånt där.

Speaker 1 (04:31)
Ja, det borde finnas.

Om han bor i Malmö

Men det sjuka är att jag frågade chat-GPT, detta har inte jag kommit på ska jag säga. Det är typ en grej på internet just nu. Det var min kollega som tipsade mig att fråga chat-GPT, finns det en sjöhäst Moji? Och den är precis lika förvirrad som alla andra. Alltså den typ ballar ju totalt. Du måste testa det.

Speaker 2 (05:11)
Då är så det en sjöhäst i Mojjie?

Speaker 1 (05:17)
Eller

engelska? Gör det nu så ska du få läsa upp.

Speaker 2 (05:21)
Sjöhästemoji. Okej, då säger den så här. Japp, det finns faktiskt en sjöhästemoji. Nej, vänta. Okej, ja, den ballar ur. Det massa emojis. Och så bara skickar den en, vad heter den, en hörning och sen nej, vänta, häst, nej, nej. Här är rätt. Och så skickar den typ alla fiskemojis som finns.

Speaker 1 (05:52)
För mig så ballar han ur och skickar en drake hela tiden.

Speaker 2 (05:55)
Men själva sjöhästen är... Och så igen en enhörning. sen nej, jag ska göra igen. Den är bla bla. så nej nej okej jag skärper mig här. Nej, nu på riktigt. Va? Det här var jätteroligt.

Speaker 1 (06:08)
pågår hur länge som helst och liksom så här så frågar jag för jag blev nyfiken om detta typ så här i ett easter egg eller någonting för att alltså det är helt orimligt att den ballar ut på det här sättet.

Speaker 2 (06:20)
Det är typ laggat till och med, det hur långt svar som helst. Jag kommer inte ens till slutet.

Speaker 1 (06:28)
Så jag rät att Istreg eller är bara helt inkapabel? Den bara haha, helt rimlig fråga. Jag önskar att jag kunde säga att det var ett hemligt påskegg. Men nej, det var bara ett fullskall och ett haveri i humor och självdisciplin. Så här är det på riktigt. Ja, det finns en sjöhäst emoji. Och så skickar den draken igen. Nej, jag skojar igen. Nej, på allvar. Och så skickar den. Drake är drake. Häst är häst. Enhörning är enhörning. Korall är en korall. Blåsfisken en blåfisk. Och så drake är nej nej.

Okej, den riktiga sjön.

Speaker 2 (07:02)
Samma här, samma här. Och den är så här... Nej men nu har verifierat enligt Unicode 15.1. Och sen fortsätter den balla ur. Men slutet är ändå... Slutligen på riktigt nej. Och sen tre gråtande emojis. Tänk om den alltid var så här. Man frågar bara så här, simpla grejer så får man aldrig riktigt...

Speaker 1 (07:25)
Sen efter det så tänkte jag, nu vill jag bara se, är den helt knäpp när det sjöhäst? Jag bad den att generera en typ så askig sjöhäst. Sen så ritade den typ en hund. Jag bara, alltså det där är en hund. Oj, det där blev en blöt labrador.

Speaker 2 (07:41)
Ja. Jag

undrar om det gäller för fler emojis. Alltså typ, vad är det för emojis som inte finns som verkligen borde finnas? Typ, finns det en surikat emoji? Nej, då är det normal.

Speaker 1 (07:56)
Okej, så det bara sjöhästen. Jag vet inte vad som händer där. Men, något om sjöhästar. Innan vi går igång på dagens intressanta ämne så ska vi tacka våra stjärnsupporter på Patreon. Och det är Alicia, Anders Nylund, Björn Jonsson, brother, Dag Rönnell, "Fyra Tre Johan Larsson EZ", Kajetan Kazimierczak, Lars Nyström, Martin Haagen, Molly Haglund, Oskari, Per Nåtby, Selim Hjorthall, Tomas Nilsson och "En NullReferenceException!"

Speaker 2 (08:28)
Ja, Så innan vi går igång, säger du alltså. Det här är något man kan gå igång på.

Speaker 1 (08:36)
Jag börjar på vandefrågor.

Speaker 2 (08:38)
Okej, men jag tror att vi alla visste om att... Vad blir det? Föra måndagen eller förra måndagen? whatever. Den 20 oktober så hade Amazon Web Services, AWS, det riktigt struligt. Det var minnsagt en händelserik dag för många internetanvändare, men kanske inte minnsagt för stackarsingenjörerna på AWS.

Speaker 1 (09:03)
Ja,

dom hade det nog värt.

Speaker 2 (09:05)
När

man förstår vad som hände, då känns det inte bra. De hade ett 14 timmar långt avbrott. Märkte du någonting?

Speaker 1 (09:17)
Ja, det gjorde jag. Vi märkte det först med att våra docker-images inte funkade. Alltså de som låg på docker-industri eller vad det hette. Vi kunde inte bygga, köra våra pullerquests, eftersom vi då drog hem docker-images och sa att vi kunde inte merge. Så vad är detta? Och sen så visade sig att det var avbrott. Sen i övrigt var vi inte så påverkade. Alltså vår slack funkade som den ska och allting. Jag vet att slackarna snart låg nere.

Min sambara strudde med Postman. Jo, man märkte ju plötsligt vilka som använde AWS för att jag skulle in på en app som heter Solid Starts, som du säkert kanske också har hört talas om som bland små barn. App för typ, ja, hur man ger vissa sorters mat och så. Den bara stod glad där och så tänkte jag att den använder säkert AWS. Men i stora drag, inte jättepåverkad.

Speaker 2 (10:10)
Ja, som du säger, slack liksom, postman, verktyg man verkligen använder. Jag som är föräldraledig, jag märkte ju inte det, vi använder ju AWS på jobbet annars, men jag märkte ju...

Speaker 1 (10:23)
Det

gör vi också, men vi blev inte drabbade så. Kanske för att vi inte har servrar i den region som var påverkad.

Speaker 2 (10:30)
Ja, det kan vara så. Men det var verkligen en ripple-effekt över hela världen. Men det jag förstod sen efterhand när jag läste om det på kvällen var att jag försökte göra Duolingo. Och så stod den bara och laddade. Och jag fattade inte varför, men det var ju därför. Så Snapchat, Duolingo, tusentals tjänster och hemsidor var nere. Och till och med, jag tyckte det här var inte så intressant. Så vi kör lite curiosa om Premier League.

Det var en Premier League match mellan West Ham och Brentford som spelades. Deras teknik för att kolla offside, det heter Semi-Automated Offside Technology, den funkade inte under halva spelet. Och jag tyckte det lite spännande att förstå för jag trodde det bara var kameror men så är det inte, så var det förr. Så jag kollade upp hur det funkar och varför det liksom blad av. Så det är sensorer i bollen som skickar boll.

i bollen som skickar bollens position 500 gånger per sekund. Oj jäklar. Det är 12 eller fler specialkambror på planen som följer varje spelare kroppspunkter, typ huvud, knän, fötter.

Speaker 1 (11:42)
Vi

axar knä och träd. Tänkte jag.

Speaker 2 (11:45)
Och

så skapar den en tredje modell av det i realtid. Och sen systemet analyserar allting hela tiden om om igen. Och om systemet ser en mail i offside, då skickas det en signal till de här videodomarna. Alltså riktiga personer, inga AI-domare. Som sen vi kräftar att det är offside, liksom, manuellt.

Speaker 1 (12:09)
Jag trodde att det bara var en domare på planen som typ, man visste väl svårt för den att se om det är offside. Om den fattat vad offside är. Jag har fått den förklarat tusen gånger.

Speaker 2 (12:13)
Ja nej, för nej

Vi går inte in på det här men nej men det är såklart jättemånga domare på sådana matcher som har koll på kameror. Sen är det väl typ så här den domaren som kanske tar huvudbeslutet som är på plan. Men i alla fall det här gör att man kan ta beslut om offside på sekunder istället för minuter när man bara använder sig av kameror för då satt det ju kameror och olika vinklar och då kan det vara ändå svårt att se om det är en offside eller inte.

Speaker 1 (12:43)
Man måste gå tillbaka och kanske kolla innan.

Speaker 2 (12:46)
Det blir svårt med vinklar att avgöra hur det blir.

Speaker 1 (12:49)
Okej, så det var också AWS på något sätt där i Donkalla.

Speaker 2 (12:53)
Det

var kopplat med AWS, någonting som processades där. Men tillbaka till AWS från Premier League. Vi ska snacka om vad var som hände. Och det är ju inte vi som har sammanställt hela det här, utan till AWS Heder så publicerar de faktiskt löpande uppdateringar under hela avbrottet. Och tre dagar efter incidenten så släppte de också en väldigt detaljerad postmorten.

som vi har länkat till så man kan läsa lite mer tekniskt specifikt vad det är som händer.

Speaker 1 (13:27)
tre dagar känns det ändå ganska snabbt att få ihop en hel postmortem. Jag tycker att annars brukar sånt kunna ta typ veckor.

Speaker 2 (13:34)
Jag tror att det har att med att de hade en liknande händelse 2023 och det tog dem fyra månader att redovisa vad som hände.

Speaker 1 (13:42)
Oj, okej. kanske fick lite skit efter det och sen så bara, nu måste vi rätta fortare.

Speaker 2 (13:47)
Ja, men jag håller med att det är otroligt snabbt. Och sen är det ett nyhetsbrev som heter The Pulse som har typ tagit deras postmortem och brytit ner det ännu enklare. Och sen har vi tagit det och brytit ner det ännu dummare. Nej men så här, jag läste postmortem och jag läste nyhetsbrevet och jag var så här, det här är lite svårt att återberätta.

Speaker 1 (14:12)
Ja, jag läste också igenom och jag bara kände att var bra att Sofie tar lid på det här.

Speaker 2 (14:17)
Så den här gången berodde avbrottet på ett DNS-fel i DynamoDB. DynamoDB är en serverless NOS-scale-databas. Den är byggd för vara väldigt tillgänglig, driftsäker. När den körs i flera availability zones, är när man kör någonting i flera datacenter i samma region, så lovar de 99,99 procent uptime.

och de brukar faktiskt leverera på det. Så det är en väldigt tillförlitlig tjänst.

Speaker 1 (14:49)
Ja, det är väl många som använder

Speaker 2 (14:53)
Väldigt. Det man ska veta om man inte håller på så mycket med cloud är att AWS är den största molnplattformen. Många använder DynamoDB också bara för de är så sjukt stora. Men som standard använder DynamoDB en eventual consistency-modell. Det betyder att om du har databasen distribuerad över flera datahallar så kommer det vara en fördröjning innan alla

som du läser ut data från den så kommer det ta lite tid innan alla läsningar visar samma resultat. Och det är helt okej för data som inte är så superkritisk men om du har väldigt viktig data så kan du välja strong consistency och då blir det att vilken data hall du en läser från så visar den faktiskt senaste versionen. Så det är de här egenskaperna som gör att DynamoDB är så himla populär för datalagring och att

AWS egna tjänster använder den också.

Speaker 1 (15:55)
Just det. Det var väl därför kanske det blev så himla stor driftstörning just. Hade bara varit Dynamo DBS och kanske Fyne Men nu drabbar det ju jättemånga av deras egna tjänster.

Speaker 2 (16:07)
Precis. Och det vore såklart konstigt om de använde något annat, typ MongoDB. Men det kan vara intressant att veta att det finns ju ändå begränsningar med DynamoDB. Om du till exempel kollar på MongoDB som många känner till som också är en nördsköddatabas så har den mycket mer rikt sånt här query language. kan göra mer avancerade sökningar, du kan ha mer komplexa datamodeller. DynamoDB är bara key value.

eller om du har behov av mycket billigare lagring för enorma datamängder så passar inte det riktigt. Men i alla fall under det här avbrottet så gick DynamoDB ner i regionen US East 1 som är i norra Virginia. Så DNS-adressen som är dynamoDB.useast.amazon.aws.com började retenera en ton post vilket i praktiken gjorde att alla system, kundernas AWS-egna system kunde inte hitta tjänsten.

Och för att förstå varför så behöver man titta närmare på hur DynamoDBs DNS-hantering fungerar. Och det är det här vi förenklar väldigt mycket för att jag hade i alla fall svårt att hänga med. Eller det är svårt att återberätta sig i en podd utan typ grafer att hålla på

Speaker 1 (17:22)
Ja,

man behöver nästan bilder och kunna rita upp allting men... ...låt se om jag hänger med.

Speaker 2 (17:26)
Ja. Men

om man tycker det är spännande, man kan också öppna länkarna och titta på graferna samtidigt för att förstå lite. Men om vi förenklar det så så avvisa använder två interna system som samarbetar för att hantera DNS-er. De har något som heter DNS Planner och den håller koll på hur hårt belastade lastbalanserarna, alltså de här sakerna som fördelar trafiken mellan olika server, hur hårt balanserade de...

hur hårt belastade balanserarna är. Det funkar väl också. Så om någon blir överbelastad så lägger de till fler lastbalanserare. Om vissa används för lite så tar den bort dem. Och DNS-planner den skapar sedan en plan som säger hur trafiken ska förderas mellan de här lastbalanserarna.

Speaker 1 (18:15)
Men shit, alltså det här är så sjukt meta. Det är ju typ en lastbalanserare som balanserar lasten mellan lastbalanserarna. Det gör redan mindblown.

Speaker 2 (18:23)
Men vad jag förstår, det här är bara en planerare. Den skapar bara plan. Den bara är den här smarta puppetmaster kanske.

Speaker 1 (18:28)
sker liksom ingenting utan det.

Eller hur smart var den nu då?

Speaker 2 (18:35)
Ja, exakt. Sen har man en till tjänst då som heter DNS Enactor och det är faktiskt den här som faktiskt uppdaterar DNS-inställningarna i Amazons DNS-tjänst som heter Route 53. Alltså, du koll på att det heter Route 53? har du hört innan om.

Speaker 1 (18:56)
Nej, men är det nån så typ till Route 66 eller nånting? För det var så det är svägar heter USA, typ som i Essexen och sånt.

Speaker 2 (19:01)
Jag har sett

Det ska ju vara något typ skämt om det. Jag började jobba med AWS för ett år sedan. blev också så här, varför döpar man en DNS-tjänst till Route23? Det blir så... Om du är ute efter så jag behöver en DNS-tjänst i molnet. Så är det väldigt ologiskt att den heter Route23 och inte bara DNS-service eller någonting. Ja, men då är det tydligen att... Vad heter det? Den vanliga TCP-porten...

för DNSR53 och då har man väl skämtat till er lite genom att det blir som en vägmärke. Så loggan för den, alltså för den produkten är som ett vägmärke. Okej, kul. Jättekul. Det är tydligen såhär väldigt AWS-skämtigt. Jag förstår inte.

Speaker 1 (19:56)
Det

som att vi skulle ha E6, alltså E53. Åh vad roligt, en motorvägs-skilt.

Speaker 2 (20:04)
Ja, vilken sker det? När man själv har kommit på er, då tycker man det är kul så klart.

Speaker 1 (20:08)
Skitfit.

Speaker 2 (20:11)
Okej, alla fall. DNS-enactor är den som trafiken styrs rätt. För att öka driftsäkerheten så kör de en DNS-enactor i varje availability zone. Alltså i varje datacenter finns det alla fall en sådan enactor. I regionen US East 1 så finns det till exempel tre datacenter och därmed så finns det tre stycken DNS-enactors. Okej?

Så eftersom flera en-actors arbetar samtidigt så händer det ibland att de råkar skriva över varandras uppdateringar. Alltså att det sker race conditions. Och systemet är byggt för att tåla det här. det händer. Ja. Ja. Och eftersom alla uppdateringar sker väldigt snabbt så bygger det hela på att, ja men, senaste informationen kommer alltid fram från DNS-plannen.

Speaker 1 (20:54)
Man bygger ju för det liksom.

Speaker 2 (21:08)
Så kort sagt, DNS Planner bestämmer hur trafiken ska fröda och DNS Enactors ser till att det faktiskt händer i realtid. Jag vet inte, var det makes the sense ändå? Ja, men det är nog det man behöver veta, liksom, om hur det funkar. Så, själva avbrottet då. Det uppstod inte på grund av en enda bugg, utan det är flera saker som hände samtidigt och det här blev lite krångligt.

Speaker 1 (21:21)
Det är inga händer ändå med, tror jag.

Speaker 2 (21:37)
Det är en DNS-enactor som blir långsam. Normalt uppdateras DNS väldigt snabbt. Men en av instanserna börjar ta mycket längre tid på sig än vanligt. Så DNS-planner börjar skapa nya planer i högt tempo. Jag vet inte om det har med varandra att göra eller det bara råkar vara så. Samtidigt går uppdateringarna väldigt trögt.

Speaker 1 (22:05)
–hos den första en ektorn.

Speaker 2 (22:06)
Enaktorn

är väldigt trög, men DNS-planen jobbar ovanligt snabbt. Och så har du en annan DNS-enaktor som jobbar för snabbt. med den långsamma enaktorn kämpar vidare så är det någon som kör på full fart och skriver in nya DNS-planer in i den DNS-tjänsten Route 53 och raderar de gamla. Och de här tre sakerna tillsammans skapar ett inkonsistent läge där systemen inte längre är var synkade med varandra.

Och det som hände då var att hela DynamoDBs DNS-poster töms.

Speaker 1 (22:43)
Det låter ju helt sjukt.

Speaker 2 (22:44)
Jag

tycker också det, men det gick till på det sättet att den långsamma DNS-enäktorn använde fortfarande en gammal plan, trots att den redan hade raderats, för att den var seg. Den har inte jobbat färdigt på en gammal plan, fast den är borta. Och den snabba enäktorn upptäcker det och tror att det är någonting som är fel. Och som en del av sin städfunktion så raderar den då alla DNS-poster för DynamoDB i regionen.

US East 1. Och resultatet är då att för alla andra tjänster så ser det ut som att din ombodig db helt försvunnit från nätet.

Speaker 1 (23:25)
Precis som den tar någon DNS-poss går det inte att hitta den.

Speaker 2 (23:28)
Nej. Så tyvärr när Dinomodb gick ner så följde alla AWS-tjänster som var beroende av Dinomodb i den regionen med. Och det sägs också att det har varit mycket diskussion kring det på nätet att så här varför är det så många som är beroende av just US East 1-regionen. Det är nog bara att det är typ först i listan.

Speaker 1 (23:56)
Ja,

jag tänker, jag som kommer från Aschuvärlden, är som att vi alltid använder typ North Europe. Eller gjorde det innan iallafall. är typ på Irland eller nånting.

Speaker 2 (24:05)
Ja, men den är billig också, så det har vi med det att göra. Men det är jättemånga tjänster som är beroende av DynamoDB. Bara för att nämna några, det Network Load Balancer, Lambda, ECS, EKS, Amazon Connect, AWS Security Token Service, AWS Management Console och det är fler. Det är de mest använda tjänsterna av alla.

Speaker 1 (24:33)
Verkligen. Lambda och allt sånt. Men det är så hela tiden några grejer. Och man också kanske, jag är inte så high på just AWS terminologin.

Speaker 2 (24:36)
Ja.

Ja, nej det är väldigt specifika AWS-produkter men så ja, det är väldigt populära produkter. Så driftavbrottet för just Dynamo, bevarade ungefär tre timmar. Men vi snackar ju om att det dröjde 14 timmar. Så, vad händer?

Speaker 1 (24:57)
Men

ändå tre timmar. Jag tänker när man väl upptäcker felet. För relativt fort borde man kunna se att alla DNS-poster är borta. Kan man inte bara manuellt lägga in dem igen eller någonting? Jo. Vad är det som ska ta så lång tid?

Speaker 2 (25:10)
Precis,

kolla du löste du direkt.

Speaker 1 (25:13)
Att

jag är ingenjör på AWS.

Speaker 2 (25:15)
Jag fattar inte. Jag skulle ha haft dig.

Speaker 1 (25:18)
Besson så du kan ringa mig sen.

Speaker 2 (25:20)
Konsulta för dem. Ja, nej men du har nu fått betalt miljoner för att konsulta där i en timme. Det var det de fick höra. De fick manuellt gå in i återställartjänsten. Men du såklart redan föra dem på det här. Jag vet det. Du bara väntar på att jag ska säga det. Men sannolikt så det så att när man startar upp din AMA-DB igen så kräver det att man undviker en så kallad thundering herd problematik.

Speaker 1 (25:49)
Det var det jag aldrig hört. Jag ser framför mig bufflar som bara springer över savannen och ska springa. Typ den scenen i Lejonkungen eller vad det är.

Speaker 2 (25:50)
Ja, det lätt.

Det

tänkte jag också innan jag må fassa där så vi ska inte ens prata om det för då kommer det bli så sorgligt. Jo men det uppstår när stora tjänster startar sånt samtidigt. Det betyder ungefär flockrusning. Det är när många klienter eller processer försöker göra samma sak samtidigt.

Speaker 1 (26:17)
Okej okej, ja det blir ju verkligen en anstormning då när alla gör det på en gång.

Speaker 2 (26:21)
Precis,

så ofta så händer just efter att något system precis blir tillgängligt igen. Och resultatet blir att alla rusar mot samma resurs på en gång. Men det kan i alla fall leda till att systemet överbelastas. Så det ett problem. Men det vet de säkert hur man fixar. Tänker jag. En intressant detalj faktiskt med det här eller själva avsaknaden med den är att i deras postmortem så nämner de inte hur de ska undvika just att

den här problematiken med DynamoDB ska undvikas.

Speaker 1 (26:56)
Nej, det känns som att man borde. I och att det var rot. Alltså... Cas, vad heter det på svenska?

Speaker 2 (27:03)
Rotorsöken? Man vet antagligen inte hur man ska lösa det ändå, därför det inte står.

Speaker 1 (27:08)
Det inte hänt antagligen. Det finns en så utelämnande.

Speaker 2 (27:11)
Ja,

men att man inte heller diskuterar det riktigt. När din AVDB väl är återställd så var problemen för AWS långt ifrån över. Tvärtom blev det bara värre. Nästa stora tjänst som drabbas var Amazon EC2 som är en del av AWS där kunder kan hyra virtuella servrar. Så du kan tänka dig att det här...

Det är stort problem. Det är virtuell server, kan instanser.

Speaker 1 (27:47)
Lite som App Services i Azure eller något liknande kanske.

Speaker 2 (27:51)
Ja, mer... Jag tror att det är som Azure har alltså, virtuella servrar.

Speaker 1 (27:57)
Ja, så det är liksom hela att du kan installera ett operativsystem och allting.

Speaker 2 (28:02)
Men ja, kunder kör såna applikationer där. Och för att förstå vad som händer behöver man förstå hur EC2 funkar. Så då har EC2 något som heter Droplet Workflow Manager. Vi kan förkortar det till DWFM istället. Men det är ett system som hanterar hur de fysiska servererna bakom EC2 fungerar. Man kan typ tänka det på något som är någon slags Kubernetes för EC2 också.

Den håller upp koll på vilka servrar som används och vilka som är lediga. Och sen har man ett koncept som heter lises, alltså hyror. Det används för att spåra om en server är upptagen eller om det kan tilldelas till en kund. Och den här dvfm, den gör regelbundna kontroller på varje server för att se är den upptagen eller är den ledig. Så resultaten från de här kontrollerna sparas i DynamoDB.

Speaker 1 (28:59)
Jag ser vad det fallerar.

Speaker 2 (29:01)
Så

när DynamoDB går ner så tappade dvfm sin källat i sanning. Det här ledde till flera problem. De här lises, hyrorna, börjar gå ut och när statuskontrollerna inte längre kan rapportera in resultat så börjar dvfm tro att många servrar inte längre är tillgängliga. Kunder får något som heter insufficient capacity-fel.

Eftersom att nästa analysis hade gått ut så trodde EC2 att inga servrar fanns lediga. Vilket ledde till felmeddelande när kunden försökte starta nya instanser. Och sen när DynamoDB kom tillbaka så hjälpte inte det heller. För DVFN försökte återställa statusen för alla servrar. Men på grund av att det var ett så enormt antal servrar så tog processen så lång tid att den fastnade. I något som hette congestive collapse.

Det låter som något tarmproblem. Matsmältnings kollaps.

Speaker 1 (30:02)
Jag tänker mer som en trafikstockning typ. Att det bara klappsar för mycket bilar på en gång.

Speaker 2 (30:10)
Det är tillstånd i fall där systemet är överblastat så att det inte längre kan komma vidare. Det här tar ingenjörerna ytterligare tre timmar att hitta sätt att delvis återställa EC2 och att kunna börja tillgöra nya instanser Nu har inte klarat, nu har vi sammanlagt sex timmar va.

Speaker 1 (30:35)
Bina va? nånting.

Speaker 2 (30:40)
Sen uppstod nya problem med nätverksdistributionen.

Speaker 1 (30:45)
Alltså

de här ringarna på vattnet, det helt sjukt.

Speaker 2 (30:48)
Ja, därför förstår du. Man vill bara gå hem.

Speaker 1 (30:52)
Ja, men jag måste också, för det här var ju på dagen för oss. Då måste det ju vara typ mitt i natten för dem väl.

Speaker 2 (30:59)
Ja, kanske, ja, delvis på natten.

Speaker 1 (31:02)
Ja, för de ligger väl bakåt i tiden för oss. Vi ser detta vid typ två eller en typ så tidig morgon eller någonting. Ja fy, ja, förlåt, fortsätt.

Speaker 2 (31:05)
Jag är ledsen.

Hoppas de har O, B...

Nej men problem med nätverksdistributionen. Så även om EC2 börjar se frisk ut internt så kunde instanserna inte kommunicera med omvärlden. Det här beror på att systemet Network Manager som sprider nätverkskonfigurationer mellan datacentren hade byggt upp en enorm backlog. Ja, såklart. Det tog fem timmar att rensa körerna.

och få nätverkstrafiken att flytta normalt igen.

Speaker 1 (31:44)
Det

måste ha varit otroligt mycket som låg i den backlumpen. det klart, när det har legat ner under sex timmar, tänk all datatrafik och allting som vänner.

Speaker 2 (31:54)
Ja, så under den här tiden så kan inte kunder starta nya EC2-instanser. Och de har ingen fungerande nätverksanslutning förrän fördrivningarna har rättats till. Till slut tog den slutliga städningen ytterligare tre timmar. När DynamoDB, DVFM, dropplet och Network Manager var stabila så behövde AWS gradvis ta bort de här

Begränsningarna, de satte throttles i systemet för att minska belastningen när incidenten inträffade. Så det var inte förrän antalet apianrop och de nya EC2-instanserna började stabiliseras så man tog bort restriktionerna helt. Så totalt tog det här ungefär 14 timmar från början av incidenten tills det var helt återställt.

Det är skönt att man inte behövde uppleva det. Men... Ja, kan tänka mig hur stressigt det var på den natten.

Speaker 1 (33:04)
Ja, verkligen. vet inte ens vad är för människor som jobbar med sånt här. Är det SRES? Site Reliability Engineers? vem? Det ju inte vanliga utvecklar antar jag. Det måste ju vara någon infrastruktur eller vad har man för arbetstidlar på?

Speaker 2 (33:24)
Jag att det är alla möjliga människor. Dels riktiga hårdvarupersoner som går och får koppla om allting och förstå hur. Så att man inte överbelastar hårdvaran över taget och någon som ska kunna algoritmer och förutse.

Speaker 1 (33:44)
avancerade

grejer. sedan alla typ så här, jag vet inte, produktmänniskor och säljare eller allt möjligt som bara måste typ hantera.

Många frågor växer ju när man hör hur det här. Dels typ så här, vi automatiserar ju så mycket. Och vi vill automatisera och vi pratar om att AI ska ta våra jobb för att allt ska vara automatiserat. Här ser vi ju hur snett det kan gå. Liksom av egentligen tre stycken ganska små grejer som händer och att den ena var långsam och den andra var snabb. att det tog så lång tid innan man satt i stopp för det. Att det här ens kan hända. Det är lite läskigt.

Speaker 2 (34:28)
Ja, problem. Jag tror dessutom att det här som hände är kanske inte en raketforskning. Det jobbiga här var väl bara att AWS har så många kunder och så många kunder i den här regionen så att händer någonting som smäller det så enormt.

Speaker 1 (34:48)
Men är det rimligt att så mycket av världens infrastruktur hänger på ändå ganska få leverantörer? AWS är den största och så har vi GCP och Azure och sådana kinesiska som inte minst vad heter. man ser ju hur stora påverkningar det har på samhället. Nu vet jag inte om det var samhällskritiska tjänster som blev drabbade.

Speaker 2 (35:16)
Ja, det var det. Ja, det var typ så här... Jag kommer inte ihåg, men vissa system i England, alltså för att... Någon så här, jag vet inte, försäkringar i skattegrejer och sånt. Det var mycket, nog bara att inte alla vill rapportera om det.

Speaker 1 (35:33)
Nej, nu blev man ändå ganska tacksam att det ändå är ganska strängt i Sverige. Jag tänker med våra myndigheter och så. De är ju väldigt noggrana med att ha data och sånt i Sverige och liknande, eller åtminstone i Europa. Så därför blev kanske inte vår digitala infrastruktur här så drabbad ändå. jag vet inte. Man kanske ska börja titta mer på liksom, alltså det finns ju här begreppet digital resiliens. Alltså, det är ju mer en...

Det är en samhällsfråga om vi nu blir så himla svårbara.

Speaker 2 (36:07)
Ja, vi pratade ju just om det här i förra podden, eller hur? att... Ja, men på något sätt så förut så hade du din server på ditt företag och du får så här... Det finns nackdelar med det, att det är så distribuerat, men då går det ner så går det ner för bara ett företag eller bara en myndighet och allt annat är uppe fortfarande och kör.

Speaker 1 (36:12)
Med backups och allting.

Speaker 2 (36:34)
Det blir också svårt att ha ingenjörer på varje stort ställe.

Speaker 1 (36:43)
Bra genomgång i alla fall. Jag tycker ändå att hängde med relativt bra i alla, även om jag inte är AWS-kunnig. Tack för genomgång Sofia. En sak jag tänker på man kanske ska tänka på också, nu var det ett stort avbrott i AWS. Men ska man se till det stora hela så är ju fortfarande AWS, det är ändå otroligt stabilt. Man tänker på hur mycket av all datatrafik i världen som den faktiskt hanterar. Nu känns det att ska sitta här försvara AWS.

Jag vill ju ändå att BES ska ringa mig sen så att... Nej men det kanske är värt att ta med sig ändå, det blir så himla lätt att man bara...

Speaker 2 (37:13)
Hahaha

Vi egentligen sponsrade av AWS.

Jo, absolut. Men det är en sak som jag tänkte på med till exempel Premier League. vet, i fotboll så finns det väldigt mycket känslor. Det här är inte bara ett och noll och längre. Och när du har någonting som händer i spelet som gör att något av lagen tycker att någonting blir orättvist så kunde det kanske lätt till kravaller. Och ibland så dör ju folk i tyvärr.

för en mycket sånt. även fast det är fotboll och man tror att det inte är allvarliga saker så kan sådana här outages leda till problem. Eller att någon inte får ut, jag vet inte, sina pengar eller någonting i tid och liksom, alltså man hör ju alltid om folk som typ, jag vet inte, tar självmord över vissa saker man inte ens trodde kunde hända. Vi hade ju till exempel den här jättestora

Devalveringen av massa kryptovalutor för några veckor sedan här. Det var ju folk som hade investerat typ så här allt de har och tagit tio gånger hävstång eller femtio gånger hävstång på några jävla skitcoins. Det var folk som tog sina liv efter det.

Speaker 1 (38:43)
Rågis.

Speaker 2 (38:46)
Men nu blev det tråkigt.

Speaker 1 (38:47)
Ja, blev verkligen ett så dökbetsstämning på slutet.

Speaker 2 (38:50)
Det

är allvarligt men är intressant teknisk genomgång kanske.

Speaker 1 (38:56)
Ja, men det tycker jag. Men ja, tack för det och vi ses ju som vanligt i nästa vecka.

Speaker 2 (39:04)
Hej då!