O Dia em que Nosso DNS Alcançou um Limite Não Documentado na AWS
Pássaro
7 de fev. de 2017
Engenharia
1 min read
Principais Conclusões
A SparkPost encontrou um limite de largura de banda de rede não documentado em um tipo específico de instância AWS EC2 que alimentava seu cluster DNS principal.
A dimensão tradicional das instâncias (CPU, RAM, disco) não revelou esse gargalo porque o problema estava relacionado ao tráfego de rede DNS agregado, não à escassez de recursos.
O uso de DNS para e-mails de saída de alto volume é incomumente intenso: a SparkPost gera milhões de consultas DNS para roteamento de domínios, autenticação (SPF/DKIM) e interações com a API da AWS.
A falha no DNS não decorreu de respostas DNS malformadas — em vez disso, os limites de capacidade de rede a nível de instância foram silenciosamente excedidos, causando falhas generalizadas nas consultas.
Como a AWS não documenta explicitamente esses limites de rede suaves, o diagnóstico do problema exigiu uma colaboração profunda entre a equipe SRE da SparkPost e os engenheiros da AWS.
A equipe resolveu o problema migrando os serviços DNS para tipos de instância maiores com maior largura de banda de rede e redesenhando partes da arquitetura DNS para melhor isolamento e recuperação.
Nenhum dado ou mensagem de cliente foi perdido, mas o evento destacou como arquiteturas nativas de nuvem podem atingir limites inesperados em escala — e como eles podem ser corrigidos rapidamente com a elasticidade da AWS.
Destaques de Perguntas e Respostas
O que aconteceu?
O cluster de DNS do SparkPost atingiu um teto inesperado de throughput de rede da AWS, fazendo com que as consultas DNS falhassem intermitentemente — o que atrasou a entrega de e-mails.
Por que o DNS quebrou em primeiro lugar?
DNS é extremamente dependente para e-mails de saída. Cada envio requer várias consultas (MX, TXT, SPF, DKIM), então alto volume de envios = enorme tráfego de DNS.
Esse padrão de tráfego superou um limite não documentado no tipo de instância EC2 que hospeda os servidores de nome.
Como o DNS para e-mail é diferente dos aplicativos da web?
Apps da web geralmente buscam conteúdo (clientes solicitam dados).
Serviços de entrega de e-mail empurram tráfego, desencadeando muito mais buscas DNS — frequentemente bilhões por mês.
O e-mail depende do DNS para roteamento, validação de segurança e failover.
Como a falha se manifestou?
As requisições DNS começaram a cair ou a expirar
As filas de entrega ficaram congestionadas
A latência aumentou em partes do sistema
Nada foi perdido — apenas atrasado.
Por que foi difícil diagnosticar isso?
O limite não foi documentado
A monitoração da AWS não mostrou explicitamente o gargalo
Todos os métricas tradicionais (CPU, RAM, disco) pareciam normais
A questão só surgiu sob um padrão específico de tráfego DNS de alto volume.
Como o SparkPost resolveu isso?
Atualizado para tipos de instância EC2 com teto de largura de banda de rede mais alto
Reestruturado clusters de DNS para serem mais resilientes a picos de tráfego agregado
Trabalhou com a AWS para identificar melhores padrões de sinalização/alerta para detectar isso mais cedo
Os dados do cliente ou o e-mail foram perdidos?
Não — apenas a entrega foi retardada. Assim que o DNS se estabilizou, toda a correspondência voltou a ser entregue normalmente.
Qual é a lição mais ampla?
Mesmo na nuvem, você pode encontrar limitações de escalabilidade invisíveis — mas designs nativos da nuvem lhe dão a flexibilidade para se recuperar rapidamente.
Elasticidade, parceria com a AWS e fortes práticas de SRE tornam a recuperação rápida possível.
Como Rastreamos Falhas de DNS Incomuns na AWS
Construímos o SparkPost com a ideia de que um serviço em nuvem como o nosso precisa ser nativo da nuvem. Isso não é apenas uma fachada. É a nossa arquitetura de nuvem que sustenta a escalabilidade, elasticidade e confiabilidade que são aspectos centrais do serviço SparkPost. Essas qualidades são grandes motivos pelos quais construímos nossa infraestrutura em cima da Amazon Web Services (AWS)—e é por isso que podemos oferecer aos nossos clientes garantias de nível de serviço e taxa de pico inigualáveis por qualquer outra empresa do setor.
Mas não fingimos que nunca enfrentamos desafios por bugs inesperados ou limites da tecnologia disponível. Enfrentamos algo assim na última sexta-feira, e aquele incidente levou a uma lentidão intermitente em nosso serviço e atrasos na entrega para alguns de nossos clientes.
Primeiro, deixe-me dizer que o problema foi resolvido no mesmo dia. Além disso, nenhum e-mail ou dado relacionado foi perdido. No entanto, se a entrega de seus e-mails foi atrasada por causa desse problema, por favor, aceite minhas desculpas (na verdade, um pedido de desculpas de toda a nossa equipe). Este incidente reforçou a importância de ter estratégias de backup abrangentes em prática - seja você utilizando backups de banco de dados PostgreSQL ou outros métodos de proteção de dados para garantir a continuidade dos negócios durante desafios de infraestrutura. Sabemos que você conta conosco, e é frustrante quando não estamos desempenhando no nível que você espera.
Algumas empresas são tentadas a varrer problemas como a degradação do serviço para debaixo do tapete e esperar que ninguém perceba. Você pode ter passado por isso com serviços que usou no passado. Eu sei que já passei. Mas não é assim que gostamos de conduzir os negócios.
Queria escrever sobre esse incidente por outro motivo também: aprendemos algo realmente interessante e valioso sobre nossa arquitetura de nuvem AWS. Equipes que constroem outros serviços de nuvem podem estar interessadas em aprender sobre isso.
Construímos o SparkPost com a ideia de que um serviço em nuvem como o nosso precisa ser nativo da nuvem. Isso não é apenas uma fachada. É a nossa arquitetura de nuvem que sustenta a escalabilidade, elasticidade e confiabilidade que são aspectos centrais do serviço SparkPost. Essas qualidades são grandes motivos pelos quais construímos nossa infraestrutura em cima da Amazon Web Services (AWS)—e é por isso que podemos oferecer aos nossos clientes garantias de nível de serviço e taxa de pico inigualáveis por qualquer outra empresa do setor.
Mas não fingimos que nunca enfrentamos desafios por bugs inesperados ou limites da tecnologia disponível. Enfrentamos algo assim na última sexta-feira, e aquele incidente levou a uma lentidão intermitente em nosso serviço e atrasos na entrega para alguns de nossos clientes.
Primeiro, deixe-me dizer que o problema foi resolvido no mesmo dia. Além disso, nenhum e-mail ou dado relacionado foi perdido. No entanto, se a entrega de seus e-mails foi atrasada por causa desse problema, por favor, aceite minhas desculpas (na verdade, um pedido de desculpas de toda a nossa equipe). Este incidente reforçou a importância de ter estratégias de backup abrangentes em prática - seja você utilizando backups de banco de dados PostgreSQL ou outros métodos de proteção de dados para garantir a continuidade dos negócios durante desafios de infraestrutura. Sabemos que você conta conosco, e é frustrante quando não estamos desempenhando no nível que você espera.
Algumas empresas são tentadas a varrer problemas como a degradação do serviço para debaixo do tapete e esperar que ninguém perceba. Você pode ter passado por isso com serviços que usou no passado. Eu sei que já passei. Mas não é assim que gostamos de conduzir os negócios.
Queria escrever sobre esse incidente por outro motivo também: aprendemos algo realmente interessante e valioso sobre nossa arquitetura de nuvem AWS. Equipes que constroem outros serviços de nuvem podem estar interessadas em aprender sobre isso.
Construímos o SparkPost com a ideia de que um serviço em nuvem como o nosso precisa ser nativo da nuvem. Isso não é apenas uma fachada. É a nossa arquitetura de nuvem que sustenta a escalabilidade, elasticidade e confiabilidade que são aspectos centrais do serviço SparkPost. Essas qualidades são grandes motivos pelos quais construímos nossa infraestrutura em cima da Amazon Web Services (AWS)—e é por isso que podemos oferecer aos nossos clientes garantias de nível de serviço e taxa de pico inigualáveis por qualquer outra empresa do setor.
Mas não fingimos que nunca enfrentamos desafios por bugs inesperados ou limites da tecnologia disponível. Enfrentamos algo assim na última sexta-feira, e aquele incidente levou a uma lentidão intermitente em nosso serviço e atrasos na entrega para alguns de nossos clientes.
Primeiro, deixe-me dizer que o problema foi resolvido no mesmo dia. Além disso, nenhum e-mail ou dado relacionado foi perdido. No entanto, se a entrega de seus e-mails foi atrasada por causa desse problema, por favor, aceite minhas desculpas (na verdade, um pedido de desculpas de toda a nossa equipe). Este incidente reforçou a importância de ter estratégias de backup abrangentes em prática - seja você utilizando backups de banco de dados PostgreSQL ou outros métodos de proteção de dados para garantir a continuidade dos negócios durante desafios de infraestrutura. Sabemos que você conta conosco, e é frustrante quando não estamos desempenhando no nível que você espera.
Algumas empresas são tentadas a varrer problemas como a degradação do serviço para debaixo do tapete e esperar que ninguém perceba. Você pode ter passado por isso com serviços que usou no passado. Eu sei que já passei. Mas não é assim que gostamos de conduzir os negócios.
Queria escrever sobre esse incidente por outro motivo também: aprendemos algo realmente interessante e valioso sobre nossa arquitetura de nuvem AWS. Equipes que constroem outros serviços de nuvem podem estar interessadas em aprender sobre isso.
Resumo
Encontramos limites práticos não documentados das instâncias EC2 que estávamos usando para nosso cluster DNS principal. Dimensionar instâncias na nuvem com base em especificações tradicionais (processador, memória, etc.) geralmente funciona da forma que você espera, mas às vezes esse modelo de hardware tradicional não se aplica. Isso é especialmente verdade em casos de uso atípicos onde limites agregados podem entrar em jogo—e há momentos em que você se depara com esses cenários sem aviso.
Encontramos um limite desse tipo na sexta-feira, quando o volume de consultas DNS criou um padrão de uso de rede para o qual nosso tipo de instância não estava preparado. No entanto, como esse limite não era óbvio nos documentos ou nas métricas padrão disponíveis, não sabíamos que o havíamos atingido. O que observamos foi uma taxa muito alta de falhas DNS, que por sua vez levou a atrasos intermitentes em diferentes pontos da nossa arquitetura.
Encontramos limites práticos não documentados das instâncias EC2 que estávamos usando para nosso cluster DNS principal. Dimensionar instâncias na nuvem com base em especificações tradicionais (processador, memória, etc.) geralmente funciona da forma que você espera, mas às vezes esse modelo de hardware tradicional não se aplica. Isso é especialmente verdade em casos de uso atípicos onde limites agregados podem entrar em jogo—e há momentos em que você se depara com esses cenários sem aviso.
Encontramos um limite desse tipo na sexta-feira, quando o volume de consultas DNS criou um padrão de uso de rede para o qual nosso tipo de instância não estava preparado. No entanto, como esse limite não era óbvio nos documentos ou nas métricas padrão disponíveis, não sabíamos que o havíamos atingido. O que observamos foi uma taxa muito alta de falhas DNS, que por sua vez levou a atrasos intermitentes em diferentes pontos da nossa arquitetura.
Encontramos limites práticos não documentados das instâncias EC2 que estávamos usando para nosso cluster DNS principal. Dimensionar instâncias na nuvem com base em especificações tradicionais (processador, memória, etc.) geralmente funciona da forma que você espera, mas às vezes esse modelo de hardware tradicional não se aplica. Isso é especialmente verdade em casos de uso atípicos onde limites agregados podem entrar em jogo—e há momentos em que você se depara com esses cenários sem aviso.
Encontramos um limite desse tipo na sexta-feira, quando o volume de consultas DNS criou um padrão de uso de rede para o qual nosso tipo de instância não estava preparado. No entanto, como esse limite não era óbvio nos documentos ou nas métricas padrão disponíveis, não sabíamos que o havíamos atingido. O que observamos foi uma taxa muito alta de falhas DNS, que por sua vez levou a atrasos intermitentes em diferentes pontos da nossa arquitetura.
Desenterrando Mais Profundamente o DNS
Por que o uso do nosso DNS é especial? Bem, isso tem muito a ver com a maneira como o e-mail funciona, em comparação com o modelo de conteúdo para o qual a AWS foi originalmente projetada. A entrega de conteúdo baseada na web faz uso intenso do que pode ser considerado cenários clássicos de “pull” de entrada: um cliente solicita dados, seja HTML, streams de vídeo ou qualquer outra coisa, da nuvem. Mas os casos de uso para provedores de serviços de mensagens como o SparkPost são exceções ao cenário usual da AWS. No nosso caso, fazemos muito empurrar de tráfego de saída: especificamente, e-mail (e outros tipos de mensagens como SMS ou notificações push para dispositivos móveis). E esse tráfego de estilo push depende fortemente do DNS.
Se você está familiarizado com DNS, pode saber que geralmente são dados bastante leves. Para solicitar uma determinada página HTML, você primeiro precisa perguntar onde essa página pode ser encontrada na Internet, mas esse pedido é uma fração do tamanho do conteúdo que você recupera.
No entanto, o e-mail faz uso excepcionalmente intenso de DNS para pesquisar domínios de entrega—por exemplo, o SparkPost envia bilhões de e-mails para mais de 1 milhão de domínios únicos todos os meses. Para cada e-mail que entregamos, temos que fazer um mínimo de duas pesquisas DNS, e o uso de registros “txt” DNS para tecnologias de combate ao phishing, como SPF e DKIM, significa que o DNS também é necessário para receber e-mails. Além disso, nosso uso mais tradicional dos serviços de API da AWS para nossos aplicativos, é difícil exagerar quão importante o DNS é para nossa infraestrutura.
Tudo isso significa que encontramos uma condição incomum em que nosso crescente volume de mensagens de saída criou um volume de tráfego DNS que atingiu um limite de throughput agregado em tipos de instância que, de outra forma, pareciam ter recursos suficientes para atender essa carga. E como ataques de negação de serviço na infraestrutura Dyn DNS do ano passado demonstraram, quando o DNS falha, tudo quebra. (Isso é algo que qualquer um que constrói sistemas que dependem do DNS já sabe dolorosamente bem.)
Os repentes problemas no DNS acionaram uma resposta de nossas equipes de operações e engenharia de confiabilidade para identificar o problema. Eles se juntaram aos nossos parceiros na Amazon para escalar do lado das operações da AWS. Trabalhando juntos, identificamos a causa e uma solução. Desdobramos um cluster de servidores de nomes de maior capacidade com um foco maior na capacidade de rede que poderia atender nossas necessidades de DNS sem atingir os limites de throughput. Felizmente, como tudo isso estava dentro da AWS, pudemos criar novas instâncias e até redimensionar instâncias existentes muito rapidamente. O DNS retomou o comportamento normal, as falhas de pesquisa cessaram, e nós (e a entrega de mensagens de saída) voltamos aos trilhos.
Para mitigar esse problema específico no futuro, estamos também fazendo alterações na arquitetura do DNS para melhor isolar nossos componentes principais do impacto de encontros com limites inesperados semelhantes. Estamos também trabalhando com a equipe da Amazon para determinar modelos de monitoramento apropriados que nos darão um aviso adequado para evitar um incidente semelhante antes que afete qualquer um de nossos clientes.
Tópico | Carga de Trabalho Típica da AWS | Carga de Trabalho de E-mail de Saída do SparkPost |
|---|---|---|
Padrão de Tráfego | Principalmente solicitações “pull” de entrada (páginas da web, APIs, mídia) | Tráfego intenso de “push” de saída (bilhões de e-mails) |
Dependência de DNS | Leve: 1–2 pesquisas por solicitação de conteúdo | Muito pesado: múltiplas pesquisas DNS por e-mail + verificações TXT SPF/DKIM |
Volume de Consultas | Previsível e proporcional à atividade do usuário | Explode com campanhas de saída visando milhões de domínios |
Tipo de Gargalo | Limites de CPU, memória ou armazenamento | Limites de throughput de rede agregada em tipos de instância |
Modo de Falha | Latência degradada ou tempo limite da API | Falhas de pesquisa DNS causando atrasos na entrega |
Visibilidade | Limites tipicamente documentados e apresentados em métricas | O teto de throughput não estava documentado e era invisível no CloudWatch |
Abordagem de Mitigação | Escalar recursos da instância ou adicionar cache | Migrar para famílias de instâncias de maior largura de banda + redesign da arquitetura DNS |
Por que o uso do nosso DNS é especial? Bem, isso tem muito a ver com a maneira como o e-mail funciona, em comparação com o modelo de conteúdo para o qual a AWS foi originalmente projetada. A entrega de conteúdo baseada na web faz uso intenso do que pode ser considerado cenários clássicos de “pull” de entrada: um cliente solicita dados, seja HTML, streams de vídeo ou qualquer outra coisa, da nuvem. Mas os casos de uso para provedores de serviços de mensagens como o SparkPost são exceções ao cenário usual da AWS. No nosso caso, fazemos muito empurrar de tráfego de saída: especificamente, e-mail (e outros tipos de mensagens como SMS ou notificações push para dispositivos móveis). E esse tráfego de estilo push depende fortemente do DNS.
Se você está familiarizado com DNS, pode saber que geralmente são dados bastante leves. Para solicitar uma determinada página HTML, você primeiro precisa perguntar onde essa página pode ser encontrada na Internet, mas esse pedido é uma fração do tamanho do conteúdo que você recupera.
No entanto, o e-mail faz uso excepcionalmente intenso de DNS para pesquisar domínios de entrega—por exemplo, o SparkPost envia bilhões de e-mails para mais de 1 milhão de domínios únicos todos os meses. Para cada e-mail que entregamos, temos que fazer um mínimo de duas pesquisas DNS, e o uso de registros “txt” DNS para tecnologias de combate ao phishing, como SPF e DKIM, significa que o DNS também é necessário para receber e-mails. Além disso, nosso uso mais tradicional dos serviços de API da AWS para nossos aplicativos, é difícil exagerar quão importante o DNS é para nossa infraestrutura.
Tudo isso significa que encontramos uma condição incomum em que nosso crescente volume de mensagens de saída criou um volume de tráfego DNS que atingiu um limite de throughput agregado em tipos de instância que, de outra forma, pareciam ter recursos suficientes para atender essa carga. E como ataques de negação de serviço na infraestrutura Dyn DNS do ano passado demonstraram, quando o DNS falha, tudo quebra. (Isso é algo que qualquer um que constrói sistemas que dependem do DNS já sabe dolorosamente bem.)
Os repentes problemas no DNS acionaram uma resposta de nossas equipes de operações e engenharia de confiabilidade para identificar o problema. Eles se juntaram aos nossos parceiros na Amazon para escalar do lado das operações da AWS. Trabalhando juntos, identificamos a causa e uma solução. Desdobramos um cluster de servidores de nomes de maior capacidade com um foco maior na capacidade de rede que poderia atender nossas necessidades de DNS sem atingir os limites de throughput. Felizmente, como tudo isso estava dentro da AWS, pudemos criar novas instâncias e até redimensionar instâncias existentes muito rapidamente. O DNS retomou o comportamento normal, as falhas de pesquisa cessaram, e nós (e a entrega de mensagens de saída) voltamos aos trilhos.
Para mitigar esse problema específico no futuro, estamos também fazendo alterações na arquitetura do DNS para melhor isolar nossos componentes principais do impacto de encontros com limites inesperados semelhantes. Estamos também trabalhando com a equipe da Amazon para determinar modelos de monitoramento apropriados que nos darão um aviso adequado para evitar um incidente semelhante antes que afete qualquer um de nossos clientes.
Tópico | Carga de Trabalho Típica da AWS | Carga de Trabalho de E-mail de Saída do SparkPost |
|---|---|---|
Padrão de Tráfego | Principalmente solicitações “pull” de entrada (páginas da web, APIs, mídia) | Tráfego intenso de “push” de saída (bilhões de e-mails) |
Dependência de DNS | Leve: 1–2 pesquisas por solicitação de conteúdo | Muito pesado: múltiplas pesquisas DNS por e-mail + verificações TXT SPF/DKIM |
Volume de Consultas | Previsível e proporcional à atividade do usuário | Explode com campanhas de saída visando milhões de domínios |
Tipo de Gargalo | Limites de CPU, memória ou armazenamento | Limites de throughput de rede agregada em tipos de instância |
Modo de Falha | Latência degradada ou tempo limite da API | Falhas de pesquisa DNS causando atrasos na entrega |
Visibilidade | Limites tipicamente documentados e apresentados em métricas | O teto de throughput não estava documentado e era invisível no CloudWatch |
Abordagem de Mitigação | Escalar recursos da instância ou adicionar cache | Migrar para famílias de instâncias de maior largura de banda + redesign da arquitetura DNS |
Por que o uso do nosso DNS é especial? Bem, isso tem muito a ver com a maneira como o e-mail funciona, em comparação com o modelo de conteúdo para o qual a AWS foi originalmente projetada. A entrega de conteúdo baseada na web faz uso intenso do que pode ser considerado cenários clássicos de “pull” de entrada: um cliente solicita dados, seja HTML, streams de vídeo ou qualquer outra coisa, da nuvem. Mas os casos de uso para provedores de serviços de mensagens como o SparkPost são exceções ao cenário usual da AWS. No nosso caso, fazemos muito empurrar de tráfego de saída: especificamente, e-mail (e outros tipos de mensagens como SMS ou notificações push para dispositivos móveis). E esse tráfego de estilo push depende fortemente do DNS.
Se você está familiarizado com DNS, pode saber que geralmente são dados bastante leves. Para solicitar uma determinada página HTML, você primeiro precisa perguntar onde essa página pode ser encontrada na Internet, mas esse pedido é uma fração do tamanho do conteúdo que você recupera.
No entanto, o e-mail faz uso excepcionalmente intenso de DNS para pesquisar domínios de entrega—por exemplo, o SparkPost envia bilhões de e-mails para mais de 1 milhão de domínios únicos todos os meses. Para cada e-mail que entregamos, temos que fazer um mínimo de duas pesquisas DNS, e o uso de registros “txt” DNS para tecnologias de combate ao phishing, como SPF e DKIM, significa que o DNS também é necessário para receber e-mails. Além disso, nosso uso mais tradicional dos serviços de API da AWS para nossos aplicativos, é difícil exagerar quão importante o DNS é para nossa infraestrutura.
Tudo isso significa que encontramos uma condição incomum em que nosso crescente volume de mensagens de saída criou um volume de tráfego DNS que atingiu um limite de throughput agregado em tipos de instância que, de outra forma, pareciam ter recursos suficientes para atender essa carga. E como ataques de negação de serviço na infraestrutura Dyn DNS do ano passado demonstraram, quando o DNS falha, tudo quebra. (Isso é algo que qualquer um que constrói sistemas que dependem do DNS já sabe dolorosamente bem.)
Os repentes problemas no DNS acionaram uma resposta de nossas equipes de operações e engenharia de confiabilidade para identificar o problema. Eles se juntaram aos nossos parceiros na Amazon para escalar do lado das operações da AWS. Trabalhando juntos, identificamos a causa e uma solução. Desdobramos um cluster de servidores de nomes de maior capacidade com um foco maior na capacidade de rede que poderia atender nossas necessidades de DNS sem atingir os limites de throughput. Felizmente, como tudo isso estava dentro da AWS, pudemos criar novas instâncias e até redimensionar instâncias existentes muito rapidamente. O DNS retomou o comportamento normal, as falhas de pesquisa cessaram, e nós (e a entrega de mensagens de saída) voltamos aos trilhos.
Para mitigar esse problema específico no futuro, estamos também fazendo alterações na arquitetura do DNS para melhor isolar nossos componentes principais do impacto de encontros com limites inesperados semelhantes. Estamos também trabalhando com a equipe da Amazon para determinar modelos de monitoramento apropriados que nos darão um aviso adequado para evitar um incidente semelhante antes que afete qualquer um de nossos clientes.
Tópico | Carga de Trabalho Típica da AWS | Carga de Trabalho de E-mail de Saída do SparkPost |
|---|---|---|
Padrão de Tráfego | Principalmente solicitações “pull” de entrada (páginas da web, APIs, mídia) | Tráfego intenso de “push” de saída (bilhões de e-mails) |
Dependência de DNS | Leve: 1–2 pesquisas por solicitação de conteúdo | Muito pesado: múltiplas pesquisas DNS por e-mail + verificações TXT SPF/DKIM |
Volume de Consultas | Previsível e proporcional à atividade do usuário | Explode com campanhas de saída visando milhões de domínios |
Tipo de Gargalo | Limites de CPU, memória ou armazenamento | Limites de throughput de rede agregada em tipos de instância |
Modo de Falha | Latência degradada ou tempo limite da API | Falhas de pesquisa DNS causando atrasos na entrega |
Visibilidade | Limites tipicamente documentados e apresentados em métricas | O teto de throughput não estava documentado e era invisível no CloudWatch |
Abordagem de Mitigação | Escalar recursos da instância ou adicionar cache | Migrar para famílias de instâncias de maior largura de banda + redesign da arquitetura DNS |
AWS e o Lado Bom da Nuvem
Eu não quero minimizar o impacto deste incidente em nossos clientes. Mas nossa capacidade de identificar o problema subjacente como uma interação inesperada do nosso caso de uso com a infraestrutura da AWS — e então encontrar uma resolução para isso em um curto espaço de tempo — tem muito a ver com como construímos o SparkPost e nosso ótimo relacionamento com a equipe da Amazon.
A superb corporação de operações do SparkPost, nossa equipe de Engenharia de Confiabilidade de Sites (SRE) e nossos principais arquitetos técnicos trabalham com a Amazon todos os dias. As forças da infraestrutura da AWS nos deram uma verdadeira vantagem otimizando a arquitetura do SparkPost para a nuvem. Trabalhar tão de perto com a AWS nos últimos dois anos também nos ensinou muito sobre como criar infraestrutura da AWS e operar rapidamente, e também temos o benefício de um suporte profundo da equipe da AWS.
Se tivéssemos que contornar uma limitação semelhante em um modelo tradicional de centro de dados, algo assim poderia levar dias ou até semanas para ser totalmente resolvido. Essa agilidade e capacidade de resposta são apenas duas das razões pelas quais apostamos nosso negócio na nuvem e na AWS. Juntas, o tipo de especialização em nuvem que nossas empresas compartilham é difícil de encontrar. A Amazon tem sido uma grande parceira de negócios para nós, e estamos realmente orgulhosos do que fizemos com a pilha da AWS.
O SparkPost é o primeiro serviço de entrega de e-mail que foi construído para a nuvem desde o início. Essa abordagem nativa da nuvem é fundamental para como projetamos nossas APIs de e-mail para infraestrutura na nuvem, garantindo escalabilidade e confiabilidade para os desenvolvedores. Enviamos mais e-mails de uma verdadeira plataforma em nuvem do que qualquer um, e às vezes isso significa entrar em território inexplorado. É uma verdade fundamental da ciência da computação que você não sabe quais desafios surgem em grande escala até que os encontre. Encontramos um na AWS, mas nossa resposta rápida é um ótimo exemplo da flexibilidade que a nuvem torna possível. É também o nosso compromisso com nossos clientes.
Seja construindo sua própria infraestrutura na AWS ou sendo um cliente do SparkPost que aproveita a nossa, espero que esta explicação do que aconteceu na última sexta-feira e como o resolvemos tenha sido útil.
Eu não quero minimizar o impacto deste incidente em nossos clientes. Mas nossa capacidade de identificar o problema subjacente como uma interação inesperada do nosso caso de uso com a infraestrutura da AWS — e então encontrar uma resolução para isso em um curto espaço de tempo — tem muito a ver com como construímos o SparkPost e nosso ótimo relacionamento com a equipe da Amazon.
A superb corporação de operações do SparkPost, nossa equipe de Engenharia de Confiabilidade de Sites (SRE) e nossos principais arquitetos técnicos trabalham com a Amazon todos os dias. As forças da infraestrutura da AWS nos deram uma verdadeira vantagem otimizando a arquitetura do SparkPost para a nuvem. Trabalhar tão de perto com a AWS nos últimos dois anos também nos ensinou muito sobre como criar infraestrutura da AWS e operar rapidamente, e também temos o benefício de um suporte profundo da equipe da AWS.
Se tivéssemos que contornar uma limitação semelhante em um modelo tradicional de centro de dados, algo assim poderia levar dias ou até semanas para ser totalmente resolvido. Essa agilidade e capacidade de resposta são apenas duas das razões pelas quais apostamos nosso negócio na nuvem e na AWS. Juntas, o tipo de especialização em nuvem que nossas empresas compartilham é difícil de encontrar. A Amazon tem sido uma grande parceira de negócios para nós, e estamos realmente orgulhosos do que fizemos com a pilha da AWS.
O SparkPost é o primeiro serviço de entrega de e-mail que foi construído para a nuvem desde o início. Essa abordagem nativa da nuvem é fundamental para como projetamos nossas APIs de e-mail para infraestrutura na nuvem, garantindo escalabilidade e confiabilidade para os desenvolvedores. Enviamos mais e-mails de uma verdadeira plataforma em nuvem do que qualquer um, e às vezes isso significa entrar em território inexplorado. É uma verdade fundamental da ciência da computação que você não sabe quais desafios surgem em grande escala até que os encontre. Encontramos um na AWS, mas nossa resposta rápida é um ótimo exemplo da flexibilidade que a nuvem torna possível. É também o nosso compromisso com nossos clientes.
Seja construindo sua própria infraestrutura na AWS ou sendo um cliente do SparkPost que aproveita a nossa, espero que esta explicação do que aconteceu na última sexta-feira e como o resolvemos tenha sido útil.
Eu não quero minimizar o impacto deste incidente em nossos clientes. Mas nossa capacidade de identificar o problema subjacente como uma interação inesperada do nosso caso de uso com a infraestrutura da AWS — e então encontrar uma resolução para isso em um curto espaço de tempo — tem muito a ver com como construímos o SparkPost e nosso ótimo relacionamento com a equipe da Amazon.
A superb corporação de operações do SparkPost, nossa equipe de Engenharia de Confiabilidade de Sites (SRE) e nossos principais arquitetos técnicos trabalham com a Amazon todos os dias. As forças da infraestrutura da AWS nos deram uma verdadeira vantagem otimizando a arquitetura do SparkPost para a nuvem. Trabalhar tão de perto com a AWS nos últimos dois anos também nos ensinou muito sobre como criar infraestrutura da AWS e operar rapidamente, e também temos o benefício de um suporte profundo da equipe da AWS.
Se tivéssemos que contornar uma limitação semelhante em um modelo tradicional de centro de dados, algo assim poderia levar dias ou até semanas para ser totalmente resolvido. Essa agilidade e capacidade de resposta são apenas duas das razões pelas quais apostamos nosso negócio na nuvem e na AWS. Juntas, o tipo de especialização em nuvem que nossas empresas compartilham é difícil de encontrar. A Amazon tem sido uma grande parceira de negócios para nós, e estamos realmente orgulhosos do que fizemos com a pilha da AWS.
O SparkPost é o primeiro serviço de entrega de e-mail que foi construído para a nuvem desde o início. Essa abordagem nativa da nuvem é fundamental para como projetamos nossas APIs de e-mail para infraestrutura na nuvem, garantindo escalabilidade e confiabilidade para os desenvolvedores. Enviamos mais e-mails de uma verdadeira plataforma em nuvem do que qualquer um, e às vezes isso significa entrar em território inexplorado. É uma verdade fundamental da ciência da computação que você não sabe quais desafios surgem em grande escala até que os encontre. Encontramos um na AWS, mas nossa resposta rápida é um ótimo exemplo da flexibilidade que a nuvem torna possível. É também o nosso compromisso com nossos clientes.
Seja construindo sua própria infraestrutura na AWS ou sendo um cliente do SparkPost que aproveita a nossa, espero que esta explicação do que aconteceu na última sexta-feira e como o resolvemos tenha sido útil.
