How We Tracked Down Unusual DNS Failures in AWS

We’ve built SparkPost around the idea that a cloud service like ours needs to be cloud-native itself. That’s not just posturing. It’s our cloud architecture that underpins the scalability, elasticity, and reliability that are core aspects of the SparkPost service. Those qualities are major reasons we’ve built our infrastructure atop Servicios web de Amazon (AWS)—and it’s why we can offer our customers service level and burst rate guarantees unmatched by anyone else in the business.

But we don’t pretend that we’re never challenged by unexpected bugs or limits of available technology. We ran into something like this last Friday, and ese incidente led to intermittent slowness in our service and delivery delays for some of our customers.

En primer lugar, el problema se resolvió ese mismo día. Además, no se perdió ningún correo electrónico ni ningún dato relacionado. Sin embargo, si la entrega de sus correos electrónicos se ha ralentizado debido a este problema, acepte mis disculpas (de hecho, las disculpas de todo nuestro equipo). Sabemos que cuenta con nosotros y es frustrante que no funcionemos al nivel que espera.

Some companies are tempted to brush issues like a service degradation under the rug and hope no one notices. You may have experienced that with services you’ve used in the past. I know I have. But that’s not how we like to do business.

Quería escribir sobre este incidente también por otra razón: aprendimos algo realmente interesante y valioso sobre nuestra arquitectura en la nube de AWS. Puede que a los equipos que construyen otros servicios en la nube les interese conocerlo.

TL;DR

Nos encontramos con límites prácticos no documentados de las instancias EC2 que estábamos utilizando para nuestro clúster DNS principal. El dimensionamiento de instancias en la nube basado en especificaciones tradicionales (procesador, memoria, etc.) suele funcionar como cabría esperar, pero a veces ese modelo de hardware tradicional no se aplica. Esto es especialmente cierto en casos de uso atípicos en los que pueden entrar en juego límites agregados, y hay veces en las que uno se topa de bruces con estos escenarios sin previo aviso.

Llegamos a ese límite el viernes, cuando nuestro volumen de consultas DNS creó un patrón de uso de red para el que nuestro tipo de instancia no estaba preparado. Sin embargo, como ese límite no era obvio en los documentos ni en las métricas estándar disponibles, no sabíamos que lo habíamos alcanzado. Lo que observamos fue una tasa muy alta de fallos de DNS, que a su vez provocaron retrasos intermitentes en distintos puntos de nuestra arquitectura.

Profundizar en el DNS

¿Por qué es especial nuestro uso de DNS? Bueno, tiene mucho que ver con la forma en que funciona el correo electrónico, en comparación con el modelo de contenido para el que AWS se diseñó originalmente. La entrega de contenido basado en la web hace un uso intensivo de lo que podrían considerarse escenarios "pull" entrantes clásicos: un cliente solicita datos, ya sean HTML, secuencias de vídeo o cualquier otra cosa, desde la nube. Pero los casos de uso de proveedores de servicios de mensajería como SparkPost son excepciones al escenario habitual de AWS. En nuestro caso, enviamos mucho tráfico saliente: en concreto, correo electrónico (y otros tipos de mensajes como SMS o notificaciones push para móviles). Y ese tráfico de tipo push depende en gran medida de DNS.

Si está familiarizado con el DNS, sabrá que en general se trata de datos bastante ligeros. Para solicitar una determinada página HTML, primero hay que preguntar dónde se puede encontrar esa página en Internet, pero esa solicitud es una fracción del tamaño del contenido que se recupera.

Email, however, makes exceptionally heavy use of DNS to look up delivery domains—for example, SparkPost sends many billions of emails to over 1 million unique domains cada mes. For every email we deliver, we have to make a minimum of two DNS lookups, and the use of DNS “txt” records for anti-phishing technologies like SPF and DKIM means DNS also is required to receive mail. Add to that our more traditional use of AWS API services for our apps, and it’s hard to exaggerate how important DNS is to our infrastructure.

All of this means we ran into an unusual condition in which our growing volume of outbound messages created a DNS traffic volume that hit an aggregate network throughput limit on instance types that otherwise seemed to have sufficient resources to service that load. And as ataques de denegación de servicio a la infraestructura DNS de Dyn last year demonstrated, when DNS breaks, everything breaks. (That’s something anyone who builds systems that rely on DNS already knows painfully well.)

Los repentinos problemas de DNS provocaron una respuesta de nuestros equipos de ingeniería de operaciones y fiabilidad para identificar el problema. Se asociaron con nuestros socios de Amazon para escalar en el lado de las operaciones de AWS. Trabajando juntos, identificamos la causa y una solución. Desplegamos un clúster de servidores de nombres de mayor capacidad con un mayor enfoque en la capacidad de la red que podía satisfacer nuestras necesidades de DNS sin llegar a los límites de rendimiento. Afortunadamente, como todo esto estaba dentro de AWS, pudimos poner en marcha las nuevas instancias e incluso redimensionar las instancias existentes muy rápidamente. DNS reanudó su comportamiento normal, cesaron los fallos de búsqueda y nosotros (y la entrega de mensajes salientes) volvimos a la normalidad.

Para mitigar este problema específico en el futuro, también estamos realizando cambios en la arquitectura DNS para aislar mejor nuestros componentes principales del impacto de encuentros con umbrales similares e inesperados. También estamos trabajando con el equipo de Amazon para determinar modelos de monitorización adecuados que nos avisen con suficiente antelación para evitar un incidente similar antes de que afecte a alguno de nuestros clientes.

AWS and the Cloud’s Silver Lining

No quiero suavizar el impacto de este incidente en nuestros clientes. Pero nuestra capacidad para identificar el problema subyacente como una interacción inesperada de nuestro caso de uso con la infraestructura de AWS, y luego encontrar una solución en muy poco tiempo, tiene mucho que ver con la forma en que construimos SparkPost y nuestra excelente relación con el equipo de Amazon.

SparkPost’s superb operations corps, our Site Reliability Engineering (SRE) team, and our principal technical architects work with Amazon every day. En strengths of AWS’ infrastructure has given us a real leg up optimización de la arquitectura de SparkPost para la nube. Working so closely with AWS over the past two years also has taught us a lot about spinning up AWS infrastructure and running quickly, and we also have the benefit of deep support from the AWS team.

Si tuviéramos que sortear una limitación similar en un modelo de centro de datos tradicional, algo así podría tardar días o incluso semanas en resolverse por completo. Esa agilidad y capacidad de respuesta son solo dos de las razones por las que hemos apostado por la nube y AWS. Juntos, el tipo de experiencia en la nube que comparten nuestras empresas es difícil de encontrar. Amazon ha sido un gran socio comercial para nosotros, y estamos muy orgullosos de lo que hemos hecho con la pila de AWS".

SparkPost es el primer servicio de entrega de correo electrónico creado para la nube desde el principio. Enviamos más correo electrónico que nadie desde una verdadera plataforma en la nube, y a veces eso significa entrar en territorio desconocido. Es una verdad fundamental de la informática que no sabes qué retos se presentan a escala hasta que te topas con ellos. Encontramos uno en AWS, pero nuestra rápida respuesta es un gran ejemplo de la flexibilidad que permite la nube. También es nuestro compromiso con los clientes.

Tanto si estás construyendo tu propia infraestructura en AWS, como si eres un cliente de SparkPost que se aprovecha de la nuestra, espero que esta explicación de lo que ocurrió el viernes pasado, y cómo lo resolvimos, te haya sido útil.