We kwamen ongewenste praktische beperkingen tegen van de EC2-instances die we gebruikten voor onze primaire DNS-cluster. Het bepalen van de grootte van cloud-instances op basis van traditionele specificaties (processor, geheugen, enz.) werkt meestal zoals je zou verwachten, maar soms geldt dat traditionele hardwaremodel niet.
Business in a box.
Ontdek onze oplossingen.
Praat met ons verkoopteam
Hoe We Ongewone DNS-fouten in AWS Opspoorden
We hebben SparkPost gebouwd rond het idee dat een cloudservice zoals de onze zelf cloud-native moet zijn. Dat is niet alleen praatjes. 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 het is waarom we onze klanten serviceniveau en burst rate garanties kunnen bieden die ongeëvenaard zijn door iemand anders in the business.
Maar we doen niet alsof we nooit worden uitgedaagd door onverwachte bugs of beperkingen van beschikbare technologie. We kwamen iets dergelijks tegen afgelopen vrijdag, en dat incident leidde tot intermitterende traagheid in onze service en vertragingen in bezorging voor sommige van onze klanten.
Laat me eerst zeggen dat het probleem dezelfde dag is opgelost. Bovendien, geen e-mail of gerelateerde gegevens zijn verloren gegaan. Echter, als de bezorging van uw e-mails werd vertraagd door dit probleem, accepteer dan mijn excuses (in feite een excuus 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 in de verleiding om problemen zoals een degradatie van de dienstverlening onder het tapijt te vegen en hopen dat niemand het opmerkt. U heeft dat misschien ervaren met diensten die u in het verleden heeft gebruikt. Ik weet dat ik dat wel heb. Maar zo doen wij geen zaken.
Ik wilde over dit incident schrijven om een andere reden: we hebben iets echt interessants en waardevols geleerd over onze AWS-cloudarchitectuur. Teams die andere cloudservices bouwen, zouden geïnteresseerd kunnen zijn om er meer over te leren.
TL;DR
Dieper graven in DNS
Waarom is ons DNS-gebruik speciaal? Nou, 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 kan worden beschouwd als klassieke inkomende 'pull'-scenario's: een client vraagt om gegevens, zij het HTML, videostreams 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 uitgaande push-verkeer: specifiek, e-mail (en andere berichttypen zoals SMS of mobiele pushmeldingen). En dat push-stijl verkeer is sterk afhankelijk van DNS.
Als je bekend bent met DNS, weet je misschien dat het over het algemeen vrij lichte gegevens zijn. Om een bepaalde HTML-pagina op te vragen, moet je eerst vragen waar die pagina te vinden is op het internet, maar die aanvraag is slechts een fractie van de grootte van de inhoud die je ophaalt.
E-mail daarentegen maakt uitzonderlijk zwaar gebruik van DNS om afleveringsdomeinen op te zoeken—bijvoorbeeld, SparkPost verzendt elke maand vele miljarden e-mails naar meer dan 1 miljoen unieke domeinen elke maand. Voor elke e-mail die we leveren, moeten we minimaal twee DNS-opzoekingen uitvoeren, en het gebruik van DNS 'txt'-records voor anti-phishingtechnologieën zoals SPF en DKIM betekent dat DNS ook nodig is om mail te ontvangen. Voeg daarbij 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 stuitten op een ongebruikelijke situatie waarin ons groeiende volume aan uitgaande berichten een DNS-verkeervolume creëerde dat een totale netwerkdoorvoerlimiet bereikte op instantie-types die anders voldoende middelen leken te hebben om die belasting te verwerken. En zoals denial-of-service-aanvallen op de Dyn DNS-infrastructuur vorig jaar aantoonden, als DNS stukgaat, gaat alles stuk. (Dat is iets wat iedereen die systemen bouwt die afhankelijk zijn van DNS al pijnlijk goed weet.)
De plotselinge DNS-problemen triggerden een reactie van onze operaties- en betrouwbaarheidstechniekteams om het probleem te identificeren. Ze werkten samen met onze partners bij Amazon om de escalatie aan de AWS-operatiekant te verhogen. Samen identificeerden we de oorzaak en een oplossing. We hebben een cluster van nameservers met grotere capaciteit ingezet, met een grotere focus op netwerkcapaciteit die onze DNS-behoeften kon vervullen zonder in de rode lijnen voor doorvoer terecht te komen. Gelukkig, omdat dit allemaal binnen AWS plaatsvond, konden we de nieuwe instanties snel opstarten en zelfs bestaande instanties erg snel vergroten. DNS hervatte normaal gedrag, opzoekingsfouten hielden op, en wij (en de uitgaande bezorging van berichten) waren weer op het goede spoor.
Om dit specifieke probleem in de toekomst te voorkomen, maken we ook wijzigingen in de DNS-architectuur om onze kerncomponenten beter te isoleren tegen de impact van vergelijkbare, onverwachte drempels. We werken ook samen met het Amazon-team om geschikte monitoringsmodellen te bepalen die ons voldoende waarschuwing geven om een soortgelijk incident af te wenden voordat het een van onze klanten treft.
AWS en de Silver Lining van de Cloud
Ik wil de impact van dit incident op onze klanten niet verbloemen. Maar ons vermogen om het onderliggende probleem te identificeren als een onverwachte interactie van onze use case met de AWS-infrastructuur—en 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.
Het geweldige operationele team van SparkPost, ons Site Reliability Engineering (SRE) team, en onze voornaamste technische architecten werken elke dag met Amazon. De sterke punten van de infrastructuur van AWS hebben ons een echt voordeel gegeven om de architectuur van SparkPost voor de cloud te optimaliseren. Het nauwe samenwerken met AWS gedurende de afgelopen twee jaar heeft ons ook veel geleerd over het snel opzetten van AWS-infrastructuur, en we hebben ook het voordeel van uitgebreide ondersteuning van het AWS-team.
Als we moesten werken rond een vergelijkbare beperking in een traditioneel datacentermodel, zou iets als dit dagen of zelfs weken kunnen duren om volledig op te lossen. Die flexibiliteit en reactievermogen zijn slechts twee van de redenen waarom we ons bedrijf op de cloud en AWS hebben gevestigd. Samen is de soort cloud-expertise die onze bedrijven delen 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-mailbezorgdienst die vanaf het begin voor de cloud is gebouwd. We verzenden meer e-mail vanaf een echt cloudplatform dan wie dan ook, en soms betekent dat dat we onontgonnen gebied betreden. Het is een fundamentele waarheid van de informatica dat je niet weet welke uitdagingen zich op schaal voordoen totdat je ze tegenkomt. We hebben er een gevonden op AWS, maar onze snelle reactie is een fantastisch voorbeeld van de flexibiliteit die de cloud mogelijk maakt. Het is ook onze toewijding aan onze klanten.
Of je nu je eigen infrastructuur op AWS bouwt, of een SparkPost-klant bent die gebruik maakt van die van ons, ik hoop dat deze uitleg over wat er afgelopen vrijdag is gebeurd en hoe we het hebben opgelost nuttig is geweest.
