Escalabilidad IoT: cómo pasar de 100 a 10.000 dispositivos

La escalabilidad IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil no se prueba en el piloto: un despliegue de 100 sensores no se parece en nada a uno de 10.000, y el piloto funciona perfectamente hasta el día que deja de hacerlo.

La escalabilidad IoT casi nunca falla de golpe. Falla por partes, y cada parte avisa tarde: los paneles tardan un poco más, las alarmas llegan con retraso, la factura de la nube sube sin que nadie sepa explicar por qué, y el equipo de soporte pasa de atender dos incidencias al mes a diez a la semana.

Esta guía recorre lo que se rompe al multiplicar por cien: la ingesta, el almacenamiento, las consultas, las alarmas, la red y la operación humana, con cifras concretas para dimensionar cada una. Está escrita para integradores y operadores que ya tienen un piloto funcionando y están a punto de firmar el despliegue grande. Si todavía estás antes de esa frontera, la referencia es la guía de coste total de una plataforma IoT.

Escalabilidad IoT: lo que cambia al multiplicar por cien

El error de partida es pensar que escalar es el mismo sistema con más equipos. No lo es, porque tres cosas crecen a ritmos distintos:

• Los datos crecen en línea recta con el número de equipos. Es la parte previsible y la que todo el mundo calcula.
• Las consultas crecen más deprisa, porque con más equipos llegan más usuarios, más paneles y más informes sobre un histórico que además es más grande.
• El trabajo humano crece a saltos. Hasta cierto punto lo lleva una persona; pasado ese punto, no lo lleva nadie sin herramientas nuevas.

Ese tercer punto es el que sorprende. Los problemas de escalabilidad IoT que hunden un proyecto rara vez son de base de datos: son de nadie sabe qué sensor es el que falla, ni quién tiene que ir a cambiarlo.

La ingesta: de equipos a mensajes por segundo

El primer número que hay que calcular, y se calcula en dos minutos.

Un equipo que envía una lectura cada cinco minutos genera 288 mensajes al día. Diez mil equipos, 2,88 millones de mensajes diarios, que son unos 33 mensajes por segundo de media. Si cada mensaje trae cinco variables, son más de 5.000 millones de valores al año.

La media, sin embargo, no es el problema. El problema es el pico. Dos situaciones lo producen casi siempre:

El reloj redondo. Si los equipos se configuran para enviar "cada hora", muchos acaban enviando a las en punto. Diez mil mensajes en unos segundos, y luego nada durante 59 minutos. La solución es un desfase aleatorio por equipo, y se decide en el firmware o en la configuración, no en el servidor.

La reconexión masiva. Tras un corte de red o de electricidad, todos los equipos vuelven a la vez, y además traen lo que guardaron mientras no había conexión. Un despliegue que aguanta 33 mensajes por segundo puede recibir diez veces eso durante unos minutos. Aquí lo que salva es la cola: si la plataforma encola y procesa a su ritmo, la punta se absorbe; si procesa en línea, se pierden datos.

En MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil, el transporte habitual en estos despliegues, esto se traduce en decisiones de sesión y de calidad de servicio que conviene tomar antes y no después. El detalle está en la guía del broker MQTT.

El dato: almacenamiento y consultas

Retención y agregación en tres niveles

Guardar cinco mil millones de valores al año es posible y caro. La pregunta útil no es cuánto ocupa, sino cuánto tiempo hace falta el dato con todo su detalle.

La política que funciona en la mayoría de proyectos tiene tres niveles:

1. Detalle completo durante semanas o unos pocos meses, para diagnóstico y para el trabajo diario.
2. Agregados por hora o por día durante años, para informes, comparativas y facturación.
3. Borrado o archivado frío del detalle antiguo, según lo que exija el contrato o la normativa.

Un contador de agua es el ejemplo claro. Para detectar una fuga hacen falta las lecturas de los últimos días con todo su detalle. Para la factura anual o la comparación con el año pasado, basta el consumo diario. Guardar diez años de lecturas cada quince minutos no aporta nada y multiplica la factura de almacenamiento.

Con volúmenes grandes, además, la forma de las tablas importa tanto como su tamaño. En bases relacionales, el particionado por fecha permite consultar y archivar por periodos sin recorrer todo el histórico; la documentación de SQL Server explica el mecanismo. La regla de campo: si una consulta de un mes tiene que leer el histórico completo, el problema no es la cantidad de datos, es cómo están organizados.

Conviene decidir la política de retención en la fase de propuesta, porque es una de las partidas que más crece con el tiempo y una de las pocas que se puede acotar por escrito.

Las consultas y los paneles

Con cien equipos, un panel que hace una consulta por widget funciona. Con diez mil, ese mismo panel abre cientos de consultas cada vez que alguien lo carga, y lo carga mucha más gente.

Tres patrones resuelven la mayor parte:

• Consultar agregados, no crudo. Un gráfico de un año no necesita lecturas de cinco minutos: necesita valores diarios ya calculados.
• Separar lo operativo de lo analítico. El panel de alarmas tiene que ir rápido siempre. Un informe pesado se ejecuta en segundo plano y avisa al terminar, en vez de competir con la operación.
• Paginar y limitar por defecto. Una pantalla que lista "todos los dispositivos" es cómoda con cien y es un problema con diez mil.

