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

Multi-Event Triggers für Serverless Computing

Grundinformationen

  • Paper-ID: 2505.21199
  • Titel: Multi-Event Triggers for Serverless Computing
  • Autoren: Natalie Carl, Trever Schirmer, Niklas Kowallik, Joshua Adamek, Tobias Pfandzelter, Sergio Lucia, David Bermbach
  • Klassifizierung: cs.DC (Verteilte, parallele und Cluster-Computing)
  • Veröffentlichungsdatum: arXiv:2505.21199v3 cs.DC 11 Okt 2025
  • Paper-Link: https://arxiv.org/abs/2505.21199

Zusammenfassung

Function-as-a-Service (FaaS) ist ein ereignisgesteuertes, serverloses Cloud-Computing-Modell, bei dem kleine, zustandslose Funktionen durch Ereignisse wie HTTP-Anfragen, neue Datenbankeinträge oder Nachrichten aufgerufen werden. Aktuelle FaaS-Plattformen gehen davon aus, dass jeder Funktionsaufruf einem einzelnen Ereignis entspricht. Aus Anwendungsperspektive ist es jedoch wünschenswert, dass Funktionen auf Sammlungen verschiedener Ereignistypen reagieren oder nur bei jedem n-ten Ereignis aufgerufen werden. Um dies zu erreichen, benötigen Funktionen zusätzliche Zustandsverwaltung (wie Datenbanken) und benutzerdefinierte Logik zur Bestimmung, ob Triggerbedingungen erfüllt sind. Dieses Paper stellt Multi-Event Triggers vor, die es ermöglichen, komplexe Funktionsaufrufsbedinungen zu spezifizieren. Die Evaluierungsergebnisse zeigen, dass dieser Ansatz in Ereigniserkennungsanwendungsfällen die Ereignis-Aufrufs-Latenz um 62,5% reduziert und das System auf begrenzter Hardware über 300.000 Anfragen/Sekunde verarbeiten kann.

Forschungshintergrund und Motivation

Problemdefinition

Aktuelle FaaS-Plattformen weisen eine grundlegende Einschränkung auf: Jeder Funktionsaufruf kann nur auf ein einzelnes Ereignis reagieren. In praktischen Anwendungen sind jedoch häufig komplexere Triggermuster erforderlich:

  1. Fan-in/Join-Muster: Mehrere verschiedene Ereignistypen müssen gesammelt werden, bevor die Funktion ausgelöst wird
  2. Zähl-Trigger: Die Funktion wird nur nach jedem n-ten Ereignis ausgelöst
  3. Komplexe Bedingungstrigger: AND/OR-Kombinationsbedingungen basierend auf Ereignistyp und -menge

Einschränkungen bestehender Ansätze

Die aktuelle Implementierung von Multi-Event Triggering erfordert:

  • Zustandsverwaltung innerhalb der Funktion mit externem Datenbankspeicher
  • Funktionsaufrufe bei jedem Ereignis, wobei die meisten Aufrufe nur zur Zustandsaktualisierung dienen
  • Unnötige Ressourcenverschwendung, erhöhte Latenz und steigende Kosten
  • Verstoß gegen das FaaS-Plattform-Designprinzip der Ereignisverteilung und Funktionsaufrufe

Forschungsmotivation

Um die Vorteile des FaaS-Programmiermodells (lose Kopplung, automatische Skalierung, einfache Entwicklung) zu bewahren, muss die Multi-Event-Trigger-Logik in den Triggermechanismus der FaaS-Plattform integriert werden, anstatt dass Anwendungsentwickler dies manuell handhaben.

Kernbeiträge

  1. Konzept der Multi-Event Triggers: Erweiterung des FaaS-Funktions-Triggermechanismus zur Unterstützung komplexer Triggerbedingungen basierend auf Ereignissammlungen
  2. MET-Engine-Architektur: Entwurf einer Multi-Event-Trigger-Engine, die in bestehende FaaS-Plattformen integriert werden kann
  3. Prototypentwicklung: Implementierung eines Proof-of-Concept-Prototyps zur Demonstration der Machbarkeit des Designs
  4. Leistungsbewertung: Validierung des Potenzials und der Leistung von Multi-Event Triggern in Ereigniserkennungsanwendungsfällen

