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

[GN⁺]

Opinión de Hacker News

• Tengo la impresión de que algunas imágenes fueron dibujadas por script kiddies. El sitio solo permitía 1 píxel cada 30 segundos por usuario, así que creo que muchos automatizaron abriendo un navegador nuevo con Puppeteer o Chromium, hacían clic en un píxel y luego cerraban el navegador. Puede que incluso rotaran direcciones IP, aunque quizá ni siquiera fuera necesario. No subestimen cuánto creció esto en una sola noche y a gran escala. Cuando le mencioné un dibujo cerca de mi casa a un par de personas, sin haber dicho el nombre del sitio, todos entendieron enseguida de qué iba. A la gente le encantan este tipo de proyectos tipo /r/place cada pocos años, y esta vez parece que atrajo mucho interés porque podían pintar justo cerca de su ubicación sobre un mapa mundial.

• Me pregunto qué diferencia habría habido si esto leyera directamente archivos pmtiles estáticos desde MapLibre. Al traer pmtiles desde Bunnycdn con range request, la velocidad de respuesta se sentía casi igual a la de obtenerlos del servidor de tiles real.

  • Con wplace, pienso que un solo pmtile estático personalizado podría resolver todos los requisitos; en ese caso no hace falta procesar 150 GB de datos de OSM.

  • Comparto este enlace

• Aprecio estas explicaciones tan detalladas y la transparencia. Estoy considerando migrar el mapa de incidentes de StatusGator a OpenFreeMap en lugar de MapTiler.

  • Pueden migrar en cualquier momento. Si les preocupa la alta disponibilidad, pueden hacer self-hosting. Sigo intentando que la instancia pública sea lo más estable posible.

• Solo por las capturas de pantalla, parecía que con un solo VPS también alcanzaba, y que era un diseño demasiado complejo. Pero me di cuenta de que los píxeles están montados sobre el mapa mundial. Me pregunto cuál sería la máxima tasa de solicitudes por segundo. Tal vez esté en un nivel que apenas pueda manejar un servidor web fácil de hacer benchmark. Claro, según las características de la app, puede haber una degradación fuerte del rendimiento. Con 64 píxeles por km, para cubrir todo el planeta en color sin comprimir se necesitan 8 TB (¡algo que habrá que ver a largo plazo!). En Hetzner una caja de 10 TB cuesta 20 euros al mes; la caché parece imprescindible. wplace usa un PNG de 1000x1000 píxeles en la capa de dibujo, la imagen aparece al instante, pero el mapa en sí es muy lento y hay partes que ni siquiera cargan.

  • En Hetzner, 20 euros al mes se ve bien, pero es otra historia si siempre funciona bien en el momento en que realmente se necesita.

• Me parece que el problema era el límite de archivos abiertos. Me pregunto si con solo subir ese límite habría sido suficiente. Entiendo el bloqueo de tráfico spam, pero en teoría me pregunto si no se habría podido procesar más solo con ese ajuste.

  • Después de bastante debugging con varios LLM dejé una pregunta en el foro de la comunidad de nginx. Actualmente estimo que es por la combinación de multi_accept, open_file_cache y worker_rlimit_nofile. Si quieres más detalles, consulta aquí. El servidor estaba usando hasta 200 Mbps, así que aunque aumentaras el límite, probablemente no habría durado mucho.

• Los sitios que no implementan caché, ¿siempre es porque es 'molesto' hacerlo? Me pregunto por qué wplace.live envía tanto tráfico a OpenFreeMap y si con un solo servidor de caché propio no podría servir igual o más rápido que OpenFreeMap.

  • OpenFreeMap está detrás de un CDN, y en la página principal dice algo así: "Instancia pública gratis, sin límite de vistas/solicitudes, sin registro/cookies/API key requerida. Los costos se cubren con donaciones. Uso comercial permitido". Leyéndolo así, da la sensación de que se puede usar de inmediato. No se ve razón para poner un servidor de caché delante del CDN. Vale revisar el ancho de banda y pensarlo, pero en una situación viral inesperada uno puede estar con otras prioridades.

  • A esta pregunta se puede responder en corto: por prioridades. Yo opero un sitio de subastas bastante popular y tomo los tiles del mapa de Stadia Maps. Pago 80 dólares al mes; sé que podría hacerlo más barato cacheando los tiles y sirviéndolos desde un proxy, pero siempre hay algo más urgente y por eso aún no hice el trabajo de caché.

  • La cantidad de datos que se maneja aquí es enorme. Llegó a 56 Gbps de golpe (¡56 servidores con 100% de consumo de tráfico!). Está fuera del alcance de un servidor de caché simple. Esto debe manejarlo una red CDN tipo Cloudflare.

  • Se ve como un sitio interesante y parece no tener fines de lucro. El foco de estos sitios suele ser "hacer que funcione bien"; la respuesta a tráfico masivo no es prioridad 1. Los usuarios también se duplicaron en una noche, y la persona que lo mantiene parece ser una sola o muy poca gente.

• Nunca usé directamente Cloudflare y no estoy familiarizado con tecnología de mapas web. Si el sitio sirve sobre todo archivos estáticos, me pregunto por qué sería necesario seguir con Hetzner. Me pregunto si sería posible migrarlo completamente a Cloudflare Pages.

  • Los tiles necesitan renderizarse. Los tiles de uso frecuente ya se cachean y ese rol de caché lo hace Cloudflare. Teóricamente, sí se podría portar tileserver a Cloudflare Pages, pero igual habría que hacer portado y no parece que el costo baje.

• El límite basado en Referrer se siente como una decisión rara. Si un usuario legítimo hace 10 a 20 solicitudes por minuto, ¿no bastaría poner un límite de 100 por minuto por IP (5x el promedio) para bloquear a la mayoría? ¿O para unos pocos usuarios maliciosos no sería posible bloquear por patrones JA4/JA3?

  • También hay gente que realmente quiere explorar el planeta entero. Recuerdo haber pasado medio día viendo Google Earth. Creo que limitar por Referrer es mejor opción (a los usuarios que usan mucho tráfico les conviene redirigirlos a self-hosting en lugar de usar la instancia pública).

  • Limitar por Referrer es un buen primer paso (también habría que cambiar el mensaje de la pantalla principal). Rastrear consumo por sitio es más efectivo. Desde el sitio se puede pedir cambiar el patrón de uso, pero para el usuario individual es difícil. Sería bueno sumar límite por IP, pero si lo pones demasiado bajo en casos así no funcionará.

• Pienso que lo bloquearon muy bien. Esto fue un ataque DDoS. Menos mal que no cobraban aparte por el ancho de banda, de lo contrario habría sido un verdadero ataque de "vaciar billetera".

• La tasa de aciertos de caché es altísima. Me pregunto si tienen alguna técnica especial implementada.

  • La estructura completa de rutas y los bloques de location la diseñé pensando en caché. Si quieres, mira el ejemplo de nginx.conf