Hay un efecto secundario que se olvida: las integraciones. Un ERP que pregunta por cada dispositivo uno a uno genera 10.000 llamadas donde debería hacer una consulta por lotes. Cuando la plataforma se queda lenta sin motivo aparente, mirar quién está llamando a la API suele explicar más que cualquier métrica de sistema. Los patrones correctos están en la guía de integración por API.

Las alarmas: la tormenta silenciosa

Este es el fallo de escalabilidad IoT más frecuente, y el más caro en credibilidad.

Con cien equipos, una regla de alarma por umbral genera un correo de vez en cuando. Con diez mil, un corte de comunicaciones dispara mil alarmas de "sin datos" en cinco minutos. Nadie lee mil correos. A la tercera vez, el cliente configura una regla en su gestor de correo y deja de leerlos todos, incluidos los que importan.

Cuatro medidas, por orden de eficacia:

1. Agrupar por causa. Mil equipos de la misma zona sin datos a la misma hora es un aviso, no mil. La agrupación por emplazamiento o por gateway convierte una tormenta en una línea.
2. Retrasar la confirmación. Una alarma que se confirma tras dos ciclos perdidos elimina la mayor parte del ruido de un enlace de radio normal.
3. Escalar en el tiempo. Aviso al técnico de zona primero, al responsable después si sigue abierto.
4. Medir el ruido. Si nadie mira cuántas alarmas se cierran solas, nadie sabe que el sistema está gritando de más.

Sara lleva el mantenimiento de una red de 3.000 sensores de alumbrado. Durante el primer invierno recibió una media de 400 avisos al día, casi todos de equipos que volvían solos en minutos. Agrupó por cuadro eléctrico y exigió dos ciclos perdidos para confirmar. Los avisos bajaron a unos quince al día, y los quince eran reales. No cambió ni un sensor.

El mismo criterio vale para las notificaciones a usuarios finales: Cloud Studio IoT envía por correo, SMS, WhatsApp, llamada de voz y push, y ninguna de esas vías sobrevive a una tormenta de alarmas sin agrupación.

La red y el campo

La escalabilidad IoT también es un problema físico, y esta parte no se resuelve con más servidores.

En LoRaWAN, el aire es un recurso compartido. Más equipos en la misma zona significan más colisiones, y los equipos con peor cobertura ocupan el canal mucho más tiempo que los que están cerca. Las redes comunitarias aplican además políticas de uso justo, como la de The Things Network, que limitan el tiempo de emisión por equipo. La densidad de gateways deja de ser una cuestión de cobertura y pasa a ser de capacidad. Lo que hay que medir antes está en la guía de alcance LoRaWAN.

En redes celulares, el límite no es el aire sino la gestión: 10.000 tarjetas SIM son 10.000 elementos que caducan, se bloquean y se facturan. Sin una integración con el operador, la administración de esas SIM se convierte en un trabajo a tiempo parcial.

En el campo, la cuenta es de personas. Con una tasa de averías anual del 2 %, diez mil equipos son 200 visitas al año, unas cuatro por semana. Eso es una ruta de mantenimiento, no una incidencia ocasional, y hay que presupuestarlo desde el principio. El inventario que sostiene esas visitas es el de la gestión de dispositivos.

Lo que se rompe entre la plataforma y el campo

Hay un tramo que no pertenece a nadie y se nota al escalar: el que va desde que un equipo deja de reportar hasta que alguien decide ir a verlo.

Con cien sensores, esa decisión la toma una persona mirando el panel por la mañana. Con diez mil, hace falta un criterio escrito: cuántos ciclos perdidos convierten un silencio en una avería, qué batería obliga a programar una visita antes de que el equipo muera, y qué avisos se agrupan en una sola ruta para no mandar a un técnico dos veces al mismo polígono en la misma semana.

Rubén coordina el mantenimiento de 4.500 equipos de telemetría de riego para una comunidad de regantes. Su primer año de despliegue grande lo resolvió atendiendo avisos según llegaban, y acabó con técnicos cruzándose en la carretera. El segundo año agrupó por comarca y fijó una ruta semanal con todo lo pendiente que no fuera urgente. El número de averías fue casi el mismo; los kilómetros bajaron a la mitad.

Esa es la diferencia entre un despliegue que crece y uno que solo se hace más grande: la escala se nota primero en la logística, no en el servidor.

La operación humana y el coste por equipo

La parte de la escalabilidad IoT que no aparece en ninguna arquitectura y decide la rentabilidad.

Con cien equipos, el nombre de cada uno lo recuerda una persona. Con diez mil hace falta una convención escrita: cómo se identifican, cómo se agrupan por zona, qué etiquetas llevan. Cambiar esa convención con el parque instalado cuesta semanas; definirla al principio cuesta una tarde. Si además hay varios clientes, la estructura la marca el modelo multi-tenant.

