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 dat incident led to intermittent slowness in our service and delivery delays for some of our customers.

Laat ik eerst zeggen dat het probleem diezelfde dag nog was opgelost. Bovendien zijn er geen e-mails of gerelateerde gegevens verloren gegaan. Echter, als de aflevering van uw e-mails werd vertraagd als gevolg van dit probleem, accepteer dan alstublieft mijn excuses (in feite een verontschuldiging van ons hele team). We weten dat u op ons rekent, en het is frustrerend als we niet presteren op het niveau dat u verwacht.

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.

Ik wilde ook om een andere reden over dit incident schrijven: we hebben iets heel interessants en waardevols geleerd over onze AWS-cloudarchitectuur. Teams die andere clouddiensten bouwen, zouden het interessant kunnen vinden om hiervan te leren.

TL;DR

We liepen tegen ongedocumenteerde praktische grenzen aan van de EC2-instanties die we gebruikten voor ons primaire DNS-cluster. De dimensionering van cloud-instanties op basis van traditionele specificaties (processor, geheugen, enz.) werkt meestal zoals je zou verwachten, maar soms is dat traditionele hardwaremodel niet van toepassing. Dat geldt vooral voor atypische gebruikssituaties waar geaggregeerde limieten een rol kunnen spelen, en soms loop je zonder waarschuwing tegen dergelijke scenario's aan.

We hebben vrijdag zo'n grens bereikt toen ons DNS-queryvolume een netwerkgebruikspatroon creëerde waarop ons instance-type niet was voorbereid. Maar omdat die limiet niet duidelijk bleek uit de documentatie of de beschikbare standaardgegevens, wisten we niet dat we die hadden bereikt. Wat we zagen was een zeer hoog aantal DNS-fouten, die op hun beurt leidden tot intermitterende vertragingen op verschillende punten in onze architectuur.

Dieper graven in DNS

Waarom is ons DNS-gebruik bijzonder? Nou, het heeft veel te maken met de manier waarop e-mail werkt, vergeleken met het contentmodel waarvoor AWS oorspronkelijk is ontworpen. Web-based content delivery maakt veel gebruik van wat kan worden beschouwd als klassieke inbound "pull" scenario's: een cliënt vraagt gegevens, of het nu HTML, video streams, of iets anders, uit de cloud. Maar de use cases voor messaging service providers zoals SparkPost zijn uitzonderingen op het gebruikelijke AWS-scenario. In ons geval doen we veel outbound pushing van verkeer: met name e-mail (en andere berichttypes zoals SMS of mobiele push-notificaties). En dat push-verkeer is sterk afhankelijk van DNS.

Als u bekend bent met DNS, weet u misschien dat het over het algemeen vrij lichte gegevens zijn. Om een bepaalde HTML-pagina op te vragen, moet u eerst vragen waar die pagina op het internet te vinden is, maar dat verzoek is slechts een fractie van de omvang van de inhoud die u ophaalt.

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 elke maand. 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 denial-of-service-aanvallen op de Dyn DNS-infrastructuur last year demonstrated, when DNS breaks, everything breaks. (That’s something anyone who builds systems that rely on DNS already knows painfully well.)

De plotselinge DNS-problemen veroorzaakten een reactie van onze operationele en betrouwbaarheidsteams om het probleem te identificeren. Zij werkten samen met onze partners bij Amazon om het probleem aan de operationele kant van AWS te escaleren. Samen identificeerden we de oorzaak en een oplossing. We implementeerden een cluster van nameservers met een grotere capaciteit en een grotere focus op netwerkcapaciteit die aan onze DNS-behoeften kon voldoen zonder tegen de rode lijnen voor doorvoer aan te lopen. Gelukkig konden we, omdat dit alles binnen AWS gebeurde, de nieuwe instances opstarten en zelfs bestaande instances zeer snel aanpassen. DNS gedroeg zich weer normaal, de opzoekfouten hielden op, en wij (en de levering van uitgaande berichten) waren weer op de rails.

Om dit specifieke probleem in de toekomst tegen te gaan, brengen we ook wijzigingen aan in de DNS-architectuur om onze kerncomponenten beter te beschermen tegen de impact van soortgelijke, onverwachte drempels. We werken ook samen met het Amazon-team om geschikte bewakingsmodellen vast te stellen die ons voldoende waarschuwen om een soortgelijk incident af te wenden voordat het onze klanten treft.

AWS and the Cloud’s Silver Lining

Ik wil de impact van dit incident op onze klanten niet bagatelliseren. Maar ons vermogen om het onderliggende probleem te identificeren als een onverwachte interactie van onze use case met de AWS-infrastructuur - en vervolgens in zeer korte tijd een oplossing te vinden - heeft veel te maken met de manier waarop we SparkPost hebben gebouwd, en onze goede relatie met het Amazon-team.

SparkPost’s superb operations corps, our Site Reliability Engineering (SRE) team, and our principal technical architects work with Amazon every day. De strengths of AWS’ infrastructure has given us a real leg up het optimaliseren van de architectuur van SparkPost voor de cloud. 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.

Als we een soortgelijke beperking in een traditioneel datacentermodel zouden moeten omzeilen, zou het dagen of zelfs weken kunnen duren voordat zoiets volledig is opgelost. Die flexibiliteit en reactiesnelheid zijn slechts twee van de redenen waarom we ons bedrijf op de cloud en AWS hebben gezet. Het soort cloud-expertise dat onze bedrijven delen is moeilijk te vinden. Amazon is een geweldige zakenpartner voor ons geweest, en we zijn echt trots op wat we hebben gedaan met de AWS-stack.

SparkPost is de eerste e-mail service die vanaf het begin is gebouwd voor de cloud. We versturen meer e-mail vanaf een echt cloud platform dan wie dan ook, en soms betekent dat dat we ons op onbekend terrein begeven. Het is een fundamentele waarheid van computerwetenschap dat je niet weet welke uitdagingen zich voordoen op schaal totdat je ze tegenkomt. We hebben er een gevonden op AWS, maar onze snelle reactie is een goed voorbeeld van de flexibiliteit die de cloud mogelijk maakt. Het is ook onze inzet voor onze klanten.

Of je nu je eigen infrastructuur op AWS bouwt, of een SparkPost klant bent die gebruik maakt van de onze, ik hoop dat deze uitleg over wat er afgelopen vrijdag gebeurde, en hoe we het hebben opgelost, nuttig is geweest.