Des bases de données 50 % plus performantes et migration vers Mailgun.com

Après quelques semaines passées à déployer de nouvelles fonctionnalités très demandées concernant les webhooks, nous nous sommes penchés sur des éléments moins visibles pour que Mailgun reste au top. Plus précisément, nous avons réduit de 50 % le nombre de requêtes par seconde sur notre instance MongoDB principale. Cela permet d’augmenter les performances de Mailgun et de faciliter sa mise à l’échelle pour accompagner notre croissance. Nous ne fonctionnons plus qu’à 10 % de notre capacité maximale et pouvons gérer sereinement les pics de trafic géants, que nous rencontrons de plus en plus au fil de notre croissance, sans augmentation notable de la latence. Nous avons également redirigé tous les vestiges de mailgun.net de notre documentation et de notre panneau de configuration vers mailgun.com, ce qui accélérera nos futurs développements.

Cette semaine, nous avons travaillé à améliorer les performances des bases de données de notre application principale. Lorsque les clients envoient et reçoivent des emails via Mailgun, notre base de données MongoDB principale est constamment interrogée. Cependant, les bases de données ne peuvent pas évoluer à l’infini. Nous cherchons donc toujours à améliorer leurs performances et à faire plus avec moins.

En examinant les requêtes arrivant dans MongoDB, nous avons réalisé qu’en utilisant Redis pour mettre en cache une valeur spécifique (Redis est excellent pour la mise en cache), nous pourrions réduire considérablement le nombre de requêtes. Jetez un œil à ce graphique illustrant la période juste avant et après la mise en place du cache. Nous avons pu faire passer le nombre moyen de requêtes par seconde de 13 000 – 15 000 (avec des pics à 20 000 ou plus) à 4 000 – 6 000. Cela signifie que nous pouvons gérer plus facilement les énormes pics d’emails envoyés par nos chers clients.

C’est un fait peu connu (surtout parce que personne ne l’a jamais demandé !) : lors du lancement de Mailgun, mailgun.com n’était pas disponible. Nous avons donc commencé avec mailgun.net comme domaine principal, avant d’acheter par la suite le TLD .com également. L’exploitation de deux domaines différents (mailgun.com pour notre site Web principal et mailgun.net pour notre documentation, notre panneau de configuration et notre API) a été un véritable casse-tête et semait la confusion auprès des clients. Les tâches simples, comme la mise en œuvre de Google Analytics pour suivre l’utilisation du produit, ont été excessivement complexes. Elles nécessitaient du code supplémentaire pour suivre les actions les plus basiques sur notre produit. Il est donc difficile de comprendre ce que les clients apprécient ou non dans Mailgun. Et plus important encore, cela ampute le temps dont dispose l’équipe d’ingénierie pour développer tout ce que les clients demandent. Que cela serve de leçon à toutes les startups : choisissez un seul domaine et tenez-vous-y ! Sinon, vous passerez votre temps à lutter pour comprendre ce que font vos utilisateurs sur votre application. Le suivi inter-domaines n’est jamais aussi simple qu’on voudrait vous le faire croire.

Lorsque nous avons commencé à nous pencher sur cette migration, voici à quoi nous voulions que le code ressemble pour la redirection 301 de toutes les pages .net vers la page .com équivalente (nous devions faire une redirection 301 pour que Google et les autres moteurs de recherche transfèrent le capital lien accumulé au fil des ans, c’est une question de SEO) :

                                

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

    charset utf-8;

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

Cependant, en raison de la structure de Mailgun, il y avait un certain nombre de cas particuliers à gérer et les choses se sont compliquées. Plutôt que de faire du bricolage et de passer à autre chose, nous avons décidé de restructurer la façon dont les utilisateurs interagissent avec Mailgun via notre site Web et notre API. Cela permet de réduire le nombre d’éléments mobiles et de diminuer le risque d’introduire un bug auquel nous n’aurions pas pensé. Mais nous ne voulions pas que les utilisateurs aient à faire quoi que ce soit eux-mêmes, pas même modifier leurs favoris, et encore moins leur code

Depuis que nous avons rejoint Rackspace en août 2012, nous avons obtenu beaucoup de nouveaux jouets très sympas avec lesquels nous amuser, notamment les Dell R720 qui font tourner nos principaux processus API et SMTP (cette bête de serveur mérite un article de blog à part entière et nous espérons l’écrire bientôt). Nous avons également exploré le Rackspace Cloud et décidé de diviser Mailgun en deux parties dans le cadre de notre refonte.

• Les processus front-end tels que le site Web, le panneau de configuration et la documentation fonctionnent sur des serveurs Rackspace Cloud, derrière un Rackspace Cloud Load Balancer pour faciliter considérablement la mise à l’échelle. L’ajout de nouveaux nœuds ne nécessite que quelques simples appels d’API.
• Les processus back-end principaux tels que l’API et le SMTP fonctionnent sur des Dell R720 derrière un équilibreur de charge F5 (nous espérons visiter le centre de données Rackspace où se trouvent ces machines cet été pour nous prosterner devant leur puissance brute).

Structurer Mailgun de cette façon nous a permis de réduire nos configurations Nginx de 393 à 261 lignes de code. Une belle amélioration. Tu nous manqueras mailgun.net, mais nous nous reverrons en utilisant l’API qui reste sur

https://api.mailgun.net/v2

C’est tout pour cette semaine.

Rendez-vous la semaine prochaine pour découvrir d’autres projets sur lesquels nous avons travaillé.

Bons envois d’emails.

L’équipe Mailgun

Auteur·trice: 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!