En cuanto al coste, la intuición engaña en las dos direcciones. Baja el coste por equipo en licencias y en infraestructura, porque hay economía de escala. Pero sube en soporte, en visitas y en gestión, porque son costes lineales con el número de equipos y con el número de clientes.

Una regla práctica: antes de firmar un despliegue grande, calcula el coste de la enésima unidad, no el de la primera. Si el número sale bien con la retención que promete el contrato y con la tasa de averías real del hardware, el proyecto se sostiene. El desglose completo está en la guía de coste total.

Probar la escalabilidad IoT antes de crecer

La forma barata de saber si el sistema aguanta es simularlo, y se hace en un día.

Cuatro pruebas que cubren casi todo:

1. Ingesta sostenida. Inyecta el volumen previsto durante varias horas y comprueba que no se acumula retraso.
2. Pico de reconexión. Simula que el 100 % de los equipos vuelve a la vez con datos guardados. Es la peor situación real.
3. Carga de paneles. Abre los paneles que usará el cliente mientras corre la ingesta. Lo que se mide es el tiempo de respuesta con carga, no en vacío.
4. Tormenta de alarmas. Provoca un corte que dispare miles de avisos y cuenta cuántos llegan al destinatario final.

Conviene repetir estas cuatro pruebas cada vez que el parque se duplique, y no solo antes del primer salto: la escalabilidad IoT es una propiedad que se pierde con el tiempo, a medida que se añaden paneles, integraciones y reglas de alarma que nadie midió.

Los pilares de fiabilidad del marco AWS Well-Architected desarrollan la idea con detalle. Lo importante en IoT es hacer las pruebas con el perfil real de tus equipos, no con tráfico sintético uniforme: un despliegue de sensores a batería que despiertan cada hora se comporta de forma muy distinta a uno de equipos conectados permanentemente.

Y una comprobación que no cuesta nada: mirar si alguien ha hecho antes algo de ese tamaño en la plataforma que estás evaluando. En el alumbrado de la ciudad de Buenos Aires, Cloud Studio IoT aporta la plataforma que gestiona y monitoriza unas 150.000 luminarias junto al partner Smartmation. Un despliegue grande ya resuelto dice más que cualquier cifra de catálogo.

Conclusión

La escalabilidad IoT no se resuelve con un servidor más grande, se resuelve tomando cinco o seis decisiones antes de crecer. Lo esencial:

• Calcula los mensajes por segundo y, sobre todo, el pico: el reloj redondo y la reconexión masiva son los dos casos reales.
• Define la retención en tres niveles. El detalle envejece rápido; los agregados son los que se usan durante años.
• Separa lo operativo de lo analítico, y consulta agregados en los paneles.
• Agrupa las alarmas por causa antes de que el cliente deje de leerlas.
• En el campo, la escala se mide en visitas al año y en personas, no en registros.
• Prueba el pico de reconexión y la tormenta de alarmas antes de firmar, no después.

Si estás dimensionando un salto de escala y quieres contrastar los números, habla con el equipo o mira cómo trabajan otros integradores en el programa de partners.

Preguntas frecuentes

¿Qué es la escalabilidad IoT?

Es la capacidad de un despliegue de seguir funcionando cuando crecen los equipos, los usuarios y los datos. No es el mismo sistema con más dispositivos: el dato crece en línea recta con el número de equipos, las consultas crecen más rápido y el trabajo humano crece a saltos.

¿Cuántos mensajes por segundo generan 10.000 dispositivos IoT?

Si cada equipo reporta cada cinco minutos, envía 288 mensajes al día. Diez mil equipos son 2,88 millones de mensajes al día, unos 33 por segundo de media. Importa más el pico que la media: los equipos que reportan todos a la hora en punto, o que se reconectan a la vez después de un corte, pueden multiplicar esa cifra por diez durante varios minutos.

¿Qué es lo primero que se rompe cuando crece un despliegue IoT?

Casi nunca es la base de datos. Lo habitual es que fallen antes las alarmas y la operación: un corte de comunicaciones dispara miles de alertas de "sin datos", y nadie sabe qué sensor falla ni quién tiene que ir a cambiarlo.

¿Cuánto tiempo hay que guardar los datos IoT?

En la mayoría de los proyectos funciona una política de tres niveles: detalle completo durante semanas o pocos meses, agregados horarios o diarios durante años, y borrado o archivo en frío del detalle antiguo según el contrato o la normativa. Conviene dejar los plazos por escrito en la propuesta para que el cliente y el equipo esperen lo mismo.

¿Cómo se evita una tormenta de alarmas?

Agrupa las alarmas por causa, por ejemplo por sede o por gateway, para que mil equipos en silencio sean una sola alerta. Confirma la alarma solo después de dos ciclos perdidos, escala con el tiempo y mide cuántas alarmas se cierran solas.

¿Cómo se prueba si una plataforma IoT va a escalar?

Con cuatro pruebas y el perfil real de tus equipos: ingesta sostenida durante varias horas, pico de reconexión con todos los equipos volviendo a la vez, carga de dashboards mientras entra el dato y una tormenta de alarmas. Repítelas cada vez que el parque se duplique.