Пользователь отправляет документ, система принимает запрос, а обработка занимает несколько минут. За это время может оборваться соединение, закончиться лимит выполнения или повторно прийти сообщение из очереди. Архитектура должна сохранить одно понятное задание и корректно довести его до результата.
Для таких операций стоит разделять приём запроса, выполнение и получение результата. Выбор serverless-платформы не отменяет состояния задания, ограничений ресурсов и восстановления после сбоев.
Тема развёртывания приложений в бессерверной архитектуре рассматривалась в работе Лаппо и Владымцева. Ниже — прикладная схема для AI-обработки с длительными или повторяемыми шагами.
Выбирать среду под длительность операции
Лимиты конкретного сервиса проверяют до реализации. Например, AWS Lambda допускает время выполнения до 900 секунд. Это характеристика данного сервиса, а не всех бессерверных платформ.
Долгая обработка, загрузка большой модели и требования к оборудованию могут потребовать другого типа исполнителя: фонового контейнера, пакетного задания или постоянно работающего сервиса. Приём запроса при этом может оставаться короткой функцией.
Отдельно учитывайте доступность выбранного поставщика, договорные условия и разрешённое место обработки данных. Техническое описание сервиса не подтверждает возможность его использования любой организацией.
Разделить жизненный цикл задания
В предложенной схеме входной сервис проверяет пользователя и формат, сохраняет задание и возвращает его идентификатор. Исполнитель забирает работу из очереди, записывает промежуточные состояния и итог. Пользователь получает результат через проверку статуса или уведомление.
Полезные состояния — «принято», «ожидает выполнения», «выполняется», «завершено», «требует разбора» и «отменено». Успешный приём запроса означает создание задания, но не выполнение бизнес-операции.
Запись задания и постановку сообщения в очередь нужно согласовать. Один из вариантов — transactional outbox: запись задания и будущего сообщения совершается в одной транзакции базы данных, а отдельный процесс доставляет сообщение в очередь. Это уменьшает риск потерять работу между двумя несвязанными действиями. Повторную доставку такая схема всё равно должна переносить корректно.
Повтор сообщения не должен создавать повторное действие
AWS описывает обработку сообщений SQS через Lambda как доставку как минимум один раз: возможны повторы, обработчики должны учитывать их. Аналогичные гарантии всегда проверяют для выбранной связки сервисов.
Ключ идемпотентности связывают с пользователем или организацией и логической операцией. Сохраняют также отпечаток входа: один ключ с изменившимся содержимым нельзя молча принять за прежний запрос.
Но одного флага в локальной базе недостаточно для внешнего действия. Если исполнитель записал результат в стороннюю систему и упал до сохранения локального подтверждения, повтор способен создать дубль. Нужен поддерживаемый внешней системой ключ операции, проверка её фактического состояния либо процедура сверки и ручного разбора.
| Момент сбоя | Какой вопрос нужно решить |
|---|---|
| До записи задания | Может ли клиент безопасно повторить запрос |
| После записи, до очереди | Кто гарантирует последующую постановку в очередь |
| Во время вычисления | Откуда продолжать и допустим ли повтор вычислений |
| После внешнего действия, до подтверждения | Как узнать, было ли действие выполнено |
| После готового результата | Как вернуть тот же результат при повторном запросе |
Ограничить нагрузку и стоимость повторов
Задайте максимальную параллельность, ограничения на размер входа и число повторных попыток. Общий бюджет задания должен учитывать все его шаги, обращения к модели и повторные исполнения.
Лимит ожидания пользователя, лимит исполнителя и время скрытия сообщения в очереди выполняют разные функции. Их нельзя выбрать одним случайным значением. Например, слишком ранняя повторная выдача сообщения способна запустить второго исполнителя, пока первый ещё работает.
После исчерпания допустимых попыток задание направляют в отдельную очередь разбора. Сохраняйте причину, последнюю подтверждённую стадию и ссылку на исходный запрос. Повторный запуск из этой очереди проходит те же проверки идемпотентности.
Отмена тоже имеет границы
Нажатие «Отменить» может остановить ещё не начатую работу. Для уже выполняемой операции нужно определить точки, в которых исполнитель проверяет запрос отмены.
Если внешнее действие завершилось, нельзя показать, что его не было. Потребуется предусмотренная компенсирующая операция либо сообщение о невозможности автоматической отмены. Например, прекращение ожидания в браузере не отменяет уже записанный документ.
Разделяйте «запрос отмены принят» и «выполнение остановлено». Это такие же разные состояния, как приём и завершение задания.
Что проверять перед запуском
Испытайте обрыв на каждом значимом переходе, повторное сообщение, задержку очереди, отказ поставщика модели и одновременный запуск двух исполнителей. Для внешних действий проверьте сценарий неопределённого результата, когда ответ потерялся после выполнения.
Наблюдаемость должна связывать запрос, задание, попытку, обращение к модели и внешний результат. Пользователь видит бизнес-статус; команда — технические детали, необходимые для восстановления, с ограничением доступа к чувствительным данным.
О выборе степени автономности полезно читать отдельно в статье «AI-агент, чатбот или workflow automation». Для обработки с известными шагами явный жизненный цикл задания часто позволяет точнее определить поведение при сбое.