OpenFreeMap comparte su experiencia de soportar 100.000 solicitudes por segundo

• OpenFreeMap procesó con éxito 100,000 solicitudes por segundo y 300 millones de solicitudes de tráfico diario
• El auge repentino de Wplace.live y las solicitudes masivas automatizadas fueron la causa del pico de tráfico
• Con una tasa de caché CDN de 99.4% de Cloudflare, el servidor soportó sin problemas los 1,000 rps restantes
• Por esto, solo se produjeron fallos menores como la pérdida de algunos tiles, y el servicio se mantuvo operativo en su mayor parte
• A partir de ahora se planea mejorar la gestión automática del tráfico con límites de ancho de banda basados en referer

---

Los últimos 10 meses de OpenFreeMap y la experiencia frente a tráfico masivo

OpenFreeMap ha tenido una experiencia de operación muy estable durante los últimos 10 meses. La fiabilidad del sistema se confirmó gracias al apoyo de ancho de banda de Cloudflare, la estabilidad del servidor de Hetzner, el servicio de tiles en Btrfs y la eficiencia de nginx. Sin embargo, de un día para otro comenzaron a llegar reportes de que algunos tiles no se cargaban. Esto suele deberse a un error de algoritmo, pero esta vez se encontró en los logs de nginx el error open() "Too many open files".

Al revisar con la herramienta de monitoreo de tráfico, se detectó que se produjeron 3 mil millones de solicitudes en 24 horas, y que solo con archivos de tile pequeños se registraron 215 TB de tráfico. En los últimos 5 minutos hubo un pico de 30 millones de solicitudes, es decir, 100.000 solicitudes por segundo. Este volumen de tráfico le habría costado más de 6 millones de dólares al mes en un servicio de mapas comercial.

En el dashboard de Cloudflare, 96% respondió con 200 OK y solo un 3.6% fue anómalo (206 Partial Content). Se confirmó que la mayoría de las solicitudes se sirven normalmente y que el sistema funciona bien, salvo algunos tiles faltantes.

Causa de la ola de tráfico: Wplace.live

La causa de este pico fue Wplace.live, un nuevo sitio web de dibujo colaborativo. Tras su lanzamiento, una gran cantidad de usuarios ingresó de golpe y el servicio fue diseñado para usar mapas basados en OpenFreeMap. Para saltarse la restricción de 1 píxel cada 30 segundos, los usuarios generaron solicitudes masivas mediante herramientas de automatización (por ejemplo, Puppeteer/Chromium, rotación de IP, etc.).

El operador destaca la importancia de la comunicación previa, mencionando la experiencia previa trabajando con Neal.fun. Esta vez, como afectó la operación del servicio, aplicó por primera vez reglas de Cloudflare para bloquear tráfico. De cara al futuro, estudia soluciones de control automático de tráfico basadas en referer o headers personalizados, incluyendo el uso de la API de Cloudflare.

Soporte de Cloudflare y el rendimiento de la arquitectura de OpenFreeMap

Cloudflare aprobó la ayuda de ancho de banda en un plazo muy rápido (en menos de 48 horas, incluyendo fin de semana), y también sostuvo una discusión técnica sobre la adecuación de la arquitectura con sus ingenieros. Aun siendo una empresa grande, mostró gran capacidad de respuesta.

El operador se siente orgulloso de haber logrado una tasa de caché CDN de 99.4% y de que el servidor haya soportado una carga de 1,000 rps. Es un desempeño bastante alto para un servicio que entrega actualizaciones de datos semanalmente.

Comunicación con el desarrollador de Wplace.live y propuestas de solución

Posteriormente se logró contactar al desarrollador de Wplace.live, quien entendió que no estaban preparados para un aumento repentino de 2 millones de usuarios. A ellos se les propuso dar soporte para instancias de OpenFreeMap auto-hospedadas, con el fin de evitar concentración de tráfico y mejorar la eficiencia.

Además, que se registraran 3 mil millones de solicitudes frente a solo 2 millones de usuarios sugiere que predominaban las solicitudes masivas basadas en scripts. Como un usuario típico solo hace entre 10 y 20 solicitudes, se recomienda modificar la política del servicio para evitar solicitudes automáticas innecesarias.

Mejoras futuras y lecciones aprendidas

El operador adelantó dos mejoras pendientes:

1. Límite de ancho de banda basado en referer

   • Se prevé implementar un límite por referer con Cloudflare, por ejemplo entre 100 y 200 millones de solicitudes por ventana de 24 horas
   • Se orientará a las apps nativas a usar custom headers

2. Manejo de tiles faltantes y mejora de la configuración del servidor

   • Se realizarán ajustes para que no se generen tiles vacíos por una configuración incorrecta del servidor

OpenFreeMap se mantiene actualmente con 500 dólares mensuales en donaciones. Los costos de infraestructura están suficientemente cubiertos, pero el desarrollo nuevo depende de tiempo personal limitado. Con apoyo adicional, podría ampliarse la velocidad de desarrollo y la estabilidad del servicio.

Puedes apoyar el proyecto mediante GitHub Sponsors: https://github.com/sponsors/hyperknot