Nos encontramos con límites prácticos no documentados de las instancias EC2 que estábamos utilizando para nuestro clúster DNS principal. Dimensionar instancias en la nube basándose en especificaciones tradicionales (procesador, memoria, etc.) generalmente funciona tal como se espera, pero a veces ese modelo de hardware tradicional no se aplica.
Business in a box.
Descubre nuestras soluciones.
Habla con nuestro equipo de ventas
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 debe ser nativo de la nube. Eso no es solo una postura. Es nuestra arquitectura en la nube la que respalda la escalabilidad, elasticidad y fiabilidad que son aspectos centrales del servicio de SparkPost. Esas cualidades son unas de las principales razones por las que hemos construido nuestra infraestructura sobre Amazon Web Services (AWS), y es por eso que podemos ofrecer a nuestros clientes garantías de nivel de servicio y tasa de explosión sin igual por nadie más en el negocio.
Pero no pretendemos que nunca nos desafían errores inesperados o límites de la tecnología disponible. Nos encontramos con algo así el pasado viernes, y ese incidente llevó a una lentitud intermitente en nuestro servicio y demoras en la entrega para algunos de nuestros clientes.
Primero, permítanme 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 por este problema, por favor acepte mis 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 una degradación del servicio bajo la alfombra y esperan que nadie lo note. Puede que haya experimentado eso con los servicios que ha utilizado en el pasado. Sé que yo lo he hecho. Pero esa no es la forma en que nos gusta 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 están construyendo otros servicios en la nube podrían estar interesados en aprender sobre ello.
TL;DR
Nos encontramos con límites prácticos no documentados de las instancias EC2 que estábamos utilizando para nuestro clúster DNS primario. Dimensionar instancias en la nube basadas en especificaciones tradicionales (procesador, memoria, etc.) generalmente funciona como se esperaría, pero a veces ese modelo de hardware tradicional no se aplica. Esto es especialmente cierto en casos de uso atípicos donde los límites agregados pueden entrar en juego, y hay momentos en los que se enfrenta uno a esos escenarios sin previo aviso.
Nos encontramos con tal límite el viernes cuando nuestro volumen de consultas DNS creó un patrón de uso de red para el cual nuestro tipo de instancia no estaba preparado. Sin embargo, como ese límite no era evidente en la documentación 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 llevó 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 el modo en que funciona el correo electrónico, en comparación con el modelo de contenido para el cual AWS fue diseñado originalmente. La entrega de contenido basado en la web hace un uso intensivo de lo que podría considerarse escenarios clásicos de “pull” entrante: un cliente solicita datos, ya sea HTML, transmisiones de video o cualquier otra cosa, desde la nube. Pero los casos de uso para los proveedores de servicios de mensajería como SparkPost son excepciones al escenario habitual de AWS. En nuestro caso, hacemos mucho envío saliente de tráfico: específicamente, correo electrónico (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ás familiarizado con DNS, es posible que sepas que generalmente es un dato bastante ligero. Para solicitar una página HTML determinada, primero tienes 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 recuperas.
El correo electrónico, sin embargo, hace un uso excepcionalmente intensivo de DNS para buscar dominios de entrega. Por ejemplo, SparkPost envía muchos miles de millones de correos electrónicos a más de 1 millón de dominios únicos cada mes. Por cada correo que entregamos, tenemos que realizar un mínimo de dos búsquedas de DNS, y el uso de registros "txt" de DNS para tecnologías antifalsificación como SPF y DKIM significa que DNS también es necesario para recibir correo. Agrega a eso nuestro uso más tradicional de servicios API de AWS para nuestras aplicaciones, y es difícil exagerar lo importante que es DNS para nuestra infraestructura.
Todo esto significa que nos enfrentamos a una condición inusual en la que nuestro creciente volumen de mensajes salientes creó un volumen de tráfico DNS que alcanzó un límite de rendimiento de red agregado en tipos de instancia que de otro modo parecían tener recursos suficientes para manejar esa carga. Y como los ataques de denegación de servicio en la infraestructura Dyn DNS del año pasado demostraron, cuando DNS falla, todo falla. (Eso es algo que cualquiera que construya sistemas que dependen de DNS ya sabe muy bien.)
Los problemas repentinos de DNS desencadenaron una respuesta de nuestros equipos de operaciones e ingeniería de fiabilidad para identificar el problema. Se asociaron con 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 satisfacer nuestras necesidades de DNS sin toparnos con los límites de rendimiento. Afortunadamente, porque todo esto estaba dentro de AWS, pudimos iniciar las nuevas instancias e incluso cambiar el tamaño de las instancias existentes muy rápidamente. DNS retomó el comportamiento normal, las fallas de búsqueda cesaron, y nosotros (y la entrega de mensajes salientes) estábamos de vuelta en marcha.
Para mitigar este problema específico en el futuro, también estamos realizando cambios en la arquitectura DNS para mejorar el aislamiento de 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 monitoreo apropiados que nos brinden advertencias adecuadas para prevenir un incidente similar antes de que afecte a cualquiera de 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 solución en muy poco tiempo, tiene mucho que ver con cómo construimos SparkPost y nuestra excelente relación con el equipo de Amazon.
El excelente equipo de operaciones de SparkPost, nuestro equipo de Ingeniería de Confiabilidad del Sitio (SRE) y nuestros principales arquitectos técnicos trabajan con Amazon todos los días. Las fortalezas de la infraestructura de AWS nos han dado una verdadera ventaja optimizando la arquitectura de SparkPost para la nube. Trabajar tan de cerca con AWS durante los últimos dos años también nos ha enseñado mucho sobre cómo desplegar infraestructura de AWS y correr rápidamente, y también tenemos el beneficio de un profundo apoyo del equipo de AWS.
Si tuviéramos que lidiar con una limitación similar en un modelo tradicional de centro de datos, algo como esto podría tardar 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 comparten nuestras empresas es difícil de encontrar. Amazon ha sido un gran socio comercial para nosotros, y estamos realmente orgullosos de lo que hemos hecho con la estructura de AWS.
SparkPost es el primer servicio de entrega de correo electrónico que fue construido para la nube desde el principio. Enviamos más correos electrónicos desde una verdadera plataforma en la nube que cualquier otro, y a veces eso significa adentrarse en territorio desconocido. Es una verdad fundamental de la informática que no sabes qué desafíos ocurren a gran escala hasta que los alcanzas. Encontramos uno en AWS, pero nuestra respuesta rápida es un gran ejemplo de la flexibilidad que la nube hace posible. También es nuestro compromiso con nuestros clientes.
Ya sea que estés construyendo tu propia infraestructura en AWS, o seas un cliente de SparkPost que se beneficia de la nuestra, espero que esta explicación de lo que sucedió el pasado viernes, y cómo lo resolvimos, haya sido útil.
