How We Tracked Down Unusual DNS Failures in AWS

We’ve built SparkPost around the idea that a cloud service like ours needs to be cloud-native itself. That’s not just posturing. It’s our cloud architecture that underpins the scalability, elasticity, and reliability that are core aspects of the SparkPost service. Those qualities are major reasons we’ve built our infrastructure atop Services Web d'Amazon (AWS)—and it’s why we can offer our customers service level and burst rate guarantees unmatched by anyone else in the business.

But we don’t pretend that we’re never challenged by unexpected bugs or limits of available technology. We ran into something like this last Friday, and cet incident led to intermittent slowness in our service and delivery delays for some of our customers.

Tout d'abord, laissez-moi vous dire que le problème a été résolu le jour même. De plus, aucun courriel ni aucune donnée connexe n'ont été perdus. Cependant, si la livraison de vos e-mails a été ralentie à cause de ce problème, veuillez accepter mes excuses (en fait, les excuses de toute notre équipe). Nous savons que vous comptez sur nous, et il est frustrant de constater que nous ne sommes pas à la hauteur de vos attentes.

Some companies are tempted to brush issues like a service degradation under the rug and hope no one notices. You may have experienced that with services you’ve used in the past. I know I have. But that’s not how we like to do business.

Je voulais écrire sur cet incident pour une autre raison également : nous avons appris quelque chose de vraiment intéressant et précieux sur notre architecture de cloud AWS. Les équipes qui construisent d'autres services en nuage pourraient être intéressées par cet enseignement.

TL;DR

Nous avons rencontré les limites pratiques non documentées des instances EC2 que nous utilisions pour notre cluster DNS principal. Le dimensionnement des instances de cloud computing sur la base des spécifications traditionnelles (processeur, mémoire, etc.) fonctionne généralement comme prévu, mais parfois ce modèle matériel traditionnel ne s'applique pas. C'est particulièrement vrai dans les cas d'utilisation atypiques où des limites globales peuvent entrer en jeu - et il arrive que l'on se heurte à ces scénarios sans prévenir.

Nous avons atteint une telle limite vendredi lorsque notre volume de requêtes DNS a créé un modèle d'utilisation du réseau auquel notre type d'instance n'était pas préparé. Cependant, comme cette limite n'était pas évidente dans la documentation ou les mesures standard disponibles, nous ne savions pas que nous l'avions atteinte. Ce que nous avons observé, c'est un taux très élevé d'échecs DNS, ce qui a entraîné des retards intermittents à différents endroits de notre architecture.

Creuser plus profondément dans le DNS

Pourquoi notre utilisation du DNS est-elle particulière ? Eh bien, cela a beaucoup à voir avec le mode de fonctionnement du courrier électronique, par rapport au modèle de contenu pour lequel AWS a été conçu à l'origine. La diffusion de contenu sur le Web fait un usage intensif de ce que l'on pourrait considérer comme des scénarios classiques de "traction" entrante : un client demande des données, qu'il s'agisse de HTML, de flux vidéo ou de quoi que ce soit d'autre, depuis le nuage. Mais les cas d'utilisation des fournisseurs de services de messagerie comme SparkPost sont des exceptions au scénario AWS habituel. Dans notre cas, nous envoyons beaucoup de trafic vers l'extérieur : plus précisément, des courriels (et d'autres types de messages comme les SMS ou les notifications push mobiles). Et ce trafic de type push s'appuie fortement sur le DNS.

Si vous êtes familier avec le DNS, vous savez peut-être qu'il s'agit généralement de données assez légères. Pour demander une page HTML donnée, vous devez d'abord demander où se trouve cette page sur l'internet, mais cette demande ne représente qu'une fraction de la taille du contenu que vous récupérez.

Email, however, makes exceptionally heavy use of DNS to look up delivery domains—for example, SparkPost sends many billions of emails to over 1 million unique domains tous les mois. For every email we deliver, we have to make a minimum of two DNS lookups, and the use of DNS “txt” records for anti-phishing technologies like SPF and DKIM means DNS also is required to receive mail. Add to that our more traditional use of AWS API services for our apps, and it’s hard to exaggerate how important DNS is to our infrastructure.

