2025-11-12T05:49:09.677536

Multi-Event Triggers for Serverless Computing

Carl, Schirmer, Kowallik et al.
Function-as-a-Service (FaaS) is an event-driven serverless cloud computing model in which small, stateless functions are invoked in response to events, such as HTTP requests, new database entries, or messages. Current FaaS platform assume that each function invocation corresponds to a single event. However, from an application perspective, it is desirable to invoke functions in response to a collection of events of different types or only with every n\textsuperscript{th} event. To implement this today, a function would need additional state management, e.g., in a database, and custom logic to determine whether its trigger condition is fulfilled and the actual application code should run. In such an implementation, most function invocations would be rendered essentially useless, leading to unnecessarily high resource usage, latency, and cost for applications. In this paper, we introduce multi-event triggers, through which complex conditions for function invocations can be specified. Specifically, we introduce abstractions for invoking functions based on a set of $n$ events and joins of multiple events of different types. This enables application developers to define intricate conditions for function invocations, workflow steps, and complex event processing. Our evaluation with a proof-of-concept prototype shows that this reduces event--invocation latency by 62.5\% in an incident detection use-case and that our system can handle more than 300,000 requests per second on limited hardware, which is sufficient load for implementation in large FaaS platforms.
academic

Disparadores Multi-Evento para Computación sin Servidor

Información Básica

  • ID del Artículo: 2505.21199
  • Título: Multi-Event Triggers for Serverless Computing
  • Autores: Natalie Carl, Trever Schirmer, Niklas Kowallik, Joshua Adamek, Tobias Pfandzelter, Sergio Lucia, David Bermbach
  • Clasificación: cs.DC (Computación Distribuida, Paralela y en Clúster)
  • Fecha de Publicación: arXiv:2505.21199v3 cs.DC 11 Oct 2025
  • Enlace del Artículo: https://arxiv.org/abs/2505.21199

Resumen

Function-as-a-Service (FaaS) es un modelo de computación en la nube sin servidor impulsado por eventos, donde pequeñas funciones sin estado se invocan en respuesta a eventos (como solicitudes HTTP, nuevas entradas de base de datos o mensajes). Las plataformas FaaS actuales asumen que cada invocación de función corresponde a un único evento. Sin embargo, desde la perspectiva de la aplicación, es deseable que las funciones respondan a conjuntos de diferentes tipos de eventos o solo se invoquen cada n-ésimo evento. Para lograr esto, las funciones requieren gestión de estado adicional (como bases de datos) y lógica personalizada para determinar si se cumplen las condiciones de disparo. Este artículo propone disparadores multi-evento (multi-event triggers), que permiten especificar condiciones complejas de invocación de funciones. Los resultados de evaluación muestran que en casos de uso de detección de eventos, este enfoque reduce la latencia evento-invocación en un 62,5%, y el sistema puede manejar más de 300.000 solicitudes/segundo en hardware limitado.

Contexto de Investigación y Motivación

Definición del Problema

Las plataformas FaaS actuales tienen una limitación fundamental: cada invocación de función solo puede responder a un único evento. Sin embargo, las aplicaciones reales frecuentemente requieren implementar patrones de disparo más complejos:

  1. Patrón de Abanico de Entrada/Unión (Fan-in/Join): Necesita recopilar múltiples eventos de diferentes tipos antes de disparar la función
  2. Disparo por Conteo: Dispara la función solo después de recibir n eventos
  3. Disparo por Condiciones Complejas: Basado en combinaciones AND/OR de tipos y cantidades de eventos

Limitaciones de los Enfoques Existentes

La implementación actual de disparadores multi-evento requiere:

  • Mantener estado en la función, necesitando almacenamiento en base de datos externa
  • Invocar la función para cada evento, pero la mayoría de invocaciones solo actualizan estado sin ejecutar lógica empresarial
  • Resultando en consumo innecesario de recursos, aumento de latencia y costos elevados
  • Violando el principio de diseño de que las plataformas FaaS deben manejar distribución de eventos e invocación de funciones

Motivación de la Investigación

