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 a specifiche tradizionali (processore, memoria, ecc.) di solito funziona come ci si aspetta, ma a volte quel modello di hardware tradizionale non si applica.
Business in a box.
Scopri le nostre soluzioni.
Parla con il nostro team di vendita
Come abbiamo rintracciato insoliti errori DNS in AWS
Abbiamo costruito SparkPost intorno all'idea che un servizio cloud come il nostro debba essere nativo per il cloud. Questo non è solo ostentazione. È la nostra architettura cloud che supporta la scalabilità, elasticità e affidabilità che sono aspetti fondamentali del servizio SparkPost. Queste qualità sono ragioni principali per cui abbiamo costruito la nostra infrastruttura su Amazon Web Services (AWS)—ed è per questo che possiamo offrire ai nostri clienti garanzie di livello di servizio e burst rate ineguagliabili da chiunque altro nel settore.
Ma non fingiamo di non essere mai messi alla prova da bug inaspettati o limiti della tecnologia disponibile. Ci siamo imbattuti in qualcosa di simile venerdì scorso, e quel incidente ha portato a lentezza intermittente nel nostro servizio e ritardi di consegna per alcuni dei nostri clienti.
Per prima cosa, lasciate che vi 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 di tutto il nostro team). Sappiamo che contate su di noi, ed è frustrante quando non stiamo rendendo al livello che vi aspettate.
Alcune aziende sono tentate di nascondere sotto il tappeto problemi come un degrado del servizio e sperare che nessuno se ne accorga. Potreste aver vissuto questo con i servizi che avete utilizzato in passato. So che è capitato a me. Ma non è così che ci piace fare affari.
Volevo scrivere di questo incidente anche per un altro motivo: abbiamo imparato qualcosa di davvero interessante e prezioso sulla nostra architettura cloud AWS. I team che costruiscono altri servizi cloud potrebbero essere interessati a conoscerlo.
TL;DR
Approfondendo nel DNS
Perché l'uso del nostro DNS è speciale? Beh, 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 distribuzione di contenuti basata sul web fa ampio uso di quelli che potrebbero essere considerati scenari classici 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 "push" del traffico in uscita: specificamente, email (e altri tipi di messaggi come SMS o notifiche push mobili). E quel traffico in stile push si basa fortemente sul DNS.
Se hai familiarità con il DNS, potresti sapere che generalmente si tratta di dati piuttosto leggeri. Per richiedere una determinata pagina HTML, devi prima chiedere dove si trova quella pagina su Internet, ma quella richiesta è una frazione della dimensione del contenuto che recuperi.
L'email, tuttavia, fa un uso eccezionalmente intenso del DNS per cercare i domini di consegna—ad esempio, SparkPost invia molti miliardi di email a oltre un milione di domini unici ogni mese. Per ogni email che consegniamo, dobbiamo effettuare un minimo di due ricerche DNS, e l'uso di record "txt" del DNS per tecnologie 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 il DNS sia importante per la nostra infrastruttura.
Tutto ciò significa che ci siamo imbattuti in una condizione insolita in cui il nostro crescente volume di messaggi in uscita ha creato un volume di traffico DNS che ha colpito un limite aggregato di throughput della rete su tipi di istanze che altrimenti sembravano avere risorse sufficienti per gestire quel carico. E come gli attacchi denial-of-service sull'infrastruttura Dyn DNS dello scorso anno hanno dimostrato, quando il DNS si rompe, tutto si rompe. (Questa è una cosa che chiunque costruisca sistemi che si affidano al DNS sa già molto bene.)
I problemi DNS improvvisi hanno innescato una risposta da parte dei nostri team di operazioni e ingegneria dell'affidabilità per identificare il problema. Si sono uniti ai nostri partner di Amazon per intensificare l'operazioni dal lato AWS. Lavorando insieme, abbiamo identificato la causa e una soluzione. Abbiamo distribuito un cluster di server di nomi di maggiore capacità con maggiore attenzione alla capacità di rete che potesse soddisfare le nostre esigenze DNS senza incorrere nei limiti di throughput. Fortunatamente, poiché tutto ciò era all'interno di AWS, abbiamo potuto avviare rapidamente le nuove istanze e persino ridimensionare le istanze esistenti. Il DNS ha ripreso un comportamento normale, i fallimenti delle ricerche sono cessati e noi (e la consegna dei messaggi in uscita) siamo tornati in pista.
Per mitigare questo problema specifico in futuro, stiamo anche apportando modifiche all'architettura DNS per isolare meglio i nostri componenti principali dall'impatto di incontri con soglie simili, inaspettate. Stiamo anche lavorando con il team di Amazon per determinare modelli di monitoraggio adeguati che ci forniscano un avviso adeguato per prevenire un incidente simile prima che influisca su qualsiasi nostro cliente.
AWS e il lato positivo del Cloud
Non voglio addolcire l'impatto di questo incidente sui nostri clienti. Ma la nostra capacità di identificare il problema sottostante come un'interazione inaspettata del nostro caso d'uso con l'infrastruttura AWS—e quindi trovare rapidamente una soluzione—ha molto a che fare con come abbiamo costruito SparkPost e il nostro ottimo rapporto con il team di Amazon.
Il corpo operazioni superbo di SparkPost, il nostro team di Site Reliability Engineering (SRE) e i nostri principali architetti tecnici lavorano con Amazon ogni giorno. I punti di forza dell'infrastruttura di AWS ci hanno dato un vero vantaggio ottimizzando l'architettura di SparkPost per il cloud. Lavorare così a stretto contatto con AWS negli ultimi due anni ci ha anche insegnato molto sul far girare l'infrastruttura AWS e sull'operare rapidamente, e abbiamo anche il vantaggio di un supporto approfondito dal team di AWS.
Se avessimo dovuto aggirare una limitazione simile in un modello di data center tradizionale, qualcosa di simile potrebbe richiedere giorni o persino settimane per essere completamente risolti. 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 competenza sul cloud che condividono le nostre aziende è difficile da trovare. Amazon è stato un ottimo partner commerciale per noi, e siamo davvero orgogliosi di ciò che abbiamo fatto con lo stack di AWS.
SparkPost è il primo servizio di consegna email che è stato costruito per il cloud fin dall'inizio. Inviamo più email da una vera piattaforma cloud di chiunque altro, e a volte significa entrare in territori inesplorati. È una verità fondamentale dell'informatica che non si sa quali sfide si presentano su larga scala finché non le incontri. Ne abbiamo trovata una su AWS, ma la nostra rapida risposta è un grande esempio della flessibilità che il cloud rende possibile. È anche il nostro impegno verso i nostri clienti.
Sia che stiate costruendo la vostra infrastruttura su AWS, o un cliente SparkPost che sfrutta la nostra, spero che questa spiegazione di ciò che è successo venerdì scorso, e di come lo abbiamo risolto, sia stata utile.
