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

محفزات متعددة الأحداث للحوسبة بدون خادم

المعلومات الأساسية

  • معرّف الورقة: 2505.21199
  • العنوان: Multi-Event Triggers for Serverless Computing
  • المؤلفون: Natalie Carl, Trever Schirmer, Niklas Kowallik, Joshua Adamek, Tobias Pfandzelter, Sergio Lucia, David Bermbach
  • التصنيف: cs.DC (الحوسبة الموزعة والمتوازية والعنقودية)
  • تاريخ النشر: arXiv:2505.21199v3 cs.DC 11 أكتوبر 2025
  • رابط الورقة: https://arxiv.org/abs/2505.21199

الملخص

نموذج الدوال كخدمة (FaaS) هو نموذج حوسبة سحابية بدون خادم موجه بالأحداث، حيث يتم استدعاء دوال صغيرة بدون حالة استجابة للأحداث (مثل طلبات HTTP أو إدخالات قاعدة البيانات الجديدة أو الرسائل). تفترض منصات FaaS الحالية أن كل استدعاء دالة يتوافق مع حدث واحد. ومع ذلك، من منظور التطبيق، يرغب المطورون في أن تستجيب الدوال لمجموعات من أنواع الأحداث المختلفة أو فقط عند كل حدث n. لتحقيق ذلك، تحتاج الدوال إلى إدارة حالة إضافية (مثل قواعس البيانات) ومنطق مخصص لتحديد ما إذا كانت شروط التشغيل مستوفاة. تقترح هذه الورقة محفزات متعددة الأحداث (multi-event triggers)، والتي تسمح بتحديد شروط استدعاء دوال معقدة. تُظهر نتائج التقييم أن هذا الأسلوب يقلل من كمون الحدث إلى الاستدعاء بنسبة 62.5% في حالات الاستخدام الخاصة بكشف الأحداث، وأن النظام يمكنه التعامل مع أكثر من 300,000 طلب/ثانية على أجهزة محدودة.

الخلفية البحثية والدافع

تعريف المشكلة

تواجه منصات FaaS الحالية قيداً أساسياً: يمكن لكل استدعاء دالة أن يستجيب لحدث واحد فقط. ومع ذلك، في التطبيقات العملية، غالباً ما يكون هناك حاجة لتنفيذ أنماط تشغيل أكثر تعقيداً:

  1. نمط المروحة الداخلة/الدمج (Fan-in/Join): الحاجة إلى جمع أحداث متعددة من أنواع مختلفة قبل تشغيل الدالة
  2. تشغيل العد: تشغيل الدالة مرة واحدة فقط لكل n حدث مستقبل
  3. تشغيل الشروط المعقدة: بناءً على مجموعات AND/OR من أنواع الأحداث والكميات

قيود الطرق الموجودة

يتطلب تنفيذ محفزات متعددة الأحداث حالياً:

  • الحفاظ على الحالة داخل الدالة، مما يتطلب تخزين قاعدة بيانات خارجية
  • استدعاء الدالة لكل حدث، لكن معظم الاستدعاءات تُستخدم فقط لتحديث الحالة وليس لتنفيذ منطق الأعمال
  • يؤدي إلى استهلاك موارد غير ضروري وزيادة الكمون وارتفاع التكاليف
  • ينتهك مبدأ تصميم منصات FaaS التي يجب أن تتعامل مع توزيع الأحداث واستدعاء الدوال

الدافع البحثي

للحفاظ على مزايا نموذج برمجة FaaS (الاقتران الضعيف والتوسع التلقائي وسهولة التطوير)، يجب دمج منطق محفزات متعددة الأحداث في آلية التشغيل بمنصات FaaS، بدلاً من ترك مطوري التطبيقات يتعاملون معها يدوياً.

المساهمات الأساسية

  1. اقتراح مفهوم محفزات متعددة الأحداث: توسيع آلية تشغيل دوال FaaS لدعم شروط تشغيل معقدة بناءً على مجموعات الأحداث
  2. تصميم معمارية محرك MET: اقتراح تصميم محرك محفزات متعددة الأحداث يمكن دمجه في منصات FaaS الموجودة
  3. تطوير نظام نموذجي: تنفيذ نموذج إثبات المفهوم يوضح جدوى التصميم
  4. تقييم الأداء: التحقق من إمكانيات ومستويات أداء محفزات متعددة الأحداث في حالات الاستخدام الخاصة بكشف الأحداث