Para mantener las ventajas del modelo de programación FaaS (bajo acoplamiento, escalado automático, desarrollo fácil), es necesario integrar la lógica de disparadores multi-evento en el mecanismo de disparo de la plataforma FaaS, en lugar de que los desarrolladores de aplicaciones la manejen manualmente.

Contribuciones Principales

  1. Propuesta del Concepto de Disparadores Multi-Evento: Extensión del mecanismo de disparo de funciones FaaS para soportar condiciones de disparo complejas basadas en conjuntos de eventos
  2. Diseño de la Arquitectura del Motor MET: Propuesta de diseño de motor de disparadores multi-evento que puede integrarse en plataformas FaaS existentes
  3. Desarrollo de Sistema Prototipo: Implementación de prototipo de prueba de concepto que demuestra la viabilidad del diseño
  4. Evaluación de Rendimiento: Validación del potencial y rendimiento de los disparadores multi-evento en casos de uso de detección de eventos

Explicación Detallada del Método

Definición de Tareas

Los disparadores multi-evento permiten a los desarrolladores definir reglas de disparo complejas que especifican cuándo se invoca una función cuando se cumplen condiciones específicas de combinación de eventos. Las reglas de disparo se componen de tipos de eventos y cantidades correspondientes, soportando combinaciones de condiciones AND y OR.

Definición Formalizada de Reglas de Disparo

<rule> ::= <count> ":" <type> |
           <condition> "(" <rule> "," <rule> ")"
<condition> ::= "AND" | "OR"
<count> ::= regexp:[0-9]+
<type> ::= regexp:[a-zA-Z]+

Arquitectura del Motor MET

Diseño General

El motor MET contiene dos componentes principales que pueden escalarse independientemente:

  1. Distribuidor (Dispatcher):
    • Recibe eventos del balanceador de carga
    • Reenvía eventos a los invocadores apropiados
  2. Invocador (Invoker):
    • Procesa la lógica de disparo
    • Crea manejadores de disparo para cada MET
    • Mantiene conjuntos de disparo para cada tipo de evento
    • Verifica si se cumplen las reglas de disparo e invoca funciones

Mecanismo de Comunicación

  • Distribuidor e invocadores utilizan paso de mensajes publicación/suscripción sin intermediario
  • Los invocadores se suscriben a eventos del distribuidor basándose en tipos de eventos en las reglas de disparo que procesan
  • Soporta despliegue distribuido en configuraciones de múltiples nodos y máquina única

Diseño de Escalabilidad

  • Aumenta la cantidad de disparadores procesables mediante despliegue de invocadores adicionales
  • Soporta particionamiento de disparadores para mejorar aún más la capacidad de procesamiento
  • Objetivo de capacidad de procesamiento: 10^5 alto a 10^5 bajo solicitudes/segundo (referencia de carga de AWS Lambda en una única zona de disponibilidad)

Puntos de Innovación Técnica

  1. Soporte Nativo de Plataforma: Integra lógica multi-evento en el mecanismo de disparo, no en la capa de aplicación
  2. Optimización de Gestión de Estado: Gestión centralizada de estado en el motor de disparo, evitando invocar función para cada evento
  3. Arquitectura Modular: Soporta escalado independiente de componentes de distribución e invocación
  4. Particionamiento de Disparadores: Soporta mayor capacidad de procesamiento concurrente mediante particionamiento

Configuración Experimental

Implementación del Prototipo

  • Lenguaje de Programación: Implementación en Go del distribuidor e invocador
  • Plataforma de Despliegue: Clúster Kubernetes (Google Kubernetes Engine)
  • Paso de Mensajes: Biblioteca ZeroMQ
  • Balanceo de Carga: Servicio Kubernetes LoadBalancer
  • Plataforma de Funciones: Cualquier plataforma FaaS compatible con HTTP

Escenarios de Evaluación

Experimento 1: Prueba de Latencia

  • Caso de Uso: Aplicación de detección de eventos de centro de datos
  • Tipos de Sensores: Temperatura, tasa de pérdida de paquetes, consumo de energía
  • Regla de Disparo: OR(AND(5:packetLoss, 1:temperature), 1:powerConsumption)
  • Línea Base de Comparación: Gestión manual de estado usando base de datos PostgreSQL
  • Generación de Carga: Generador de carga k6, prueba de 30 minutos

