Un rendimiento de base de datos un 50 % mejor y el cambio a Mailgun.com

Después de unas semanas implementando algunas funciones nuevas muy solicitadas relacionadas con webhooks, hemos trabajado en algunas cosas menos visibles para mantener Mailgun a punto para ti. En concreto, hemos reducido en un 50 % el número de consultas por segundo en nuestra instancia principal de MongoDB, lo que aumenta el rendimiento de Mailgun y facilita el escalado a medida que crecemos. Ahora operamos a solo el 10 % de nuestra capacidad máxima y podemos gestionar sin problemas los enormes picos de tráfico, cada vez más frecuentes a medida que crecemos, sin un aumento notable en la latencia. También hemos redirigido todos los vestigios de mailgun.net en nuestra documentación y panel de control a mailgun.com, lo que agiliza nuestros futuros esfuerzos de desarrollo.

Esta semana hemos trabajado para lograr un mayor rendimiento en las bases de datos principales de nuestra aplicación. Cuando nuestra clientela envía y recibe emails a través de Mailgun, nuestra instancia principal de MongoDB recibe consultas constantemente. Sin embargo, las bases de datos no pueden escalar infinitamente, así que siempre intentamos mejorar el rendimiento y hacer más con menos.

Al examinar las consultas que llegaban a MongoDB, nos dimos cuenta de que si usábamos Redis para almacenar en caché un valor en particular (Redis es genial para esto), podríamos reducir drásticamente el número de consultas. Echa un vistazo a este gráfico de un periodo directamente anterior y posterior a la implementación de la caché. Logramos disminuir el promedio de consultas por segundo de entre 13 000 y 15 000 (con picos de 20 000 o más) a entre 4000 y 6000. Esto significa que podemos gestionar con mayor facilidad los enormes picos de emails enviados por nuestra querida clientela.

Es un dato poco conocido (¡sobre todo porque nadie lo había preguntado!) que cuando se lanzó Mailgun, mailgun.com no estaba disponible. Así que empezamos con mailgun.net como nuestro dominio principal y tiempo después compramos también el TLD .com. Operar con dos dominios diferentes (mailgun.com para nuestro sitio web principal y mailgun.net para nuestra documentación y panel de control, además de para la API) ha sido un verdadero dolor de cabeza y resultaba confuso para la clientela. Tareas sencillas, como implementar Google Analytics para hacer un seguimiento del uso del producto, han sido demasiado complicadas al requerir código adicional para registrar las acciones más básicas sobre nuestro producto. Esto dificulta entender qué le gusta a la clientela de Mailgun y qué no. Y, lo que es más importante, quita tiempo de ingeniería para todo lo que pide la clientela. Que esto sirva de lección a cualquier startup: ¡elige un dominio y quédate con él! De lo contrario, tendrás que luchar constantemente para entender lo que hace tu base de usuarios en toda tu aplicación. El seguimiento multidominio nunca es tan fácil como te quieren hacer creer.

Cuando empezamos a plantearnos esta migración, así queríamos que fuera el código para la redirección 301 de todas las páginas .net a sus equivalentes .com (necesitábamos hacer una redirección 301 para que Google y otros motores de búsqueda transmitieran la autoridad de enlaces acumulada a lo largo de los años; es algo de SEO):

                                

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

    charset utf-8;

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

Sin embargo, debido a la estructura de Mailgun, hubo una serie de casos extremos que abordar y las cosas se complicaron. En lugar de hacer un apaño y pasar a lo siguiente, decidimos reestructurar la forma en que la base de usuarios interactúa con Mailgun a través de nuestro sitio web y API. De esta forma, redujimos el número de piezas móviles y la probabilidad de introducir algún error en el que no hubiéramos pensado. Pero no queríamos que la base de usuarios tuviera que hacer nada por sí misma, ni siquiera cambiar sus marcadores, y mucho menos su código.

Desde que nos unimos a Rackspace allá por agosto de 2012, hemos conseguido muchos juguetes geniales con los que trastear, incluidos los servidores Dell R720 que ejecutan nuestros procesos principales de API & SMTP (esta bestia de servidor merece todo un artículo de blog por sí sola y esperamos escribirlo pronto). También hemos experimentado con Rackspace Cloud y decidimos dividir Mailgun en dos partes como parte de nuestra refactorización.

• Procesos del front-end como el sitio web, el panel de control y la documentación ejecutándose en servidores de Rackspace Cloud, detrás de un equilibrador de carga Rackspace Cloud Load Balancer para facilitar enormemente la escalabilidad. Añadir nuevos nodos requiere solo unas sencillas llamadas a la API.
• Procesos centrales del back-end como la API y SMTP ejecutándose en servidores Dell R720 detrás de un equilibrador de carga F5 (esperamos visitar el centro de datos de Rackspace donde se encuentran estas máquinas este verano para postrarnos ante su enorme potencia).

Estructurar Mailgun de este modo nos permitió acortar nuestras configuraciones de nginx de 393 a 261 líneas de código. No es una mala mejora. Te echaremos de menos, mailgun.net, pero aún nos veremos al usar la API, que se mantiene en

https://api.mailgun.net/v2

Eso es todo por esta semana.

No te pierdas nuestra próxima actualización, donde hablaremos de otras cosas en las que hemos estado trabajando.

Felices envíos.

El equipo de Mailgun

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!