Hoe We Ongebruikelijke DNS-fouten in AWS Opspoorden
We hebben SparkPost opgebouwd rond het idee dat een cloudservice zoals de onze zelf cloud-native moet zijn. Dat is geen pose. Het is onze cloudarchitectuur die de schaalbaarheid, elasticiteit en betrouwbaarheid ondersteunt die kernaspecten zijn van de SparkPost-service. Die kwaliteiten zijn belangrijke redenen waarom we onze infrastructuur bovenop Amazon Web Services (AWS) hebben gebouwd—en waarom we onze klanten garanties voor serviceniveau en burst-snelheden kunnen bieden die door niemand anders in de branche worden geëvenaard.
Maar we doen niet alsof we nooit worden uitgedaagd door onverwachte bugs of beperkingen van de beschikbare technologie. Vorige vrijdag kwamen we zoiets tegen, en dat incident leidde tot intermitterende traagheid in onze service en vertragingen bij de levering voor sommige van onze klanten.
Laat ik eerst zeggen dat het probleem dezelfde dag is opgelost. Bovendien is er geen e-mail of gerelateerde gegevens verloren gegaan. Mocht de aflevering van uw e-mails echter vertraagd zijn vanwege dit probleem, accepteer dan alstublieft mijn excuses (in feite, excuses van ons hele team). We weten dat u op ons rekent en het is frustrerend wanneer we niet presteren op het niveau dat u verwacht.
Sommige bedrijven zijn geneigd om problemen zoals een servicevermindering onder het tapijt te vegen en te hopen dat niemand het merkt. U heeft dat misschien ervaren met diensten die u in het verleden heeft gebruikt. Ik weet dat ik dat heb. Maar dat is niet hoe wij zaken willen doen.
Ik wilde ook om een andere reden over dit incident schrijven: we hebben iets echt interessants en waardevols geleerd over onze AWS-cloudarchitectuur. Teams die andere clouddiensten bouwen, zijn misschien geïnteresseerd om er meer over te weten te komen.
TL;DR
We kwamen niet-gedocumenteerde praktische limieten tegen van de EC2-instanties die we gebruikten voor ons primaire DNS-cluster. Cloudinstanties dimensioneren op basis van traditionele specificaties (processor, geheugen, enz.) werkt meestal zoals u zou verwachten, maar soms is dat traditionele hardwaremodel niet van toepassing. Dat geldt vooral in atypische gebruikssituaties waar aggregatielimieten kunnen optreden—en er zijn tijden dat je onvoorbereid op die scenario's stuit.
We stuitten op zo'n limiet op vrijdag toen ons DNS-queryvolume een netwerkgebruikspatroon creëerde waarvoor ons instantietype niet was voorbereid. Omdat die limiet echter niet duidelijk was uit de documentatie of de beschikbare standaardmetriek, wisten we niet dat we deze hadden bereikt. Wat we zagen was een zeer hoge mate van DNS-fouten, hetgeen vervolgens leidde tot intermitterende vertragingen op verschillende punten in onze architectuur.
Dieper Ingraven in DNS
Waarom is ons DNS-gebruik bijzonder? Welnu, het heeft veel te maken met de manier waarop e-mail werkt, vergeleken met het contentmodel waarvoor AWS oorspronkelijk is ontworpen. Webgebaseerde contentlevering maakt veel gebruik van wat men als klassieke inkomende 'pull'-scenario's zou kunnen beschouwen: een cliënt vraagt gegevens op, of het nu HTML is, videostreams of iets anders, vanuit de cloud. Maar de gebruikssituaties voor aanbieders van berichtendiensten zoals SparkPost zijn uitzonderingen op het gebruikelijke AWS-scenario. In ons geval doen we veel uitgaand verkeer: specifiek, e-mail (en andere berichttypen zoals SMS of mobiele pushmeldingen). En dat push-verkeer vertrouwt sterk op DNS.
Als u bekend bent met DNS, weet u misschien dat het over het algemeen vrij lichte gegevens zijn. Om een bepaalde HTML-pagina aan te vragen, moet je eerst vragen waar die pagina op het internet te vinden is, maar dat verzoek is een fractie van de grootte van de inhoud die je ophaalt.
E-mail maakt echter uitzonderlijk veel gebruik van DNS om afleverdomeinen op te zoeken—bijvoorbeeld, SparkPost verstuurt elke maand vele miljarden e-mails naar meer dan 1 miljoen unieke domeinen . Voor elke e-mail die we bezorgen, moeten we minimaal twee DNS-opzoekingen doen, en het gebruik van DNS 'txt'-records voor anti-phishingtechnologieën zoals SPF en DKIM betekent ook dat DNS nodig is om e-mail te ontvangen. Voeg daaraan toe ons meer traditionele gebruik van AWS API-diensten voor onze apps, en het is moeilijk te overdrijven hoe belangrijk DNS is voor onze infrastructuur.
Dit alles betekent dat we in een ongebruikelijke situatie terechtkwamen waarbij ons groeiende volume aan uitgaande berichten een DNS-verkeersvolume creëerde dat een gecombineerde netwerkdoorvoerslimiet bereikte op instantietypen die anders voldoende middelen leken te hebben om die belasting te hanteren. En zoals denial-of-service-aanvallen op de Dyn DNS-infrastructuur vorig jaar aantoonden, wanneer DNS faalt, faalt alles. (Dat is iets wat iedereen die systemen bouwt die op DNS vertrouwen pijnlijk goed weet.)
De plotselinge DNS-problemen veroorzaakten een reactie van onze operatie- en betrouwbaarheidstechniekenteams om het probleem te identificeren. Ze werkten samen met onze partners bij Amazon om op te schalen aan de AWS-operatiekant. Samen identificeerden we de oorzaak en een oplossing. We implementeerden een cluster van naamservers met grotere capaciteit met een grotere focus op netwerkcapaciteit die aan onze DNS-behoeften kon voldoen zonder dat de doorvoerlimieten werden overschreden. Gelukkig, omdat dit alles binnen AWS was, konden we de nieuwe instanties snel in gebruik nemen en zelfs bestaande instanties zeer snel opnieuw ordenen. DNS hervatte normaal gedrag, fouten bij het opzoeken stopten, en we waren (en de uitgaande berichtaflevering) weer op schema.
Om tegen dit specifieke probleem in de toekomst te mitigeren, maken we ook DNS-architectuurwijzigingen om onze kerncomponenten beter te isoleren van de impact van soortgelijke, onverwachte drempels. We werken ook samen met het Amazon-team om geschikte monitoringmodellen te bepalen die ons voldoende waarschuwing geven om een soortgelijk incident af te wenden voordat het effect heeft op een van onze klanten.
AWS en de Zilveren Rand van de Cloud
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 ons gebruiksscenario met de AWS-infrastructuur—om vervolgens binnen zeer korte tijd een oplossing te vinden—heeft veel te maken met hoe we SparkPost hebben gebouwd, en onze geweldige relatie met het Amazon-team.
SparkPost's uitstekende operationele team, ons Site Reliability Engineering (SRE)-team en onze voornaamste technische architecten werken elke dag met Amazon samen. De sterke punten van de AWS-infrastructuur hebben ons echt een voorsprong gegeven bij het optimaliseren van SparkPost's architectuur voor de cloud. Zo nauw samenwerken met AWS gedurende de afgelopen twee jaren heeft ons ook veel geleerd over het snel inzetten van AWS-infrastructuur en het snel handelen, en we hebben ook het voordeel van diepgaande ondersteuning van het AWS-team.
Als we met een vergelijkbare beperking in een traditioneel datacentermodel zouden moeten werken, zou iets als dit dagen of zelfs weken kunnen duren om volledig op te lossen. Die wendbaarheid en reactiesnelheid zijn slechts twee van de redenen waarom we ons bedrijf hebben gevestigd op de cloud en AWS. Samen is het soort cloudexpertise dat onze bedrijven delen moeilijk te verkrijgen. 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-mailbezorgservice die vanaf het begin is gebouwd voor de cloud. We verzenden meer e-mail vanuit een echt cloudplatform dan wie dan ook, en soms betekent dat onontgonnen gebied betreden. Het is een fundamentele waarheid van de informatica dat u niet weet welke uitdagingen zich op schaal voordoen totdat u ze tegenkomt. We vonden er een bij AWS, maar onze snelle reactie is een geweldig voorbeeld van de flexibiliteit die de cloud mogelijk maakt. Het is ook onze toewijding aan onze klanten.
Of u nu uw eigen infrastructuur op AWS bouwt, of een SparkPost-klant bent die gebruik maakt van de onze, ik hoop dat deze uitleg van wat er afgelopen vrijdag is gebeurd, en hoe we het hebben opgelost, nuttig is geweest.