Experimento 2: Prueba de Solicitudes Concurrentes

  • Configuración de Hardware:
    • Nodo único: c7i.2xlarge (8 vCPU, 16 GiB)
    • Cuatro nodos: 4×c7i.2xlarge
    • Generador de carga: c7i.16xlarge (64 vCPU, 128 GiB)
  • Regla de Disparo: 3:a (dispara una vez cada tres eventos)
  • Carga: Carga de caracteres aleatorios de 1.024 bytes

Experimento 3: Prueba de Disparadores Concurrentes

  • Hardware: c7i.large (4 vCPU, 8 GiB)
  • Regla de Disparo: AND(2:a, 2:b), hasta 1.024 disparadores concurrentes
  • Carga: 128 usuarios virtuales, carga de 1.024 bytes

Resultados Experimentales

Resultados Principales

Mejora de Rendimiento de Latencia

  • Reducción de Latencia Evento-Invocación del 62,5% (mediana)
  • Reducción de 4,3 veces en cantidad de invocaciones de función (comparado con línea base que invoca función para cada evento)
  • Reducción significativa de sobrecarga de invocaciones de función innecesarias

Rendimiento de Rendimiento

  • Configuración de Nodo Único: Máximo 131.012,7 solicitudes/segundo (4.096 usuarios virtuales)
  • Configuración de Cuatro Nodos: Máximo 313.154,81 solicitudes/segundo (64 usuarios virtuales)
  • El rendimiento crece linealmente con solicitudes concurrentes hasta 2^11 solicitudes

Rendimiento de Disparadores Concurrentes

  • Disparador Único: 236.601,77 solicitudes/segundo
  • 8 Disparadores: 63.717,27 solicitudes/segundo
  • 1.024 Disparadores: 883,67 solicitudes/segundo
  • El rendimiento está principalmente limitado por CPU, optimizable mediante paralelización de verificación de reglas de disparo

Hallazgos Experimentales

  1. Mejora Significativa de Latencia: El motor MET reduce significativamente la latencia de procesamiento de eventos comparado con métodos de gestión manual de estado
  2. Buena Escalabilidad: El sistema demuestra buena capacidad de escalado horizontal
  3. Alto Rendimiento: Logra capacidad de procesamiento requerida por plataformas FaaS grandes en hardware limitado
  4. Limitaciones de Concurrencia: La cantidad de disparadores concurrentes en un único invocador tiene limitaciones de CPU, pero puede mitigarse mediante particionamiento

Trabajo Relacionado

Soluciones de Gestión de Estado

  • Crucial: Capa de objetos compartidos distribuidos
  • Cloudburst: Almacén de pares clave-valor con escalado automático integrado
  • Boki: Persistencia de estado basada en API de registro
  • Faasm: Compartición de regiones de memoria en tiempo de ejecución WebAssembly

Orquestación de Flujos de Trabajo

  • TriggerFlow: Motor de flujo de trabajo personalizado basado en Knative
  • FaaSFlow: Programación de flujo de trabajo distribuido entre nodos FaaS
  • DataFlower: Programación de funciones basada en disponibilidad de datos

Distinción de Soluciones Existentes

La singularidad de este enfoque radica en invocar funciones solo cuando se cumplen completamente las condiciones de disparo, reduciendo ejecuciones innecesarias y evitando necesidad de mecanismos de bloqueo para condiciones de carrera.

Conclusiones y Discusión

Conclusiones Principales

  1. Los disparadores multi-evento resuelven efectivamente la falta de soporte nativo de abanico de entrada en plataformas FaaS
  2. El motor MET reduce significativamente la latencia de invocación y el consumo de recursos
  3. El sistema posee capacidad de rendimiento para despliegue en entornos en la nube a gran escala
  4. Mantiene las ventajas principales del paradigma sin servidor (bajo acoplamiento, escalado automático, sobrecarga operativa mínima)

