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.
Cómo encontramos fallos de DNS inusuales en AWS
Hemos construido SparkPost alrededor de la idea de que un servicio en la nube como el nuestro necesita ser nativo de la nube por sí mismo. Eso no es solo una postura. Es nuestra arquitectura en la nube la que sustenta la escalabilidad, elasticidad y fiabilidad que son aspectos centrales del servicio de SparkPost. Esas cualidades son las principales razones por las que hemos construido nuestra infraestructura sobre Amazon Web Services (AWS), y por eso podemos ofrecer a nuestros clientes niveles de servicio y garantías de tasas de ráfaga inigualables por cualquier otro en el negocio.
Pero no pretendemos que nunca enfrentamos desafíos por errores inesperados o límites de la tecnología disponible. Nos encontramos con algo así el pasado viernes, y ese incidente provocó lentitud intermitente en nuestro servicio y retrasos en la entrega para algunos de nuestros clientes.
Primero déjame 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 tus correos electrónicos fue retrasada debido a este problema, por favor acepta mis disculpas (de hecho, una disculpa de todo nuestro equipo). Este incidente reforzó la importancia de tener estrategias de respaldo completas en su lugar, ya sea que estés utilizando copias de seguridad de la base de datos PostgreSQL u otros métodos de protección de datos para asegurar la continuidad del negocio durante los desafíos de infraestructura. Sabemos que cuentas con nosotros y es frustrante cuando no estamos rindiendo al nivel que esperas.
Algunas empresas se sienten tentadas a pasar por alto problemas como una degradación del servicio y esperar que nadie lo note. Puedes haber experimentado eso con servicios que has usado en el pasado. Yo sé que sí. 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 AWS. Los equipos que están construyendo otros servicios en la nube podrían estar interesados en conocerlo.
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 cómo implementar la infraestructura de AWS rápidamente, y también tenemos el beneficio del apoyo profundo del equipo de AWS.
Si tuviéramos que superar una limitación similar en un modelo de centro de datos tradicional, algo así podría tomar días o incluso semanas para resolver por completo. Esa agilidad y capacidad de respuesta son solo dos de las razones por las que hemos apostado nuestro negocio en la nube y AWS. En conjunto, el tipo de experiencia en la nube que nuestras empresas comparten es difícil de conseguir. Amazon ha sido un gran socio comercial para nosotros, y estamos realmente orgullosos de lo que hemos hecho con la pila de AWS.
SparkPost es el primer servicio de entrega de correos electrónicos que se construyó para la nube desde el principio. Este enfoque nativo de la nube es fundamental para cómo diseñamos nuestros email APIs para infraestructura en la nube, asegurando escalabilidad y fiabilidad para los desarrolladores. Enviamos más correos electrónicos desde una verdadera plataforma en la nube que nadie, y a veces eso significa adentrarse en territorios inexplorados. Es una verdad fundamental de la informática que no sabes qué desafíos ocurren a escala hasta que los enfrentas. 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 aprovecha la nuestra, espero que esta explicación de lo que sucedió el pasado viernes, y cómo lo resolvimos, haya sido útil.
