Il giorno in cui il nostro DNS ha raggiunto un limite non documentato in AWS
Uccello
7 feb 2017
Ingegneria
1 min read
Punti Chiave
SparkPost ha riscontrato un limite di throughput di rete non documentato su un tipo specifico di istanza AWS EC2 che alimentava il suo cluster DNS principale.
La dimensione tradizionale delle istanze (CPU, RAM, disco) non ha rivelato questo collo di bottiglia perché il problema era legato al traffico DNS di rete aggregato, non alla scarsità di risorse.
L'uso del DNS per le email in uscita ad alto volume è insolitamente elevato: SparkPost genera milioni di richieste DNS per instradamento di dominio, autenticazione (SPF/DKIM) e interazioni con l'API di AWS.
Il fallimento del DNS non è derivato da risposte DNS malformate — piuttosto, i limiti di capacità di rete a livello di istanza sono stati superati silenziosamente, causando ampie mancate risposte.
Poiché AWS non documenta esplicitamente questi limiti di rete morbidi, diagnosticare il problema ha richiesto una profonda collaborazione tra il team SRE di SparkPost e gli ingegneri AWS.
Il team ha risolto il problema migrazione dei servizi DNS a tipi di istanza più grandi con una maggiore larghezza di banda di rete e riprogettando parti dell'architettura DNS per una migliore isolazione e failover.
Non sono stati persi dati o messaggi dei clienti, ma l'evento ha evidenziato come le architetture cloud-native possano raggiungere limiti imprevisti su larga scala — e quanto rapidamente possano essere risolti con l'elasticità di AWS.
Punti salienti del Q&A
Cosa è successo?
Il cluster DNS di SparkPost ha raggiunto un'improvvisa soglia di throughput di rete AWS, causando il fallimento intermittente delle ricerche DNS — il che ha ritardato la consegna delle email.
Perché il DNS si è rotto del tutto?
Il DNS è estremamente dipendente per l'email in uscita. Ogni invio richiede molteplici ricerche (MX, TXT, SPF, DKIM), quindi un alto volume di invio = traffico DNS massivo.
Questo modello di traffico ha superato un limite non documentato sul tipo di istanza EC2 che ospita i nameserver.
Qual è la differenza tra DNS per email e applicazioni web?
App web principalmente richiedono contenuti (i client richiedono dati).
Servizi di consegna email inviare traffico, attivando molti più lookup DNS - spesso miliardi al mese.
Email dipende da DNS per il routing, la convalida della sicurezza e il failover.
Come si è manifestato il fallimento?
Le richieste DNS hanno iniziato a cadere o a scadere
Le code di consegna si sono accumulate
La latenza è aumentata in alcune parti del sistema
Nulla è stato perso, solo ritardato.
Perché era difficile diagnosticare questo?
Il limite non era documentato
Il monitoraggio di AWS non mostrava esplicitamente il collo di bottiglia
Tutti i metriche tradizionali (CPU, RAM, disco) sembravano normali
Il problema è emerso solo sotto un modello di traffico DNS specifico e ad alto volume.
Come ha risolto SparkPost il problema?
Aggiornato a tipi di istanze EC2 con soffitti di throughput di rete più elevati
Ristrutturato i cluster DNS per essere più resilienti agli picchi di traffico aggregati
Collaborato con AWS per identificare migliori schemi di segnale/alerting per catturare questo prima
Sono stati persi dati dei clienti o email?
No — solo la consegna è rallentata. Una volta stabilito il DNS, tutta la posta ha ripreso la consegna normale.
Qual è la lezione più ampia?
Anche nel cloud, puoi incontrare vincoli di scalabilità non visibili — ma i progetti nativi del cloud ti offrono la flessibilità di recuperare rapidamente.
L'elasticità, la partnership con AWS e solide pratiche SRE rendono possibile un rapido recupero.
Come abbiamo tracciato le anomalie nei fallimenti DNS in AWS
Abbiamo costruito SparkPost attorno all'idea che un servizio cloud come il nostro debba essere nativo del cloud stesso. Non si tratta solo di una posa. È la nostra architettura cloud che sottende la scalabilità, l'elasticità e l'affidabilità che sono aspetti fondamentali del servizio SparkPost. Queste qualità sono motivazioni principali per cui abbiamo costruito la nostra infrastruttura su Amazon Web Services (AWS)—ed è per questo che possiamo offrire ai nostri clienti garanzie sul livello di servizio e sui tassi di picco senza pari da chiunque altro nel settore.
Ma non facciamo finta che non siamo mai messi alla prova da bug inaspettati o dai limiti della tecnologia disponibile. Ci siamo imbattuti in qualcosa di simile venerdì scorso, e quell'incidente ha portato a una lentezza intermittente nel nostro servizio e ritardi di consegna per alcuni dei nostri clienti.
Per prima cosa, lasciate che dica che il problema è stato risolto lo stesso giorno. Inoltre, nessuna email o dato correlato è andato perso. Tuttavia, se la consegna delle vostre email è stata rallentata a causa di questo problema, vi prego di accettare le mie scuse (in effetti, le scuse da parte dell'intero nostro team). Questo incidente ha rafforzato l'importanza di avere strategie di backup complete - che stiate utilizzando backup del database PostgreSQL o altri metodi di protezione dei dati per garantire la continuità aziendale durante le sfide infrastrutturali. Sappiamo che contate su di noi, e è frustrante quando non stiamo performando al livello che ci si aspetta.
Alcune aziende sono tentate di nascondere problemi come una degradazione del servizio sotto il tappeto e sperare che nessuno se ne accorga. Potreste averlo sperimentato con servizi che avete usato in passato. So di averlo fatto. Ma non è così che ci piace fare affari.
Volevo scrivere di questo incidente anche per un altro motivo: abbiamo appreso qualcosa di davvero interessante e prezioso sulla nostra architettura cloud AWS. I team che costruiscono altri servizi cloud potrebbero essere interessati a saperne di più.
Abbiamo costruito SparkPost attorno all'idea che un servizio cloud come il nostro debba essere nativo del cloud stesso. Non si tratta solo di una posa. È la nostra architettura cloud che sottende la scalabilità, l'elasticità e l'affidabilità che sono aspetti fondamentali del servizio SparkPost. Queste qualità sono motivazioni principali per cui abbiamo costruito la nostra infrastruttura su Amazon Web Services (AWS)—ed è per questo che possiamo offrire ai nostri clienti garanzie sul livello di servizio e sui tassi di picco senza pari da chiunque altro nel settore.
Ma non facciamo finta che non siamo mai messi alla prova da bug inaspettati o dai limiti della tecnologia disponibile. Ci siamo imbattuti in qualcosa di simile venerdì scorso, e quell'incidente ha portato a una lentezza intermittente nel nostro servizio e ritardi di consegna per alcuni dei nostri clienti.
Per prima cosa, lasciate che dica che il problema è stato risolto lo stesso giorno. Inoltre, nessuna email o dato correlato è andato perso. Tuttavia, se la consegna delle vostre email è stata rallentata a causa di questo problema, vi prego di accettare le mie scuse (in effetti, le scuse da parte dell'intero nostro team). Questo incidente ha rafforzato l'importanza di avere strategie di backup complete - che stiate utilizzando backup del database PostgreSQL o altri metodi di protezione dei dati per garantire la continuità aziendale durante le sfide infrastrutturali. Sappiamo che contate su di noi, e è frustrante quando non stiamo performando al livello che ci si aspetta.
Alcune aziende sono tentate di nascondere problemi come una degradazione del servizio sotto il tappeto e sperare che nessuno se ne accorga. Potreste averlo sperimentato con servizi che avete usato in passato. So di averlo fatto. Ma non è così che ci piace fare affari.
Volevo scrivere di questo incidente anche per un altro motivo: abbiamo appreso qualcosa di davvero interessante e prezioso sulla nostra architettura cloud AWS. I team che costruiscono altri servizi cloud potrebbero essere interessati a saperne di più.
Abbiamo costruito SparkPost attorno all'idea che un servizio cloud come il nostro debba essere nativo del cloud stesso. Non si tratta solo di una posa. È la nostra architettura cloud che sottende la scalabilità, l'elasticità e l'affidabilità che sono aspetti fondamentali del servizio SparkPost. Queste qualità sono motivazioni principali per cui abbiamo costruito la nostra infrastruttura su Amazon Web Services (AWS)—ed è per questo che possiamo offrire ai nostri clienti garanzie sul livello di servizio e sui tassi di picco senza pari da chiunque altro nel settore.
Ma non facciamo finta che non siamo mai messi alla prova da bug inaspettati o dai limiti della tecnologia disponibile. Ci siamo imbattuti in qualcosa di simile venerdì scorso, e quell'incidente ha portato a una lentezza intermittente nel nostro servizio e ritardi di consegna per alcuni dei nostri clienti.
Per prima cosa, lasciate che dica che il problema è stato risolto lo stesso giorno. Inoltre, nessuna email o dato correlato è andato perso. Tuttavia, se la consegna delle vostre email è stata rallentata a causa di questo problema, vi prego di accettare le mie scuse (in effetti, le scuse da parte dell'intero nostro team). Questo incidente ha rafforzato l'importanza di avere strategie di backup complete - che stiate utilizzando backup del database PostgreSQL o altri metodi di protezione dei dati per garantire la continuità aziendale durante le sfide infrastrutturali. Sappiamo che contate su di noi, e è frustrante quando non stiamo performando al livello che ci si aspetta.
Alcune aziende sono tentate di nascondere problemi come una degradazione del servizio sotto il tappeto e sperare che nessuno se ne accorga. Potreste averlo sperimentato con servizi che avete usato in passato. So di averlo fatto. Ma non è così che ci piace fare affari.
Volevo scrivere di questo incidente anche per un altro motivo: abbiamo appreso qualcosa di davvero interessante e prezioso sulla nostra architettura cloud AWS. I team che costruiscono altri servizi cloud potrebbero essere interessati a saperne di più.
TL;DR
Ci siamo imbattuti in limiti pratici non documentati delle istanze EC2 che stavamo utilizzando per il nostro cluster DNS principale. Dimensionare le istanze cloud in base alle specifiche tradizionali (processore, memoria, ecc.) di solito funziona proprio come ci si aspetterebbe, ma a volte quel modello hardware tradizionale non si applica. Questo è particolarmente vero in casi d'uso atipici in cui possono entrare in gioco limiti aggregati—e ci sono momenti in cui ci si imbatte in quegli scenari senza preavviso.
Abbiamo toccato un tale limite venerdì quando il nostro volume di query DNS ha creato un modello di utilizzo della rete per il quale il nostro tipo di istanza non era preparato. Tuttavia, poiché quel limite non era ovvio dai documenti o dalle metriche standard disponibili, non sapevamo di averlo raggiunto. Ciò che abbiamo osservato è stata un'alta percentuale di errori DNS, che a sua volta ha portato a ritardi intermittenti in diversi punti della nostra architettura.
Ci siamo imbattuti in limiti pratici non documentati delle istanze EC2 che stavamo utilizzando per il nostro cluster DNS principale. Dimensionare le istanze cloud in base alle specifiche tradizionali (processore, memoria, ecc.) di solito funziona proprio come ci si aspetterebbe, ma a volte quel modello hardware tradizionale non si applica. Questo è particolarmente vero in casi d'uso atipici in cui possono entrare in gioco limiti aggregati—e ci sono momenti in cui ci si imbatte in quegli scenari senza preavviso.
Abbiamo toccato un tale limite venerdì quando il nostro volume di query DNS ha creato un modello di utilizzo della rete per il quale il nostro tipo di istanza non era preparato. Tuttavia, poiché quel limite non era ovvio dai documenti o dalle metriche standard disponibili, non sapevamo di averlo raggiunto. Ciò che abbiamo osservato è stata un'alta percentuale di errori DNS, che a sua volta ha portato a ritardi intermittenti in diversi punti della nostra architettura.
Ci siamo imbattuti in limiti pratici non documentati delle istanze EC2 che stavamo utilizzando per il nostro cluster DNS principale. Dimensionare le istanze cloud in base alle specifiche tradizionali (processore, memoria, ecc.) di solito funziona proprio come ci si aspetterebbe, ma a volte quel modello hardware tradizionale non si applica. Questo è particolarmente vero in casi d'uso atipici in cui possono entrare in gioco limiti aggregati—e ci sono momenti in cui ci si imbatte in quegli scenari senza preavviso.
Abbiamo toccato un tale limite venerdì quando il nostro volume di query DNS ha creato un modello di utilizzo della rete per il quale il nostro tipo di istanza non era preparato. Tuttavia, poiché quel limite non era ovvio dai documenti o dalle metriche standard disponibili, non sapevamo di averlo raggiunto. Ciò che abbiamo osservato è stata un'alta percentuale di errori DNS, che a sua volta ha portato a ritardi intermittenti in diversi punti della nostra architettura.
Scavando più a fondo nel DNS
Perché l'uso del nostro DNS è speciale? Bene, ha molto a che fare con il modo in cui funziona l'email, rispetto al modello di contenuto per cui AWS è stato originariamente progettato. La consegna di contenuti basata sul web fa ampio uso di quelli che potrebbero essere considerati classici scenari di “pull” in entrata: un client richiede dati, siano essi HTML, flussi video o qualsiasi altra cosa, dal cloud. Ma i casi d'uso per i fornitori di servizi di messaggistica come SparkPost sono eccezioni allo scenario AWS usuale. Nel nostro caso, facciamo molto pushing di traffico in uscita: in particolare, email (e altri tipi di messaggi come SMS o notifiche push mobili). E quel traffico in stile push si basa pesantemente su DNS.
Se sei familiare con il DNS, potresti sapere che è generalmente un dato piuttosto leggero. Per richiedere una determinata pagina HTML, devi prima chiedere dove può essere trovata quella pagina su Internet, ma quella richiesta è una frazione delle dimensioni del contenuto che recuperi.
Tuttavia, l'email fa un uso eccezionalmente intenso del DNS per cercare i domini di consegna: ad esempio, SparkPost invia miliardi di email a oltre 1 milione di domini unici ogni mese. Per ogni email che consegniamo, dobbiamo fare un minimo di due lookup DNS, e l'uso dei record DNS “txt” per tecnologie di anti-phishing come SPF e DKIM significa che il DNS è anche necessario per ricevere la posta. Aggiungi a ciò il nostro utilizzo più tradizionale dei servizi API AWS per le nostre app, ed è difficile esagerare quanto sia importante il DNS per la nostra infrastruttura.
Tutto ciò significa che ci siamo imbattuti in una condizione insolita in cui il nostro volume crescente di messaggi in uscita ha creato un volume di traffico DNS che ha colpito un limite aggregato di capacità di rete su tipi di istanza che altrimenti sembravano avere risorse sufficienti per gestire quel carico. E come gli attacchi di negazione del servizio sull'infrastruttura DNS di Dyn hanno dimostrato lo scorso anno, quando il DNS si rompe, tutto si rompe. (È qualcosa che chiunque costruisca sistemi che si basano sul DNS già sa con grande dolore.)
Le problematiche DNS improvvise hanno innescato una risposta da parte dei nostri team di operazioni e ingegneria dell'affidabilità per identificare il problema. Hanno collaborato con i nostri partner di Amazon per accelerare il lato delle operazioni AWS. Lavorando insieme, abbiamo identificato la causa e una soluzione. Abbiamo distribuito un cluster di nameserver di maggiore capacità con un focus maggiore sulla capacità di rete che potesse soddisfare le nostre esigenze DNS senza colpire le linee rosse per la capacità. Fortunatamente, poiché tutto ciò era all'interno di AWS, abbiamo potuto creare nuove istanze e anche ridimensionare istanze esistenti molto rapidamente. Il DNS ha ripreso un comportamento normale, i fallimenti nei lookup sono cessati e noi (e la consegna dei messaggi in uscita) eravamo di nuovo sulla buona strada.
Per mitigare questo specifico problema in futuro, stiamo anche apportando modifiche all'architettura DNS per meglio isolare i nostri componenti fondamentali dall'impatto di incontri con soglie simili e inaspettate. Stiamo anche collaborando con il team di Amazon per determinare modelli di monitoraggio appropriati che ci daranno un adeguato preavviso per evitare un incidente simile prima che influisca su uno qualsiasi dei nostri clienti.
Argomento | Carico di lavoro tipico di AWS | Carico di lavoro delle email in uscita di SparkPost |
|---|---|---|
Schema di traffico | Per lo più richieste in entrata “pull” (pagine web, API, media) | Traffico in uscita “push” pesante (miliardi di email) |
Dipendenza da DNS | Leggera: 1–2 lookup per richiesta di contenuto | Molto pesante: molteplici lookup DNS per email + controlli TXT SPF/DKIM |
Volume delle query | Prevedibile e proporzionale all'attività dell'utente | Esplode con campagne in uscita che mirano a milioni di domini |
Tipo di collo di bottiglia | Limiti di CPU, memoria o archiviazione | Limiti aggregati di capacità di rete sui tipi di istanza |
Modalità di guasto | Latenza degradante o timeout API | Fallimenti nei lookup DNS che causano ritardi nella consegna |
Visibilità | I limiti sono tipicamente documentati e mostrati nelle metriche | Il limite di capacità non era documentato e invisibile in CloudWatch |
Approccio di mitigazione | Scala le risorse delle istanze o aggiungi caching | Migrazione a famiglie di istanze a banda più elevata + redesign dell'architettura DNS |
Perché l'uso del nostro DNS è speciale? Bene, ha molto a che fare con il modo in cui funziona l'email, rispetto al modello di contenuto per cui AWS è stato originariamente progettato. La consegna di contenuti basata sul web fa ampio uso di quelli che potrebbero essere considerati classici scenari di “pull” in entrata: un client richiede dati, siano essi HTML, flussi video o qualsiasi altra cosa, dal cloud. Ma i casi d'uso per i fornitori di servizi di messaggistica come SparkPost sono eccezioni allo scenario AWS usuale. Nel nostro caso, facciamo molto pushing di traffico in uscita: in particolare, email (e altri tipi di messaggi come SMS o notifiche push mobili). E quel traffico in stile push si basa pesantemente su DNS.
Se sei familiare con il DNS, potresti sapere che è generalmente un dato piuttosto leggero. Per richiedere una determinata pagina HTML, devi prima chiedere dove può essere trovata quella pagina su Internet, ma quella richiesta è una frazione delle dimensioni del contenuto che recuperi.
Tuttavia, l'email fa un uso eccezionalmente intenso del DNS per cercare i domini di consegna: ad esempio, SparkPost invia miliardi di email a oltre 1 milione di domini unici ogni mese. Per ogni email che consegniamo, dobbiamo fare un minimo di due lookup DNS, e l'uso dei record DNS “txt” per tecnologie di anti-phishing come SPF e DKIM significa che il DNS è anche necessario per ricevere la posta. Aggiungi a ciò il nostro utilizzo più tradizionale dei servizi API AWS per le nostre app, ed è difficile esagerare quanto sia importante il DNS per la nostra infrastruttura.
Tutto ciò significa che ci siamo imbattuti in una condizione insolita in cui il nostro volume crescente di messaggi in uscita ha creato un volume di traffico DNS che ha colpito un limite aggregato di capacità di rete su tipi di istanza che altrimenti sembravano avere risorse sufficienti per gestire quel carico. E come gli attacchi di negazione del servizio sull'infrastruttura DNS di Dyn hanno dimostrato lo scorso anno, quando il DNS si rompe, tutto si rompe. (È qualcosa che chiunque costruisca sistemi che si basano sul DNS già sa con grande dolore.)
Le problematiche DNS improvvise hanno innescato una risposta da parte dei nostri team di operazioni e ingegneria dell'affidabilità per identificare il problema. Hanno collaborato con i nostri partner di Amazon per accelerare il lato delle operazioni AWS. Lavorando insieme, abbiamo identificato la causa e una soluzione. Abbiamo distribuito un cluster di nameserver di maggiore capacità con un focus maggiore sulla capacità di rete che potesse soddisfare le nostre esigenze DNS senza colpire le linee rosse per la capacità. Fortunatamente, poiché tutto ciò era all'interno di AWS, abbiamo potuto creare nuove istanze e anche ridimensionare istanze esistenti molto rapidamente. Il DNS ha ripreso un comportamento normale, i fallimenti nei lookup sono cessati e noi (e la consegna dei messaggi in uscita) eravamo di nuovo sulla buona strada.
Per mitigare questo specifico problema in futuro, stiamo anche apportando modifiche all'architettura DNS per meglio isolare i nostri componenti fondamentali dall'impatto di incontri con soglie simili e inaspettate. Stiamo anche collaborando con il team di Amazon per determinare modelli di monitoraggio appropriati che ci daranno un adeguato preavviso per evitare un incidente simile prima che influisca su uno qualsiasi dei nostri clienti.
Argomento | Carico di lavoro tipico di AWS | Carico di lavoro delle email in uscita di SparkPost |
|---|---|---|
Schema di traffico | Per lo più richieste in entrata “pull” (pagine web, API, media) | Traffico in uscita “push” pesante (miliardi di email) |
Dipendenza da DNS | Leggera: 1–2 lookup per richiesta di contenuto | Molto pesante: molteplici lookup DNS per email + controlli TXT SPF/DKIM |
Volume delle query | Prevedibile e proporzionale all'attività dell'utente | Esplode con campagne in uscita che mirano a milioni di domini |
Tipo di collo di bottiglia | Limiti di CPU, memoria o archiviazione | Limiti aggregati di capacità di rete sui tipi di istanza |
Modalità di guasto | Latenza degradante o timeout API | Fallimenti nei lookup DNS che causano ritardi nella consegna |
Visibilità | I limiti sono tipicamente documentati e mostrati nelle metriche | Il limite di capacità non era documentato e invisibile in CloudWatch |
Approccio di mitigazione | Scala le risorse delle istanze o aggiungi caching | Migrazione a famiglie di istanze a banda più elevata + redesign dell'architettura DNS |
Perché l'uso del nostro DNS è speciale? Bene, ha molto a che fare con il modo in cui funziona l'email, rispetto al modello di contenuto per cui AWS è stato originariamente progettato. La consegna di contenuti basata sul web fa ampio uso di quelli che potrebbero essere considerati classici scenari di “pull” in entrata: un client richiede dati, siano essi HTML, flussi video o qualsiasi altra cosa, dal cloud. Ma i casi d'uso per i fornitori di servizi di messaggistica come SparkPost sono eccezioni allo scenario AWS usuale. Nel nostro caso, facciamo molto pushing di traffico in uscita: in particolare, email (e altri tipi di messaggi come SMS o notifiche push mobili). E quel traffico in stile push si basa pesantemente su DNS.
Se sei familiare con il DNS, potresti sapere che è generalmente un dato piuttosto leggero. Per richiedere una determinata pagina HTML, devi prima chiedere dove può essere trovata quella pagina su Internet, ma quella richiesta è una frazione delle dimensioni del contenuto che recuperi.
Tuttavia, l'email fa un uso eccezionalmente intenso del DNS per cercare i domini di consegna: ad esempio, SparkPost invia miliardi di email a oltre 1 milione di domini unici ogni mese. Per ogni email che consegniamo, dobbiamo fare un minimo di due lookup DNS, e l'uso dei record DNS “txt” per tecnologie di anti-phishing come SPF e DKIM significa che il DNS è anche necessario per ricevere la posta. Aggiungi a ciò il nostro utilizzo più tradizionale dei servizi API AWS per le nostre app, ed è difficile esagerare quanto sia importante il DNS per la nostra infrastruttura.
Tutto ciò significa che ci siamo imbattuti in una condizione insolita in cui il nostro volume crescente di messaggi in uscita ha creato un volume di traffico DNS che ha colpito un limite aggregato di capacità di rete su tipi di istanza che altrimenti sembravano avere risorse sufficienti per gestire quel carico. E come gli attacchi di negazione del servizio sull'infrastruttura DNS di Dyn hanno dimostrato lo scorso anno, quando il DNS si rompe, tutto si rompe. (È qualcosa che chiunque costruisca sistemi che si basano sul DNS già sa con grande dolore.)
Le problematiche DNS improvvise hanno innescato una risposta da parte dei nostri team di operazioni e ingegneria dell'affidabilità per identificare il problema. Hanno collaborato con i nostri partner di Amazon per accelerare il lato delle operazioni AWS. Lavorando insieme, abbiamo identificato la causa e una soluzione. Abbiamo distribuito un cluster di nameserver di maggiore capacità con un focus maggiore sulla capacità di rete che potesse soddisfare le nostre esigenze DNS senza colpire le linee rosse per la capacità. Fortunatamente, poiché tutto ciò era all'interno di AWS, abbiamo potuto creare nuove istanze e anche ridimensionare istanze esistenti molto rapidamente. Il DNS ha ripreso un comportamento normale, i fallimenti nei lookup sono cessati e noi (e la consegna dei messaggi in uscita) eravamo di nuovo sulla buona strada.
Per mitigare questo specifico problema in futuro, stiamo anche apportando modifiche all'architettura DNS per meglio isolare i nostri componenti fondamentali dall'impatto di incontri con soglie simili e inaspettate. Stiamo anche collaborando con il team di Amazon per determinare modelli di monitoraggio appropriati che ci daranno un adeguato preavviso per evitare un incidente simile prima che influisca su uno qualsiasi dei nostri clienti.
Argomento | Carico di lavoro tipico di AWS | Carico di lavoro delle email in uscita di SparkPost |
|---|---|---|
Schema di traffico | Per lo più richieste in entrata “pull” (pagine web, API, media) | Traffico in uscita “push” pesante (miliardi di email) |
Dipendenza da DNS | Leggera: 1–2 lookup per richiesta di contenuto | Molto pesante: molteplici lookup DNS per email + controlli TXT SPF/DKIM |
Volume delle query | Prevedibile e proporzionale all'attività dell'utente | Esplode con campagne in uscita che mirano a milioni di domini |
Tipo di collo di bottiglia | Limiti di CPU, memoria o archiviazione | Limiti aggregati di capacità di rete sui tipi di istanza |
Modalità di guasto | Latenza degradante o timeout API | Fallimenti nei lookup DNS che causano ritardi nella consegna |
Visibilità | I limiti sono tipicamente documentati e mostrati nelle metriche | Il limite di capacità non era documentato e invisibile in CloudWatch |
Approccio di mitigazione | Scala le risorse delle istanze o aggiungi caching | Migrazione a famiglie di istanze a banda più elevata + redesign dell'architettura DNS |
Il lato positivo di AWS e del Cloud
Non voglio minimizzare l'impatto di questo incidente sui nostri clienti. Ma la nostra capacità di identificare il problema sottostante come un'interazione inaspettata del nostro uso con l'infrastruttura AWS — e poi trovare una soluzione in tempi molto brevi — ha molto a che fare con come abbiamo costruito SparkPost e la nostra ottima relazione con il team di Amazon.
Il corpo operativo superbo di SparkPost, il nostro team di Ingegneria dell'Affidabilità del Sito (SRE) e i nostri architetti tecnici principali lavorano con Amazon ogni giorno. I punti di forza dell'infrastruttura di AWS ci hanno dato un vero vantaggio nell'ottimizzazione dell'architettura di SparkPost per il cloud. Lavorare così a stretto contatto con AWS negli ultimi due anni ci ha anche insegnato molto su come avviare l'infrastruttura AWS e agire rapidamente, e abbiamo anche il beneficio di un supporto profondo dal team AWS.
Se dovessimo lavorare attorno a una limitazione simile in un modello di data center tradizionale, qualcosa del genere potrebbe richiedere giorni o addirittura settimane per essere completamente risolto. Quell'agilità e reattività sono solo due dei motivi per cui abbiamo puntato il nostro business sul cloud e su AWS. Insieme, il tipo di esperienza nel cloud che le nostre aziende condividono è difficile da trovare. Amazon è stato un ottimo partner commerciale per noi, e siamo davvero orgogliosi di ciò che abbiamo fatto con lo stack AWS.
SparkPost è il primo servizio di consegna email che è stato costruito per il cloud fin dall'inizio. Questo approccio nativo al cloud è fondamentale per come progettiamo le nostre API email per l'infrastruttura cloud, garantendo scalabilità e affidabilità per gli sviluppatori. Inviamo più email da una vera piattaforma cloud di chiunque altro, e a volte questo significa entrare in territori inesplorati. È una verità fondamentale dell'informatica che non si conoscono le sfide che si verificano su larga scala fino a quando non le si affronta. Ne abbiamo trovata una su AWS, ma la nostra risposta rapida è un ottimo esempio della flessibilità che il cloud rende possibile. È anche il nostro impegno verso i nostri clienti.
Che tu stia costruendo la tua infrastruttura su AWS, o sia un cliente di SparkPost che sfrutta la nostra, spero che questa spiegazione di ciò che è successo venerdì scorso e di come lo abbiamo risolto sia stata utile.
Non voglio minimizzare l'impatto di questo incidente sui nostri clienti. Ma la nostra capacità di identificare il problema sottostante come un'interazione inaspettata del nostro uso con l'infrastruttura AWS — e poi trovare una soluzione in tempi molto brevi — ha molto a che fare con come abbiamo costruito SparkPost e la nostra ottima relazione con il team di Amazon.
Il corpo operativo superbo di SparkPost, il nostro team di Ingegneria dell'Affidabilità del Sito (SRE) e i nostri architetti tecnici principali lavorano con Amazon ogni giorno. I punti di forza dell'infrastruttura di AWS ci hanno dato un vero vantaggio nell'ottimizzazione dell'architettura di SparkPost per il cloud. Lavorare così a stretto contatto con AWS negli ultimi due anni ci ha anche insegnato molto su come avviare l'infrastruttura AWS e agire rapidamente, e abbiamo anche il beneficio di un supporto profondo dal team AWS.
Se dovessimo lavorare attorno a una limitazione simile in un modello di data center tradizionale, qualcosa del genere potrebbe richiedere giorni o addirittura settimane per essere completamente risolto. Quell'agilità e reattività sono solo due dei motivi per cui abbiamo puntato il nostro business sul cloud e su AWS. Insieme, il tipo di esperienza nel cloud che le nostre aziende condividono è difficile da trovare. Amazon è stato un ottimo partner commerciale per noi, e siamo davvero orgogliosi di ciò che abbiamo fatto con lo stack AWS.
SparkPost è il primo servizio di consegna email che è stato costruito per il cloud fin dall'inizio. Questo approccio nativo al cloud è fondamentale per come progettiamo le nostre API email per l'infrastruttura cloud, garantendo scalabilità e affidabilità per gli sviluppatori. Inviamo più email da una vera piattaforma cloud di chiunque altro, e a volte questo significa entrare in territori inesplorati. È una verità fondamentale dell'informatica che non si conoscono le sfide che si verificano su larga scala fino a quando non le si affronta. Ne abbiamo trovata una su AWS, ma la nostra risposta rapida è un ottimo esempio della flessibilità che il cloud rende possibile. È anche il nostro impegno verso i nostri clienti.
Che tu stia costruendo la tua infrastruttura su AWS, o sia un cliente di SparkPost che sfrutta la nostra, spero che questa spiegazione di ciò che è successo venerdì scorso e di come lo abbiamo risolto sia stata utile.
Non voglio minimizzare l'impatto di questo incidente sui nostri clienti. Ma la nostra capacità di identificare il problema sottostante come un'interazione inaspettata del nostro uso con l'infrastruttura AWS — e poi trovare una soluzione in tempi molto brevi — ha molto a che fare con come abbiamo costruito SparkPost e la nostra ottima relazione con il team di Amazon.
Il corpo operativo superbo di SparkPost, il nostro team di Ingegneria dell'Affidabilità del Sito (SRE) e i nostri architetti tecnici principali lavorano con Amazon ogni giorno. I punti di forza dell'infrastruttura di AWS ci hanno dato un vero vantaggio nell'ottimizzazione dell'architettura di SparkPost per il cloud. Lavorare così a stretto contatto con AWS negli ultimi due anni ci ha anche insegnato molto su come avviare l'infrastruttura AWS e agire rapidamente, e abbiamo anche il beneficio di un supporto profondo dal team AWS.
Se dovessimo lavorare attorno a una limitazione simile in un modello di data center tradizionale, qualcosa del genere potrebbe richiedere giorni o addirittura settimane per essere completamente risolto. Quell'agilità e reattività sono solo due dei motivi per cui abbiamo puntato il nostro business sul cloud e su AWS. Insieme, il tipo di esperienza nel cloud che le nostre aziende condividono è difficile da trovare. Amazon è stato un ottimo partner commerciale per noi, e siamo davvero orgogliosi di ciò che abbiamo fatto con lo stack AWS.
SparkPost è il primo servizio di consegna email che è stato costruito per il cloud fin dall'inizio. Questo approccio nativo al cloud è fondamentale per come progettiamo le nostre API email per l'infrastruttura cloud, garantendo scalabilità e affidabilità per gli sviluppatori. Inviamo più email da una vera piattaforma cloud di chiunque altro, e a volte questo significa entrare in territori inesplorati. È una verità fondamentale dell'informatica che non si conoscono le sfide che si verificano su larga scala fino a quando non le si affronta. Ne abbiamo trovata una su AWS, ma la nostra risposta rapida è un ottimo esempio della flessibilità che il cloud rende possibile. È anche il nostro impegno verso i nostri clienti.
Che tu stia costruendo la tua infrastruttura su AWS, o sia un cliente di SparkPost che sfrutta la nostra, spero che questa spiegazione di ciò che è successo venerdì scorso e di come lo abbiamo risolto sia stata utile.
