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.
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 een pose. Het is onze cloudarchitectuur die de schaalbaarheid, elasticiteit en betrouwbaarheid ondersteunt die kernaspecten zijn van de SparkPost dienst. Die kwaliteiten zijn belangrijke redenen waarom we onze infrastructuur hebben gebouwd op Amazon Web Services (AWS)—en het is de reden waarom we onze klanten serviceniveaus en burst-rate garanties 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 de grenzen van beschikbare technologie. We zijn afgelopen vrijdag tegen iets dergelijks aangelopen en dat incident leidde tot intermitterende traagheid in onze service en bezorgingsvertragingen voor sommige van onze klanten.
Allereerst wil ik zeggen dat het probleem dezelfde dag is opgelost. Bovendien is er geen e-mail of gerelateerde gegevens verloren gegaan. Als de bezorging van uw e-mails vanwege dit probleem vertraagd was, accepteer alstublieft mijn excuses (in feite, excuses van ons hele team). Dit incident heeft het belang van het hebben van uitgebreide back-upstrategieën benadrukt - of je nu gebruik maakt van PostgreSQL databaseback-ups of andere databeveiligingsmethoden om de bedrijfscontinuïteit te waarborgen tijdens infrastructurele uitdagingen. 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 degradatie van de service onder het tapijt te vegen en hopen dat niemand het merkt. Misschien heeft u dat ervaren met diensten die u in het verleden heeft gebruikt. Ik weet dat ik dat heb. Maar zo willen we geen zaken doen.
Ik wilde 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, kunnen geïnteresseerd zijn om hierover 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 ons gebruiksscenario met de AWS-infrastructuur—en vervolgens zeer snel een oplossing ervoor te vinden—heeft veel te maken met hoe we SparkPost hebben gebouwd, en onze geweldige relatie met het Amazon-team.
SparkPost’s uitstekende operatieteam, ons Site Reliability Engineering (SRE)-team, en onze belangrijkste technische architecten werken elke dag met Amazon samen. De sterke punten van AWS' infrastructuur hebben ons een echt voordeel gegeven bij het optimaliseren van SparkPost’s architectuur voor de cloud. Door de afgelopen twee jaar zo nauw met AWS samen te werken, hebben we ook veel geleerd over het snel opzetten en beheren van AWS-infrastructuur, en we hebben ook het voordeel van uitgebreide ondersteuning van het AWS-team.
Als we met een vergelijkbare beperking moesten omgaan in een traditioneel datacentermodel, zou zoiets dagen of zelfs weken in beslag kunnen nemen om volledig op te lossen. Die wendbaarheid en responsiviteit zijn slechts twee van de redenen waarom we onze zaak op de cloud en AWS hebben gevestigd. Samen is het soort cloud-expertise dat onze bedrijven delen moeilijk te verkrijgen. Amazon is een geweldige zakenpartner voor ons geweest, en we zijn er 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. Deze cloud-native aanpak is fundamenteel voor hoe we onze e-mail-API's voor cloudinfrastructuur ontwerpen, wat zorgt voor schaalbaarheid en betrouwbaarheid voor ontwikkelaars. We versturen meer e-mail vanaf een echt cloudplatform dan wie dan ook, en soms betekent dat het betreden van onontgonnen gebied. Het is een fundamentele waarheid van de computerwetenschap dat je niet weet welke uitdagingen zich voordoen op schaal totdat je ze tegenkomt. We vonden er één 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 die gebruikmaakt van die van ons, ik hoop dat deze uitleg van wat er afgelopen vrijdag is gebeurd, en hoe we het hebben opgelost, nuttig is geweest.
