De dag dat onze DNS een ongedocumenteerde limiet bereikte in AWS
Bird
7 feb 2017
Techniek
1 min read
Belangrijkste punten
SparkPost ondervond een ongedocumenteerde netwerkdoorvoerlimiet op een specifiek AWS EC2-instance-type dat zijn primaire DNS-cluster aandreef.
Traditionele instance-grootte (CPU, RAM, schijf) onthulde deze flessenhals niet omdat het probleem verband hield met geaggregeerd DNS-netwerkverkeer, niet met resource-uitputting.
DNS-gebruik voor uitgaande e-mail met een hoog volume is ongewoon zwaar: SparkPost genereert miljoenen DNS-lookups voor domeinroutering, authenticatie (SPF/DKIM) en AWS API-interacties.
De DNS-fout was niet het gevolg van onjuiste DNS-antwoorden — in plaats daarvan werden de netwerkcapaciteitsdrempels op instance-niveau stilletjes overschreden, wat wijdverspreide opzoekfouten veroorzaakte.
Omdat AWS deze zachte netwerkbeperkingen niet expliciet documenteert, vereiste het diagnosticeren van het probleem nauwe samenwerking tussen het SRE-team van SparkPost en AWS-ingenieurs.
Het team loste het probleem op door DNS-services te migreren naar grotere instance-types met meer netwerkbandbreedte en delen van de DNS-architectuur opnieuw te ontwerpen voor betere isolatie en failover.
Er gingen geen klantgegevens of berichten verloren, maar de gebeurtenis benadrukte hoe cloud-native architecturen onverwachte limieten op schaal kunnen bereiken — en hoe snel ze kunnen worden opgelost met AWS-elasticiteit.
Q&A Hoogtepunten
Wat is er gebeurd?
Het DNS-cluster van SparkPost bereikte onverwacht een AWS-netwerkdoorvoerlimiet, waardoor DNS-opzoekingen af en toe mislukten — wat de levering van e-mails vertraagde.
Waarom ging DNS überhaupt stuk?
DNS is extreem afhankelijk van externe e-mail. Elke verzending vereist meerdere opzoekingen (MX, TXT, SPF, DKIM), dus een hoog verzendvolume = enorme DNS-verkeer.
Dit verkeerspatroon overschreed een niet-gepubliceerde limiet op het EC2 instance type dat de nameservers host.
Hoe verschilt DNS voor e-mail van webapplicaties?
Web apps trekken meestal inhoud binnen (klanten vragen om gegevens).
Email bezorgdiensten duwen verkeer, waardoor veel meer DNS-opzoeken worden geactiveerd — vaak miljarden per maand.
Email is afhankelijk van DNS voor routering, veiligheidscontrole en failover.
Hoe manifesteerde de mislukking zich?
DNS-verzoeken begonnen te falen of liepen vast
Bezorgingswachtrijen liepen vol
Latentie nam toe in delen van het systeem
Niets ging verloren — alleen vertraagd.
Waarom was dit moeilijk te diagnosticeren?
De limiet was niet gedocumenteerd
AWS monitoring toonde niet expliciet de bottleneck
Alle traditionele metrics (CPU, RAM, schijf) zagen er normaal uit
Het probleem kwam alleen aan het licht onder een specifiek, hoog-volume DNS-verkeer patroon.
Hoe heeft SparkPost het opgelost?
Geüpgraded naar EC2-instantietypen met hogere netwerksnelheid plafond
DNS-clusters opnieuw ontworpen om veerkrachtiger te zijn tegen pieken in het totale verkeer
Samen met AWS gewerkt om betere signaal/waarschuwingspatronen te identificeren om dit eerder op te vangen
Is klantgegevens of mail verloren?
Nee — alleen de bezorging vertraagde. Zodra DNS gestabiliseerd was, werd alle post weer normaal bezorgd.
Wat is de bredere les?
Zelfs in de cloud, kun je onzichtbare schaalbeperkingen tegenkomen — maar cloud-native ontwerpen geven je de flexibiliteit om snel te herstellen.
Elasticiteit, samenwerking met AWS, en sterke SRE-praktijken maken een snel herstel mogelijk.
Hoe We Unusual DNS Failures in AWS Opspoorden
We hebben SparkPost opgebouwd rond het idee dat een cloudservice zoals de onze zelf cloud-native moet zijn. Dat is niet alleen een houding aannemen. Het is onze cloudarchitectuur die de schaalbaarheid, elasticiteit en betrouwbaarheid ondersteunt die kernaspecten van de SparkPost-dienst zijn. Die kwaliteiten zijn belangrijke redenen waarom we onze infrastructuur bovenop Amazon Web Services (AWS) hebben gebouwd—en het is de reden waarom we onze klanten servicestandaarden en pieksnelheidsgaranties kunnen bieden die ongeëvenaard zijn door iemand anders in de zaak.
Maar we doen niet alsof we nooit worden uitgedaagd door onverwachte bugs of de grenzen van beschikbare technologie. We liepen afgelopen vrijdag tegen zoiets aan, en dat incident leidde tot af en toe traagheid in onze service en bezorgingsvertragingen voor sommige van onze klanten.
Allereerst wil ik zeggen dat het probleem dezelfde dag was opgelost. Bovendien is er geen e-mail of gerelateerde data verloren gegaan. Als de levering van uw e-mails echter vertraagd was door dit probleem, accepteer dan mijn excuses (in feite, een excuus van ons hele team). Dit incident benadrukte het belang van het hebben van uitgebreide back-upstrategieën - of u nu PostgreSQL-database back-ups of andere gegevensbeschermingsmethoden gebruikt 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 voelen zich geneigd om kwesties zoals een verslechtering van de dienstverlening onder het tapijt te vegen en hopen dat niemand het merkt. U hebt dat misschien meegemaakt met diensten die u in het verleden hebt gebruikt. Ik weet dat ik dat heb gedaan. Maar zo doen wij geen zaken.
Ik wilde om nog een reden over dit incident schrijven: we hebben iets heel interessants en waardevols geleerd over onze AWS-cloudarchitectuur. Teams die andere clouddiensten bouwen, vinden het misschien interessant om erover te leren.
We hebben SparkPost opgebouwd rond het idee dat een cloudservice zoals de onze zelf cloud-native moet zijn. Dat is niet alleen een houding aannemen. Het is onze cloudarchitectuur die de schaalbaarheid, elasticiteit en betrouwbaarheid ondersteunt die kernaspecten van de SparkPost-dienst zijn. Die kwaliteiten zijn belangrijke redenen waarom we onze infrastructuur bovenop Amazon Web Services (AWS) hebben gebouwd—en het is de reden waarom we onze klanten servicestandaarden en pieksnelheidsgaranties kunnen bieden die ongeëvenaard zijn door iemand anders in de zaak.
Maar we doen niet alsof we nooit worden uitgedaagd door onverwachte bugs of de grenzen van beschikbare technologie. We liepen afgelopen vrijdag tegen zoiets aan, en dat incident leidde tot af en toe traagheid in onze service en bezorgingsvertragingen voor sommige van onze klanten.
Allereerst wil ik zeggen dat het probleem dezelfde dag was opgelost. Bovendien is er geen e-mail of gerelateerde data verloren gegaan. Als de levering van uw e-mails echter vertraagd was door dit probleem, accepteer dan mijn excuses (in feite, een excuus van ons hele team). Dit incident benadrukte het belang van het hebben van uitgebreide back-upstrategieën - of u nu PostgreSQL-database back-ups of andere gegevensbeschermingsmethoden gebruikt 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 voelen zich geneigd om kwesties zoals een verslechtering van de dienstverlening onder het tapijt te vegen en hopen dat niemand het merkt. U hebt dat misschien meegemaakt met diensten die u in het verleden hebt gebruikt. Ik weet dat ik dat heb gedaan. Maar zo doen wij geen zaken.
Ik wilde om nog een reden over dit incident schrijven: we hebben iets heel interessants en waardevols geleerd over onze AWS-cloudarchitectuur. Teams die andere clouddiensten bouwen, vinden het misschien interessant om erover te leren.
We hebben SparkPost opgebouwd rond het idee dat een cloudservice zoals de onze zelf cloud-native moet zijn. Dat is niet alleen een houding aannemen. Het is onze cloudarchitectuur die de schaalbaarheid, elasticiteit en betrouwbaarheid ondersteunt die kernaspecten van de SparkPost-dienst zijn. Die kwaliteiten zijn belangrijke redenen waarom we onze infrastructuur bovenop Amazon Web Services (AWS) hebben gebouwd—en het is de reden waarom we onze klanten servicestandaarden en pieksnelheidsgaranties kunnen bieden die ongeëvenaard zijn door iemand anders in de zaak.
Maar we doen niet alsof we nooit worden uitgedaagd door onverwachte bugs of de grenzen van beschikbare technologie. We liepen afgelopen vrijdag tegen zoiets aan, en dat incident leidde tot af en toe traagheid in onze service en bezorgingsvertragingen voor sommige van onze klanten.
Allereerst wil ik zeggen dat het probleem dezelfde dag was opgelost. Bovendien is er geen e-mail of gerelateerde data verloren gegaan. Als de levering van uw e-mails echter vertraagd was door dit probleem, accepteer dan mijn excuses (in feite, een excuus van ons hele team). Dit incident benadrukte het belang van het hebben van uitgebreide back-upstrategieën - of u nu PostgreSQL-database back-ups of andere gegevensbeschermingsmethoden gebruikt 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 voelen zich geneigd om kwesties zoals een verslechtering van de dienstverlening onder het tapijt te vegen en hopen dat niemand het merkt. U hebt dat misschien meegemaakt met diensten die u in het verleden hebt gebruikt. Ik weet dat ik dat heb gedaan. Maar zo doen wij geen zaken.
Ik wilde om nog een reden over dit incident schrijven: we hebben iets heel interessants en waardevols geleerd over onze AWS-cloudarchitectuur. Teams die andere clouddiensten bouwen, vinden het misschien interessant om erover te leren.
TL;DR
We kwamen praktische limieten tegen van de EC2-instanties die we gebruikten voor ons primaire DNS-cluster, die niet in de documentatie waren vastgelegd. Het dimensioneren 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 is vooral waar in atypische gebruikssituaties waar cumulatieve limieten een rol kunnen spelen—en er zijn momenten waarop je zonder waarschuwing met die scenario's wordt geconfronteerd.
We bereikten zo'n limiet op vrijdag toen ons DNS-queryvolume een netwerkgebruikspatroon creëerde waarvoor ons instantietype niet voorbereid was. Omdat die limiet echter niet duidelijk was uit de documentatie of standaard beschikbare statistieken, wisten we niet dat we die hadden bereikt. Wat we waarnamen, was een zeer hoge mate van DNS-fouten, wat op zijn beurt leidde tot intermitterende vertragingen op verschillende punten in onze architectuur.
We kwamen praktische limieten tegen van de EC2-instanties die we gebruikten voor ons primaire DNS-cluster, die niet in de documentatie waren vastgelegd. Het dimensioneren 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 is vooral waar in atypische gebruikssituaties waar cumulatieve limieten een rol kunnen spelen—en er zijn momenten waarop je zonder waarschuwing met die scenario's wordt geconfronteerd.
We bereikten zo'n limiet op vrijdag toen ons DNS-queryvolume een netwerkgebruikspatroon creëerde waarvoor ons instantietype niet voorbereid was. Omdat die limiet echter niet duidelijk was uit de documentatie of standaard beschikbare statistieken, wisten we niet dat we die hadden bereikt. Wat we waarnamen, was een zeer hoge mate van DNS-fouten, wat op zijn beurt leidde tot intermitterende vertragingen op verschillende punten in onze architectuur.
We kwamen praktische limieten tegen van de EC2-instanties die we gebruikten voor ons primaire DNS-cluster, die niet in de documentatie waren vastgelegd. Het dimensioneren 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 is vooral waar in atypische gebruikssituaties waar cumulatieve limieten een rol kunnen spelen—en er zijn momenten waarop je zonder waarschuwing met die scenario's wordt geconfronteerd.
We bereikten zo'n limiet op vrijdag toen ons DNS-queryvolume een netwerkgebruikspatroon creëerde waarvoor ons instantietype niet voorbereid was. Omdat die limiet echter niet duidelijk was uit de documentatie of standaard beschikbare statistieken, wisten we niet dat we die hadden bereikt. Wat we waarnamen, was een zeer hoge mate van DNS-fouten, wat op zijn beurt leidde 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. Webgebaseerde contentlevering maakt intensief gebruik van wat klassiek inkomend "pull"-scenario kan worden beschouwd: een client vraagt gegevens op, of het nu gaat om HTML, videostreams of iets anders, vanuit de cloud. Maar de gebruikssituaties voor berichtendienstproviders zoals SparkPost zijn uitzonderingen op het gebruikelijke AWS-scenario. In ons geval doen we veel uitgaande verkeersconstructies: specifiek e-mail (en andere berichten zoals sms of mobiele pushmeldingen). En dat push-stijl verkeer maakt zwaar gebruik van DNS.
Als je bekend bent met DNS, weet je misschien dat het meestal vrij lichte gegevens zijn. Om een bepaalde HTML-pagina op te vragen, moet je eerst vragen waar deze pagina op het internet te vinden is, maar die aanvraag is een fractie van de omvang van de inhoud die je ophaalt.
E-mail daarentegen maakt uitzonderlijk veel gebruik van DNS om afleverdomeinen 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 bezorgen, moeten we minimaal twee DNS-lookups uitvoeren, en het gebruik van DNS "txt"-records voor anti-phishingtechnologieën zoals SPF en DKIM betekent dat DNS ook nodig is om e-mail te ontvangen. Voeg daarbij ons meer traditionele gebruik van AWS API-diensten voor onze apps, en het is moeilijk om te overdrijven hoe belangrijk DNS is voor onze infrastructuur.
Dit alles betekent dat we een ongebruikelijke situatie tegenkwamen waarin ons groeiende volume uitgaande berichten een DNS-verkeersvolume creëerde dat een cumulatieve netwerkdoorvoercaplimiet bereikte op instance-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 breekt, breekt alles. (Dat is iets wat iedereen die systemen bouwt die op DNS vertrouwen al pijnlijk goed weet.)
De plotselinge DNS-problemen stimuleerden een reactie van onze operationele en betrouwbaarheidstechnische teams om het probleem te identificeren. Ze werkten samen met onze partners bij Amazon om het op te lossen aan de AWS-kant. Samen hebben we de oorzaak geïdentificeerd en een oplossing gevonden. We hebben een cluster van namenservers met een grotere capaciteit ingezet, met een grotere aandacht voor netwerkcapaciteit, die aan onze DNS-behoeften zou kunnen voldoen zonder tegen de limieten voor doorvoer op te lopen. Gelukkig omdat dit allemaal binnen AWS was, konden we de nieuwe instances snel opzetten en zelfs bestaande instances snel vergroten. DNS hervatte zijn normale gedrag, lookup-mislukkingen hielden op, en wij (en de uitgaande berichtbezorging) waren weer op koers.
Om deze specifieke kwestie in de toekomst te mitigeren, maken we ook DNS-architectuurwijzigingen om onze kerncomponenten beter te isoleren tegen de impact van ontmoetingen met soortgelijke, onverwachte limieten. We werken ook samen met het Amazon-team om passende monitoringmodellen te bepalen die ons voldoende waarschuwing geven om een soortgelijke gebeurtenis te voorkomen voordat het onze klanten beïnvloedt.
Onderwerp | Typische AWS-werklast | SparkPost's Uitgaande E-mail Werklast |
|---|---|---|
Verkeerspatroon | Meestal inkomende "pull"-verzoeken (webpagina's, API's, media) | Zwaar uitgaand "push"-verkeer (miljarden e-mails) |
DNS-afhankelijkheid | Licht: 1–2 lookups per inhoudsverzoek | Zeer zwaar: meerdere DNS-lookups per e-mail + SPF/DKIM TXT-controles |
Queryvolume | Voorspelbaar en proportioneel aan gebruikersactiviteit | Explodeert met uitgaande campagnes gericht op miljoenen domeinen |
Knelpunttype | CPU-, geheugen- of opslaglimieten | Cumulatieve netwerkdoorvoercaplimieten op instance-types |
Foutmodus | Afgenomen latentie of API-timeout | DNS lookup-mislukkingen veroorzaken bezorgvertragingen |
Zichtbaarheid | Limieten zijn meestal gedocumenteerd en weergegeven in statistieken | Doorvoerceiling was ongedocumenteerd en onzichtbaar in CloudWatch |
Mitigatiebenadering | Schalingsinstantiemiddelen of caching toevoegen | Migreren naar instance families met hogere bandbreedte + DNS-architectuur redesign |
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. Webgebaseerde contentlevering maakt intensief gebruik van wat klassiek inkomend "pull"-scenario kan worden beschouwd: een client vraagt gegevens op, of het nu gaat om HTML, videostreams of iets anders, vanuit de cloud. Maar de gebruikssituaties voor berichtendienstproviders zoals SparkPost zijn uitzonderingen op het gebruikelijke AWS-scenario. In ons geval doen we veel uitgaande verkeersconstructies: specifiek e-mail (en andere berichten zoals sms of mobiele pushmeldingen). En dat push-stijl verkeer maakt zwaar gebruik van DNS.
Als je bekend bent met DNS, weet je misschien dat het meestal vrij lichte gegevens zijn. Om een bepaalde HTML-pagina op te vragen, moet je eerst vragen waar deze pagina op het internet te vinden is, maar die aanvraag is een fractie van de omvang van de inhoud die je ophaalt.
E-mail daarentegen maakt uitzonderlijk veel gebruik van DNS om afleverdomeinen 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 bezorgen, moeten we minimaal twee DNS-lookups uitvoeren, en het gebruik van DNS "txt"-records voor anti-phishingtechnologieën zoals SPF en DKIM betekent dat DNS ook nodig is om e-mail te ontvangen. Voeg daarbij ons meer traditionele gebruik van AWS API-diensten voor onze apps, en het is moeilijk om te overdrijven hoe belangrijk DNS is voor onze infrastructuur.
Dit alles betekent dat we een ongebruikelijke situatie tegenkwamen waarin ons groeiende volume uitgaande berichten een DNS-verkeersvolume creëerde dat een cumulatieve netwerkdoorvoercaplimiet bereikte op instance-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 breekt, breekt alles. (Dat is iets wat iedereen die systemen bouwt die op DNS vertrouwen al pijnlijk goed weet.)
De plotselinge DNS-problemen stimuleerden een reactie van onze operationele en betrouwbaarheidstechnische teams om het probleem te identificeren. Ze werkten samen met onze partners bij Amazon om het op te lossen aan de AWS-kant. Samen hebben we de oorzaak geïdentificeerd en een oplossing gevonden. We hebben een cluster van namenservers met een grotere capaciteit ingezet, met een grotere aandacht voor netwerkcapaciteit, die aan onze DNS-behoeften zou kunnen voldoen zonder tegen de limieten voor doorvoer op te lopen. Gelukkig omdat dit allemaal binnen AWS was, konden we de nieuwe instances snel opzetten en zelfs bestaande instances snel vergroten. DNS hervatte zijn normale gedrag, lookup-mislukkingen hielden op, en wij (en de uitgaande berichtbezorging) waren weer op koers.
Om deze specifieke kwestie in de toekomst te mitigeren, maken we ook DNS-architectuurwijzigingen om onze kerncomponenten beter te isoleren tegen de impact van ontmoetingen met soortgelijke, onverwachte limieten. We werken ook samen met het Amazon-team om passende monitoringmodellen te bepalen die ons voldoende waarschuwing geven om een soortgelijke gebeurtenis te voorkomen voordat het onze klanten beïnvloedt.
Onderwerp | Typische AWS-werklast | SparkPost's Uitgaande E-mail Werklast |
|---|---|---|
Verkeerspatroon | Meestal inkomende "pull"-verzoeken (webpagina's, API's, media) | Zwaar uitgaand "push"-verkeer (miljarden e-mails) |
DNS-afhankelijkheid | Licht: 1–2 lookups per inhoudsverzoek | Zeer zwaar: meerdere DNS-lookups per e-mail + SPF/DKIM TXT-controles |
Queryvolume | Voorspelbaar en proportioneel aan gebruikersactiviteit | Explodeert met uitgaande campagnes gericht op miljoenen domeinen |
Knelpunttype | CPU-, geheugen- of opslaglimieten | Cumulatieve netwerkdoorvoercaplimieten op instance-types |
Foutmodus | Afgenomen latentie of API-timeout | DNS lookup-mislukkingen veroorzaken bezorgvertragingen |
Zichtbaarheid | Limieten zijn meestal gedocumenteerd en weergegeven in statistieken | Doorvoerceiling was ongedocumenteerd en onzichtbaar in CloudWatch |
Mitigatiebenadering | Schalingsinstantiemiddelen of caching toevoegen | Migreren naar instance families met hogere bandbreedte + DNS-architectuur redesign |
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. Webgebaseerde contentlevering maakt intensief gebruik van wat klassiek inkomend "pull"-scenario kan worden beschouwd: een client vraagt gegevens op, of het nu gaat om HTML, videostreams of iets anders, vanuit de cloud. Maar de gebruikssituaties voor berichtendienstproviders zoals SparkPost zijn uitzonderingen op het gebruikelijke AWS-scenario. In ons geval doen we veel uitgaande verkeersconstructies: specifiek e-mail (en andere berichten zoals sms of mobiele pushmeldingen). En dat push-stijl verkeer maakt zwaar gebruik van DNS.
Als je bekend bent met DNS, weet je misschien dat het meestal vrij lichte gegevens zijn. Om een bepaalde HTML-pagina op te vragen, moet je eerst vragen waar deze pagina op het internet te vinden is, maar die aanvraag is een fractie van de omvang van de inhoud die je ophaalt.
E-mail daarentegen maakt uitzonderlijk veel gebruik van DNS om afleverdomeinen 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 bezorgen, moeten we minimaal twee DNS-lookups uitvoeren, en het gebruik van DNS "txt"-records voor anti-phishingtechnologieën zoals SPF en DKIM betekent dat DNS ook nodig is om e-mail te ontvangen. Voeg daarbij ons meer traditionele gebruik van AWS API-diensten voor onze apps, en het is moeilijk om te overdrijven hoe belangrijk DNS is voor onze infrastructuur.
Dit alles betekent dat we een ongebruikelijke situatie tegenkwamen waarin ons groeiende volume uitgaande berichten een DNS-verkeersvolume creëerde dat een cumulatieve netwerkdoorvoercaplimiet bereikte op instance-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 breekt, breekt alles. (Dat is iets wat iedereen die systemen bouwt die op DNS vertrouwen al pijnlijk goed weet.)
De plotselinge DNS-problemen stimuleerden een reactie van onze operationele en betrouwbaarheidstechnische teams om het probleem te identificeren. Ze werkten samen met onze partners bij Amazon om het op te lossen aan de AWS-kant. Samen hebben we de oorzaak geïdentificeerd en een oplossing gevonden. We hebben een cluster van namenservers met een grotere capaciteit ingezet, met een grotere aandacht voor netwerkcapaciteit, die aan onze DNS-behoeften zou kunnen voldoen zonder tegen de limieten voor doorvoer op te lopen. Gelukkig omdat dit allemaal binnen AWS was, konden we de nieuwe instances snel opzetten en zelfs bestaande instances snel vergroten. DNS hervatte zijn normale gedrag, lookup-mislukkingen hielden op, en wij (en de uitgaande berichtbezorging) waren weer op koers.
Om deze specifieke kwestie in de toekomst te mitigeren, maken we ook DNS-architectuurwijzigingen om onze kerncomponenten beter te isoleren tegen de impact van ontmoetingen met soortgelijke, onverwachte limieten. We werken ook samen met het Amazon-team om passende monitoringmodellen te bepalen die ons voldoende waarschuwing geven om een soortgelijke gebeurtenis te voorkomen voordat het onze klanten beïnvloedt.
Onderwerp | Typische AWS-werklast | SparkPost's Uitgaande E-mail Werklast |
|---|---|---|
Verkeerspatroon | Meestal inkomende "pull"-verzoeken (webpagina's, API's, media) | Zwaar uitgaand "push"-verkeer (miljarden e-mails) |
DNS-afhankelijkheid | Licht: 1–2 lookups per inhoudsverzoek | Zeer zwaar: meerdere DNS-lookups per e-mail + SPF/DKIM TXT-controles |
Queryvolume | Voorspelbaar en proportioneel aan gebruikersactiviteit | Explodeert met uitgaande campagnes gericht op miljoenen domeinen |
Knelpunttype | CPU-, geheugen- of opslaglimieten | Cumulatieve netwerkdoorvoercaplimieten op instance-types |
Foutmodus | Afgenomen latentie of API-timeout | DNS lookup-mislukkingen veroorzaken bezorgvertragingen |
Zichtbaarheid | Limieten zijn meestal gedocumenteerd en weergegeven in statistieken | Doorvoerceiling was ongedocumenteerd en onzichtbaar in CloudWatch |
Mitigatiebenadering | Schalingsinstantiemiddelen of caching toevoegen | Migreren naar instance families met hogere bandbreedte + DNS-architectuur redesign |
AWS en de zilveren rand 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 gebruiksgeval met de AWS-infrastructuur—en vervolgens een oplossing ervoor te vinden in zeer korte tijd—heeft veel te maken met hoe we SparkPost hebben gebouwd, en onze geweldige relatie met het Amazon-team.
Het voortreffelijke operationele korps van SparkPost, ons Site Reliability Engineering (SRE) team, en onze belangrijkste technische architecten werken elke dag samen met Amazon. De sterke punten van AWS' infrastructuur hebben ons een echt voordeel gegeven bij het optimaliseren van SparkPost’s architectuur voor de cloud. Het nauw samenwerken met AWS gedurende de afgelopen twee jaar heeft ons ook veel geleerd over het opzetten van AWS-infrastructuur en snel werken, en we profiteren ook van de uitgebreide ondersteuning van het AWS-team.
Als we rond een vergelijkbare beperking in een traditioneel datacentermodel hadden moeten werken, zou iets dergelijks dagen of zelfs weken kunnen duren om volledig op te lossen. Die flexibiliteit en reactie zijn slechts twee van de redenen waarom we ons bedrijf op de cloud en AWS hebben gericht. Samen is het soort cloudexpertise dat onze bedrijven delen moeilijk te vinden. Amazon is een geweldige zakenpartner voor ons geweest, en we zijn erg 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 benadering is fundamenteel voor hoe we onze e-mail-API's voor cloudinfrastructuur ontwerpen, wat zorgt voor schaalbaarheid en betrouwbaarheid voor ontwikkelaars. We verzenden meer e-mails vanaf een echt cloudplatform dan wie dan ook, en soms betekent dat dat we onontgonnen terrein betreden. Het is een fundamentele waarheid van de informatica dat je niet weet welke uitdagingen zich op schaal voordoen totdat je ze tegenkomt. We vonden er een op AWS, maar onze snelle reactie is een uitstekend 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 gebruikmaakt van de onze, ik hoop dat deze uitleg van wat er afgelopen vrijdag gebeurde, en hoe we het hebben opgelost, nuttig is geweest.
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 gebruiksgeval met de AWS-infrastructuur—en vervolgens een oplossing ervoor te vinden in zeer korte tijd—heeft veel te maken met hoe we SparkPost hebben gebouwd, en onze geweldige relatie met het Amazon-team.
Het voortreffelijke operationele korps van SparkPost, ons Site Reliability Engineering (SRE) team, en onze belangrijkste technische architecten werken elke dag samen met Amazon. De sterke punten van AWS' infrastructuur hebben ons een echt voordeel gegeven bij het optimaliseren van SparkPost’s architectuur voor de cloud. Het nauw samenwerken met AWS gedurende de afgelopen twee jaar heeft ons ook veel geleerd over het opzetten van AWS-infrastructuur en snel werken, en we profiteren ook van de uitgebreide ondersteuning van het AWS-team.
Als we rond een vergelijkbare beperking in een traditioneel datacentermodel hadden moeten werken, zou iets dergelijks dagen of zelfs weken kunnen duren om volledig op te lossen. Die flexibiliteit en reactie zijn slechts twee van de redenen waarom we ons bedrijf op de cloud en AWS hebben gericht. Samen is het soort cloudexpertise dat onze bedrijven delen moeilijk te vinden. Amazon is een geweldige zakenpartner voor ons geweest, en we zijn erg 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 benadering is fundamenteel voor hoe we onze e-mail-API's voor cloudinfrastructuur ontwerpen, wat zorgt voor schaalbaarheid en betrouwbaarheid voor ontwikkelaars. We verzenden meer e-mails vanaf een echt cloudplatform dan wie dan ook, en soms betekent dat dat we onontgonnen terrein betreden. Het is een fundamentele waarheid van de informatica dat je niet weet welke uitdagingen zich op schaal voordoen totdat je ze tegenkomt. We vonden er een op AWS, maar onze snelle reactie is een uitstekend 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 gebruikmaakt van de onze, ik hoop dat deze uitleg van wat er afgelopen vrijdag gebeurde, en hoe we het hebben opgelost, nuttig is geweest.
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 gebruiksgeval met de AWS-infrastructuur—en vervolgens een oplossing ervoor te vinden in zeer korte tijd—heeft veel te maken met hoe we SparkPost hebben gebouwd, en onze geweldige relatie met het Amazon-team.
Het voortreffelijke operationele korps van SparkPost, ons Site Reliability Engineering (SRE) team, en onze belangrijkste technische architecten werken elke dag samen met Amazon. De sterke punten van AWS' infrastructuur hebben ons een echt voordeel gegeven bij het optimaliseren van SparkPost’s architectuur voor de cloud. Het nauw samenwerken met AWS gedurende de afgelopen twee jaar heeft ons ook veel geleerd over het opzetten van AWS-infrastructuur en snel werken, en we profiteren ook van de uitgebreide ondersteuning van het AWS-team.
Als we rond een vergelijkbare beperking in een traditioneel datacentermodel hadden moeten werken, zou iets dergelijks dagen of zelfs weken kunnen duren om volledig op te lossen. Die flexibiliteit en reactie zijn slechts twee van de redenen waarom we ons bedrijf op de cloud en AWS hebben gericht. Samen is het soort cloudexpertise dat onze bedrijven delen moeilijk te vinden. Amazon is een geweldige zakenpartner voor ons geweest, en we zijn erg 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 benadering is fundamenteel voor hoe we onze e-mail-API's voor cloudinfrastructuur ontwerpen, wat zorgt voor schaalbaarheid en betrouwbaarheid voor ontwikkelaars. We verzenden meer e-mails vanaf een echt cloudplatform dan wie dan ook, en soms betekent dat dat we onontgonnen terrein betreden. Het is een fundamentele waarheid van de informatica dat je niet weet welke uitdagingen zich op schaal voordoen totdat je ze tegenkomt. We vonden er een op AWS, maar onze snelle reactie is een uitstekend 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 gebruikmaakt van de onze, ik hoop dat deze uitleg van wat er afgelopen vrijdag gebeurde, en hoe we het hebben opgelost, nuttig is geweest.
