Post-mortem Mailgun de mai 2016

Ce rapport a été initialement publié le 31 mai 2016.

Mailgun a récemment subi plusieurs incidents distincts ayant impacté la disponibilité de nos services. Nous souhaitons profiter de cette occasion pour offrir à nos clients une visibilité sur la cause profonde de ces incidents, ainsi que des détails sur ce que nous avons fait pour les résoudre et garantir qu’ils ne se reproduisent plus à l’avenir.

Mailgun est fréquemment la cible d’attaques par déni de service distribué (DDoS) vastes et variées. Bien que de nombreuses attaques soient bloquées avec des perturbations minimes, nous avons rencontré plusieurs incidents ayant eu un impact prolongé sur nos services. En particulier, une attaque survenue le 23 mai a ciblé certaines parties de notre centre de données principal, et la méthode de l’attaque était suffisamment unique pour que notre fournisseur d’hébergement ait besoin de près d’une heure pour identifier efficacement l’attaque et déployer les mesures d’atténuation appropriées nous ayant permis de rétablir les services à 100 %.

Au début du mois, nous avons observé une augmentation constante du nombre de clients rencontrant des délais d’attente anormaux lors de l’utilisation du service API/SMTP de Mailgun. À mesure que le nombre de rapports concernant ce problème augmentait, il est devenu évident qu’il y avait un problème systémique avec notre service.

Nous maintenons plusieurs systèmes différents pour surveiller le débit et la latence de notre service, et nos propres données ne correspondaient pas à ce que les clients rencontraient. Après avoir terminé l’investigation de notre application, nous avons signalé ce problème à notre fournisseur d’hébergement afin d’inspecter notre infrastructure réseau et de déterminer si un problème pouvait être identifié dans notre répartiteur de charge géré ou d’autres équipements réseau.

Les premières sessions de dépannage se sont révélées peu concluantes, car le problème en lui-même était intermittent et difficile à reproduire. Après plusieurs tentatives, nous avons finalement pu vérifier que les requêtes expirées n’atteignaient pas notre équipement réseau périphérique, ce qui nous a conduits à examiner les équipements en amont sur le réseau.

Nous avons commencé à inspecter l’équipement responsable de la protection de notre infrastructure contre les attaques DDoS, et nous avons observé que lorsque cet appareil était désactivé, nous ne pouvions plus reproduire ces délais d’attente, et nous avons immédiatement commencé à enquêter pour comprendre quelles en étaient les causes possibles. Après analyse avec l’équipe DDoS de notre fournisseur d’hébergement, nous avons découvert que notre système d’atténuation DDoS impactait le trafic légitime. Après avoir apporté des ajustements à nos contre-mesures, nous avons pu éliminer ces erreurs.

Mailgun renvoie une erreur 421 lorsque nous sommes incapables de mettre un message en file d’attente avec succès. Ce message d’erreur est conçu pour avertir l’utilisateur que le message n’a pas été reçu par Mailgun et qu’une nouvelle tentative doit être effectuée plus tard. Il s’agit d’une partie normale du protocole SMTP, utilisée pour signaler à l’expéditeur de réessayer d’envoyer le message avec un délai.

La semaine dernière, nous avons commencé à constater des niveaux élevés de retours d’erreurs 421. La cause de cette erreur était due à une dégradation des performances que nous rencontrions avec nos clusters Cassandra, là où nous conservons les messages pour le stockage.

La cause de nos problèmes de performances Cassandra était due à un bug de compactage dans la version de Cassandra que nous exécutions, ce qui bloquait les compactages et provoquait des pics d’E/S disque réduisant le débit global de Cassandra. Tant que le cluster était dans cet état, nous étions par intermittence incapables de stocker des messages, ce qui entraînait les erreurs 421.

1. Alertes – Bien que dans de nombreux cas notre système d’atténuation DDoS ne cause pas de perturbations, nous avons appris qu’il est important pour l’équipe d’ingénierie de Mailgun de savoir quand le système est activé. Avoir ces données nous permet de déterminer plus efficacement si les problèmes sont causés ou non par ces protections. Nous avons déjà collaboré avec notre fournisseur d’hébergement pour déployer un système d’alerte qui alerte nos ingénieurs lorsque ces protections s’activent.
2. Profils d’atténuation – Nous ajustons nos profils d’atténuation DDoS afin d’améliorer notre posture défensive tout en minimisant l’impact sur le trafic légitime. Nous travaillons avec notre fournisseur d’hébergement pour développer ces profils et prévoyons que ce travail sera terminé cette semaine.
3. Mise à niveau de Cassandra – Nous avons commencé à effectuer des mises à niveau en continu de nos clusters Cassandra pour les mettre à niveau vers une version qui n’est pas impactée par le bug de compactage de Cassandra, accompagnées d’ajustements de configuration plus adaptés au type de charge de travail.
4. Conception de l’infrastructure – Nous sommes en train de repenser l’infrastructure sous-jacente de Mailgun. Cet effort nous fournira un réseau et une structure de déploiement plus robustes, qui réduiront l’impact de types d’attaques similaires. Cet effort est en cours et nous partagerons plus de détails à l’avenir.

Enfin, bien que nous sachions que ces types d’incidents sont difficiles, l’équipe Mailgun s’engage à se concentrer sur le plan ci-dessus et sur toute autre étape nécessaire pour garantir que vous puissiez continuer à compter sur Mailgun pour la livraison de vos emails.

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