Análisis post mortem de Mailgun de mayo de 2016

Este informe se publicó originalmente el 31 de mayo de 2016.

Recientemente, Mailgun ha sufrido varios incidentes independientes que han afectado a la disponibilidad de nuestros servicios. Queremos aprovechar esta oportunidad para explicar a nuestros clientes la causa raíz de estos incidentes, así como los detalles de lo que hemos hecho para solucionarlos y asegurarnos de que no vuelvan a ocurrir en el futuro.

Mailgun es con frecuencia el objetivo de grandes y variados ataques distribuidos de denegación de servicio (DDoS). Aunque muchos ataques se bloquean con una interrupción mínima, hemos sufrido varios incidentes con un impacto prolongado en nuestros servicios. En concreto, un ataque del 23 de mayo se dirigió a partes de nuestro centro de datos principal y el método del ataque fue tan peculiar que nuestro proveedor de alojamiento necesitó casi una hora para identificarlo de manera efectiva y desplegar las mitigaciones adecuadas que nos permitieron restablecer los servicios al 100 %.

A principios de mes, observamos un aumento constante de clientes que experimentaban tiempos de espera anormales al utilizar el servicio API/SMTP de Mailgun. A medida que aumentaba el número de informes sobre este problema, quedó claro que había un fallo sistémico en nuestro servicio.

Mantenemos varios sistemas diferentes para supervisar el rendimiento y la latencia de nuestro servicio y nuestros propios datos no se correspondían con lo que experimentaban los clientes. Tras completar la investigación de nuestra aplicación, derivamos este problema a nuestro proveedor de alojamiento para que inspeccionara nuestra infraestructura de red y determinara si se podía identificar un problema en nuestro balanceador de carga gestionado u otros dispositivos de red.

Las sesiones iniciales de resolución de problemas no fueron concluyentes, ya que el problema en sí era intermitente y difícil de reproducir. Tras varios intentos, por fin pudimos verificar que las solicitudes que agotaban el tiempo de espera no llegaban a nuestro dispositivo de red perimetral, lo que nos llevó a investigar los dispositivos en sentido ascendente de la red.

Empezamos a inspeccionar el dispositivo encargado de proteger nuestra infraestructura de los ataques DDoS y observamos que, al desactivarlo, ya no podíamos reproducir estos tiempos de espera, por lo que empezamos a investigar de inmediato para comprender cuáles eran las posibles causas. Tras analizarlo con el equipo de DDoS de nuestro proveedor de alojamiento, descubrimos que nuestro sistema de mitigación de DDoS estaba afectando al tráfico legítimo. Tras realizar ajustes en nuestras contramedidas, pudimos eliminar estos errores.

Mailgun devuelve un error 421 cuando no podemos poner en cola un mensaje correctamente. Este mensaje de error está diseñado para notificar al usuario que Mailgun no ha recibido el mensaje y que debe volver a intentarlo más tarde. Esto es una parte normal de SMTP y se utiliza para indicar al remitente que vuelva a intentar enviar el mensaje con un retraso.

La semana pasada, empezamos a ver niveles elevados de errores 421. La causa de este error se debió a la degradación del rendimiento que estábamos experimentando con nuestros clústeres de Cassandra, que es donde guardamos los mensajes para su almacenamiento.

La causa de nuestros problemas de rendimiento de Cassandra se debió a un error de compactación en la versión de Cassandra que estábamos ejecutando, que provocaba que las compactaciones se estancaran y hubiera picos de E/S de disco, lo que reducía el rendimiento general de Cassandra. Mientras el clúster estuvo en esta situación, fuimos intermitentemente incapaces de almacenar mensajes, lo que provocó los errores 421.

1. Alertas: aunque en muchos casos nuestro sistema de mitigación de DDoS no causa interrupciones, hemos aprendido que es importante que el equipo de ingeniería de Mailgun sepa cuándo se activa el sistema. Disponer de estos datos nos permite correlacionar con mayor eficacia si los problemas están causados o no por estas protecciones. Ya hemos trabajado con nuestro proveedor de alojamiento para implementar un sistema de alertas que avise al equipo de ingeniería cuando se activen estas protecciones.
2. Perfiles de mitigación: estamos ajustando nuestros perfiles de mitigación de DDoS para mejorar nuestra postura defensiva y reducir al mínimo el impacto en el tráfico legítimo. Estamos trabajando con nuestro proveedor de alojamiento para desarrollar estos perfiles y esperamos que este trabajo termine esta semana.
3. Actualización de Cassandra: hemos empezado a realizar actualizaciones continuas de nuestros clústeres de Cassandra para actualizarlos a una versión que no se vea afectada por el error de compactación de Cassandra, junto con ajustes de configuración más adecuados para el tipo de carga de trabajo.
4. Diseño de la infraestructura: estamos en proceso de rediseñar la infraestructura subyacente de Mailgun. Este esfuerzo nos proporcionará una red y una estructura de despliegue más sólidas que reducirán el impacto de ataques similares. Este esfuerzo está en marcha y compartiremos más detalles en el futuro.

Por último, aunque sabemos que estos tipos de incidentes suponen un reto, el equipo de Mailgun se compromete a centrarse en el plan anterior y en cualquier otra medida necesaria para garantizar que puedas seguir confiando en Mailgun para la entrega de tus emails.

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.