OpenFreeMap compartilha a experiência de suportar 100 mil requisições por segundo

• OpenFreeMap processou com sucesso 100 mil requisições por segundo e 300 milhões de requisições de tráfego diário
• A súbita popularidade do Wplace.live e requisições em massa automatizadas foram a causa do pico de tráfego
• A taxa de cache do CDN da Cloudflare alcançou 99,4%, enquanto o servidor lidou sem problemas com os 1.000 rps restantes
• Como resultado, ocorreram apenas falhas pequenas, como a falta de tiles, e o serviço continuou operando normalmente na maior parte do tempo
• No futuro, serão anunciadas melhorias no gerenciamento automático de tráfego, incluindo limitação de largura de banda baseada no referer

---

A experiência de 10 meses do OpenFreeMap e da resposta ao tráfego em larga escala

OpenFreeMap vem tendo uma operação muito estável nos últimos 10 meses. A confiabilidade do sistema foi comprovada pelo suporte de largura de banda da Cloudflare, a estabilidade dos servidores Hetzner, o serviço de tiles no Btrfs e a eficiência do nginx. No entanto, em um dia, recebemos um relatório de que alguns tiles não carregavam. Normalmente isso era causado por bug de algoritmo, mas desta vez encontrou-se, no log do nginx, o erro open() "Too many open files".

Ao verificar com a ferramenta de monitoramento de tráfego, observou-se que houve 3 bilhões de requisições em 24 horas e que até arquivos de tiles pequenos geraram 215 TB de tráfego. Houve recentemente um pico de 30 milhões de requisições em 5 minutos, atingindo 100 mil requisições por segundo. Este volume de tráfego custaria mais de US$ 6 milhões por mês em serviços comerciais de mapas.

No painel da Cloudflare, 96% responderam com 200 OK e apenas 3,6% foram anômalos (206 Partial Content). A maior parte das requisições foi servida normalmente, e, excluindo alguns tiles ausentes, o sistema inteiro funcionou bem.

Causa do pico de tráfego: Wplace.live

A causa desse pico foi o novo site de desenho colaborativo Wplace.live. Logo após seu lançamento, chegou uma grande quantidade de usuários, e ele foi projetado para usar mapas baseados no OpenFreeMap. Usuários usaram ferramentas automatizadas (como Puppeteer/Chromium, rotação de IP etc.) para burlar o limite de 1 pixel/30 segundos, gerando requisições em massa.

O responsável destacou, com base em experiência anterior com o Neal.fun, a importância da comunicação prévia antes de um aumento de tráfego. Como desta vez houve impacto na operação do serviço, aplicaram-se regras da Cloudflare pela primeira vez para bloqueio. No futuro, busca-se uma solução de controle automático de tráfego baseada em referer ou cabeçalho personalizado (incluindo o uso da API da Cloudflare).

Suporte da Cloudflare e o desempenho da arquitetura do OpenFreeMap

A Cloudflare aprovou rapidamente o apoio de largura de banda em até 48 horas, incluindo fim de semana, e houve até uma discussão com engenheiros sobre a adequação da arquitetura. Mesmo sendo uma empresa grande, demonstrou resposta bastante flexível.

O operador destacou que alcançou 99,4% de taxa de cache no CDN e que o servidor suportou sem dificuldade carga de 1.000 rps. Para um serviço que oferece atualização de dados semanal, isso é um desempenho bastante alto.

Comunicação com o desenvolvedor do Wplace.live e proposta de solução

Posteriormente, foi feito contato com os desenvolvedores do Wplace.live e entendeu-se que eles não estavam preparados para o aumento repentino de 2 milhões de usuários. Discutiu-se a oferta de instâncias de auto-hospedagem do OpenFreeMap para eles, com o objetivo de reduzir a concentração de tráfego e aumentar a eficiência.

Além disso, o fato de 3 bilhões de requisições ocorrerem para apenas 2 milhões de usuários reais sugere que predominou requisição em massa baseada em script. Como usuários comuns fazem entre 10 e 20 requisições, recomendou-se ajustar a política do serviço para impedir requisições automatizadas desnecessárias.

Melhorias e aprendizados futuros

O operador anunciou duas melhorias:

1. Limite de largura de banda baseado em referer

   • A partir do Cloudflare, será implementada a limitação de solicitações por referer em faixas de 100 milhões a 200 milhões por 24 horas, entre outros cenários
   • Os aplicativos nativos serão direcionados a usar cabeçalho personalizado

2. Tratamento de tiles ausentes e melhoria da configuração do servidor

   • Serão tomadas medidas para evitar que tiles vazios sejam gerados por configuração incorreta de servidor

O OpenFreeMap é mantido atualmente por doações de US$ 500 por mês. Os custos de infraestrutura já estão cobertos, mas o desenvolvimento novo depende do tempo disponível de pessoa física. Com mais apoio, é possível ampliar a velocidade de desenvolvimento e a estabilidade do serviço.

É possível participar apoiando o projeto pelo GitHub: https://github.com/sponsors/hyperknot