Methodische Details

Aufgabendefinition

Multi-Event Triggers ermöglichen es Entwicklern, komplexe Triggerregeln zu definieren, die angeben, wann eine Funktion bei Erfüllung bestimmter Ereigniskombinationsbedingungen aufgerufen wird. Triggerregeln bestehen aus Ereignistypen und entsprechenden Mengen und unterstützen Kombinationen von AND- und OR-Bedingungen.

Formale Definition von Triggerregeln

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

MET-Engine-Architektur

Gesamtdesign

Die MET-Engine besteht aus zwei unabhängig skalierbaren Hauptkomponenten:

  1. Dispatcher:
    • Empfängt Ereignisse vom Load Balancer
    • Leitet Ereignisse an entsprechende Invoker weiter
  2. Invoker:
    • Verarbeitet Triggerlogik
    • Erstellt Trigger-Handler für jeden MET
    • Verwaltet Trigger-Sets für jeden Ereignistyp
    • Prüft, ob Triggerregeln erfüllt sind, und ruft Funktionen auf

Kommunikationsmechanismus

  • Dispatcher und Invoker verwenden Broker-lose Publish/Subscribe-Nachrichtenübermittlung
  • Invoker abonnieren Dispatcher-Ereignisse basierend auf Ereignistypen in ihren verarbeiteten Triggerregeln
  • Unterstützt verteilte Bereitstellung in Multi-Node- und Single-Machine-Setups

Skalierbarkeitsdesign

  • Erhöhung der Anzahl verarbeitbarer Trigger durch Bereitstellung zusätzlicher Invoker
  • Unterstützung von Trigger-Partitionierung für weitere Leistungssteigerung
  • Zielverarbeitungskapazität: Hohe 10^5 bis niedrige 10^5 Anfragen/Sekunde (Referenz: AWS Lambda Single-AZ-Last)

Technische Innovationen

  1. Native Plattformunterstützung: Integration von Multi-Event-Logik in den Triggermechanismus statt auf Anwendungsebene
  2. Optimierte Zustandsverwaltung: Zentrale Zustandsverwaltung in der Trigger-Engine, um zu vermeiden, dass jedes Ereignis die Funktion aufruft
  3. Modulare Architektur: Unterstützt unabhängige Skalierung von Dispatch- und Invoke-Komponenten
  4. Trigger-Partitionierung: Unterstützt höhere Parallelverarbeitungskapazität durch Partitionierung

Experimentelle Einrichtung

Prototyp-Implementierung

  • Programmiersprache: Go für Dispatcher und Invoker
  • Bereitstellungsplattform: Kubernetes-Cluster (Google Kubernetes Engine)
  • Nachrichtenübermittlung: ZeroMQ-Bibliothek
  • Load Balancing: Kubernetes LoadBalancer-Service
  • Funktionsplattform: Beliebige HTTP-fähige FaaS-Plattform

Evaluierungsszenarien

Experiment 1: Latenz-Test

  • Anwendungsfall: Ereigniserkennungsanwendung im Rechenzentrum
  • Sensortypen: Temperatur, Paketverlustraten, Stromverbrauch
  • Triggerregel: OR(AND(5:packetLoss, 1:temperature), 1:powerConsumption)
  • Baseline-Vergleich: Manuelle Zustandsverwaltung mit PostgreSQL-Datenbank
  • Lastgenerierung: k6-Lastgenerator, 30-Minuten-Test

Experiment 2: Gleichzeitige Anfragen-Test

  • Hardwarekonfiguration:
    • Single-Node: c7i.2xlarge (8 vCPU, 16 GiB)
    • Vier-Node: 4×c7i.2xlarge
    • Lastgenerator: c7i.16xlarge (64 vCPU, 128 GiB)
  • Triggerregel: 3:a (Auslösung nach jedem dritten Ereignis)
  • Last: 1.024-Byte-Zufallszeichenlast

Experiment 3: Gleichzeitige Trigger-Test

  • Hardware: c7i.large (4 vCPU, 8 GiB)
  • Triggerregel: AND(2:a, 2:b), bis zu 1.024 gleichzeitige Trigger
  • Last: 128 virtuelle Benutzer, 1.024-Byte-Last

