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 wie erwartet, aber manchmal trifft dieses traditionelle Hardware-Modell nicht zu.
Business in a box.
Entdecken Sie unsere Lösungen.
Sprechen Sie mit unserem Vertriebsteam
Wie Wir Ungewöhnliche DNS-Ausfälle in AWS Aufspürten
Wir haben SparkPost um die Idee herum aufgebaut, dass ein Cloud-Dienst wie unserer selbst cloud-native sein muss. Das ist nicht nur Angeberei. Es ist unsere Cloud-Architektur, die die Skalierbarkeit, Elastizität und Zuverlässigkeit untermauert, die wesentliche Aspekte des SparkPost-Dienstes sind. Diese Qualitäten sind die Hauptgründe, warum wir unsere Infrastruktur auf Amazon Web Services (AWS) aufgebaut haben – und weshalb wir unseren Kunden Service-Level- und Burst-Rate-Garantien bieten können, die von niemand anderem im Geschäft übertroffen werden.
Aber wir tun nicht so, als würden wir nie von unerwarteten Bugs oder den Grenzen der verfügbaren Technologie herausgefordert. Letzten Freitag sind wir auf etwas derartiges gestoßen, und dieser Vorfall führte zu gelegentlicher Langsamkeit in unserem Dienst und zu Lieferverzögerungen für einige unserer Kunden.
Zuerst möchte ich sagen, dass das Problem am selben Tag gelöst wurde. Darüber hinaus gingen keine E-Mails oder zugehörigen Daten verloren. Wenn jedoch die Zustellung Ihrer E-Mails aufgrund dieses Problems verlangsamt wurde, bitte ich Sie um 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 sind versucht, Probleme wie eine Dienstbeeinträchtigung unter den Teppich zu kehren und zu hoffen, dass es niemand bemerkt. Sie haben das möglicherweise bei Diensten erlebt, die Sie in der Vergangenheit genutzt haben. Ich weiß, dass ich das habe. Aber so machen wir das Geschäft nicht gerne.
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 lernen.
TL;DR
Tiefer in DNS eintauchen
Warum ist unser DNS-Einsatz besonders? Nun, es hat viel mit der Funktionsweise von E-Mail zu tun, im Vergleich zum Inhaltsmodell, für das AWS ursprünglich entwickelt wurde. Die webbasierte Inhaltsbereitstellung nutzt stark die klassischen eingehenden „Pull“-Szenarien: Ein Client fordert Daten an, sei es HTML, Videostreams oder etwas anderes, aus der Cloud. Aber die Anwendungsfälle für Messaging-Dienstleister wie SparkPost sind Ausnahmen zum üblichen AWS-Szenario. In unserem Fall senden wir viel ausgehenden Traffic: speziell E-Mails (und andere Nachrichtentypen wie SMS oder mobile Push-Benachrichtigungen). Und dieser Push-Traffic stützt sich stark auf DNS.
Wenn Sie mit DNS vertraut sind, wissen Sie vielleicht, dass es im Allgemeinen relativ leichte Daten sind. Um eine HTML-Seite anzufordern, muss man zuerst fragen, wo diese Seite im Internet zu finden ist, aber diese Anfrage ist ein Bruchteil der Größe des Inhalts, den man abruft.
E-Mail hingegen macht ungewöhnlich starken Gebrauch von DNS, um Zustelldomains aufzuspüren — zum Beispiel sendet SparkPost jeden Monat viele Milliarden E-Mails an über 1 Million einzigartige Domains . 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. Fügen Sie dazu unsere traditionellere Nutzung der AWS-API-Dienste für unsere Apps hinzu, und es ist schwer zu übertreiben, wie wichtig DNS für unsere Infrastruktur ist.
All dies bedeutet, dass wir auf eine ungewöhnliche Bedingung gestoßen sind, in der unser wachsendes Volumen an ausgehenden Nachrichten ein DNS-Verkehrsvolumen erzeugte, das ein aggregiertes Netzwerkdurchsatzlimit bei Instanztypen erreichte, die sonst ausreichende Ressourcen zu haben schienen, um diese Last zu bewältigen. Und wie Denial-of-Service-Angriffe auf die Dyn-DNS-Infrastruktur im letzten Jahr zeigten, wenn DNS ausfällt, fällt alles aus. (Das ist etwas, was jeder, der Systeme baut, die auf DNS angewiesen sind, schmerzlich gut kennt.)
Die plötzlichen DNS-Probleme lösten eine Reaktion unserer Operations- und Zuverlässigkeitsingenieur-Teams aus, um das Problem zu identifizieren. Sie arbeiteten mit unseren Partnern bei Amazon zusammen, um die Eskalation auf der AWS-Betriebsseite zu unterstützen. Gemeinsam identifizierten wir die Ursache und eine Lösung. Wir setzten einen Cluster größerer Kapazitäts-Nameserver mit einem stärkeren Fokus auf Netzwerk-Kapazität ein, der unsere DNS-Bedürfnisse erfüllen konnte, ohne die Durchsatzobergrenzen zu erreichen. Glücklicherweise konnten wir, da sich all dies innerhalb von AWS abspielte, die neuen Instanzen schnell hochfahren und sogar vorhandene Instanzen sehr schnell umstellen. DNS kehrte zum normalen Verhalten zurück, Abfragefehler hörten auf, und wir (und die Zustellung ausgehender Nachrichten) waren wieder auf Kurs.
Um dieses spezifische Problem in Zukunft zu mildern, nehmen wir auch Änderungen an der DNS-Architektur vor, um unsere Kernkomponenten besser von den Auswirkungen ähnlicher, unerwarteter Schwellenwerte abzuschirmen. Wir arbeiten auch mit dem Amazon-Team zusammen, um geeignete Überwachungsmodelle zu ermitteln, die uns ausreichende Warnungen geben, um ein ähnliches Ereignis zu verhindern, bevor es eines unserer Kunden betrifft.
AWS und die Silberstreifen der Cloud
Ich möchte den Einfluss 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 schnell eine Lösung zu finden –, hat viel damit zu tun, wie wir SparkPost aufgebaut haben und mit unserer großartigen Beziehung zum Amazon-Team.
SparkPosts hervorragendes Betriebsteam, unser Site Reliability Engineering (SRE)-Team und unsere leitenden technischen Architekten arbeiten jeden Tag mit Amazon. Die Stärken der AWS-Infrastruktur haben uns einen echten Vorteil verschafft beim Optimieren der SparkPost-Architektur für die Cloud. Die enge Zusammenarbeit mit AWS in den letzten zwei Jahren hat uns auch viel darüber beigebracht, wie man die AWS-Infrastruktur schnell hochfährt und umsetzt, und wir profitieren auch von der umfassenden Unterstützung des AWS-Teams.
Wenn wir eine ähnliche Einschränkung in einem traditionellen Rechenzentrumsmodell umgehen müssten, könnte so etwas Tage oder sogar Wochen dauern, 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 aufgebaut haben. Gemeinsam ist die Art von Cloud-Expertise, die unsere Unternehmen teilen, schwer zu finden. Amazon war 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-Zustellservice, der von Anfang an für die Cloud entwickelt wurde. Wir senden mehr E-Mail von einer echten Cloud-Plattform als jeder andere, und manchmal bedeutet das, unbekanntes Terrain zu betreten. Es ist eine grundlegende Wahrheit der Informatik, dass man nicht weiß, welche Herausforderungen in großem Maßstab auftreten, bis man sie erreicht. Wir haben eines auf AWS gefunden, aber unsere schnelle Reaktion ist ein großartiges Beispiel für die Flexibilität, die die Cloud ermöglicht. Es ist auch unser Engagement für unsere Kunden.
Unabhängig davon, ob Sie Ihre eigene Infrastruktur auf AWS aufbauen oder ein SparkPost-Kunde sind, der unsere nutzt, hoffe ich, dass diese Erklärung dessen, was letzten Freitag passiert ist und wie wir es gelöst haben, nützlich war.