Limitaciones

  1. Limitación de Distribución Geográfica: El diseño actual se enfoca en configuraciones de múltiples nodos en un único centro de datos, no es apropiado para disparadores multi-evento distribuidos geográficamente
  2. Sin Soporte de Condición NOT: Debido a la imposibilidad de garantizar que cierto tipo de evento no se ha recibido en entorno distribuido, no soporta condiciones NOT
  3. Problema de Sincronización de Eventos: Necesita resolver problemas de pérdida de eventos y sincronización causados por fallos de sensores

Direcciones Futuras

  1. Soporte de Distribución Geográfica: Usar tipos de datos replicados sin conflictos (CRDT) para rastrear eventos
  2. Extensión de Tipos de Disparadores: Soportar más tipos de disparadores como XOR
  3. Mecanismo de Tolerancia a Fallos: Introducir mecanismo de tiempo de vida (TTL) de eventos para manejar eventos expirados
  4. Integración de Plataforma: Integración profunda con funciones de plataforma FaaS como balanceo de carga

Evaluación Profunda

Ventajas

  1. Identificación Precisa del Problema: Identifica con precisión la limitación fundamental de plataformas FaaS en procesamiento de eventos complejos
  2. Diseño de Solución Razonable: El diseño de arquitectura del motor MET considera escalabilidad y practicidad
  3. Evaluación Suficiente: Evaluación integral desde múltiples dimensiones de latencia, rendimiento y concurrencia
  4. Alto Valor Práctico: Resuelve problemas de dolor en aplicaciones reales, con fuerte valor práctico
  5. Rendimiento Excelente: La reducción de latencia del 62,5% y capacidad de procesamiento de 30.000+ solicitudes/segundo demuestran la efectividad de la solución

Insuficiencias

  1. Limitación de Distribución Geográfica: Soporte insuficiente para escenarios de aplicaciones distribuidas globalmente
  2. Mecanismo de Tolerancia a Fallos Simple: Manejo incompleto de situaciones anómalas como particiones de red y fallos de nodos
  3. Capacidad de Expresión de Reglas de Disparo: Las combinaciones AND/OR actuales pueden no cubrir todos los escenarios empresariales complejos
  4. Integración con Plataformas Existentes: Como componente externo integrado, puede no aprovechar completamente optimizaciones internas de plataforma

Impacto

  1. Contribución Académica: Proporciona nueva dirección de investigación y solución para el campo FaaS
  2. Valor Industrial: Aplicable directamente a plataformas FaaS existentes, mejorando capacidad de procesamiento de eventos complejos
  3. Potencial de Estandarización: Potencial para convertirse en forma estándar de implementación de disparadores multi-evento en plataformas FaaS
  4. Reproducibilidad: La implementación de prototipo de código abierto proporciona buena reproducibilidad

Escenarios Aplicables

  1. Procesamiento de Datos IoT: Aplicaciones de IoT que necesitan agregar datos de múltiples sensores
  2. Procesamiento de Eventos Complejos: Monitoreo de transacciones financieras, detección de seguridad de red y otros escenarios que requieren análisis correlacionado
  3. Orquestación de Flujos de Trabajo: Flujos de trabajo sin servidor que necesitan esperar a que se completen múltiples tareas previas
  4. Optimización de Procesamiento por Lotes: Agregar múltiples eventos pequeños para procesamiento por lotes posterior mejorando eficiencia

Referencias Bibliográficas

El artículo cita 34 referencias relacionadas, cubriendo principalmente:

  • Investigación de plataformas FaaS y mecanismos de disparo
  • Orquestación de flujos de trabajo sin servidor
  • Gestión de estado y procesamiento de eventos complejos
  • Evaluación de rendimiento y pruebas de referencia

Las referencias clave incluyen análisis de arquitectura de AWS Lambda, revisiones de computación sin servidor, y sistemas de orquestación de flujos de trabajo relacionados.


Este artículo propone una solución innovadora a una limitación importante de plataformas FaaS, con fuerte valor teórico y práctico. El diseño del motor MET equilibra rendimiento y escalabilidad, con evaluación experimental suficiente que valida la efectividad de la solución. Aunque hay espacio para mejora en distribución geográfica y tolerancia a fallos, en general es un trabajo de investigación de alta calidad.