Come Abbiamo Tracciato Le Strane Falle DNS in AWS
Abbiamo costruito SparkPost attorno all'idea che un servizio cloud come il nostro deve essere esso stesso nativo del cloud. Non è solo una facciata. È la nostra architettura cloud che sostiene la scalabilità, l'elasticità e l'affidabilità che sono aspetti fondamentali del servizio SparkPost. Queste qualità sono motivi principali per cui abbiamo costruito la nostra infrastruttura su Amazon Web Services (AWS)—e per cui possiamo offrire ai nostri clienti garanzie sui livelli di servizio e sui tassi di picco che non sono eguagliati da nessun altro nel settore.
Ma non facciamo finta che non siamo mai sfidati da bug imprevisti o limiti della tecnologia disponibile. Ci siamo imbattuti in qualcosa di simile venerdì scorso, e quel incidente ha portato a lentezze intermittenti nel nostro servizio e ritardi nella consegna per alcuni dei nostri clienti.
Prima di tutto, lascia che dica che il problema è stato risolto lo stesso giorno. Inoltre, nessuna email o dato correlato è andato perso. Tuttavia, se la consegna delle tue email è stata rallentata a causa di questo problema, ti prego di accettare le mie scuse (in effetti, le scuse da parte del nostro intero team). Sappiamo che conti su di noi, e risulta frustrante quando non ci comportiamo al livello che ti aspetti.
Alcune aziende sono tentate di nascondere problemi come la degradazione del servizio e sperare che nessuno se ne accorga. Potresti averlo sperimentato con servizi che hai utilizzato in passato. So che io l'ho fatto. 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 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 basandosi su specifiche tradizionali (processore, memoria, ecc.) di solito funziona come ci si aspetta, 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 colpito 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 dalla documentazione o dalle metriche standard disponibili, non sapevamo di averlo superato. Ciò che abbiamo osservato è stato un tasso molto elevato di errori DNS, che a sua volta ha portato a ritardi intermittenti in diversi punti della nostra architettura.
Approfondendo il DNS
Perché il nostro utilizzo del DNS è speciale? Bene, ha molto a che fare con il modo in cui funziona l'email, rispetto al modello di contenuto per il quale AWS è stato originariamente progettato. La consegna di contenuti basata sul web fa ampio uso di ciò che potrebbe essere considerato scenari di