Post-mortem do Mailgun de maio de 2016

Isso foi originalmente relatado em 31 de maio de 2016.

O Mailgun sofreu recentemente vários incidentes distintos que impactaram a disponibilidade de nossos serviços. Gostaríamos de aproveitar esta oportunidade para dar aos nossos clientes visibilidade sobre a causa raiz desses incidentes, juntamente com detalhes do que fizemos para resolvê-los e garantir que não voltem a ocorrer no futuro.

O Mailgun é frequentemente alvo de grandes e variados ataques de negação de serviço distribuída (DDoS). Embora muitos ataques sejam bloqueados com interrupção mínima, sofremos vários incidentes em que houve um impacto prolongado em nossos serviços. Em especial, um ataque no dia 23 de maio atingiu partes do nosso data center primário, e o método de ataque foi peculiar o suficiente para que nosso provedor de hospedagem precisasse de quase uma hora para identificá-lo de forma eficaz e implementar as mitigações apropriadas que nos permitiram restaurar 100% dos serviços.

No início do mês, observamos um aumento constante de clientes que enfrentavam tempos limite anormais ao usar o serviço de API/SMTP do Mailgun. À medida que o número de relatórios sobre esse problema aumentou, ficou claro que havia um problema sistêmico em nosso serviço.

Mantemos vários sistemas diferentes para monitorar a vazão e a latência em nosso serviço, e nossos próprios dados não correspondiam ao que os clientes estavam enfrentando. Após concluirmos a investigação de nosso aplicativo, encaminhamos esse problema ao nosso provedor de hospedagem para inspecionar nossa infraestrutura de rede e determinar se um problema poderia ser identificado em nosso balanceador de carga gerenciado ou em outros dispositivos de rede.

As sessões iniciais de solução de problemas foram inconclusivas, pois o problema em si era intermitente e difícil de reproduzir. Após várias tentativas, finalmente conseguimos verificar que as solicitações com estouro de tempo limite não estavam chegando ao nosso dispositivo de rede de borda, o que nos levou a investigar os dispositivos upstream na rede.

Começamos a inspecionar o dispositivo responsável por proteger nossa infraestrutura contra ataques DDoS e observamos que, quando esse dispositivo era desativado, não conseguíamos mais reproduzir esses tempos limite, e começamos imediatamente a investigar para entender quais eram as possíveis causas. Após análise com a equipe de DDoS de nosso provedor de hospedagem, descobrimos que nosso sistema de mitigação de DDoS estava impactando o tráfego legítimo. Depois de fazer ajustes em nossas contramedidas, conseguimos eliminar esses erros.

O Mailgun retorna um erro 421 quando não conseguimos colocar uma mensagem na fila com sucesso. Essa mensagem de erro tem o objetivo de notificar o usuário de que a mensagem não foi recebida pelo Mailgun e que uma nova tentativa deve ser feita mais tarde. Isso é uma parte normal do SMTP e serve para sinalizar ao remetente que tente reenviar a mensagem com um atraso.

Na semana passada, começamos a ver níveis elevados de erros 421 sendo retornados. A causa desse erro deveu-se à degradação de desempenho que estávamos enfrentando em nossos clusters Cassandra, que é onde mantemos as mensagens armazenadas.

A causa de nossos problemas de desempenho do Cassandra deveu-se a um bug de compactação na versão do Cassandra que estávamos executando, o que estava fazendo com que as compactações travassem e os picos de E/S de disco reduzissem a vazão geral do Cassandra. Enquanto o cluster estava nessa condição, ficamos intermitentemente incapazes de armazenar mensagens, o que resultava nos erros 421.

1. Alertas – Embora em muitos casos nosso sistema de mitigação de DDoS não cause interrupções, aprendemos que é importante que a nossa equipe de engenharia do Mailgun saiba quando o sistema é ativado. Ter esses dados nos permite correlacionar de forma mais eficaz se os problemas estão ou não sendo causados por essas proteções. Já trabalhamos com nosso provedor de hospedagem para implantar um sistema de alerta que avisa nossa equipe de engenharia quando essas proteções são ativadas.
2. Perfis de mitigação – Estamos ajustando nossos perfis de mitigação de DDoS para melhorar nossa postura defensiva e, ao mesmo tempo, minimizar o impacto no tráfego legítimo. Estamos trabalhando com nosso provedor de hospedagem para desenvolver esses perfis e prevemos que esse trabalho seja concluído esta semana.
3. Upgrade do Cassandra – Começamos a realizar upgrades contínuos de nossos clusters Cassandra para fazer upgrade deles para uma versão que não é afetada pelo bug de compactação do Cassandra, juntamente com ajustes de configuração mais adequados ao tipo de carga de trabalho.
4. Design de infraestrutura – Estamos em processo de reformulação da infraestrutura subjacente do Mailgun. Esse esforço nos dará uma rede e uma estrutura de implantação mais robustas, o que reduzirá o impacto de tipos semelhantes de ataques. Esse esforço está em andamento, e compartilharemos mais detalhes no futuro.

Por fim, embora saibamos que esses tipos de incidentes são desafiadores, a equipe do Mailgun tem o compromisso de focar no plano acima e em quaisquer outras etapas necessárias para garantir que você possa continuar contando com o Mailgun para a sua entrega de e-mail.

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.