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 Amazon Web Services (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 dieser Vorfall led to intermittent slowness in our service and delivery delays for some of our customers.

Zunächst möchte ich sagen, dass das Problem noch am selben Tag behoben wurde. Außerdem gingen keine E-Mails oder damit verbundene Daten verloren. Falls sich die Zustellung Ihrer E-Mails aufgrund dieses Problems verlangsamt hat, bitte ich Sie, meine Entschuldigung anzunehmen (und zwar die Entschuldigung unseres gesamten Teams). Wir wissen, dass Sie sich auf uns verlassen, und es ist frustrierend, wenn wir nicht die von Ihnen erwartete Leistung erbringen.

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.

Ich wollte auch aus einem anderen Grund über diesen Vorfall schreiben: Wir haben etwas wirklich Interessantes und Wertvolles über unsere AWS-Cloud-Architektur gelernt. Teams, die andere Cloud-Services aufbauen, könnten daran interessiert sein.

TL;DR

Wir stießen bei den EC2-Instanzen, die wir für unseren primären DNS-Cluster verwendeten, an undokumentierte praktische Grenzen. Die Dimensionierung von Cloud-Instanzen auf der Grundlage traditioneller Spezifikationen (Prozessor, Arbeitsspeicher usw.) funktioniert in der Regel so, wie man es erwarten würde, aber manchmal trifft dieses traditionelle Hardwaremodell nicht zu. Das gilt vor allem für atypische Anwendungsfälle, bei denen aggregierte Grenzen ins Spiel kommen können - und es kommt vor, dass man ohne Vorwarnung in solche Szenarien gerät.

Wir haben eine solche Grenze am Freitag erreicht, als unser DNS-Abfragevolumen ein Netzwerknutzungsmuster erzeugte, auf das unser Instance-Typ nicht vorbereitet war. Da diese Grenze jedoch nicht aus den Dokumenten oder den verfügbaren Standardmetriken ersichtlich war, wussten wir nicht, dass wir sie erreicht hatten. Was wir beobachteten, war eine sehr hohe Rate von DNS-Fehlern, die wiederum zu zeitweiligen Verzögerungen an verschiedenen Stellen unserer Architektur führten.

Tieferer Einblick in DNS

Warum ist unsere DNS-Nutzung besonders? Nun, es hat viel mit der Funktionsweise von E-Mail zu tun, verglichen mit dem Inhaltsmodell, für das AWS ursprünglich konzipiert wurde. Bei der webbasierten Bereitstellung von Inhalten wird viel von dem Gebrauch gemacht, was man als klassische eingehende "Pull"-Szenarien bezeichnen könnte: Ein Client fordert Daten, sei es HTML, Videostreams oder etwas anderes, aus der Cloud an. Aber die Anwendungsfälle für Messaging-Dienstleister wie SparkPost sind Ausnahmen vom üblichen AWS-Szenario. In unserem Fall machen wir viel ausgehenden Push-Verkehr: insbesondere E-Mail (und andere Nachrichtentypen wie SMS oder mobile Push-Benachrichtigungen). Und dieser Push-Verkehr stützt sich stark auf DNS.

Wenn Sie mit dem DNS vertraut sind, wissen Sie vielleicht, dass es sich im Allgemeinen um recht leichtgewichtige Daten handelt. Um eine bestimmte HTML-Seite anzufordern, müssen Sie zunächst fragen, wo diese Seite im Internet zu finden ist, aber diese Anfrage ist nur ein Bruchteil der Größe des abgerufenen Inhalts.

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 jeden Monat. 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 Denial-of-Service-Angriffe auf die Dyn DNS-Infrastruktur last year demonstrated, when DNS breaks, everything breaks. (That’s something anyone who builds systems that rely on DNS already knows painfully well.)

Die plötzlichen DNS-Probleme lösten eine Reaktion unserer Betriebs- und Zuverlässigkeitstechnik-Teams aus, um das Problem zu identifizieren. Sie arbeiteten mit unseren Partnern bei Amazon zusammen, um das Problem auf der AWS-Betriebsseite zu eskalieren. Gemeinsam ermittelten wir die Ursache und fanden eine Lösung. Wir stellten einen Cluster von Nameservern mit größerer Kapazität bereit und konzentrierten uns dabei stärker auf die Netzwerkkapazität, die unsere DNS-Anforderungen erfüllen konnte, ohne dass der Durchsatz in den roten Bereich geriet. Da dies alles innerhalb von AWS geschah, konnten wir die neuen Instanzen sehr schnell in Betrieb nehmen und sogar die Größe der vorhandenen Instanzen ändern. DNS nahm sein normales Verhalten wieder auf, Lookup-Fehler traten nicht mehr auf, und wir (und die Zustellung ausgehender Nachrichten) waren wieder auf Kurs.

Um dieses spezielle Problem in Zukunft zu vermeiden, nehmen wir auch Änderungen an der DNS-Architektur vor, um unsere Kernkomponenten besser vor den Auswirkungen ähnlicher, unerwarteter Schwellenwerte zu schützen. Außerdem arbeiten wir mit dem Amazon-Team zusammen, um geeignete Überwachungsmodelle festzulegen, die uns eine ausreichende Warnung geben, um einen ähnlichen Vorfall zu verhindern, bevor er einen unserer Kunden betrifft.

AWS and the Cloud’s Silver Lining

Ich möchte die Auswirkungen dieses Vorfalls auf unsere Kunden nicht beschönigen. Aber unsere Fähigkeit, das zugrundeliegende Problem als eine unerwartete Interaktion unseres Anwendungsfalls mit der AWS-Infrastruktur zu identifizieren - und dann in kürzester Zeit eine Lösung dafür zu finden - hat viel damit zu tun, wie wir SparkPost aufgebaut haben, und mit unserer großartigen Beziehung zum Amazon-Team.

SparkPost’s superb operations corps, our Site Reliability Engineering (SRE) team, and our principal technical architects work with Amazon every day. Die strengths of AWS’ infrastructure has given us a real leg up Optimierung der Architektur von SparkPost für die Cloud. 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.

Wenn wir eine ähnliche Einschränkung in einem herkömmlichen Rechenzentrumsmodell umgehen müssten, könnte es Tage oder sogar Wochen dauern, bis so etwas vollständig gelöst ist. Diese Agilität und Reaktionsfähigkeit sind nur zwei der Gründe, warum wir unser Geschäft auf die Cloud und AWS ausgerichtet haben. Die Art von Cloud-Expertise, die unsere Unternehmen gemeinsam haben, ist nur schwer zu finden. Amazon ist ein großartiger Geschäftspartner für uns, und wir sind wirklich stolz darauf, was wir mit dem AWS-Stack erreicht haben.

SparkPost ist der erste E-Mail-Versanddienst, der von Anfang an für die Cloud entwickelt wurde. Wir versenden mehr E-Mails über eine echte Cloud-Plattform als jeder andere, und manchmal bedeutet das, dass wir Neuland betreten. Es ist eine grundlegende Wahrheit der Informatik, dass man nicht weiß, welche Herausforderungen bei der Skalierung auftreten, bis man auf sie trifft. Wir haben bei AWS eine gefunden, aber unsere schnelle Reaktion ist ein großartiges Beispiel für die Flexibilität, die die Cloud ermöglicht. Es ist auch unsere Verpflichtung gegenüber unseren Kunden.

Unabhängig davon, ob Sie Ihre eigene Infrastruktur auf AWS aufbauen oder ein SparkPost-Kunde sind, der die Vorteile von AWS nutzt, hoffe ich, dass diese Erklärung des Vorfalls vom letzten Freitag und die Lösung des Problems für Sie hilfreich war.