Mailgun-Post-mortem Mai 2016

Dieser Bericht wurde ursprünglich am 31. Mai 2016 veröffentlicht.

Bei Mailgun kam es kürzlich zu mehreren voneinander unabhängigen Vorfällen, die die Verfügbarkeit unserer Dienste beeinträchtigten. Wir möchten diese Gelegenheit nutzen, um unseren Kunden die Ursachen dieser Vorfälle transparent darzulegen. Außerdem möchten wir im Detail erläutern, welche Maßnahmen wir ergriffen haben, um diese zu beheben und sicherzustellen, dass sie in Zukunft nicht mehr auftreten.

Mailgun ist häufig das Ziel von großen und vielfältigen Distributed-Denial-of-Service-Angriffen (DDoS-Angriffen). Während viele Angriffe mit minimalen Unterbrechungen abgewehrt werden, kam es zu einigen Vorfällen mit längeren Auswirkungen auf unsere Dienste. Insbesondere richtete sich ein Angriff am 23. Mai gegen Teile unseres primären Rechenzentrums. Die Angriffsmethode war so ungewöhnlich, dass unser Hosting-Anbieter fast eine Stunde benötigte, um den Angriff zuverlässig zu identifizieren und die entsprechenden Gegenmaßnahmen einzuleiten, mit denen wir unsere Dienste zu 100 % wiederherstellen konnten.

Bereits zu Beginn des Monats stellten wir fest, dass unsere Kunden bei der Nutzung der Mailgun-API und des SMTP-Dienstes zunehmend von ungewöhnlichen Timeouts betroffen waren. Als die Zahl der Berichte zu diesem Problem zunahm, wurde deutlich, dass ein systemisches Problem mit unserem Dienst vorlag.

Wir unterhalten verschiedene Systeme zur Überwachung von Durchsatz und Latenz in unserem Dienst, aber unsere eigenen Daten stimmten nicht mit den Erfahrungen unserer Kunden überein. Nachdem wir die Untersuchung unserer Anwendung abgeschlossen hatten, leiteten wir dieses Problem an unseren Hosting-Anbieter weiter. Dieser sollte unsere Netzwerkinfrastruktur überprüfen, um festzustellen, ob ein Problem bei unserem verwalteten Load-Balancer oder anderen Netzwerkgeräten vorliegt.

Die ersten Fehlerbehebungsversuche blieben ohne Ergebnis, da das Problem nur zeitweilig auftrat und schwer zu reproduzieren war. Nach mehreren Versuchen konnten wir schließlich bestätigen, dass die betroffenen Anfragen unser Edge-Netzwerkgerät gar nicht erst erreichten. Daraufhin untersuchten wir die vorgeschalteten Geräte im Netzwerk.

Wir überprüften das Gerät, das unsere Infrastruktur vor DDoS-Angriffen schützt. Dabei stellten wir fest, dass sich die Timeouts bei deaktiviertem Gerät nicht mehr reproduzieren ließen. Wir begannen sofort mit der Untersuchung, um die möglichen Ursachen zu verstehen. Nach der Analyse gemeinsam mit dem DDoS-Team unseres Hosting-Anbieters fanden wir heraus, dass unser System zur DDoS-Abwehr den legitimen Datenverkehr beeinträchtigte. Nachdem wir unsere Gegenmaßnahmen angepasst hatten, konnten wir diese Fehler beheben.

Mailgun gibt einen 421-Fehler zurück, wenn wir eine Nachricht nicht erfolgreich in die Warteschlange einreihen können. Diese Fehlermeldung dient dazu, den Nutzer darüber zu informieren, dass die Nachricht nicht von Mailgun empfangen wurde und ein erneuter Versuch zu einem späteren Zeitpunkt erfolgen sollte. Dies ist ein normaler Bestandteil von SMTP und signalisiert dem Absender, den Nachrichtenversand mit einer Verzögerung erneut zu versuchen.

Letzte Woche stellten wir fest, dass vermehrt 421-Fehler zurückgegeben wurden. Die Ursache für diesen Fehler war ein Leistungsabfall bei unseren Cassandra-Clustern, in denen wir Nachrichten dauerhaft speichern.

Die Ursache für die Leistungsprobleme lag an einem Compaction-Bug in der von uns verwendeten Cassandra-Version. Dieser führte dazu, dass Komprimierungsprozesse ins Stocken gerieten, I/O-Spitzenwerte auf den Festplatten entstanden und der gesamte Durchsatz von Cassandra sank. Solange sich der Cluster in diesem Zustand befand, konnten wir zeitweilig keine Nachrichten speichern, was zu den 421-Fehlern führte.

1. Warnungen – Obwohl unser System zur DDoS-Abwehr in vielen Fällen keine Störungen verursacht, haben wir gelernt, dass es für das Engineering-Team von Mailgun wichtig ist, zu wissen, wann das System aktiviert wird. Mithilfe dieser Daten können wir besser nachvollziehen, ob Probleme durch diese Schutzmaßnahmen verursacht werden oder nicht. Wir haben bereits mit unserem Hosting-Anbieter zusammengearbeitet, um ein Warnsystem bereitzustellen, das unser Technikteam alarmiert, wenn diese Schutzmaßnahmen aktiviert werden.
2. Abwehrprofile – Wir passen unsere DDoS-Abwehrprofile an, um unsere Verteidigungsposition zu stärken und gleichzeitig die Auswirkungen auf den legitimen Datenverkehr zu minimieren. Wir arbeiten bei der Entwicklung dieser Profile mit unserem Hosting-Anbieter zusammen und gehen davon aus, dass wir diese Arbeit noch diese Woche abschließen werden.
3. Cassandra-Upgrade – Wir haben mit der Durchführung rollierender Upgrades unserer Cassandra-Cluster begonnen. Damit nehmen wir ein Upgrade auf eine Version vor, die nicht vom Cassandra-Compaction-Bug betroffen ist. Zudem haben wir Konfigurationsanpassungen vorgenommen, die besser für diese Art von Arbeitslast geeignet sind.
4. Infrastrukturdesign – Wir sind dabei, die zugrunde liegende Mailgun-Infrastruktur neu zu gestalten. Diese Maßnahme wird uns eine robustere Netzwerk- und Bereitstellungsstruktur verschaffen, wodurch die Auswirkungen ähnlicher Angriffe verringert werden. Diese Arbeiten sind bereits im Gange, und wir werden in Zukunft weitere Details dazu mitteilen.

Auch wenn wir wissen, dass solche Vorfälle eine Herausforderung darstellen, setzt das Mailgun-Team alles daran, sich auf die oben genannten Maßnahmen und alle weiteren notwendigen Schritte zu konzentrieren. So stellen wir sicher, dass Sie sich bei Ihrer E-Mail-Zustellung weiterhin auf Mailgun verlassen können.

Autor: Josh Odom Josh Odom is President of the CPaaS unit at Sinch. Previously, he acted as Chief Technology Officer of Mailgun, and the Senior Product and Engineering leader at Rackspace. He covers a variety of topics for the blog from incidents and data security to product growth.