El día en que nuestro DNS alcanzó un límite no documentado en AWS
Pájaro
7 feb 2017
Ingeniería
1 min read
Puntos clave
SparkPost encontró un límite de rendimiento de red no documentado en un tipo específico de instancia AWS EC2 que impulsaba su clúster DNS principal.
La dimensionamiento tradicional de instancias (CPU, RAM, disco) no reveló este cuello de botella porque el problema estaba relacionado con el tráfico de red DNS agregado, no con la escasez de recursos.
El uso de DNS para correos electrónicos salientes de alto volumen es inusualmente intenso: SparkPost genera millones de búsquedas DNS para el enrutamiento de dominios, autenticación (SPF/DKIM) e interacciones con API de AWS.
El fallo de DNS no se debió a respuestas DNS mal formadas, sino que los umbrales de capacidad de red al nivel de la instancia fueron superados silenciosamente, causando fallos generalizados en las búsquedas.
Debido a que AWS no documenta explícitamente estos límites de red blandos, diagnosticar el problema requirió una colaboración profunda entre el equipo SRE de SparkPost y los ingenieros de AWS.
El equipo resolvió el problema migrando los servicios DNS a tipos de instancias más grandes con mayor ancho de banda de red y rediseñando partes de la arquitectura DNS para un mejor aislamiento y conmutación por error.
No se perdieron datos de clientes ni mensajes, pero el evento destacó cómo las arquitecturas nativas de la nube pueden encontrar límites inesperados a escala — y qué tan rápido pueden ser solucionados con la elasticidad de AWS.
Destacados de Q&A
¿Qué ocurrió?
El clúster DNS de SparkPost alcanzó un límite inesperado de rendimiento de red de AWS, lo que provocó fallos intermitentes en las búsquedas DNS, lo que retrasó la entrega de correos electrónicos.
¿Por qué se rompió DNS en absoluto?
El DNS es extremadamente dependiente para el correo electrónico saliente. Cada envío requiere múltiples consultas (MX, TXT, SPF, DKIM), por lo que un alto volumen de envíos = tráfico masivo de DNS.
Este patrón de tráfico superó un límite no documentado en el tipo de instancia EC2 que aloja los servidores de nombres.
¿Cómo es DNS para email diferente de las aplicaciones web?
Web apps mayormente pull contenido (los clientes solicitan datos).
Servicios de entrega de correo electrónico push tráfico, desencadenando muchas más consultas DNS — a menudo miles de millones por mes.
El correo electrónico depende de DNS para enrutamiento, validación de seguridad y conmutación por error.
¿Cómo se manifestó el failure?
Las solicitudes de DNS comenzaron a fallar o agotarse
Las colas de entrega se acumularon
La latencia aumentó en partes del sistema
No se perdió nada — solo se retrasó.
¿Por qué fue difícil de diagnosticar?
El límite no estaba documentado
La monitorización de AWS no mostraba explícitamente el cuello de botella
Todas las métricas tradicionales (CPU, RAM, disco) parecían normales
El problema solo surgía bajo un patrón de tráfico DNS específico y de alto volumen.
¿Cómo lo solucionó SparkPost?
Actualizado a tipos de instancias EC2 con techos de rendimiento de red más altos
Rearquitecturó los clústeres DNS para ser más resistentes a picos de tráfico agregados
Trabajó con AWS para identificar mejores patrones de señal/alerta para detectar esto antes
¿Se perdió datos de cliente o correo?
No — solo se ralentizó la entrega. Una vez que DNS se estabilizó, todo el correo reanudó su entrega normal.
¿Cuál es la lección más amplia?
Incluso en la nube, puedes encontrar restricciones de escalado no visibles — pero los diseños nativos de la nube te dan la flexibilidad para recuperarte rápidamente.
La elasticidad, la colaboración con AWS, y las sólidas prácticas de SRE hacen posible una recuperación rápida.
Cómo rastreamos fallos inusuales de DNS en AWS
Hemos construido SparkPost alrededor de la idea de que un servicio en la nube como el nuestro debe ser nativo de la nube. Eso no es solo postulación. Es nuestra arquitectura en la nube la que sustenta la escalabilidad, elasticidad y fiabilidad que son aspectos centrales del servicio SparkPost. Esas cualidades son 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 ráfagas inigualables por cualquier otra persona en el negocio.
Pero no pretendemos que nunca enfrentamos desafíos por errores inesperados o límites de la tecnología disponible. Nos topamos con algo así el pasado viernes, y ese incidente llevó a una lentitud intermitente en nuestro servicio y retrasos 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 ralentizó debido a este problema, por favor acepte 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é usando copias de seguridad de la base de datos PostgreSQL u otros métodos de protección de datos para garantizar la continuidad del negocio durante desafíos de infraestructura. Sabemos que cuenta con nosotros, y es frustrante cuando no estamos actuando al nivel que espera.
Algunas empresas están tentadas a ocultar problemas como una degradación del servicio bajo la alfombra y esperar que nadie lo note. Puede que haya experimentado eso con los servicios que ha utilizado en el pasado. Sé que yo sí. Pero así no es como nos gusta hacer negocios.
Quise 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 conocerlo.
Hemos construido SparkPost alrededor de la idea de que un servicio en la nube como el nuestro debe ser nativo de la nube. Eso no es solo postulación. Es nuestra arquitectura en la nube la que sustenta la escalabilidad, elasticidad y fiabilidad que son aspectos centrales del servicio SparkPost. Esas cualidades son 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 ráfagas inigualables por cualquier otra persona en el negocio.
Pero no pretendemos que nunca enfrentamos desafíos por errores inesperados o límites de la tecnología disponible. Nos topamos con algo así el pasado viernes, y ese incidente llevó a una lentitud intermitente en nuestro servicio y retrasos 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 ralentizó debido a este problema, por favor acepte 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é usando copias de seguridad de la base de datos PostgreSQL u otros métodos de protección de datos para garantizar la continuidad del negocio durante desafíos de infraestructura. Sabemos que cuenta con nosotros, y es frustrante cuando no estamos actuando al nivel que espera.
Algunas empresas están tentadas a ocultar problemas como una degradación del servicio bajo la alfombra y esperar que nadie lo note. Puede que haya experimentado eso con los servicios que ha utilizado en el pasado. Sé que yo sí. Pero así no es como nos gusta hacer negocios.
Quise 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 conocerlo.
Hemos construido SparkPost alrededor de la idea de que un servicio en la nube como el nuestro debe ser nativo de la nube. Eso no es solo postulación. Es nuestra arquitectura en la nube la que sustenta la escalabilidad, elasticidad y fiabilidad que son aspectos centrales del servicio SparkPost. Esas cualidades son 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 ráfagas inigualables por cualquier otra persona en el negocio.
Pero no pretendemos que nunca enfrentamos desafíos por errores inesperados o límites de la tecnología disponible. Nos topamos con algo así el pasado viernes, y ese incidente llevó a una lentitud intermitente en nuestro servicio y retrasos 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 ralentizó debido a este problema, por favor acepte 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é usando copias de seguridad de la base de datos PostgreSQL u otros métodos de protección de datos para garantizar la continuidad del negocio durante desafíos de infraestructura. Sabemos que cuenta con nosotros, y es frustrante cuando no estamos actuando al nivel que espera.
Algunas empresas están tentadas a ocultar problemas como una degradación del servicio bajo la alfombra y esperar que nadie lo note. Puede que haya experimentado eso con los servicios que ha utilizado en el pasado. Sé que yo sí. Pero así no es como nos gusta hacer negocios.
Quise 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 conocerlo.
TL;DR
Nos encontramos con límites prácticos no documentados de las instancias EC2 que estábamos usando para nuestro clúster primario de DNS. Dimensionar instancias en la nube basándose en especificaciones tradicionales (procesador, memoria, etc.) generalmente funciona como se espera, pero a veces ese modelo de hardware tradicional no se aplica. Eso es especialmente cierto en casos de uso atípicos donde los límites agregados pueden entrar en juego, y hay momentos en que te enfrentas a esos escenarios sin previo aviso.
Nos topamos con tal límite el viernes cuando nuestro volumen de consultas de DNS creó 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 evidente en los documentos o 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.
Nos encontramos con límites prácticos no documentados de las instancias EC2 que estábamos usando para nuestro clúster primario de DNS. Dimensionar instancias en la nube basándose en especificaciones tradicionales (procesador, memoria, etc.) generalmente funciona como se espera, pero a veces ese modelo de hardware tradicional no se aplica. Eso es especialmente cierto en casos de uso atípicos donde los límites agregados pueden entrar en juego, y hay momentos en que te enfrentas a esos escenarios sin previo aviso.
Nos topamos con tal límite el viernes cuando nuestro volumen de consultas de DNS creó 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 evidente en los documentos o 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.
Nos encontramos con límites prácticos no documentados de las instancias EC2 que estábamos usando para nuestro clúster primario de DNS. Dimensionar instancias en la nube basándose en especificaciones tradicionales (procesador, memoria, etc.) generalmente funciona como se espera, pero a veces ese modelo de hardware tradicional no se aplica. Eso es especialmente cierto en casos de uso atípicos donde los límites agregados pueden entrar en juego, y hay momentos en que te enfrentas a esos escenarios sin previo aviso.
Nos topamos con tal límite el viernes cuando nuestro volumen de consultas de DNS creó 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 evidente en los documentos o 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 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ía considerarse escenarios clásicos de “pull” de entrada: 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 externo: específicamente, correo electrónico (y otros tipos de mensajes como SMS o notificaciones push móviles). Y ese tráfico de tipo push depende en gran medida del DNS.
Si estás familiarizado con el DNS, puedes saber que suele ser datos bastante ligeros. 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 obtienes.
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. Para cada correo electrónico que entregamos, tenemos que hacer un mínimo de dos búsquedas 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 correos. A eso se suma nuestro uso más tradicional de servicios API de AWS 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 de salida 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 demostraron el año pasado, cuando el DNS falla, todo falla. (Eso es algo que cualquiera que construya sistemas que dependen del DNS ya sabe muy bien.)
Los problemas repentinos de DNS desencadenaron una respuesta de nuestros equipos de operaciones e ingeniería de confiabilidad 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 podría satisfacer nuestras necesidades de DNS sin cruzar los umbrales de rendimiento. Afortunadamente, porque todo esto fue 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 de salida) volvimos al camino correcto.
Para mitigar este problema específico en el futuro, también estamos haciendo 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 proporcionen una advertencia adecuada para evitar un incidente similar antes de que afecte a cualquiera de nuestros clientes.
Tema | Carga de Trabajo típica de AWS | Carga de Trabajo de Correo Electrónico Saliente de SparkPost |
|---|---|---|
Patrón de Tráfico | Mayormente solicitudes “pull” de entrada (páginas web, APIs, medios) | Tráfico de “push” de salida intenso (miles de millones de correos electrónicos) |
Dependencia de DNS | Ligera: 1–2 búsquedas por solicitud de contenido | Muy intensa: múltiples búsquedas DNS por correo electrónico + comprobaciones SPF/DKIM TXT |
Volumen de Consultas | Predecible y proporcional a la actividad del usuario | Explota con campañas de salida que apuntan a millones de dominios |
Tipo de Cuello de Botella | Límites de CPU, memoria o almacenamiento | Límites de rendimiento de red agregados en tipos de instancia |
Modo de Error | Latencia degradada o tiempo de espera de API | Fallos de búsqueda DNS que causan retrasos en la entrega |
Visibilidad | Los límites suelen estar documentados y aparecen en métricas | El techo de rendimiento no estaba documentado e invisible en CloudWatch |
Enfoque de Mitigación | Escalar recursos de instancia o agregar caché | Migrar a familias de instancias con mayor ancho de banda + rediseño de la arquitectura 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ía considerarse escenarios clásicos de “pull” de entrada: 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 externo: específicamente, correo electrónico (y otros tipos de mensajes como SMS o notificaciones push móviles). Y ese tráfico de tipo push depende en gran medida del DNS.
Si estás familiarizado con el DNS, puedes saber que suele ser datos bastante ligeros. 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 obtienes.
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. Para cada correo electrónico que entregamos, tenemos que hacer un mínimo de dos búsquedas 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 correos. A eso se suma nuestro uso más tradicional de servicios API de AWS 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 de salida 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 demostraron el año pasado, cuando el DNS falla, todo falla. (Eso es algo que cualquiera que construya sistemas que dependen del DNS ya sabe muy bien.)
Los problemas repentinos de DNS desencadenaron una respuesta de nuestros equipos de operaciones e ingeniería de confiabilidad 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 podría satisfacer nuestras necesidades de DNS sin cruzar los umbrales de rendimiento. Afortunadamente, porque todo esto fue 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 de salida) volvimos al camino correcto.
Para mitigar este problema específico en el futuro, también estamos haciendo 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 proporcionen una advertencia adecuada para evitar un incidente similar antes de que afecte a cualquiera de nuestros clientes.
Tema | Carga de Trabajo típica de AWS | Carga de Trabajo de Correo Electrónico Saliente de SparkPost |
|---|---|---|
Patrón de Tráfico | Mayormente solicitudes “pull” de entrada (páginas web, APIs, medios) | Tráfico de “push” de salida intenso (miles de millones de correos electrónicos) |
Dependencia de DNS | Ligera: 1–2 búsquedas por solicitud de contenido | Muy intensa: múltiples búsquedas DNS por correo electrónico + comprobaciones SPF/DKIM TXT |
Volumen de Consultas | Predecible y proporcional a la actividad del usuario | Explota con campañas de salida que apuntan a millones de dominios |
Tipo de Cuello de Botella | Límites de CPU, memoria o almacenamiento | Límites de rendimiento de red agregados en tipos de instancia |
Modo de Error | Latencia degradada o tiempo de espera de API | Fallos de búsqueda DNS que causan retrasos en la entrega |
Visibilidad | Los límites suelen estar documentados y aparecen en métricas | El techo de rendimiento no estaba documentado e invisible en CloudWatch |
Enfoque de Mitigación | Escalar recursos de instancia o agregar caché | Migrar a familias de instancias con mayor ancho de banda + rediseño de la arquitectura 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ía considerarse escenarios clásicos de “pull” de entrada: 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 externo: específicamente, correo electrónico (y otros tipos de mensajes como SMS o notificaciones push móviles). Y ese tráfico de tipo push depende en gran medida del DNS.
Si estás familiarizado con el DNS, puedes saber que suele ser datos bastante ligeros. 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 obtienes.
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. Para cada correo electrónico que entregamos, tenemos que hacer un mínimo de dos búsquedas 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 correos. A eso se suma nuestro uso más tradicional de servicios API de AWS 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 de salida 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 demostraron el año pasado, cuando el DNS falla, todo falla. (Eso es algo que cualquiera que construya sistemas que dependen del DNS ya sabe muy bien.)
Los problemas repentinos de DNS desencadenaron una respuesta de nuestros equipos de operaciones e ingeniería de confiabilidad 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 podría satisfacer nuestras necesidades de DNS sin cruzar los umbrales de rendimiento. Afortunadamente, porque todo esto fue 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 de salida) volvimos al camino correcto.
Para mitigar este problema específico en el futuro, también estamos haciendo 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 proporcionen una advertencia adecuada para evitar un incidente similar antes de que afecte a cualquiera de nuestros clientes.
Tema | Carga de Trabajo típica de AWS | Carga de Trabajo de Correo Electrónico Saliente de SparkPost |
|---|---|---|
Patrón de Tráfico | Mayormente solicitudes “pull” de entrada (páginas web, APIs, medios) | Tráfico de “push” de salida intenso (miles de millones de correos electrónicos) |
Dependencia de DNS | Ligera: 1–2 búsquedas por solicitud de contenido | Muy intensa: múltiples búsquedas DNS por correo electrónico + comprobaciones SPF/DKIM TXT |
Volumen de Consultas | Predecible y proporcional a la actividad del usuario | Explota con campañas de salida que apuntan a millones de dominios |
Tipo de Cuello de Botella | Límites de CPU, memoria o almacenamiento | Límites de rendimiento de red agregados en tipos de instancia |
Modo de Error | Latencia degradada o tiempo de espera de API | Fallos de búsqueda DNS que causan retrasos en la entrega |
Visibilidad | Los límites suelen estar documentados y aparecen en métricas | El techo de rendimiento no estaba documentado e invisible en CloudWatch |
Enfoque de Mitigación | Escalar recursos de instancia o agregar caché | Migrar a familias de instancias con mayor ancho de banda + rediseño de la arquitectura DNS |
AWS and the Cloud’s Silver Lining
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 magnífico equipo de operaciones de SparkPost, nuestro equipo de Ingeniería de Confiabilidad del Sitio (SRE), y nuestros arquitectos técnicos principales trabajan con Amazon todos los días. Las fortalezas de la infraestructura de AWS nos han dado una verdadera ventaja para optimizar 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 y funcionar rápidamente, y también tenemos el beneficio de un profundo apoyo del equipo de AWS.
Si tuviéramos que trabajar alrededor de una limitación similar en un modelo de centro de datos tradicional, algo así podría tomar días o incluso semanas para 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 pila de AWS.
SparkPost es el primer servicio de entrega de correo electrónico que fue construido para la nube desde el principio. Este enfoque nativo de la nube es fundamental para cómo diseñamos nuestras APIs de correo electrónico 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 entrar en territorio desconocido. 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 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 ocurrió el pasado viernes, y cómo lo resolvimos, haya sido útil.
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 magnífico equipo de operaciones de SparkPost, nuestro equipo de Ingeniería de Confiabilidad del Sitio (SRE), y nuestros arquitectos técnicos principales trabajan con Amazon todos los días. Las fortalezas de la infraestructura de AWS nos han dado una verdadera ventaja para optimizar 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 y funcionar rápidamente, y también tenemos el beneficio de un profundo apoyo del equipo de AWS.
Si tuviéramos que trabajar alrededor de una limitación similar en un modelo de centro de datos tradicional, algo así podría tomar días o incluso semanas para 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 pila de AWS.
SparkPost es el primer servicio de entrega de correo electrónico que fue construido para la nube desde el principio. Este enfoque nativo de la nube es fundamental para cómo diseñamos nuestras APIs de correo electrónico 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 entrar en territorio desconocido. 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 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 ocurrió el pasado viernes, y cómo lo resolvimos, haya sido útil.
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 magnífico equipo de operaciones de SparkPost, nuestro equipo de Ingeniería de Confiabilidad del Sitio (SRE), y nuestros arquitectos técnicos principales trabajan con Amazon todos los días. Las fortalezas de la infraestructura de AWS nos han dado una verdadera ventaja para optimizar 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 y funcionar rápidamente, y también tenemos el beneficio de un profundo apoyo del equipo de AWS.
Si tuviéramos que trabajar alrededor de una limitación similar en un modelo de centro de datos tradicional, algo así podría tomar días o incluso semanas para 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 pila de AWS.
SparkPost es el primer servicio de entrega de correo electrónico que fue construido para la nube desde el principio. Este enfoque nativo de la nube es fundamental para cómo diseñamos nuestras APIs de correo electrónico 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 entrar en territorio desconocido. 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 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 ocurrió el pasado viernes, y cómo lo resolvimos, haya sido útil.