شرح الطريقة

تعريف المهمة

تسمح محفزات متعددة الأحداث للمطورين بتحديد قواعد تشغيل معقدة تحدد متى يتم استدعاء الدالة عند استيفاء مجموعات أحداث معينة. تتكون قواعد التشغيل من أنواع الأحداث والكميات المقابلة، وتدعم مجموعات شروط AND و OR.

التعريف الرسمي لقواعد التشغيل

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

معمارية محرك MET

التصميم الشامل

يحتوي محرك MET على مكونين رئيسيين قابلين للتوسع بشكل مستقل:

  1. المُرسِل (Dispatcher):
    • يستقبل الأحداث من موازن التحميل
    • يحول الأحداث إلى المستدعي المناسب
  2. المستدعي (Invoker):
    • يعالج منطق التشغيل
    • ينشئ معالجات تشغيل لكل MET
    • يحافظ على مجموعات تشغيل لكل نوع حدث
    • يتحقق من استيفاء قواعد التشغيل ويستدعي الدالة

آلية الاتصال

  • يستخدم المُرسِل والمستدعي نشر/اشتراك رسائل بدون وسيط
  • يشترك المستدعي في أحداث المُرسِل بناءً على أنواع الأحداث في قواعد التشغيل التي يعالجها
  • يدعم النشر الموزع في إعدادات متعددة العقد والآلة الواحدة

تصميم قابلية التوسع

  • زيادة عدد المستدعين المنتشرين لزيادة عدد المحفزات القابلة للمعالجة
  • دعم تقسيم المحفزات لزيادة قدرة المعالجة
  • الهدف: قدرة معالجة من 10^5 إلى 10^6 طلب/ثانية (مرجع: AWS Lambda في منطقة توفر واحدة)

نقاط الابتكار التقني

  1. الدعم الأصلي للمنصة: دمج منطق متعدد الأحداث في آلية التشغيل بدلاً من طبقة التطبيق
  2. تحسين إدارة الحالة: إدارة الحالة المركزية في محرك التشغيل لتجنب استدعاء الدالة لكل حدث
  3. معمارية معيارية: دعم التوسع المستقل لمكونات الإرسال والاستدعاء
  4. تقسيم المحفزات: دعم المعالجة المتزامنة الأعلى من خلال التقسيم

إعداد التجارب

تنفيذ النموذج

  • لغة البرمجة: تنفيذ المُرسِل والمستدعي بلغة Go
  • منصة النشر: مجموعة Kubernetes (Google Kubernetes Engine)
  • نقل الرسائل: مكتبة ZeroMQ
  • موازن التحميل: خدمة Kubernetes LoadBalancer
  • منصة الدوال: أي منصة FaaS تدعم HTTP

سيناريوهات التقييم

التجربة 1: اختبار الكمون

  • حالة الاستخدام: تطبيق كشف أحداث مركز البيانات
  • أنواع المستشعرات: درجة الحرارة ومعدل فقدان الحزم والطاقة
  • قاعدة التشغيل: OR(AND(5:packetLoss, 1:temperature), 1:powerConsumption)
  • خط الأساس: إدارة الحالة اليدوية باستخدام قاعدة بيانات PostgreSQL
  • توليد الحمل: مولد الحمل k6، اختبار لمدة 30 دقيقة

التجربة 2: اختبار الطلبات المتزامنة

  • إعدادات الأجهزة:
    • عقدة واحدة: c7i.2xlarge (8 vCPU، 16 GiB)
    • أربع عقد: 4×c7i.2xlarge
    • مولد الحمل: c7i.16xlarge (64 vCPU، 128 GiB)
  • قاعدة التشغيل: 3:a (تشغيل مرة واحدة لكل ثلاثة أحداث)
  • الحمل: حمل عشوائي بحجم 1,024 بايت

