Resumen Ejecutivo

Cuando una empresa de escala en logística de rápido crecimiento expandió su flota comercial activa a más de 75.000 vehículos, su infraestructura principal chocó contra un severo límite arquitectónico. Los pings de telemetría de alta frecuencia (coordenadas GPS, diagnóstico del motor, métricas de temperatura) inundaron la base de datos relacional PostgreSQL heredada, lo que provocó la saturación de IOPS del disco, contención de registros de escritura anticipada (WAL) y saturación del grupo de conexiones.

Durante las horas pico de despacho, los paneles de seguimiento de vehículos en tiempo real presentaban retrasos de hasta 15 minutos, lo que provocaba el incumplimiento de los Acuerdos de Nivel de Servicio (SLA) de los transportadores y apagones operativos diarios.

Se contrató a Betta para auditar, rediseñar y ejecutar una migración con cero tiempo de inactividad de la arquitectura de ingesta. Al reemplazar la configuración REST/PostgreSQL monolítica con una tubería de transmisión impulsada por eventos, potenciada por una pasarela Go de alta concurrencia, transmisiones de mensajes Redpanda/Kafka, procesamiento con estado de Apache Flink y almacenamiento en columnas de ClickHouse, Betta eliminó el cuello de botella de la base de datos mientras redujo los costos de infraestructura en la nube en un 58.1%.

Métricas Clave de Impacto

• Latencia de Ingesta P99: Reducida de 12.400 ms a 82 ms (reducción del 99.3%).

• Capacidad de Ingesta: Escalada de 4.200 eventos/seg a más de 125.000 eventos/seg (incremento de capacidad de 29.7x).

• Frescura de los Datos de Seguimiento: Mejorada de un retraso de más de 15 minutos a actualizaciones en tiempo real de < 450 milisegundos.

• Gasto en Infraestructura en la Nube: Reducido de $42.500/mes a $17.800/mes (ahorro de costos del 58.1%).

• Disponibilidad de la Plataforma: Elevada del 98.2% al 99.999% durante las ventanas pico de despacho.

El Desafío del Cliente: El Cuello de Botella Relacional

A medida que el cliente creció de cientos a decenas de miles de vehículos conectados activos, el volumen de emisión de telemetría aumentó exponencialmente. Cada vehículo transmitía cargas útiles de estado cada dos segundos, generando más de 37.500 solicitudes continuas de escritura por segundo durante el pico de despacho de la mañana.

Causas Técnicas Raíz Subyacentes

1. Fragmentación del Índice B-Tree: Los datos de telemetría de alta cardinalidad que llegaban desordenados forzaron escrituras aleatorias de E/S a través de los índices B-Tree de PostgreSQL. La división de páginas de índice agotó el caché shared_buffers, llevando la utilización de E/S de disco al 100%.

2. Contención de Bloqueo de Registro de Escritura Anticipada (WAL): Las operaciones INSERT continuas y sin búfer causaron una contención extrema de descarga de WAL en el disco, creando latencias de escritura exponenciales en todos los trabajadores de la aplicación.

3. Agotamiento del Grupo de Conexiones: Las escrituras lentas de la base de datos mantuvieron abiertas las conexiones HTTP en la capa de la aplicación, agotando los grupos de subprocesos y provocando fallas en cascada HTTP 504 Gateway Timeouts a través de las API públicas de seguimiento.

4. Ráfagas por Zonas Sin Cobertura Celular Fuera de Orden: Cuando los camiones de entrega volvían a emerger de zonas rurales sin señal, cargaban pings almacenados en búfer en lotes de ráfaga. Estos picos repentinos ahogaron la capa de ingesta, desencadenando graves fallas en cascada.

La Solución de Ingeniería de Betta: Arquitectura Distribuida Impulsada por Eventos

El equipo de SRE senior y arquitectos de la nube de Betta diseñó e implementó un motor de procesamiento de telemetría desacoplado y orientado primero a la transmisión, creado para la ingesta de series temporales altamente concurrentes y escalables horizontalmente.

Desglose de Componentes y Estrategia Técnica

1. Pasarela de Ingesta en Go con Asignación Cero

Betta diseñó un servicio de ingesta ligero y sin bloqueos escrito en Go utilizando valyala/fasthttp y análisis JSON de alta velocidad con sonic. La pasarela valida las cargas útiles entrantes y las envía directamente a los búferes de memoria de productores asíncronos, desacoplando el transporte de red de la durabilidad del almacenamiento en disco.

2. Búfer de Transmisión Particionado (Redpanda/Kafka)

El flujo de telemetría entrante se enrutó a un tema de Redpanda de 64 particiones con hash explícito mediante vehicle_vin.

• Particionamiento por Clave: El hash en vehicle_vin garantizó que cada métrica emitida por un vehículo determinado aterrizara exactamente en la misma partición de flujo en orden cronológico.

• Consumo Paralelo: Permitió hasta 64 trabajadores de consumo independientes y sin bloqueos en los motores de procesamiento descendentes.

3. Procesamiento de Flujo con Estado con Marcas de Agua (Apache Flink)

