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 encontramos fallos de DNS inusuales 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
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, 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ían 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 proveedores de servicios de mensajería como SparkPost son excepciones al escenario habitual de AWS. En nuestro caso, hacemos mucho envío de tráfico saliente: específicamente, correo electrónico (y otros tipos de mensajes como SMS o notificaciones push móviles). Y ese tráfico al estilo "push" depende en gran medida del DNS.
Si estás familiarizado con DNS, puedes saber que generalmente es un dato bastante ligero. Para solicitar una página HTML dada, 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 del 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 electrónico que entregamos, tenemos que hacer un mínimo de dos búsquedas de DNS, y el uso de registros "txt" de DNS para tecnologías anti-phishing como SPF y DKIM significa que DNS también es necesario para recibir correos. Agrega a eso nuestro uso más tradicional de servicios AWS API para nuestras aplicaciones, y es difícil exagerar lo importante que es el 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 DNS que alcanzó un límite de ancho de banda agregado en tipos de instancias que parecían tener suficientes recursos para manejar esa carga. Y como los ataques de denegación de servicio en la infraestructura de Dyn DNS del año pasado demostraron, cuando el DNS falla, todo falla. (Eso es algo que cualquiera que construye sistemas que dependen del DNS ya conoce muy bien).
Los repentinos problemas de DNS desencadenaron una respuesta de nuestros equipos de operaciones e ingeniería de confiabilidad para identificar el problema. Se unieron 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 alcanzar los límites críticos de rendimiento. Afortunadamente, dado que todo esto estaba dentro de AWS, pudimos activar las nuevas instancias e incluso redimensionar las instancias existentes muy rápidamente. El DNS retomó su comportamiento normal, cesaron las fallas de búsqueda, y nosotros (y la entrega de mensajes salientes) volvimos a estar en marcha.
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 encontrarse con umbrales similares e inesperados. También estamos trabajando con el equipo de Amazon para determinar modelos de monitoreo apropiados que nos brinden una advertencia adecuada para evitar un incidente similar antes de que afecte a cualquiera de nuestros clientes.
AWS y la Silver Lining del Cloud
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 cuerpo 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 la implementación de la infraestructura de AWS y cómo operar rápidamente, y también contamos con el beneficio del respaldo profundo del equipo de AWS.
Si hubiéramos tenido 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 completamente. Esa agilidad y capacidad de respuesta son solo dos de las razones por las que hemos apostado nuestro negocio en la nube y en 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 el stack 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 desde una verdadera plataforma en la nube que nadie, y a veces eso significa entrar en territorios inexplorados. Es una verdad fundamental de la informática 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és construyendo tu propia infraestructura en AWS, o seas un cliente de SparkPost que se aprovecha de la nuestra, espero que esta explicación de lo que sucedió el pasado viernes, y cómo lo resolvimos, te haya sido útil.
