Der Tag, an dem unser DNS eine undocumented Grenze in AWS erreichte
Vogel
07.02.2017
Ingenieurwissenschaft
1 min read
Wichtige Erkenntnisse
SparkPost stieß auf ein nicht dokumentiertes Netzwerk-Durchsatzlimit bei einem bestimmten AWS EC2-Instanztyp, der seinen primären DNS-Cluster antreibt.
Die traditionelle Größenbestimmung von Instanzen (CPU, RAM, Festplatte) hat dieses Nadelöhr nicht aufgedeckt, da das Problem mit dem aggregierten DNS-Netzwerkverkehr und nicht mit Ressourcenknappheit verbunden war.
Die DNS-Nutzung für hochvolumige ausgehende E-Mails ist ungewöhnlich hoch: SparkPost generiert Millionen von DNS-Abfragen für Domain-Routing, Authentifizierung (SPF/DKIM) und AWS-API-Interaktionen.
Der DNS-Ausfall resultierte nicht aus fehlerhaften DNS-Antworten – vielmehr wurden Instanz-Netzwerkkapazitätsschwellen stillschweigend überschritten, wodurch weit verbreitete Abfragefehler verursacht wurden.
Da AWS diese weichen Netzwerkbegrenzungen nicht ausdrücklich dokumentiert, erforderte die Diagnose des Problems eine enge Zusammenarbeit zwischen SparkPosts SRE-Team und AWS-Ingenieuren.
Das Team löste das Problem, indem es die DNS-Dienste auf größere Instanztypen mit höherer Netzwerkbandbreite migrierte und Teile der DNS-Architektur neu gestaltete für bessere Isolation und Failover.
Keine Kundendaten oder Nachrichten gingen verloren, aber das Ereignis zeigte, wie cloud-native Architekturen unerwartete Grenzen in großem Maßstab erreichen können — und wie schnell sie mit AWS-Elastizität behoben werden können.
Q&A Highlights
Was ist passiert?
Das DNS-Cluster von SparkPost erreichte unerwartet eine Netzwerkdurchsatzgrenze bei AWS, was dazu führte, dass DNS-Abfragen zeitweise fehlschlugen — was die Zustellung von E-Mails verzögerte.
Warum ist DNS überhaupt ausgefallen?
DNS ist extrem abhängig von Abfragen für ausgehende E-Mails. Jeder Versand erfordert mehrere Lookups (MX, TXT, SPF, DKIM), also ist ein hohes Versandvolumen gleichbedeutend mit massivem DNS-Verkehr.
Dieses Verkehrsmuster überschritt ein undokumentiertes Limit auf dem EC2-Instanztyp, der die Nameserver hostete.
Wie unterscheidet sich DNS für E-Mail von Webanwendungen?
Web-Apps ziehen meist Inhalte ab (Clients fordern Daten an).
Email-Zustellungsdienste drücken den Datenverkehr, was weit mehr DNS-Lookups auslöst — oft Milliarden pro Monat.
Email hängt von DNS für Routing, Sicherheitsvalidierung und Failover ab.
Wie zeigte sich der Fehler?
DNS-Anfragen begannen zu unterbrechen oder abzulaufen
Lieferwarteschlangen stauten sich auf
Die Latenz nahm in Teilen des Systems zu
Nichts ging verloren — nur verzögert.
Warum war das schwer zu diagnostizieren?
Das Limit wurde nicht dokumentiert
Die AWS-Überwachung zeigte den Engpass nicht explizit
Alle traditionellen Metriken (CPU, RAM, Festplatte) sahen normal aus
Das Problem trat nur bei einem bestimmten, hochvolumigen DNS-Datenverkehrsmuster auf.
Wie hat SparkPost es behoben?
Aufgerüstet zu EC2-Instance-Typen mit höheren Netzwerkdurchsatzgrenzen
DNS-Cluster neu gestaltet, um widerstandsfähiger gegenüber aggregierten Verkehrsspitzen zu sein
Mit AWS zusammengearbeitet, um bessere Signal-/Alarmierungsmuster zu identifizieren, um dies früher zu erkennen
Wurden Kundendaten oder E-Mails verloren?
Nein — nur die Zustellung wurde langsamer. Sobald das DNS stabilisiert war, wurde die gesamte E-Mail-Zustellung wieder normal aufgenommen.
Was ist die breitere Lektion?
Selbst in der Cloud können Sie auf unsichtbare Skalierungsbegrenzungen stoßen — aber cloud-native Designs geben Ihnen die Flexibilität, sich schnell zu erholen.
Elastizität, Partnerschaft mit AWS und starke SRE-Praktiken ermöglichen eine schnelle Erholung.
Wie wir ungewöhnliche DNS-Ausfälle in AWS aufgespürt haben
Wir haben SparkPost um die Idee herum aufgebaut, dass ein Cloud-Dienst wie unserer selbst cloud-nativ sein muss. Das ist nicht nur 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, warum wir unsere Infrastruktur auf Amazon Web Services (AWS) aufgebaut haben — und warum wir unseren Kunden Servicelevel- und Burst-Rate-Garantien bieten können, die von niemand anderem in der Branche übertroffen werden.
Aber wir tun nicht so, als würden wir niemals vor unerwarteten Bugs oder Grenzen der verfügbaren Technologie stehen. Letzten Freitag sind wir auf etwas Ähnliches gestoßen, und dieser Vorfall führte zu sporadischen Verzögerungen in unserem Service und Lieferverzögerungen für einige unserer Kunden.
Erstens möchte ich sagen, dass das Problem noch am selben Tag gelöst wurde. Außerdem wurden keine E-Mails oder zugehörigen Daten verloren. Wenn jedoch die Zustellung Ihrer E-Mails aufgrund dieses Problems verzögert wurde, nehmen Sie bitte meine Entschuldigung an (tatsächlich die Entschuldigung unseres gesamten Teams). Dieser Vorfall hat die Bedeutung verstärkt, umfassende Backup-Strategien zu haben - unabhängig davon, ob Sie PostgreSQL-Datenbanksicherungen oder andere Datenschutzmethoden verwenden, um die Geschäftskontinuität während Infrastruktur-Herausforderungen 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. Möglicherweise haben Sie das mit Diensten erlebt, die Sie in der Vergangenheit genutzt haben. Ich weiß, dass ich es habe. Aber so machen wir keine Geschäfte.
Ich wollte 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-Dienste entwickeln, könnten daran interessiert sein, darüber zu lernen.
Wir haben SparkPost um die Idee herum aufgebaut, dass ein Cloud-Dienst wie unserer selbst cloud-nativ sein muss. Das ist nicht nur 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, warum wir unsere Infrastruktur auf Amazon Web Services (AWS) aufgebaut haben — und warum wir unseren Kunden Servicelevel- und Burst-Rate-Garantien bieten können, die von niemand anderem in der Branche übertroffen werden.
Aber wir tun nicht so, als würden wir niemals vor unerwarteten Bugs oder Grenzen der verfügbaren Technologie stehen. Letzten Freitag sind wir auf etwas Ähnliches gestoßen, und dieser Vorfall führte zu sporadischen Verzögerungen in unserem Service und Lieferverzögerungen für einige unserer Kunden.
Erstens möchte ich sagen, dass das Problem noch am selben Tag gelöst wurde. Außerdem wurden keine E-Mails oder zugehörigen Daten verloren. Wenn jedoch die Zustellung Ihrer E-Mails aufgrund dieses Problems verzögert wurde, nehmen Sie bitte meine Entschuldigung an (tatsächlich die Entschuldigung unseres gesamten Teams). Dieser Vorfall hat die Bedeutung verstärkt, umfassende Backup-Strategien zu haben - unabhängig davon, ob Sie PostgreSQL-Datenbanksicherungen oder andere Datenschutzmethoden verwenden, um die Geschäftskontinuität während Infrastruktur-Herausforderungen 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. Möglicherweise haben Sie das mit Diensten erlebt, die Sie in der Vergangenheit genutzt haben. Ich weiß, dass ich es habe. Aber so machen wir keine Geschäfte.
Ich wollte 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-Dienste entwickeln, könnten daran interessiert sein, darüber zu lernen.
Wir haben SparkPost um die Idee herum aufgebaut, dass ein Cloud-Dienst wie unserer selbst cloud-nativ sein muss. Das ist nicht nur 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, warum wir unsere Infrastruktur auf Amazon Web Services (AWS) aufgebaut haben — und warum wir unseren Kunden Servicelevel- und Burst-Rate-Garantien bieten können, die von niemand anderem in der Branche übertroffen werden.
Aber wir tun nicht so, als würden wir niemals vor unerwarteten Bugs oder Grenzen der verfügbaren Technologie stehen. Letzten Freitag sind wir auf etwas Ähnliches gestoßen, und dieser Vorfall führte zu sporadischen Verzögerungen in unserem Service und Lieferverzögerungen für einige unserer Kunden.
Erstens möchte ich sagen, dass das Problem noch am selben Tag gelöst wurde. Außerdem wurden keine E-Mails oder zugehörigen Daten verloren. Wenn jedoch die Zustellung Ihrer E-Mails aufgrund dieses Problems verzögert wurde, nehmen Sie bitte meine Entschuldigung an (tatsächlich die Entschuldigung unseres gesamten Teams). Dieser Vorfall hat die Bedeutung verstärkt, umfassende Backup-Strategien zu haben - unabhängig davon, ob Sie PostgreSQL-Datenbanksicherungen oder andere Datenschutzmethoden verwenden, um die Geschäftskontinuität während Infrastruktur-Herausforderungen 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. Möglicherweise haben Sie das mit Diensten erlebt, die Sie in der Vergangenheit genutzt haben. Ich weiß, dass ich es habe. Aber so machen wir keine Geschäfte.
Ich wollte 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-Dienste entwickeln, könnten daran interessiert sein, darüber zu lernen.
TL;DR
Wir stießen auf nicht dokumentierte praktische Grenzen der EC2-Instanzen, die wir für unser primäres DNS-Cluster verwendeten. Die Dimensionierung von Cloud-Instanzen basierend auf traditionellen Spezifikationen (Prozessor, Speicher usw.) funktioniert normalerweise wie erwartet, aber manchmal gilt dieses traditionelle Hardwaremodell nicht. Das ist besonders in atypischen Anwendungsfällen der Fall, in denen aggregierte Grenzen ins Spiel kommen können – und es gibt Zeiten, in denen man ohne Vorwarnung auf diese Szenarien stößt.
Wir stießen am Freitag auf eine solche Grenze, als unser DNS-Abfragevolumen ein Netzwerkbenutzungsmuster erzeugte, für das unser Instanztyp nicht vorbereitet war. Da diese Grenze jedoch weder in den Dokumenten noch in den verfügbaren Standardmetriken ersichtlich war, wussten wir nicht, dass wir sie erreicht hatten. Was wir beobachteten, war eine sehr hohe Rate von DNS-Ausfällen, was wiederum zu sporadischen Verzögerungen an verschiedenen Stellen in unserer Architektur führte.
Wir stießen auf nicht dokumentierte praktische Grenzen der EC2-Instanzen, die wir für unser primäres DNS-Cluster verwendeten. Die Dimensionierung von Cloud-Instanzen basierend auf traditionellen Spezifikationen (Prozessor, Speicher usw.) funktioniert normalerweise wie erwartet, aber manchmal gilt dieses traditionelle Hardwaremodell nicht. Das ist besonders in atypischen Anwendungsfällen der Fall, in denen aggregierte Grenzen ins Spiel kommen können – und es gibt Zeiten, in denen man ohne Vorwarnung auf diese Szenarien stößt.
Wir stießen am Freitag auf eine solche Grenze, als unser DNS-Abfragevolumen ein Netzwerkbenutzungsmuster erzeugte, für das unser Instanztyp nicht vorbereitet war. Da diese Grenze jedoch weder in den Dokumenten noch in den verfügbaren Standardmetriken ersichtlich war, wussten wir nicht, dass wir sie erreicht hatten. Was wir beobachteten, war eine sehr hohe Rate von DNS-Ausfällen, was wiederum zu sporadischen Verzögerungen an verschiedenen Stellen in unserer Architektur führte.
Wir stießen auf nicht dokumentierte praktische Grenzen der EC2-Instanzen, die wir für unser primäres DNS-Cluster verwendeten. Die Dimensionierung von Cloud-Instanzen basierend auf traditionellen Spezifikationen (Prozessor, Speicher usw.) funktioniert normalerweise wie erwartet, aber manchmal gilt dieses traditionelle Hardwaremodell nicht. Das ist besonders in atypischen Anwendungsfällen der Fall, in denen aggregierte Grenzen ins Spiel kommen können – und es gibt Zeiten, in denen man ohne Vorwarnung auf diese Szenarien stößt.
Wir stießen am Freitag auf eine solche Grenze, als unser DNS-Abfragevolumen ein Netzwerkbenutzungsmuster erzeugte, für das unser Instanztyp nicht vorbereitet war. Da diese Grenze jedoch weder in den Dokumenten noch in den verfügbaren Standardmetriken ersichtlich war, wussten wir nicht, dass wir sie erreicht hatten. Was wir beobachteten, war eine sehr hohe Rate von DNS-Ausfällen, was wiederum zu sporadischen Verzögerungen an verschiedenen Stellen in unserer Architektur führte.
Tiefer in DNS eintauchen
Warum ist unsere DNS-Nutzung besonders? Nun, es hat viel mit der Funktionsweise von E-Mails zu tun, im Vergleich zum Inhaltsmodell, für das AWS ursprünglich entwickelt wurde. Webbasierte Inhaltsbereitstellung nutzt stark klassische eingehende „Pull“-Szenarien: ein Client fordert Daten an, sei es HTML, Videostreams oder etwas anderes, aus der Cloud. Aber die Anwendungsfälle für Messaging-Service-Provider wie SparkPost sind Ausnahmen vom üblichen AWS-Szenario. In unserem Fall schieben wir viel ausgehenden Traffic: speziell E-Mail (und andere Nachrichtentypen wie SMS oder mobile Push-Benachrichtigungen). Und dieser Push-artige Traffic verlässt sich stark auf DNS.
Wenn Sie mit DNS vertraut sind, wissen Sie vielleicht, dass es sich im Allgemeinen um relativ leichte Daten handelt. Um eine bestimmte HTML-Seite anzufordern, müssen Sie zuerst fragen, wo diese Seite im Internet zu finden ist, aber diese Anfrage ist nur ein Bruchteil der Größe des Inhalts, den Sie abrufen.
E-Mail nutzt jedoch DNS außergewöhnlich stark, um Lieferdomänen zu finden—zum Beispiel sendet SparkPost jeden Monat viele Milliarden E-Mails an über 1 Million einzigartige Domänen. Für jede E-Mail, die wir zustellen, müssen wir mindestens zwei DNS-Abfragen durchführen, und die Nutzung von DNS-„txt“-Records 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-Diensten für unsere Apps, und es ist schwer zu übertreiben, wie wichtig DNS für unsere Infrastruktur ist.
All dies bedeutet, dass wir auf eine ungewöhnliche Situation stießen, in der unser wachsendes Volumen an ausgehenden Nachrichten eine DNS-Datenverkehrsmenge erzeugte, die ein aggregiertes Netzwerk-Durchsatzlimit auf Instanztypen erreichte, die ansonsten ausreichend Ressourcen zu haben schienen, um diese Last zu bewältigen. Und wie Denial-of-Service-Angriffe auf die Dyn DNS-Infrastruktur im letzten Jahr gezeigt haben, wenn DNS ausfällt, bricht alles zusammen. (Das ist etwas, das jeder, der Systeme baut, die auf DNS angewiesen sind, schmerzlich gut weiß.)
Die plötzlichen DNS-Probleme lösten eine Reaktion unserer Betriebs- und Zuverlässigkeitsingenieurteams aus, um das Problem zu identifizieren. Sie arbeiteten mit unseren Partnern bei Amazon zusammen, um die Eskalation auf der AWS-Betriebsseite zu intensivieren. Gemeinsam identifizierten wir die Ursache und eine Lösung. Wir implementierten einen Cluster von Nameservern mit größerer Kapazität, der sich stärker auf die Netzwerkkapazität konzentriert, die unsere DNS-Anforderungen erfüllen könnte, ohne gegen die Durchsatzgrenzen zu verstoßen. Glücklicherweise, da all dies innerhalb von AWS geschah, konnten wir die neuen Instanzen schnell hochfahren und sogar vorhandene Instanzen schnell umskalieren. DNS verhielt sich wieder normal, Abfrageausfälle hörten auf, und wir (und die Auslieferung von ausgehenden Nachrichten) waren wieder auf Kurs.
Um künftige ähnliche Probleme zu mindern, nehmen wir auch Änderungen an der DNS-Architektur vor, um unsere Kernkomponenten besser vor den Auswirkungen von ähnlichen, unerwarteten Schwellenwerten zu isolieren. Wir arbeiten auch mit dem Amazon-Team zusammen, um geeignete Überwachungsmodelle zu bestimmen, die uns ausreichende Warnungen geben, um ein ähnliches Ereignis abzufangen, bevor es unsere Kunden beeinträchtigt.
Thema | Typische AWS-Workload | SparkPost’s Outbound Email Workload |
|---|---|---|
Datenverkehrsmuster | Meist eingehende „Pull“-Anfragen (Webseiten, APIs, Medien) | Schwerlastiger ausgehender „Push“-Verkehr (Milliarden von E-Mails) |
DNS-Abhängigkeit | Leicht: 1–2 Abfragen pro Inhaltsanfrage | Sehr schwer: mehrere DNS-Abfragen pro E-Mail + SPF/DKIM TXT-Überprüfungen |
Abfragevolumen | Vorhersehbar und proportional zur Benutzeraktivität | Explodiert mit ausgehenden Kampagnen, die auf Millionen von Domänen abzielen |
Engpassart | CPU, Speicherkapazität oder Speichergrenzen | Aggregierte Netzwerk-Durchsatzlimits auf Instanztypen |
Fehlermodus | Verschlechterte Latenz oder API-Timeout | DNS-Abfragefehler, die Lieferverzögerungen verursachen |
Sichtbarkeit | Grenzen typischerweise dokumentiert und in Metriken sichtbar | Durchsatzgrenze war undokumentiert und unsichtbar in CloudWatch |
Minderungsansatz | Instanzressourcen skalieren oder Caching hinzufügen | Umstieg auf Instanzfamilien mit höherer Bandbreite + DNS-Architektur-Neugestaltung |
Warum ist unsere DNS-Nutzung besonders? Nun, es hat viel mit der Funktionsweise von E-Mails zu tun, im Vergleich zum Inhaltsmodell, für das AWS ursprünglich entwickelt wurde. Webbasierte Inhaltsbereitstellung nutzt stark klassische eingehende „Pull“-Szenarien: ein Client fordert Daten an, sei es HTML, Videostreams oder etwas anderes, aus der Cloud. Aber die Anwendungsfälle für Messaging-Service-Provider wie SparkPost sind Ausnahmen vom üblichen AWS-Szenario. In unserem Fall schieben wir viel ausgehenden Traffic: speziell E-Mail (und andere Nachrichtentypen wie SMS oder mobile Push-Benachrichtigungen). Und dieser Push-artige Traffic verlässt sich stark auf DNS.
Wenn Sie mit DNS vertraut sind, wissen Sie vielleicht, dass es sich im Allgemeinen um relativ leichte Daten handelt. Um eine bestimmte HTML-Seite anzufordern, müssen Sie zuerst fragen, wo diese Seite im Internet zu finden ist, aber diese Anfrage ist nur ein Bruchteil der Größe des Inhalts, den Sie abrufen.
E-Mail nutzt jedoch DNS außergewöhnlich stark, um Lieferdomänen zu finden—zum Beispiel sendet SparkPost jeden Monat viele Milliarden E-Mails an über 1 Million einzigartige Domänen. Für jede E-Mail, die wir zustellen, müssen wir mindestens zwei DNS-Abfragen durchführen, und die Nutzung von DNS-„txt“-Records 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-Diensten für unsere Apps, und es ist schwer zu übertreiben, wie wichtig DNS für unsere Infrastruktur ist.
All dies bedeutet, dass wir auf eine ungewöhnliche Situation stießen, in der unser wachsendes Volumen an ausgehenden Nachrichten eine DNS-Datenverkehrsmenge erzeugte, die ein aggregiertes Netzwerk-Durchsatzlimit auf Instanztypen erreichte, die ansonsten ausreichend Ressourcen zu haben schienen, um diese Last zu bewältigen. Und wie Denial-of-Service-Angriffe auf die Dyn DNS-Infrastruktur im letzten Jahr gezeigt haben, wenn DNS ausfällt, bricht alles zusammen. (Das ist etwas, das jeder, der Systeme baut, die auf DNS angewiesen sind, schmerzlich gut weiß.)
Die plötzlichen DNS-Probleme lösten eine Reaktion unserer Betriebs- und Zuverlässigkeitsingenieurteams aus, um das Problem zu identifizieren. Sie arbeiteten mit unseren Partnern bei Amazon zusammen, um die Eskalation auf der AWS-Betriebsseite zu intensivieren. Gemeinsam identifizierten wir die Ursache und eine Lösung. Wir implementierten einen Cluster von Nameservern mit größerer Kapazität, der sich stärker auf die Netzwerkkapazität konzentriert, die unsere DNS-Anforderungen erfüllen könnte, ohne gegen die Durchsatzgrenzen zu verstoßen. Glücklicherweise, da all dies innerhalb von AWS geschah, konnten wir die neuen Instanzen schnell hochfahren und sogar vorhandene Instanzen schnell umskalieren. DNS verhielt sich wieder normal, Abfrageausfälle hörten auf, und wir (und die Auslieferung von ausgehenden Nachrichten) waren wieder auf Kurs.
Um künftige ähnliche Probleme zu mindern, nehmen wir auch Änderungen an der DNS-Architektur vor, um unsere Kernkomponenten besser vor den Auswirkungen von ähnlichen, unerwarteten Schwellenwerten zu isolieren. Wir arbeiten auch mit dem Amazon-Team zusammen, um geeignete Überwachungsmodelle zu bestimmen, die uns ausreichende Warnungen geben, um ein ähnliches Ereignis abzufangen, bevor es unsere Kunden beeinträchtigt.
Thema | Typische AWS-Workload | SparkPost’s Outbound Email Workload |
|---|---|---|
Datenverkehrsmuster | Meist eingehende „Pull“-Anfragen (Webseiten, APIs, Medien) | Schwerlastiger ausgehender „Push“-Verkehr (Milliarden von E-Mails) |
DNS-Abhängigkeit | Leicht: 1–2 Abfragen pro Inhaltsanfrage | Sehr schwer: mehrere DNS-Abfragen pro E-Mail + SPF/DKIM TXT-Überprüfungen |
Abfragevolumen | Vorhersehbar und proportional zur Benutzeraktivität | Explodiert mit ausgehenden Kampagnen, die auf Millionen von Domänen abzielen |
Engpassart | CPU, Speicherkapazität oder Speichergrenzen | Aggregierte Netzwerk-Durchsatzlimits auf Instanztypen |
Fehlermodus | Verschlechterte Latenz oder API-Timeout | DNS-Abfragefehler, die Lieferverzögerungen verursachen |
Sichtbarkeit | Grenzen typischerweise dokumentiert und in Metriken sichtbar | Durchsatzgrenze war undokumentiert und unsichtbar in CloudWatch |
Minderungsansatz | Instanzressourcen skalieren oder Caching hinzufügen | Umstieg auf Instanzfamilien mit höherer Bandbreite + DNS-Architektur-Neugestaltung |
Warum ist unsere DNS-Nutzung besonders? Nun, es hat viel mit der Funktionsweise von E-Mails zu tun, im Vergleich zum Inhaltsmodell, für das AWS ursprünglich entwickelt wurde. Webbasierte Inhaltsbereitstellung nutzt stark klassische eingehende „Pull“-Szenarien: ein Client fordert Daten an, sei es HTML, Videostreams oder etwas anderes, aus der Cloud. Aber die Anwendungsfälle für Messaging-Service-Provider wie SparkPost sind Ausnahmen vom üblichen AWS-Szenario. In unserem Fall schieben wir viel ausgehenden Traffic: speziell E-Mail (und andere Nachrichtentypen wie SMS oder mobile Push-Benachrichtigungen). Und dieser Push-artige Traffic verlässt sich stark auf DNS.
Wenn Sie mit DNS vertraut sind, wissen Sie vielleicht, dass es sich im Allgemeinen um relativ leichte Daten handelt. Um eine bestimmte HTML-Seite anzufordern, müssen Sie zuerst fragen, wo diese Seite im Internet zu finden ist, aber diese Anfrage ist nur ein Bruchteil der Größe des Inhalts, den Sie abrufen.
E-Mail nutzt jedoch DNS außergewöhnlich stark, um Lieferdomänen zu finden—zum Beispiel sendet SparkPost jeden Monat viele Milliarden E-Mails an über 1 Million einzigartige Domänen. Für jede E-Mail, die wir zustellen, müssen wir mindestens zwei DNS-Abfragen durchführen, und die Nutzung von DNS-„txt“-Records 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-Diensten für unsere Apps, und es ist schwer zu übertreiben, wie wichtig DNS für unsere Infrastruktur ist.
All dies bedeutet, dass wir auf eine ungewöhnliche Situation stießen, in der unser wachsendes Volumen an ausgehenden Nachrichten eine DNS-Datenverkehrsmenge erzeugte, die ein aggregiertes Netzwerk-Durchsatzlimit auf Instanztypen erreichte, die ansonsten ausreichend Ressourcen zu haben schienen, um diese Last zu bewältigen. Und wie Denial-of-Service-Angriffe auf die Dyn DNS-Infrastruktur im letzten Jahr gezeigt haben, wenn DNS ausfällt, bricht alles zusammen. (Das ist etwas, das jeder, der Systeme baut, die auf DNS angewiesen sind, schmerzlich gut weiß.)
Die plötzlichen DNS-Probleme lösten eine Reaktion unserer Betriebs- und Zuverlässigkeitsingenieurteams aus, um das Problem zu identifizieren. Sie arbeiteten mit unseren Partnern bei Amazon zusammen, um die Eskalation auf der AWS-Betriebsseite zu intensivieren. Gemeinsam identifizierten wir die Ursache und eine Lösung. Wir implementierten einen Cluster von Nameservern mit größerer Kapazität, der sich stärker auf die Netzwerkkapazität konzentriert, die unsere DNS-Anforderungen erfüllen könnte, ohne gegen die Durchsatzgrenzen zu verstoßen. Glücklicherweise, da all dies innerhalb von AWS geschah, konnten wir die neuen Instanzen schnell hochfahren und sogar vorhandene Instanzen schnell umskalieren. DNS verhielt sich wieder normal, Abfrageausfälle hörten auf, und wir (und die Auslieferung von ausgehenden Nachrichten) waren wieder auf Kurs.
Um künftige ähnliche Probleme zu mindern, nehmen wir auch Änderungen an der DNS-Architektur vor, um unsere Kernkomponenten besser vor den Auswirkungen von ähnlichen, unerwarteten Schwellenwerten zu isolieren. Wir arbeiten auch mit dem Amazon-Team zusammen, um geeignete Überwachungsmodelle zu bestimmen, die uns ausreichende Warnungen geben, um ein ähnliches Ereignis abzufangen, bevor es unsere Kunden beeinträchtigt.
Thema | Typische AWS-Workload | SparkPost’s Outbound Email Workload |
|---|---|---|
Datenverkehrsmuster | Meist eingehende „Pull“-Anfragen (Webseiten, APIs, Medien) | Schwerlastiger ausgehender „Push“-Verkehr (Milliarden von E-Mails) |
DNS-Abhängigkeit | Leicht: 1–2 Abfragen pro Inhaltsanfrage | Sehr schwer: mehrere DNS-Abfragen pro E-Mail + SPF/DKIM TXT-Überprüfungen |
Abfragevolumen | Vorhersehbar und proportional zur Benutzeraktivität | Explodiert mit ausgehenden Kampagnen, die auf Millionen von Domänen abzielen |
Engpassart | CPU, Speicherkapazität oder Speichergrenzen | Aggregierte Netzwerk-Durchsatzlimits auf Instanztypen |
Fehlermodus | Verschlechterte Latenz oder API-Timeout | DNS-Abfragefehler, die Lieferverzögerungen verursachen |
Sichtbarkeit | Grenzen typischerweise dokumentiert und in Metriken sichtbar | Durchsatzgrenze war undokumentiert und unsichtbar in CloudWatch |
Minderungsansatz | Instanzressourcen skalieren oder Caching hinzufügen | Umstieg auf Instanzfamilien mit höherer Bandbreite + DNS-Architektur-Neugestaltung |
AWS und das Silberstreif am Horizont 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 in sehr kurzer Zeit eine Lösung dafür zu finden – hat viel damit zu tun, wie wir SparkPost aufgebaut haben und unsere großartige Beziehung zum Amazon-Team.
Das hervorragende Operations-Korps von SparkPost, unser Site Reliability Engineering (SRE)-Team und unsere leitenden technischen Architekten arbeiten täglich mit Amazon zusammen. Die Stärken der AWS-Infrastruktur haben uns einen echten Vorteil verschafft, SparkPosts Architektur für die Cloud zu optimieren. Die enge Zusammenarbeit mit AWS in den letzten zwei Jahren hat uns auch viel darüber gelehrt, wie man AWS-Infrastruktur schnell bereitstellt und betreibt, und wir profitieren auch von der tiefen 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 ausgerichtet 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-Zustelldienst, 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 Cloud-Infrastruktur gestalten, um Skalierbarkeit und Zuverlässigkeit für Entwickler zu gewährleisten. Wir senden mehr E-Mails 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 auf sie trifft. Wir haben eine auf 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 Ihre eigene Infrastruktur auf AWS aufbauen oder als SparkPost-Kunde von unserer profitieren, ich hoffe, dass diese Erklärung dessen, was letzten Freitag geschehen ist, und wie wir es gelöst haben, nützlich war.
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 in sehr kurzer Zeit eine Lösung dafür zu finden – hat viel damit zu tun, wie wir SparkPost aufgebaut haben und unsere großartige Beziehung zum Amazon-Team.
Das hervorragende Operations-Korps von SparkPost, unser Site Reliability Engineering (SRE)-Team und unsere leitenden technischen Architekten arbeiten täglich mit Amazon zusammen. Die Stärken der AWS-Infrastruktur haben uns einen echten Vorteil verschafft, SparkPosts Architektur für die Cloud zu optimieren. Die enge Zusammenarbeit mit AWS in den letzten zwei Jahren hat uns auch viel darüber gelehrt, wie man AWS-Infrastruktur schnell bereitstellt und betreibt, und wir profitieren auch von der tiefen 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 ausgerichtet 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-Zustelldienst, 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 Cloud-Infrastruktur gestalten, um Skalierbarkeit und Zuverlässigkeit für Entwickler zu gewährleisten. Wir senden mehr E-Mails 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 auf sie trifft. Wir haben eine auf 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 Ihre eigene Infrastruktur auf AWS aufbauen oder als SparkPost-Kunde von unserer profitieren, ich hoffe, dass diese Erklärung dessen, was letzten Freitag geschehen ist, und wie wir es gelöst haben, nützlich war.
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 in sehr kurzer Zeit eine Lösung dafür zu finden – hat viel damit zu tun, wie wir SparkPost aufgebaut haben und unsere großartige Beziehung zum Amazon-Team.
Das hervorragende Operations-Korps von SparkPost, unser Site Reliability Engineering (SRE)-Team und unsere leitenden technischen Architekten arbeiten täglich mit Amazon zusammen. Die Stärken der AWS-Infrastruktur haben uns einen echten Vorteil verschafft, SparkPosts Architektur für die Cloud zu optimieren. Die enge Zusammenarbeit mit AWS in den letzten zwei Jahren hat uns auch viel darüber gelehrt, wie man AWS-Infrastruktur schnell bereitstellt und betreibt, und wir profitieren auch von der tiefen 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 ausgerichtet 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-Zustelldienst, 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 Cloud-Infrastruktur gestalten, um Skalierbarkeit und Zuverlässigkeit für Entwickler zu gewährleisten. Wir senden mehr E-Mails 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 auf sie trifft. Wir haben eine auf 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 Ihre eigene Infrastruktur auf AWS aufbauen oder als SparkPost-Kunde von unserer profitieren, ich hoffe, dass diese Erklärung dessen, was letzten Freitag geschehen ist, und wie wir es gelöst haben, nützlich war.
