How We Tracked Down Unusual DNS Failures in AWS

We’ve built SparkPost around the idea that a cloud service like ours needs to be cloud-native itself. That’s not just posturing. It’s our cloud architecture that underpins the scalability, elasticity, and reliability that are core aspects of the SparkPost service. Those qualities are major reasons we’ve built our infrastructure atop Amazon Web Services (AWS)—and it’s why we can offer our customers service level and burst rate guarantees unmatched by anyone else in the business.

But we don’t pretend that we’re never challenged by unexpected bugs or limits of available technology. We ran into something like this last Friday, and den händelsen led to intermittent slowness in our service and delivery delays for some of our customers.

Låt mig först säga att problemet löstes samma dag. Dessutom gick inga e-postmeddelanden eller relaterade data förlorade. Men om leveransen av dina e-postmeddelanden fördröjdes på grund av detta problem ber jag om ursäkt (faktiskt en ursäkt från hela vårt team). Vi vet att ni litar på oss, och det är frustrerande när vi inte presterar på den nivå ni förväntar er.

Some companies are tempted to brush issues like a service degradation under the rug and hope no one notices. You may have experienced that with services you’ve used in the past. I know I have. But that’s not how we like to do business.

Jag ville skriva om den här incidenten av en annan anledning också: vi lärde oss något riktigt intressant och värdefullt om vår molnarkitektur för AWS. Team som bygger andra molntjänster kan vara intresserade av att lära sig mer om detta.

TL;DR

Vi stötte på odokumenterade praktiska begränsningar för de EC2-instanser som vi använde för vårt primära DNS-kluster. Att dimensionera molninstanser baserat på traditionella specifikationer (processor, minne osv.) fungerar vanligtvis precis som man förväntar sig, men ibland gäller inte den traditionella hårdvarumodellen. Det gäller särskilt i atypiska användningsfall där aggregerade gränser kan spela in - och det finns tillfällen då man stöter på sådana scenarier utan förvarning.

Vi stötte på en sådan gräns i fredags när vår DNS-frågevolym skapade ett nätverksanvändningsmönster som vår instanstyp inte var förberedd för. Men eftersom den gränsen inte framgick av dokumentationen eller tillgängliga standardmätvärden visste vi inte att vi hade nått den. Det vi såg var en mycket hög frekvens av DNS-fel, vilket i sin tur ledde till intermittenta fördröjningar på olika ställen i vår arkitektur.

Att gräva djupare i DNS

Varför är vår DNS-användning speciell? Det har mycket att göra med hur e-post fungerar, jämfört med den innehållsmodell som AWS ursprungligen utformades för. Webbaserad innehållsleverans använder sig i stor utsträckning av vad som kan betraktas som klassiska inkommande "pull"-scenarier: en klient begär data, oavsett om det är HTML, videoströmmar eller något annat, från molnet. Men användningsområdena för leverantörer av meddelandetjänster som SparkPost är undantag från det vanliga AWS-scenariot. I vårt fall arbetar vi mycket med utgående trafik, närmare bestämt e-post (och andra meddelandetyper som SMS eller mobila push-aviseringar). Och den typen av push-trafik är starkt beroende av DNS.

Om du är bekant med DNS kanske du vet att det i allmänhet är ganska lätta data. Om du vill begära en viss HTML-sida måste du först fråga var sidan finns på Internet, men den begäran är bara en bråkdel av storleken på det innehåll som du hämtar.

Email, however, makes exceptionally heavy use of DNS to look up delivery domains—for example, SparkPost sends many billions of emails to over 1 million unique domains varje månad. For every email we deliver, we have to make a minimum of two DNS lookups, and the use of DNS “txt” records for anti-phishing technologies like SPF and DKIM means DNS also is required to receive mail. Add to that our more traditional use of AWS API services for our apps, and it’s hard to exaggerate how important DNS is to our infrastructure.

All of this means we ran into an unusual condition in which our growing volume of outbound messages created a DNS traffic volume that hit an aggregate network throughput limit on instance types that otherwise seemed to have sufficient resources to service that load. And as överbelastningsattacker mot Dyn DNS-infrastrukturen last year demonstrated, when DNS breaks, everything breaks. (That’s something anyone who builds systems that rely on DNS already knows painfully well.)

De plötsliga DNS-problemen fick våra drift- och tillförlitlighetsteam att identifiera problemet. De samarbetade med våra partners på Amazon för att eskalera problemet på AWS driftsida. Genom att arbeta tillsammans identifierade vi orsaken och en lösning. Vi driftsatte ett kluster av namnservrar med större kapacitet och ett större fokus på nätverkskapacitet som kunde uppfylla våra DNS-behov utan att hamna på gränsen för genomströmning. Eftersom allt detta skedde inom AWS kunde vi lyckligtvis starta de nya instanserna och även ändra storleken på befintliga instanser mycket snabbt. DNS återgick till normalt beteende, misslyckade uppslagningar upphörde och vi (och leveransen av utgående meddelanden) var tillbaka på rätt spår.

För att motverka detta specifika problem i framtiden gör vi också ändringar i DNS-arkitekturen för att bättre isolera våra kärnkomponenter från effekterna av liknande, oväntade tröskelvärden. Vi arbetar också med Amazon-teamet för att ta fram lämpliga övervakningsmodeller som ger oss tillräcklig förvarning för att avvärja en liknande incident innan den drabbar någon av våra kunder.

AWS and the Cloud’s Silver Lining

Jag vill inte förringa den inverkan som denna incident har på våra kunder. Men vår förmåga att identifiera det underliggande problemet som en oväntad interaktion mellan vårt användningsfall och AWS infrastruktur - och sedan hitta en lösning på det på mycket kort tid - har mycket att göra med hur vi byggde SparkPost, och vår goda relation med Amazon-teamet.

SparkPost’s superb operations corps, our Site Reliability Engineering (SRE) team, and our principal technical architects work with Amazon every day. Den strengths of AWS’ infrastructure has given us a real leg up optimera SparkPosts arkitektur för molnet. Working so closely with AWS over the past two years also has taught us a lot about spinning up AWS infrastructure and running quickly, and we also have the benefit of deep support from the AWS team.

Om vi hade varit tvungna att hantera en liknande begränsning i en traditionell datacentermodell hade det kunnat ta dagar eller till och med veckor att lösa ett sådant här problem. Denna smidighet och lyhördhet är bara två av anledningarna till att vi har byggt vår verksamhet på molnet och AWS. Den typ av molnexpertis som våra företag delar är svår att hitta tillsammans. Amazon har varit en bra affärspartner för oss, och vi är verkligen stolta över vad vi har gjort med AWS-stacken.

SparkPost är den första e-postleveranstjänsten som byggdes för molnet från början. Vi skickar mer e-post från en äkta molnplattform än någon annan, och ibland innebär det att vi ger oss in på okänt territorium. Det är en grundläggande sanning inom datavetenskap att man inte vet vilka utmaningar som uppstår i stor skala förrän man stöter på dem. Vi hittade en på AWS, men vår snabba respons är ett utmärkt exempel på den flexibilitet som molnet möjliggör. Det är också vårt åtagande gentemot våra kunder.

Oavsett om du bygger din egen infrastruktur på AWS eller är en SparkPost-kund som drar nytta av vår, hoppas jag att denna förklaring av vad som hände i fredags och hur vi löste det har varit till nytta.