All of this means we ran into an unusual condition in which our growing volume of outbound messages created a DNS traffic volume that hit an aggregate network throughput limit on instance types that otherwise seemed to have sufficient resources to service that load. And as attaques par déni de service sur l'infrastructure Dyn DNS last year demonstrated, when DNS breaks, everything breaks. (That’s something anyone who builds systems that rely on DNS already knows painfully well.)

Les problèmes soudains de DNS ont déclenché une intervention de nos équipes d'exploitation et d'ingénierie de fiabilité pour identifier le problème. Elles ont fait équipe avec nos partenaires chez Amazon pour remonter la pente du côté des opérations AWS. En travaillant ensemble, nous avons identifié la cause et une solution. Nous avons déployé un cluster de serveurs de noms de plus grande capacité, en mettant l'accent sur la capacité du réseau, afin de répondre à nos besoins en matière de DNS sans nous heurter aux limites du débit. Heureusement, comme tout cela se passait dans AWS, nous avons pu faire tourner les nouvelles instances et même redimensionner les instances existantes très rapidement. Le DNS a repris un comportement normal, les échecs de recherche ont cessé, et nous (et la livraison des messages sortants) étions de nouveau sur la bonne voie.

Pour atténuer ce problème spécifique à l'avenir, nous apportons également des modifications à l'architecture DNS afin de mieux isoler nos composants principaux de l'impact de rencontres avec des seuils similaires et inattendus. Nous travaillons également avec l'équipe d'Amazon pour déterminer les modèles de surveillance appropriés qui nous permettront de prévenir un incident similaire avant qu'il n'affecte l'un de nos clients.

AWS and the Cloud’s Silver Lining

Je ne veux pas édulcorer l'impact de cet incident sur nos clients. Mais notre capacité à identifier le problème sous-jacent comme une interaction inattendue de notre cas d'utilisation avec l'infrastructure AWS - et à trouver une solution dans les plus brefs délais - a beaucoup à voir avec la façon dont nous avons construit SparkPost, et notre excellente relation avec l'équipe Amazon.

SparkPost’s superb operations corps, our Site Reliability Engineering (SRE) team, and our principal technical architects work with Amazon every day. Le strengths of AWS’ infrastructure has given us a real leg up optimiser l'architecture de SparkPost pour le nuage. Working so closely with AWS over the past two years also has taught us a lot about spinning up AWS infrastructure and running quickly, and we also have the benefit of deep support from the AWS team.

Si nous devions faire face à une limitation similaire dans un modèle de centre de données traditionnel, il nous faudrait des jours, voire des semaines, pour résoudre complètement un problème de ce type. Cette agilité et cette réactivité ne sont que deux des raisons pour lesquelles nous avons misé sur le cloud et AWS. Ensemble, le type d'expertise en matière de cloud que nos entreprises partagent est difficile à trouver. Amazon a été un excellent partenaire commercial pour nous, et nous sommes vraiment fiers de ce que nous avons fait avec la pile AWS.

SparkPost est le premier service d'envoi d'e-mails qui a été conçu dès le départ pour le cloud. Nous envoyons plus d'e-mails que quiconque à partir d'une véritable plateforme en nuage, ce qui implique parfois de pénétrer en territoire inconnu. L'une des vérités fondamentales de l'informatique est que l'on ne sait pas quels défis se posent à l'échelle avant de les relever. Nous en avons trouvé un sur AWS, mais notre réponse rapide est un excellent exemple de la flexibilité que le cloud rend possible. C'est aussi notre engagement envers nos clients.

Que vous construisiez votre propre infrastructure sur AWS, ou que vous soyez un client de SparkPost qui profite de la nôtre, j'espère que cette explication de ce qui s'est passé vendredi dernier, et de la manière dont nous l'avons résolu, vous aura été utile.