50 % bessere Datenbankleistung und der Umzug zu Mailgun.com

Nachdem wir in den letzten Wochen einige häufig gewünschte neue Webhook-Funktionen eingeführt haben, widmeten wir uns weniger sichtbaren Dingen, um Mailgun für Sie auf dem neuesten Stand zu halten. Konkret haben wir die Anzahl der Abfragen pro Sekunde auf unserer primären MongoDB-Instanz um 50 % gesenkt. Dadurch wird die Leistung von Mailgun gesteigert und die Skalierung bei weiterem Wachstum vereinfacht. Wir arbeiten jetzt mit nur 10 % unserer maximalen Kapazität und bewältigen die enormen Traffic-Spitzen, die mit unserem Wachstum immer häufiger auftreten, problemlos ohne einen spürbaren Anstieg der Latenz. Außerdem haben wir alle Überreste von mailgun.net in unserer Dokumentation und im Control Panel auf mailgun.com umgeleitet, um zukünftige Entwicklungsarbeiten zu beschleunigen.

Diese Woche haben wir daran gearbeitet, die Leistung unserer primären Anwendungsdatenbanken zu verbessern. Wenn Kunden E-Mails über Mailgun senden und empfangen, wird unsere primäre MongoDB ununterbrochen abgefragt. Da Datenbanken jedoch nicht unendlich skalierbar sind, suchen wir ständig nach Möglichkeiten, die Leistung zu optimieren und mit weniger Aufwand mehr zu erreichen.

Bei der Untersuchung der MongoDB-Abfragen stellten wir fest, dass wir durch die Nutzung von Redis zum Zwischenspeichern eines bestimmten Wertes (Redis eignet sich hervorragend für das Caching) die Anzahl der Abfragen drastisch reduzieren können. Sehen Sie sich diese Grafik aus der Zeit direkt vor und nach der Implementierung des Cachings an. Wir konnten die durchschnittliche Anzahl der Abfragen pro Sekunde von 13.000–15.000 (mit Spitzenwerten von 20.000 oder mehr) auf 4.000–6.000 senken. Das bedeutet, dass wir die enormen Spitzen beim E-Mail-Versand durch unsere geschätzte Kundschaft noch besser bewältigen können.

Es ist eine wenig bekannte Tatsache (vor allem, weil nie jemand danach gefragt hat), dass mailgun.com beim Start von Mailgun noch nicht verfügbar war. Daher begannen wir mit mailgun.net als primärer Domain und kauften erst später auch die .com-TLD. Der Betrieb von zwei verschiedenen Domains – mailgun.com für unsere Haupt-Website und mailgun.net für unsere Dokumentation, das Control Panel sowie die API – war sehr mühsam und für unsere Kundschaft verwirrend. Einfache Aufgaben wie die Implementierung von Google Analytics zum Tracking der Produktnutzung waren übermäßig kompliziert und erforderten zusätzliches Coding, um die grundlegendsten Aktionen rund um unser Produkt zu erfassen. Dies erschwert es, nachzuvollziehen, was unserer Kundschaft an Mailgun gefällt und was nicht. Und am wichtigsten: Es kostet Entwicklungszeit, die für all die Dinge fehlt, welche unsere Kundschaft wünscht. Das sollte allen Start-ups da draußen eine Lehre sein: Wählen Sie eine Domain und bleiben Sie dabei. Andernfalls werden Sie ständig damit kämpfen, zu verstehen, was Ihre Nutzerschaft in Ihrer gesamten Anwendung tut. Cross-Domain-Tracking ist nie so einfach, wie man Sie glauben machen möchte.

Als wir begannen, uns mit dieser Migration zu beschäftigen, sollte der Code für die 301-Weiterleitung aller .net-Seiten auf die entsprechende .com-Seite folgendermaßen aussehen (wir mussten eine 301-Weiterleitung einrichten, damit Google und andere Suchmaschinen den über die Jahre aufgebauten Link-Wert weitergeben – das ist eine SEO-Sache):

                                

                                    server {  
    listen       80;
    server_name  ~^.*$;

    charset utf-8;

    location / {
        rewrite ^ http://mailgun.com$request_uri? permanent;
    }
}
                                
                            

Aufgrund der Struktur von Mailgun gab es jedoch eine Reihe von Randfällen zu berücksichtigen, und die Sache wurde kompliziert. Anstatt eine schnelle Notlösung zu basteln und zum nächsten Punkt überzugehen, haben wir uns entschlossen, die Art und Weise neu zu strukturieren, wie unsere Nutzerschaft über unsere Website und API mit Mailgun interagiert. Dadurch wird die Anzahl der beweglichen Teile reduziert und die Wahrscheinlichkeit verringert, einen Bug einzubauen, an den wir nicht gedacht haben. Wir wollten jedoch nicht, dass unsere Nutzerschaft selbst aktiv werden muss – nicht einmal zum Ändern ihrer Lesezeichen, ganz zu schweigen von ihrem Code.

Seit wir im August 2012 zu Rackspace gekommen sind, haben wir viele wirklich großartige Spielzeuge bekommen, darunter die Dell R720-Server, auf denen unsere primären API- und SMTP-Prozesse laufen (dieses Server-Biest verdient einen eigenen Blog-Beitrag, den wir hoffentlich bald verfassen werden). Wir haben auch mit der Rackspace Cloud experimentiert und beschlossen, Mailgun im Zuge unseres Refactorings in zwei Teile aufzuspalten.

• Front-End-Prozesse wie Website, Control Panel und Dokumentation, die auf Rackspace Cloud-Servern hinter einem Rackspace Cloud-Load-Balancer laufen, um die Skalierung sehr einfach zu gestalten. Das Hinzufügen neuer Nodes erfordert nur einige wenige API-Aufrufe.
• Zentrale Back-End-Prozesse wie API und SMTP, die auf Dell R720-Servern hinter einem F5-Load-Balancer laufen (wir hoffen, in diesem Sommer das Rackspace-Rechenzentrum zu besuchen, in dem diese Maschinen stehen, um uns vor ihrer enormen Leistung zu verneigen).

Durch diese Strukturierung von Mailgun konnten wir unsere Nginx-Konfigurationen von 393 auf 261 Codezeilen verkürzen. Keine schlechte Verbesserung. Wir werden dich vermissen, mailgun.net, sehen uns aber weiterhin bei der Nutzung der API, die hier bleibt:

https://api.mailgun.net/v2

Das war’s für diese Woche.

Bleiben Sie dran, denn nächste Woche sprechen wir über weitere Dinge, an denen wir gearbeitet haben.

Viel Erfolg beim E-Mail-Versand.

Ihr Mailgun-Team

Autor: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!