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.
Come abbiamo rintracciato insoliti errori 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 atteggiamento. È la nostra architettura cloud che supporta la scalabilità, l'elasticità e l'affidabilità che sono aspetti fondamentali del servizio SparkPost. Queste qualità sono le principali ragioni 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 velocità di burst rate che non hanno pari nel settore.
Ma non fingiamo di non essere mai sfidati da bug imprevisti o limiti della tecnologia disponibile. Abbiamo incontrato qualcosa di simile venerdì scorso, e quell'incidente ha portato a lentezza intermittente nel nostro servizio e ritardi nella consegna per alcuni dei nostri clienti.
Prima di tutto, lasciatemi dire che il problema è stato risolto lo stesso giorno. Inoltre, nessun 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 realtà, le scuse da parte di tutto il nostro team). Questo incidente ha sottolineato l'importanza di avere strategie di backup complete in atto - sia che stiate utilizzando backup di database PostgreSQL o altri metodi di protezione dei dati per garantire la continuità aziendale durante le sfide infrastrutturali. Sappiamo che contate su di noi, ed è frustrante quando non ci esibiamo al livello che vi aspettate.
Alcune aziende sono tentate di nascondere sotto il tappeto problemi come il degrado del servizio e sperare che nessuno se ne accorga. Potreste aver sperimentato questo con servizi che avete utilizzato in passato. So di averlo fatto. Ma non è così che ci piace fare affari.
Ho voluto scrivere su questo incidente anche per un altro motivo: abbiamo imparato qualcosa di veramente interessante e prezioso sulla nostra architettura cloud AWS. I team che costruiscono altri servizi cloud potrebbero essere interessati a saperne di più.
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 di AWS, e poi trovare una soluzione in brevissimo tempo, ha molto a che fare con il modo in cui abbiamo costruito SparkPost e il nostro ottimo rapporto con il team di Amazon.
Il superbo corpo operazioni 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 su come avviare rapidamente l'infrastruttura AWS e farla funzionare velocemente, e abbiamo anche il vantaggio di un supporto approfondito da parte del team AWS.
Se avessimo dovuto aggirare una limitazione simile in un modello di data center tradizionale, qualcosa del genere potrebbe richiedere giorni o persino settimane per essere completamente risolto. Quell’agilità e reattività sono solo due dei motivi per cui abbiamo puntato la nostra attività sul cloud e su AWS. Insieme, il tipo di esperienza nel 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 AWS.
SparkPost è il primo servizio di consegna email costruito per il cloud sin dall'inizio. Questo approccio nativo del cloud è fondamentale per come progettiamo i nostri email API 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 ciò significa entrare in territori inesplorati. È una verità fondamentale dell'informatica che non sai quali sfide si presenteranno su larga scala fino a quando non le incontri. Ne abbiamo trovata una su AWS, ma la nostra risposta rapida è un grande esempio della flessibilità resa possibile dal cloud. È anche il nostro impegno verso i nostri clienti.
Che tu stia costruendo la tua infrastruttura su AWS, o un cliente SparkPost che sfrutta la nostra, spero che questa spiegazione di ciò che è successo venerdì scorso e di come abbiamo risolto la questione sia stata utile.