Para manejar volcados de reconexión celular fuera de orden sin degradar el cálculo del estado en vivo, Betta implementó una topología de procesamiento de flujo de Apache Flink utilizando Marcas de Agua de Desorden Acotado:

• Los eventos de telemetría dentro de una ventana de retraso de 15 segundos se procesan inmediatamente para el seguimiento del estado en vivo y se escriben en un caché de estado Redis activo y en el motor analítico de ClickHouse.

• Los eventos de telemetría con más de 15 segundos de antigüedad (rellenos tardíos) se separan automáticamente a través de las Salidas Laterales de Flink y se enrutan directamente a un lago de datos de Amazon S3 Parquet, evitando por completo y protegiendo la capa de base de datos operativa en tiempo real.

4. Motor de Almacenamiento Columnar de Alto Rendimiento (ClickHouse)

El almacenamiento relacional fue reemplazado por un clúster de ClickHouse que ejecuta el motor de almacenamiento ReplacingMergeTree:

• Eficiencia de Almacenamiento: La compresión de datos LZ4 redujo la utilización de disco físico en un 85% en comparación con las filas de PostgreSQL sin procesar.

• Ingesta por Lotes: Las salidas del motor se agregan en microlotes de 1 segundo antes de confirmarse, lo que permite a ClickHouse ingerir más de 100.000 filas por segundo sin incurrir en contención de bloqueo de escritura.

Estrategia de Ejecución: Migración con Cero Tiempo de Inactividad

Modificar una tubería principal que opera las 24 horas del día, los 7 días de la semana requería una estrategia de migración con cero tiempo de inactividad y aversión al riesgo, ejecutada en cuatro fases:

Automatización de Infraestructura como Código: Betta codificó las configuraciones completas de los clústeres de Kubernetes, Redpanda, Flink y ClickHouse en módulos de Terraform con control de versiones y valores de Helm, lo que permite el aprovisionamiento reproducible de entornos.

• Duplicación de Tráfico Espejo con eBPF: Utilizando la clonación de paquetes de red Cilium eBPF en la capa de Ingress de Kubernetes, el 100% del tráfico de telemetría en vivo se duplicó y se envió a la nueva tubería de transmisión en paralelo. Los SRE verificaron el rendimiento del sistema, la validación de esquemas y la integridad de los datos bajo cargas de producción reales sin impactar las operaciones de los clientes en vivo.

• Salvaguardas de Observabilidad y Alertas: Se integraron paneles de OpenTelemetry, Prometheus y Grafana para monitorear los Indicadores de Nivel de Servicio (SLI) principales. Se configuraron alertas de PagerDuty para retrasos de consumo que superen los 5.000 mensajes o latencias de la tubería P99 que superen los 500 ms.

• Transición de Lectura sin Fisuras: Las API del portal de seguimiento se actualizaron para leer el estado en tiempo real desde Redis y las analíticas de series temporales históricas desde ClickHouse. Una vez establecida la paridad en la latencia de lectura, los puntos finales de ingesta de PostgreSQL heredados se desmantelaron de forma segura.

Resultados e Impacto Comercial

Tras el despliegue, Betta realizó pruebas de carga exhaustivas para evaluar el rendimiento de la plataforma bajo condiciones simuladas que representan 3 veces la escala máxima del cliente (225.000 activos conectados activos).

Comparación de Rendimiento Técnico

Resultados Comerciales Estratégicos

• Restablecimiento del Cumplimiento del SLA del Transportador: La visibilidad de posicionamiento inferior a un segundo permitió al cliente superar los SLA de precisión en la entrega del transportador, evitando costosas multas contractuales.

• Reducción Significativa de OPEX: Al alejarse de nodos de bases de datos relacionales sobre-provisionados y con alta densidad de escritura, los costos mensuales de computación en la nube se redujeron en $296.400 anuales.

• Ganancia en Productividad de Ingeniería: Los equipos de SRE del cliente salieron de los ciclos diarios de respuesta a incidentes, redirigiendo sus esfuerzos de ingeniería hacia nuevas funciones del producto, como alertas de mantenimiento predictivo y optimización de rutas con IA.

Resumen y Próximos Pasos

Escalar cargas de trabajo de series temporales de alto rendimiento requiere alejarse de los patrones tradicionales de bases de datos y adoptar primitivas enfocadas primero en la transmisión, diseñadas para altos volúmenes de escritura. Al asociarse con Betta, el cliente eliminó cuellos de botella críticos del sistema, estabilizó los servicios principales de la plataforma y estableció una base de infraestructura capaz de soportar la expansión de la flota en los años venideros.

Asóciese con Betta

Betta ofrece servicios de ingeniería especializados para el sector B2B en DevOps, SRE, Infraestructura en la Nube y Seguridad. Ya sea que esté abordando cuellos de botella de escala, migrando sistemas heredados o modernizando la confiabilidad de la plataforma, nuestros equipos de ingeniería integrados ofrecen resultados concretos.

¿Listo para optimizar su infraestructura de nube de alto rendimiento?

Contacte al Equipo de Arquitectura de Betta para programar una evaluación de su infraestructura.