Wie wir ungewöhnliche DNS-Ausfälle in AWS aufspürten
Wir haben SparkPost mit der Idee entwickelt, dass ein Cloud-Service wie unserer selbst cloud-nativ sein muss. Das ist nicht nur ein Lippenbekenntnis. Es ist unsere Cloud-Architektur, die die Skalierbarkeit, Elastizität und Zuverlässigkeit untermauert, die zentrale Aspekte des SparkPost-Services sind. Diese Eigenschaften sind Hauptgründe, warum wir unsere Infrastruktur auf Amazon Web Services (AWS) aufgebaut haben—und es ist der Grund, warum wir unseren Kunden Service-Level- und Burst-Rate-Garantien anbieten können, die von niemand anderem in der Branche übertroffen werden.
Aber wir tun nicht so, als ob wir nie mit unerwarteten Fehlern oder den Grenzen verfügbarer Technologien herausgefordert werden. Wir sind letzten Freitag mit so etwas konfrontiert worden, und dieser Vorfall führte zu intermittierender Langsamkeit in unserem Service und Lieferverzögerungen für einige unserer Kunden.
Zuerst möchte ich sagen, dass das Problem am selben Tag gelöst wurde. Darüber hinaus wurde keine E-Mail oder verwandte Daten verloren. Wenn die Lieferung Ihrer E-Mails jedoch aufgrund dieses Problems verzögert wurde, akzeptieren Sie bitte meine Entschuldigung (tatsächlich eine Entschuldigung von unserem gesamten Team). Wir wissen, dass Sie auf uns zählen, und es ist frustrierend, wenn wir nicht auf dem Niveau arbeiten, das Sie erwarten.
Einige Unternehmen versuchen, Probleme wie eine Serviceverschlechterung einfach unter den Teppich zu kehren und hoffen, dass es niemand bemerkt. Möglicherweise haben Sie das mit Diensten erlebt, die Sie in der Vergangenheit genutzt haben. Ich weiß, dass ich das getan habe. Aber so möchten wir nicht Geschäfte machen.
Ich wollte aus einem weiteren Grund über diesen Vorfall schreiben: Wir haben etwas wirklich Interessantes und Wertvolles über unsere AWS-Cloud-Architektur gelernt. Teams, die andere Cloud-Dienste aufbauen, könnten daran interessiert sein, davon zu erfahren.
TL;DR
Wir sind auf nicht dokumentierte praktische Grenzen der EC2-Instanzen gestoßen, die wir für unseren primären DNS-Cluster verwendet haben. Die Dimensionierung von Cloud-Instanzen basierend auf traditionellen Spezifikationen (Prozessor, Speicher usw.) funktioniert normalerweise genau so, wie Sie es erwarten würden, aber manchmal gilt dieses traditionelle Hardwaremodell nicht. Das gilt insbesondere in atypischen Anwendungsfällen, in denen aggregierte Grenzen ins Spiel kommen können—und es gibt Zeiten, in denen Sie ohne Vorwarnung direkt in diese Szenarien geraten.
Wir sind solchen Grenzen am Freitag begegnet, als unser DNS-Abfragevolumen ein Netzwerknutzungsmuster erzeugte, auf das unser Instanztyp nicht vorbereitet war. Allerdings wussten wir nicht, dass wir darauf gestoßen waren, da dieses Limit in den Dokumentationen oder den verfügbaren Standardmetriken nicht offensichtlich war. Was wir beobachteten, war eine sehr hohe Rate von DNS-Fehlern, was wiederum zu intermittierenden Verzögerungen an verschiedenen Stellen unserer Architektur führte.
Tiefer in DNS eintauchen
Warum ist unsere DNS-Nutzung besonders? Nun, es hat viel damit zu tun, wie E-Mail funktioniert, im Vergleich zu dem Inhaltsmodell, für das AWS ursprünglich entworfen wurde. Die webbasierte Inhaltsauslieferung macht stark Gebrauch von dem, was als klassische eingehende "Pull"-Szenarien betrachtet werden könnte: ein Client fordert Daten an, seien es HTML, Video-Streams oder irgendetwas anderes aus der Cloud. Aber die Anwendungsfälle für Messaging-Dienstanbieter wie SparkPost sind Ausnahmen von dem üblichen AWS-Szenario. In unserem Fall gibt es viel outbound Traffic: konkret E-Mails (und andere Nachrichtentypen wie SMS oder mobile Push-Benachrichtigungen). Und dieser Push-Verkehr ist stark von DNS abhängig.
Wenn Sie mit DNS vertraut sind, wissen Sie, dass es im Allgemeinen relativ leichte Daten sind. Um eine bestimmte HTML-Seite anzufordern, müssen Sie zuerst fragen, wo diese Seite im Internet zu finden ist, aber diese Anfrage ist ein Bruchteil der Größe des Inhalts, den Sie abrufen.
E-Mail hingegen nutzt DNS in außergewöhnlichem Umfang, um Lieferdomänen abzufragen—zum Beispiel sendet SparkPost jeden Monat viele Milliarden E-Mails an über 1 Million einzigartiger Domänen jeden Monat. Für jede E-Mail, die wir zustellen, müssen wir mindestens zwei DNS-Abfragen durchführen, und die Verwendung von DNS "txt"-Einträgen für Anti-Phishing-Technologien wie SPF und DKIM bedeutet, dass DNS auch erforderlich ist, um E-Mails zu empfangen. Hinzu kommt unsere traditionellere Nutzung von AWS-API-Services für unsere Anwendungen, sodass es schwierig ist, zu übertreiben, wie wichtig DNS für unsere Infrastruktur ist.
All dies bedeutet, dass wir auf eine ungewöhnliche Bedingung gestoßen sind, bei der unser wachsendes Volumen an ausgehenden Nachrichten ein DNS-Verkehrsvolumen erzeugte, das ein aggregiertes Netzwerkdurchsatzlimit bei Instanztypen traf, die ansonsten über ausreichende Ressourcen verfügten, um diese Last zu bedienen. Und wie Denial-of-Service-Angriffe auf die Dyn-DNS-Infrastruktur im letzten Jahr demonstrierten, wenn DNS ausfällt, fällt alles aus. (Das wissen alle, die Systeme bauen, die auf DNS angewiesen sind, bereits schmerzlich gut.)
Die plötzlichen DNS-Probleme lösten eine Reaktion unserer Betriebs- und Zuverlässigkeitsengineering-Teams aus, um das Problem zu identifizieren. Sie arbeiteten mit unseren Partnern bei Amazon zusammen, um auf der AWS-Betriebsseite zu eskalieren. Gemeinsam identifizierten wir die Ursache und eine Lösung. Wir setzten einen Cluster größerer Kapazitätsnameserver ein, der sich stärker auf die Netzwerk-Kapazität konzentrierte, um unseren DNS-Bedarf zu erfüllen, ohne die roten Linien für den Durchsatz zu überschreiten. Glücklicherweise konnten wir, da all dies innerhalb von AWS war, die neuen Instanzen und sogar die vorhandenen Instanzen sehr schnell bereitstellen. DNS zeigte wieder normales Verhalten, Abfragefehler hörten auf, und wir (und die Auslieferung der ausgehenden Nachrichten) waren wieder auf Kurs.
Um dieses spezifische Problem in Zukunft zu mildern, führen wir auch Änderungen an der DNS-Architektur durch, um unsere Kernkomponenten besser vor den Auswirkungen ähnlicher, unerwarteter Schwellenwerte zu isolieren. Wir arbeiten auch mit dem Amazon-Team zusammen, um geeignete Überwachungsmodelle zu bestimmen, die uns ausreichend Warnungen geben, um ein ähnliches Ereignis zu vermeiden, bevor es Auswirkungen auf unsere Kunden hat.
AWS und die Silberlinie der Cloud
Ich möchte die Auswirkungen dieses Vorfalls auf unsere Kunden nicht beschönigen. Aber unsere Fähigkeit, das zugrunde liegende Problem als eine unerwartete Interaktion unseres Anwendungsfalls mit der AWS-Infrastruktur zu identifizieren—und dann sehr schnell eine Lösung zu finden—hat viel damit zu tun, wie wir SparkPost aufgebaut haben, und unsere großartige Beziehung zum Amazon-Team.
Das hervorragende Operations-Team von SparkPost, unser Site Reliability Engineering (SRE) Team und unsere Haupttechnischen Architekten arbeiten jeden Tag mit Amazon zusammen. Die Stärken von AWS' Infrastruktur haben uns einen echten Vorteil verschafft bei der Optimierung von SparkPost’s Architektur für die Cloud. Die enge Zusammenarbeit mit AWS in den letzten zwei Jahren hat uns auch viel darüber beigebracht, wie man AWS-Infrastruktur schnell bereitstellt, und wir haben auch den Vorteil der tiefen Unterstützung des AWS-Teams.
Wenn wir mit einer ähnlichen Einschränkung in einem traditionellen Rechenzentrumsmodell arbeiten müssten, könnte etwas wie dies Tage oder sogar Wochen in Anspruch nehmen, um vollständig gelöst zu werden. Diese Agilität und Reaktionsfähigkeit sind nur zwei der Gründe, warum wir unser Geschäft auf die Cloud und AWS gesetzt haben. Gemeinsam ist die Art von Cloud-Expertise, die unsere Unternehmen teilen, schwer zu finden. Amazon ist ein großartiger Geschäftspartner für uns, und wir sind wirklich stolz auf das, was wir mit dem AWS-Stapel erreicht haben.
SparkPost ist der erste E-Mail-Zustelldienst, der von Anfang an für die Cloud entwickelt wurde. Wir senden mehr E-Mails von einer echten Cloud-Plattform als jeder andere und manchmal bedeutet das, dass wir unerforschte Gebiete betreten. Es ist eine grundlegende Wahrheit der Informatik, dass man nicht weiß, welche Herausforderungen bei großem Maßstab auftreten, bis man ihnen begegnet. Wir haben in AWS eine gefunden, aber unsere schnelle Reaktion ist ein großartiges Beispiel für die Flexibilität, die die Cloud möglich macht. Es ist auch unser Engagement für unsere Kunden.
Egal, ob Sie Ihre eigene Infrastruktur auf AWS aufbauen oder ein SparkPost-Kunde sind, der unsere Infrastruktur nutzt, ich hoffe, diese Erklärung dessen, was letzten Freitag passiert ist und wie wir es gelöst haben, war hilfreich.