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.
Wie Wir Ungewöhnliche DNS-Ausfälle in AWS Aufspürten
Wir haben SparkPost um die Idee herum aufgebaut, dass ein Cloud-Service wie unserer selbst cloud-nativ sein muss. Das ist nicht nur leeres Gerede. 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 Hauptgründe dafür, dass 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 bieten können, die von niemand anderem im Geschäft übertroffen werden.
Aber wir tun nicht so, als hätten wir nie mit unerwarteten Bugs oder Grenzen der verfügbaren Technologie zu kämpfen. Letzten Freitag sind wir auf etwas Ähnliches gestoßen, und dieser Vorfall führte zu sporadischer Langsamkeit in unserem Dienst und Zustellungsverzögerungen für einige unserer Kunden.
Lassen Sie mich zunächst sagen, dass das Problem am selben Tag gelöst wurde. Darüber hinaus gingen keine E-Mails oder zugehörige Daten verloren. Wenn jedoch die Zustellung Ihrer E-Mails aufgrund dieses Problems verlangsamt wurde, akzeptieren Sie bitte meine Entschuldigung (tatsächlich eine Entschuldigung von unserem gesamten Team). Dieser Vorfall hat die Bedeutung unterstrichen, umfassende Backup-Strategien umzusetzen - egal ob Sie PostgreSQL-Datenbanksicherungen oder andere Datenschutzmethoden verwenden, um Geschäftskontinuität während Infrastrukturherausforderungen sicherzustellen. 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 Dienstleistungsverschlechterung unter den Teppich zu kehren und zu hoffen, dass es niemand bemerkt. Sie haben das vielleicht schon bei Diensten, die Sie in der Vergangenheit genutzt haben, erlebt. Ich weiß, dass ich es habe. Aber das ist nicht, wie wir Geschäfte machen wollen.
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, darüber zu erfahren.
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 die Auswirkungen dieses Vorfalls auf unsere Kunden nicht beschönigen. Aber unsere Fähigkeit, das zugrunde liegende Problem als unerwartete Interaktion unserer Anwendungsfälle mit der AWS-Infrastruktur zu identifizieren und dann in sehr kurzer Zeit eine Lösung zu finden, hat viel damit zu tun, wie wir SparkPost aufgebaut haben und wie wir ein großartiges Verhältnis zum Amazon-Team pflegen.
Das hervorragende Betriebskorps von SparkPost, unser Site Reliability Engineering (SRE) Team und unsere leitenden technischen Architekten arbeiten jeden Tag mit Amazon zusammen. Die Stärken der AWS-Infrastruktur haben uns einen echten Vorteil bei der Optimierung von SparkPosts Architektur für die Cloud verschafft. Die enge Zusammenarbeit mit AWS in den letzten zwei Jahren hat uns auch viel darüber gelehrt, wie man AWS-Infrastruktur in Betrieb nimmt und schnell verwaltet, 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 es Tage oder sogar Wochen dauern, bis etwas vollständig gelöst ist. Diese Agilität und Reaktionsfähigkeit sind nur zwei der Gründe, weshalb wir unser Geschäft auf die Cloud und AWS stützen. 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-Dienstleister, der von Anfang an für die Cloud entwickelt wurde. Dieser cloud-native Ansatz ist grundlegend dafür, wie wir unsere E-Mail-APIs für die Cloud-Infrastruktur entwerfen, um Skalierbarkeit und Zuverlässigkeit für Entwickler sicherzustellen. Wir versenden mehr E-Mails von einer echten Cloud-Plattform als jeder andere, und manchmal bedeutet das, unbekanntes Terrain zu betreten. Eine grundlegende Wahrheit der Informatik ist, dass man die Herausforderungen in großem Maßstab nicht kennt, bis man auf sie stößt. Wir haben eine bei AWS 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 gegenüber unseren Kunden.
Ob Sie nun Ihre eigene Infrastruktur auf AWS aufbauen oder ein SparkPost-Kunde sind, der unsere Vorteile nutzt, ich hoffe, dass diese Erklärung darüber, was letzten Freitag geschah und wie wir es gelöst haben, nützlich war.
