Мультисобытийные триггеры для бессерверных вычислений

Основная информация

• ID статьи: 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

Аннотация

Function-as-a-Service (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 ГиБ)
  • Четырёхузловая: 4×c7i.2xlarge
  • Генератор нагрузки: c7i.16xlarge (64 vCPU, 128 ГиБ)
• Правило срабатывания: 3:a (срабатывание при каждом третьем событии)
• Нагрузка: 1024-байтовая случайная полезная нагрузка

Эксперимент 3: Тестирование параллельных триггеров

• Оборудование: c7i.large (4 vCPU, 8 ГиБ)
• Правило срабатывания: AND(2:a, 2:b), до 1024 параллельных триггеров
• Нагрузка: 128 виртуальных пользователей, 1024-байтовая полезная нагрузка

Результаты экспериментов

Основные результаты

Улучшение производительности задержки

• Снижение задержки события-вызова на 62,5% (медиана)
• Снижение количества вызовов функций в 4,3 раза (по сравнению с базовым вариантом, когда функция вызывается для каждого события)
• Значительное снижение затрат на ненужные вызовы функций

Производительность пропускной способности

• Одноузловая конфигурация: максимум 131 012,7 запросов/сек (4096 виртуальных пользователей)
• Четырёхузловая конфигурация: максимум 313 154,81 запросов/сек (64 виртуальных пользователя)
• Пропускная способность растёт линейно с параллельными запросами до 2^11 запросов

Производительность параллельных триггеров

• Одиночный триггер: 236 601,77 запросов/сек
• 8 триггеров: 63 717,27 запросов/сек
• 1024 триггера: 883,67 запросов/сек
• Производительность в основном ограничена процессором; оптимизация достигается путём параллелизации проверки правил срабатывания

Экспериментальные выводы

1. Значительное улучшение задержки: MET-движок значительно снижает задержку обработки событий по сравнению с методом ручного управления состоянием
2. Хорошая масштабируемость: система демонстрирует хорошие возможности горизонтального масштабирования
3. Высокая пропускная способность: достигает пропускной способности обработки, необходимой для крупных FaaS-платформ, на ограниченном оборудовании
4. Ограничения параллелизма: количество параллельных триггеров в одном вызывающем устройстве ограничено процессором, но может быть смягчено разделением

Связанные работы

Решения для управления состоянием

• 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-движка сбалансировано между производительностью и масштабируемостью, а экспериментальная оценка полностью подтверждает эффективность решения. Хотя есть место для улучшения в области географического распределения и отказоустойчивости, в целом это высокачественная исследовательская работа.