Experimentelle Ergebnisse

Hauptergebnisse

Latenz-Leistungsverbesserung

  • Ereignis-Aufrufs-Latenz um 62,5% reduziert (Median)
  • Funktionsaufrufe um 4,3-fach reduziert (im Vergleich zur Baseline mit Aufrufen bei jedem Ereignis)
  • Signifikante Reduktion unnötiger Funktionsaufrufe

Durchsatzleistung

  • Single-Node-Konfiguration: Maximal 131.012,7 Anfragen/Sekunde (4.096 virtuelle Benutzer)
  • Vier-Node-Konfiguration: Maximal 313.154,81 Anfragen/Sekunde (64 virtuelle Benutzer)
  • Durchsatz wächst linear mit gleichzeitigen Anfragen bis 2^11 Anfragen

Gleichzeitige Trigger-Leistung

  • Einzelner Trigger: 236.601,77 Anfragen/Sekunde
  • 8 Trigger: 63.717,27 Anfragen/Sekunde
  • 1.024 Trigger: 883,67 Anfragen/Sekunde
  • Leistung hauptsächlich CPU-limitiert; Optimierung durch Parallelisierung der Triggerregel-Überprüfung

Experimentelle Erkenntnisse

  1. Signifikante Latenzverbesserung: MET-Engine reduziert Ereignisverarbeitungslatenz erheblich im Vergleich zu manueller Zustandsverwaltung
  2. Gute Skalierbarkeit: System zeigt gute horizontale Skalierungsfähigkeit
  3. Hoher Durchsatz: Erreicht auf begrenzter Hardware die erforderliche Verarbeitungskapazität großer FaaS-Plattformen
  4. Parallelisierungsgrenzen: Begrenzte Anzahl gleichzeitiger Trigger pro Invoker durch CPU-Limitierung, kann aber durch Partitionierung gemildert werden

Verwandte Arbeiten

Zustandsverwaltungslösungen

  • Crucial: Verteilte gemeinsame Objektschicht
  • Cloudburst: Integrierter automatisch skalierender Schlüssel-Wert-Speicher
  • Boki: Zustandspersistierung basierend auf Log-API
  • Faasm: Speicherbereichsfreigabe für WebAssembly-Laufzeiten

Workflow-Orchestrierung

  • TriggerFlow: Benutzerdefinierte Workflow-Engine basierend auf Knative
  • FaaSFlow: Verteilte Workflow-Planung über FaaS-Arbeitknoten
  • DataFlower: Funktionsplanung basierend auf Datenverfügbarkeit

Unterschiede zu bestehenden Lösungen

Die Besonderheit dieses Ansatzes liegt darin, dass Funktionen nur aufgerufen werden, wenn vollständige Triggerbedingungen erfüllt sind, was unnötige Ausführungen reduziert und Sperrmechanismen für Racebedingungen vermeidet.

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

  1. Multi-Event Triggers lösen effektiv das Problem fehlender nativer Fan-in-Unterstützung in FaaS-Plattformen
  2. MET-Engine reduziert signifikant Aufrufslatenz und Ressourcenverbrauch
  3. System besitzt Leistungsfähigkeit für Bereitstellung in großflächigen Cloud-Umgebungen
  4. Bewahrt Kernvorteile des serverlosen Paradigmas (lose Kopplung, automatische Skalierung, minimale Betriebsverwaltung)

Einschränkungen

  1. Geografische Verteilungsgrenzen: Aktuelles Design konzentriert sich auf Multi-Node-Single-Rack-Setups, nicht geeignet für geografisch verteilte Multi-Event Triggers
  2. NOT-Bedingungen nicht unterstützt: Aufgrund der Unmöglichkeit, in verteilten Umgebungen zu garantieren, dass bestimmte Ereignistypen nicht empfangen wurden
  3. Ereignissynchronisierungsprobleme: Behandlung von Ereignisverlusten und Synchronisierungsproblemen durch Sensorausfälle erforderlich

