Cómo Rastreamos Fallos Inusuales de DNS en AWS

Hemos construido SparkPost en torno a la idea de que un servicio en la nube como el nuestro necesita ser nativo de la nube. No es solo una fachada. Es nuestra arquitectura en la nube la que subyace a la escalabilidad, elasticidad y fiabilidad que son aspectos fundamentales del servicio SparkPost. Esas cualidades son razones principales por las que hemos construido nuestra infraestructura sobre Amazon Web Services (AWS)—y es por esto que podemos ofrecer a nuestros clientes garantías de nivel de servicio y tasa de picos inigualables por nadie más en el sector.

Pero no pretendemos que nunca somos desafiados por errores inesperados o límites de la tecnología disponible. Nos encontramos con algo como esto el viernes pasado, y ese incidente condujo a una lentitud intermitente en nuestro servicio y retrasos en la entrega para algunos de nuestros clientes.

Primero, permítame decir que el problema se resolvió ese mismo día. Además, no se perdió ningún correo electrónico ni datos relacionados. Sin embargo, si la entrega de sus correos electrónicos se vio ralentizada debido a este problema, le pido disculpas (de hecho, una disculpa de todo nuestro equipo). Sabemos que cuenta con nosotros, y es frustrante cuando no estamos rindiendo al nivel que usted espera.

Algunas empresas se sienten tentadas a ocultar problemas como la degradación del servicio y esperar que nadie lo note. Es posible que haya experimentado eso con servicios que ha utilizado en el pasado. Yo sé que lo he hecho. Pero esa no es nuestra forma de hacer negocios.

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

Resumen

Nos encontramos con límites prácticos no documentados de las instancias de EC2 que utilizábamos para nuestro clúster DNS principal. Dimensionar las instancias en la nube basándose en especificaciones tradicionales (procesador, memoria, etc.) normalmente funciona tal como se esperaría, pero a veces ese modelo de hardware tradicional no se aplica. Eso es especialmente cierto en casos de uso atípicos donde pueden entrar en juego límites agregados—y hay momentos en que te enfrentas a esos escenarios sin previo aviso.

Nos enfrentamos a tal limitación el viernes cuando el volumen de consultas DNS generó un patrón de uso de red para el cual nuestro tipo de instancia no estaba preparado. Sin embargo, dado que ese límite no era obvio en los documentos o 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, lo que a su vez condujo a retrasos intermitentes en diferentes puntos de nuestra arquitectura.

Profundizando en DNS

¿Por qué es especial nuestro uso de DNS? Bueno, tiene mucho que ver con la forma en que funciona el correo electrónico, comparado con el modelo de contenido para el cual AWS fue originalmente diseñado. La entrega de contenido basada en web hace un uso intensivo de lo que podría considerarse escenarios clásicos de “pull” entrante: un cliente solicita datos, ya sea HTML, flujos de video o cualquier otra cosa, de la nube. Pero los casos de uso para proveedores de servicios de mensajería como SparkPost son excepciones al escenario habitual de AWS. En nuestro caso, hacemos mucho push de tráfico saliente: específicamente, correos electrónicos (y otros tipos de mensajes como SMS o notificaciones push móviles). Y ese tráfico de estilo push depende en gran medida de DNS.

Si está familiarizado con DNS, sabrá que generalmente es un dato bastante ligero. Para solicitar una página HTML determinada, primero debe pedir donde se puede encontrar esa página en Internet, pero esa solicitud es una fracción del tamaño del contenido que recupera.

El correo electrónico, sin embargo, hace un uso excepcionalmente intenso de DNS para buscar dominios de entrega—por ejemplo, SparkPost envía miles de millones de correos electrónicos a más de 1 millón de dominios ántes cada mes. Por cada correo electrónico que entregamos, tenemos que realizar un mínimo de dos consultas DNS, y el uso de registros DNS “txt” para tecnologías anti-phishing como SPF y DKIM significa que DNS también es necesario para recibir correo. Añádase a eso nuestro uso más tradicional de los servicios API de AWS para nuestras aplicaciones, y es difícil exagerar cuán importante es DNS para nuestra infraestructura.

Todo esto significa que nos encontramos con una condición inusual en la que nuestro creciente volumen de mensajes salientes creó un volumen de tràfico de DNS que alcanzó un límite de capacidad de red agregado en tipos de instancias que de otro modo parecían tener suficientes recursos para atender esa carga. Y como los ataques de denegación de servicio a la infraestructura DNS de Dyn demostraron el año pasado, cuando DNS falla, todo falla. (Eso es algo que cualquiera que construya sistemas que dependen de DNS ya sabe dolorosamente bien.)

Los problemas inesperados de DNS desencadenaron una respuesta de nuestros equipos de operaciones e ingeniería de fiabilidad para identificar el problema. Se unieron a nuestros socios en Amazon para escalar en el lado de 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 red que pudiera cumplir con nuestras necesidades de DNS sin entrar en los límites rojos de capacidad. Afortunadamente, dado que todo esto estaba dentro de AWS, pudimos lanzar las nuevas instancias e incluso redimensionar las instancias existentes muy rápidamente. DNS reanudó su comportamiento normal, cesaron los fallos de consulta, y nosotros (y la entrega de mensajes salientes) volvimos a estar en camino.

Para mitigar este problema específico en el futuro, también estamos realizando cambios en la arquitectura de DNS para aislar mejor nuestros componentes principales del impacto de encuentros con umbrales inesperados similares. También estamos trabajando con el equipo de Amazon para determinar modelos de monitoreo apropiados que nos den el aviso adecuado para prevenir un incidente similar antes de que afecte a nuestros clientes.

AWS y el Lado Positivo de la Nube

No quiero endulzar 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 resolució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.

El cuerpo de operaciones superb de SparkPost, nuestro equipo de Ingeniería de Fiabilidad del Sitio (SRE), y nuestros arquitectos técnicos principales trabajan con Amazon todos los días. Las fortalezas de la infraestructura de AWS nos ha dado una ventaja real en optimizar la arquitectura de SparkPost para la nube. Trabajar tan cerca con AWS durante los últimos dos años también nos ha enseñado mucho sobre el lanza de infraestructura de AWS y su uso eficiente, y también contamos con el beneficio de un firme apoyo del equipo de AWS.

Si tuviéramos que trabajar alrededor de una limitación similar en un modelo tradicional de centro de datos, algo como esto podría tomar días o incluso semanas en resolverse completamente. Esa agilidad y capacidad de respuesta son solo dos de las razones por las que hemos apostado nuestro negocio en la nube y AWS. Juntos, el tipo de experiencia en la nube que nuestras empresas comparten es difícil de encontrar. Amazon ha sido un gran socio comercial para nosotros, y estamos realmente orgullosos de lo que hemos logrado con el stack de AWS.

SparkPost es el primer servicio de entrega de correos electrónicos que se construyó para la nube desde el principio. Enviamos más correos electrónicos desde una verdadera plataforma en la nube que nadie, y a veces eso significa entrar en territorio inexplorado. Es una verdad fundamental de la ciencia de la computación que no sabes qué desafíos ocurren a gran escala hasta que los enfrentas. Encontramos uno en AWS, pero nuestra respuesta rápida es un gran ejemplo de la flexibilidad que hace posible la nube. También es nuestro compromiso con nuestros clientes.

Ya sea que esté construyendo su propia infraestructura en AWS, o sea un cliente de SparkPost que aprovecha la nuestra, espero que esta explicación de lo que ocurrió el viernes pasado, y cómo lo resolvimos, haya sido útil.