التجربة 3: اختبار المحفزات المتزامنة

  • الأجهزة: c7i.large (4 vCPU، 8 GiB)
  • قاعدة التشغيل: AND(2:a, 2:b)، حتى 1,024 محفز متزامن
  • الحمل: 128 مستخدم افتراضي، حمل 1,024 بايت

نتائج التجارب

النتائج الرئيسية

تحسن أداء الكمون

  • تقليل كمون الحدث إلى الاستدعاء بنسبة 62.5% (الوسيط)
  • تقليل عدد استدعاءات الدوال بمعامل 4.3 (مقارنة بخط الأساس الذي يستدعي الدالة لكل حدث)
  • تقليل كبير في نفقات استدعاءات الدوال غير الضرورية

أداء الإنتاجية

  • إعداد عقدة واحدة: أقصى 131,012.7 طلب/ثانية (4,096 مستخدم افتراضي)
  • إعداد أربع عقد: أقصى 313,154.81 طلب/ثانية (64 مستخدم افتراضي)
  • تنمو الإنتاجية خطياً مع الطلبات المتزامنة حتى 2^11 طلب

أداء المحفزات المتزامنة

  • محفز واحد: 236,601.77 طلب/ثانية
  • 8 محفزات: 63,717.27 طلب/ثانية
  • 1,024 محفز: 883.67 طلب/ثانية
  • تقتصر الأداء بشكل أساسي على CPU، مع تحسين من خلال موازاة فحص قواعد التشغيل

النتائج التجريبية

  1. تحسن كمون كبير: يقلل محرك MET بشكل كبير من كمون معالجة الأحداث مقارنة بطرق إدارة الحالة اليدوية
  2. قابلية توسع جيدة: يُظهر النظام قدرة توسع أفقي جيدة
  3. إنتاجية عالية: يحقق قدرة معالجة مطلوبة لمنصات FaaS الكبيرة على أجهزة محدودة
  4. قيود التزامن: يوجد حد لعدد المحفزات المتزامنة لكل مستدعي بسبب قيود CPU، لكن يمكن تخفيفه من خلال التقسيم

الأعمال ذات الصلة

حلول إدارة الحالة

  • Crucial: طبقة كائنات مشتركة موزعة
  • Cloudburst: تخزين مفاتيح بقيمة مع توسع تلقائي متكامل
  • Boki: استمرارية الحالة بناءً على API السجل
  • Faasm: مشاركة المناطق الذاكرة لوقت تشغيل WebAssembly

تنسيق سير العمل

  • TriggerFlow: محرك سير عمل مخصص قائم على Knative
  • FaaSFlow: جدولة سير عمل موزعة عبر عقد FaaS
  • DataFlower: جدولة الدوال بناءً على توفر البيانات

التمايز عن الحلول الموجودة

يتمثل التفرد في هذا الحل في أن الدالة تُستدعى فقط عند استيفاء شروط التشغيل الكاملة، مما يقلل من التنفيذات غير الضرورية ويتجنب الحاجة إلى آليات القفل لمعالجة حالات السباق.

الخلاصة والمناقشة

الاستنتاجات الرئيسية

  1. تحل محفزات متعددة الأحداث بفعالية مشكلة افتقار منصات FaaS إلى الدعم الأصلي للمروحة الداخلة
  2. يقلل محرك MET بشكل كبير من كمون الاستدعاء واستهلاك الموارد
  3. يمتلك النظام قدرة الأداء للنشر في بيئات سحابية واسعة النطاق
  4. يحافظ على المزايا الأساسية لنموذج الحوسبة بدون خادم (الاقتران الضعيف والتوسع التلقائي والحد الأدنى من نفقات التشغيل)

القيود

  1. قيود التوزيع الجغرافي: يركز التصميم الحالي على إعدادات متعددة العقد في منطقة واحدة، وغير مناسب لمحفزات متعددة الأحداث الموزعة جغرافياً
  2. عدم دعم شروط NOT: لا يمكن ضمان عدم استقبال فئة معينة من الأحداث في البيئة الموزعة، لذا لا يتم دعم شروط NOT
  3. مشاكل مزامنة الأحداث: الحاجة إلى حل مشاكل فقدان الأحداث والمزامنة الناجمة عن أعطال المستشعرات