Zukünftige Richtungen

  1. Geografische Verteilungsunterstützung: Verwendung konfliktfreier replizierter Datentypen (CRDT) zur Ereignisverfolgung
  2. Trigger-Typ-Erweiterung: Unterstützung zusätzlicher Trigger-Typen wie XOR
  3. Fehlertoleranz-Mechanismen: Einführung von Event-Time-to-Live (TTL)-Mechanismen zur Behandlung abgelaufener Ereignisse
  4. Plattformintegration: Tiefe Integration mit FaaS-Plattform-Funktionen wie Load Balancing

Tiefgehende Bewertung

Stärken

  1. Genaue Problemidentifikation: Präzise Identifikation grundlegender Einschränkungen von FaaS-Plattformen bei komplexer Ereignisverarbeitung
  2. Vernünftiges Lösungsdesign: MET-Engine-Architektur berücksichtigt Skalierbarkeit und Praktikabilität
  3. Umfassende Experimente: Vollständige Evaluierung aus mehreren Dimensionen (Latenz, Durchsatz, Parallelisierung)
  4. Hoher praktischer Wert: Löst echte Schmerzen in praktischen Anwendungen mit starkem praktischem Nutzen
  5. Ausgezeichnete Leistung: 62,5% Latenzreduktion und 300.000+ Anfragen/Sekunde Verarbeitungskapazität beweisen Lösungseffektivität

Schwächen

  1. Geografische Verteilungsgrenzen: Unzureichende Unterstützung für global verteilte Anwendungsszenarien
  2. Einfache Fehlertoleranz: Unzureichende Behandlungsmechanismen für Netzwerkpartitionierung, Knotenfehler und andere Anomalien
  3. Ausdruckskraft von Triggerregeln: Aktuelle AND/OR-Kombinationen können möglicherweise nicht alle komplexen Geschäftsszenarien abdecken
  4. Integration mit bestehenden Plattformen: Als externe Komponente integriert, kann möglicherweise nicht vollständig interne Plattformoptimierungen nutzen

Auswirkungen

  1. Akademischer Beitrag: Bietet neue Forschungsrichtungen und Lösungen für das FaaS-Feld
  2. Industrieller Wert: Direkt anwendbar auf bestehende FaaS-Plattformen zur Verbesserung der Komplexereignisverarbeitungsfähigkeit
  3. Standardisierungspotenzial: Könnte zum Standard-Implementierungsansatz für Multi-Event Triggers in FaaS-Plattformen werden
  4. Reproduzierbarkeit: Open-Source-Prototyp-Implementierung bietet gute Reproduzierbarkeit

Anwendungsszenarien

  1. IoT-Datenverarbeitung: IoT-Anwendungen, die Daten mehrerer Sensoren aggregieren müssen
  2. Komplexe Ereignisverarbeitung: Finanzhandelsüberwachung, Netzwerksicherheitserkennung und andere Szenarien, die Korrelationsanalyse erfordern
  3. Workflow-Orchestrierung: Serverlose Workflows, die auf Abschluss mehrerer vorgelagerter Aufgaben warten müssen
  4. Batch-Verarbeitung-Optimierung: Aggregation mehrerer kleiner Ereignisse zur Batch-Verarbeitung für verbesserte Effizienz

Literaturverzeichnis

Das Paper zitiert 34 verwandte Literaturquellen, die hauptsächlich folgende Bereiche abdecken:

  • FaaS-Plattformen und Triggermechanismus-Forschung
  • Serverlose Workflow-Orchestrierung
  • Zustandsverwaltung und komplexe Ereignisverarbeitung
  • Leistungsbewertung und Benchmarking

Wichtige Referenzen umfassen AWS Lambda-Architekturanalyse, Übersichten zu serverlosen Berechnungen sowie verwandte Workflow-Orchestrierungssysteme.

Dieses Paper stellt eine innovative Lösung für eine wichtige Einschränkung von FaaS-Plattformen vor und besitzt starken theoretischen und praktischen Wert. Das Design der MET-Engine berücksichtigt sowohl Leistung als auch Skalierbarkeit, und die experimentelle Evaluierung validiert die Lösungseffektivität umfassend. Obwohl es Verbesserungspotenzial bei geografischer Verteilung und Fehlertoleranz gibt, handelt es sich insgesamt um hochwertige Forschungsarbeit.