Em 18 de novembro, a Cloudflare teve um incidente que afetou milhares de clientes, incluindo clientes que utilizam o nosso serviço. Nosso serviço de proxy é hospedado na AWS em uma arquitetura de altíssima disponibilidade, que não foi afetada (nem mesmo pela recente interrupção da AWS). Também projetamos nosso sistema para ser resiliente a falhas centralizadas e para ter impacto limitado sobre os clientes caso algo saia do ar.
O incidente durou aproximadamente 5h 34min, desde a queda até a resolução completa (observamos a recuperação já nas primeiras 3 horas do incidente). Você pode ver nossa linha do tempo do incidente aqui.
Gostaríamos de compartilhar algumas observações interessantes durante a interrupção, além de destacar alguns aspectos da nossa arquitetura que limitaram o impacto sobre nossos clientes.
Observações Internas + Como Limitamos o Impacto para os Clientes
Como nosso proxy e pipeline de processamento interno são hospedados na AWS, nenhuma das nossas operações críticas foi afetada. No entanto, nosso dashboard é hospedado na Cloudflare, então foi impactado assim como a maioria dos sites na internet. Como usamos a Cloudflare para hospedagem (Cloudflare Workers/Pages/etc) e não apenas para proxy, não foi possível simplesmente redirecionar o DNS para contornar a interrupção. Além disso, muitos serviços upstream dependem da Cloudflare de uma forma ou de outra. Quando se precisa de uma distribuição de assets barata via CDN, naturalmente se acaba recorrendo à Cloudflare.
Interrupções em Serviços Upstream
Do nosso ponto de vista, conseguimos observar a interrupção a partir dos servidores upstream. Registramos um alto número de erros 5XX provenientes de servidores afetados pela interrupção da Cloudflare em nosso proxy. Também recebemos alertas sobre isso, e é possível notar que o horário do aumento nos erros coincide quase exatamente com o início da interrupção da Cloudflare às 11:48 UTC.
Como nosso proxy passa pelos load balancers da AWS e retornamos a mesma resposta HTTP das fontes de scripts upstream, obtemos todas as métricas quando interrupções como essa acontecem. Isso é uma vantagem de ter o tráfego roteado pelo nosso sistema, pois conseguimos observar interrupções imediatamente e notificar nossos clientes sobre o impacto.
Como continuamos servindo scripts durante a interrupção
Fazemos cache de requisições para scripts idênticos quando a política de cache (Cache-Control) permite. Nesse caso, scripts hospedados na Cloudflare continuaram acessíveis e permaneceriam assim até o cache ser invalidado. Essa é uma vantagem do uso do proxy cside.
Abaixo está uma captura de tela do nosso dashboard interno no Grafana mostrando as métricas de scripts durante o período da interrupção.
Durante a interrupção: o dashboard mostra que tivemos uma taxa de acerto de cache de 70,8%, o que significa que muitos scripts continuaram sendo servidos durante a interrupção e que, de outra forma, poderiam ter ficado inacessíveis.
Linha de base normal: esse percentual está próximo do habitual para nós. Por exemplo, em 17 de novembro a taxa média de acerto de cache foi de 74%, o que significa que continuamos servindo o número usual de scripts em cache.
O número total de requisições caiu, no entanto.**
O cside foi projetado para lidar com interrupções generalizadas
Esse tipo de interrupção generalizada é inevitável devido à natureza centralizada dos provedores de nuvem, mas fazemos o possível para limitar o impacto delas por meio de implantações multi-região do nosso proxy e de uma arquitetura "Fail Open" que garante que as requisições continuem passando mesmo que tudo saia do ar.
É importante destacar também que nossos serviços de edge são projetados para operar em modo "isolado" caso nosso pipeline centralizado fique indisponível. Isso significa que, mesmo sem conseguir se comunicar com esse sistema, nosso proxy continuará operacional e poderá receber e retornar requisições de scripts. Portanto, por design, a queda de um sistema centralizado não pode derrubar completamente todos os nossos nós de edge.
Você pode ler uma análise detalhada de como nossa arquitetura evita que sites fiquem fora do ar aqui.
O post do blog da Cloudflare aqui também entra em muitos detalhes e vale a leitura.
Observação sobre o tratamento de erros:
- A causa da interrupção da Cloudflare estava relacionada a um modo específico de falha em programas Rust que utilizam chamadas à função
.unwrap(), o que causou os erros 500 que observamos. Não utilizamos essa função em nenhuma parte do nosso código de proxy, que também é escrito em Rust.
O cside é formado por uma equipe de engenheiros experientes em web distribuída. Entre eles estão contribuidores principais de navegadores como o Servo, ex-engenheiros da Cloudflare e contribuidores pioneiros de projetos open source como Tailwind e Bootstrap. Nos importamos com a web; tratamos nossa infraestrutura e arquitetura como uma obra de arte. Aplaudimos empresas como a Cloudflare por compartilharem detalhes aprofundados sobre incidentes — aprendemos com eles ao longo de nossas carreiras para evitar que se repitam sempre que possível.