الاتجاهات المستقبلية

  1. دعم التوزيع الجغرافي: استخدام أنواع البيانات المكررة الخالية من التضارب (CRDT) لتتبع الأحداث
  2. توسيع أنواع المحفزات: دعم أنواع محفزات إضافية مثل XOR
  3. آليات تحمل الأعطال: إدخال آلية مدة حياة الحدث (TTL) للتعامل مع الأحداث المنتهية الصلاحية
  4. التكامل مع المنصة: التكامل العميق مع وظائف منصات FaaS مثل موازن التحميل

التقييم المتعمق

المزايا

  1. تحديد المشكلة دقيق: تحديد دقيق للقيود الأساسية في منصات FaaS في معالجة الأحداث المعقدة
  2. تصميم الحل معقول: تصميم معمارية محرك MET يأخذ في الاعتبار قابلية التوسع والعملية
  3. تجارب شاملة: تقييم شامل من عدة جوانب بما في ذلك الكمون والإنتاجية والتزامن
  4. قيمة عملية عالية: حل مشاكل حقيقية في التطبيقات العملية بقيمة عملية قوية جداً
  5. أداء ممتازة: يثبت تقليل الكمون بنسبة 62.5% وقدرة المعالجة بأكثر من 300,000 طلب/ثانية فعالية الحل

أوجه القصور

  1. قيود التوزيع الجغرافي: دعم غير كافٍ لسيناريوهات التطبيقات الموزعة عالمياً
  2. آليات تحمل الأعطال البسيطة: معالجة غير كافية للحالات الاستثنائية مثل تقسيم الشبكة وأعطال العقد
  3. قدرة التعبير عن قواعد التشغيل: قد لا تغطي مجموعات AND/OR الحالية جميع سيناريوهات الأعمال المعقدة
  4. التكامل مع المنصات الموجودة: كمكون خارجي، قد لا تتمكن من الاستفادة الكاملة من التحسينات الداخلية للمنصة

التأثير

  1. المساهمة الأكاديمية: توفير اتجاه بحثي جديد وحل لمجال FaaS
  2. القيمة الصناعية: يمكن تطبيقها مباشرة على منصات FaaS الموجودة لتحسين قدرات معالجة الأحداث المعقدة
  3. إمكانية التوحيد: قد تصبح طريقة التنفيذ القياسية لمحفزات متعددة الأحداث في منصات FaaS
  4. قابلية إعادة الإنتاج: يوفر التنفيذ النموذجي مفتوح المصدر قابلية إعادة إنتاج جيدة

حالات الاستخدام المناسبة

  1. معالجة بيانات IoT: تطبيقات إنترنت الأشياء التي تحتاج إلى تجميع بيانات من مستشعرات متعددة
  2. معالجة الأحداث المعقدة: سيناريوهات تتطلب تحليل الارتباط مثل مراقبة المعاملات المالية وكشف الأمان السيبراني
  3. تنسيق سير العمل: سير عمل بدون خادم يحتاج إلى انتظار إكمال مهام متعددة سابقة
  4. تحسين المعالجة الدفعية: تجميع أحداث صغيرة متعددة ومعالجتها دفعة واحدة لتحسين الكفاءة

المراجع

تستشهد الورقة بـ 34 مرجعاً ذا صلة، تغطي بشكل أساسي:

  • أبحاث منصات FaaS وآليات التشغيل
  • تنسيق سير العمل بدون خادم
  • إدارة الحالة ومعالجة الأحداث المعقدة
  • تقييم الأداء والاختبارات المعيارية

تتضمن المراجع الرئيسية تحليل معمارية AWS Lambda والمسوحات الشاملة للحوسبة بدون خادم وأنظمة تنسيق سير العمل ذات الصلة.

تقترح هذه الورقة حلاً مبتكراً لقيد مهم في منصات FaaS، وتتمتع بقيمة نظرية وعملية قوية جداً. يوازن تصميم محرك MET بين الأداء وقابلية التوسع، ويتحقق التقييم التجريبي بشكل كافٍ من فعالية الحل. على الرغم من وجود مجال للتحسين في جوانب التوزيع الجغرافي وتحمل الأعطال، إلا أنها بشكل عام عمل بحثي عالي الجودة.