Serverless Передача файлов: Architecture и Design

Serverless-архитектура подходит для передачи файлов лучше, чем кажется на первый взгляд. Пиковые нагрузки предсказуемо высокие и непредсказуемо редкие: пользователь отправляет файл раз в час, загрузка длится секунды. Lambda тарифицирует по 100 мс, API Gateway — по запросу, S3 — по байтам. Между передачами вы платите почти ноль. Постоянно работающий EC2 или контейнер за те же рабочие нагрузки обходится в 5–10 раз дороже. Компромисс — холодные старты, ограничения состояния и ловушки бесконечных повторов.

Почему serverless подходит для передачи файлов

Пиковость — ключевая характеристика нагрузок по передаче файлов. Маркетинговое агентство передаёт 50 GB видеоматериалов в пятницу вечером и почти ничего не делает в остальное время. Lambda автоматически масштабируется до 1 000 параллельных выполнений за секунды и сворачивается до нуля после. Нет нужды держать серверы в режиме ожидания. Кроме того, serverless снижает операционную нагрузку: нет патчей ОС, нет балансировщиков нагрузки для управления, нет обновлений runtime (AWS управляет средой выполнения Lambda, хотя вы отвечаете за зависимости функции). Для небольших команд это принципиально.

Основные компоненты и их ответственности

Типичная serverless-система передачи файлов состоит из шести слоёв:

API Gateway обрабатывает HTTP-запросы: аутентификацию JWT, ограничение частоты запросов и маршрутизацию к Lambda. REST API Gateway стоит $3,50 за миллион запросов; HTTP API — $1,00/млн с меньшим набором функций. Для передачи файлов HTTP API достаточен в большинстве случаев.

Lambda запускает бизнес-логику: генерацию presigned URL, проверку метаданных, запись в базу данных, отправку уведомлений. Сами байты файла через Lambda не проходят — только метаданные.

S3 хранит файлы. Не пытайтесь проксировать загрузки через Lambda: Lambda имеет лимит payload в 6 МБ через API Gateway и лимит выполнения в 15 минут. Для файлов в 10 GB прямая загрузка в S3 — единственно разумный вариант.

DynamoDB или Aurora Serverless v2 хранят метаданные: сессии передачи, ссылки, счётчики загрузок, политики истечения. DynamoDB On-Demand хорошо работает при непредсказуемых нагрузках; Aurora Serverless v2 подойдёт, если нужен SQL с реляционными связями.

SES/SNS/Telegram Bot API отправляют уведомления. Для российских и CIS-пользователей Telegram Bot API предпочтительнее email: у пользователей выше процент открытий.

EventBridge запускает постобработку: EventBridge реагирует на s3:ObjectCreated и запускает Lambda-функции сканирования, генерации миниатюр или отправки уведомлений получателю.

Прямые загрузки в S3 через presigned URL

Этот паттерн устраняет Lambda из горячего пути загрузки:

Клиент вызывает POST /sessions → Lambda генерирует presigned URL для PutObject (срок действия 1 час, максимальный размер 10 GB через Content-Length), сохраняет метаданные сессии в DynamoDB, возвращает URL.
Клиент PUT файла напрямую в S3 — Lambda не запускается, API Gateway не задействован.
S3 Event Notification запускает Lambda постобработки.
Lambda постобработки записывает статус завершения, генерирует ссылку для скачивания, отправляет уведомление получателю.

Lambda шага 1 выполняется примерно 100 мс, стоит около $0,0000002. Lambda шага 4 выполняется 200–500 мс в зависимости от постобработки. Сам файл в 10 GB проходит через S3, не касаясь ни одной Lambda.

Событийная постобработка

S3 Event Notifications с EventBridge — правильный способ запускать постобработку. Настройте правило EventBridge на событие Object Created в вашем бакете с фильтром prefix/suffix, чтобы избежать бесконечных циклов (если Lambda записывает обратно в тот же бакет с другим суффиксом — нормально; если в тот же путь — рекурсивный триггер). Типичный конвейер постобработки:

Антивирусное сканирование через ClamAV в Lambda (32–256 МБ RAM, 10–60 секунд для типичных файлов)
Генерация миниатюр для изображений через sharp в Node.js Lambda
Извлечение метаданных: EXIF, длительность видео, количество страниц PDF
Уведомление получателя через SES или Telegram

Каждая Lambda специализируется на одной задаче. Оркестрируйте через Step Functions, если последовательность имеет значение или нужны ветки при ошибках.

Холодные старты и их снижение

Холодный старт Lambda на Node.js: 200–800 мс. На Go или Rust: 50–150 мс. На Java с JVM: 1–4 секунды. Для генерации presigned URL (быстрый путь) холодный старт становится заметным при пике в понедельник утром.

Три стратегии снижения:

Provisioned Concurrency держит N экземпляров Lambda прогретыми. Стоит примерно $0,015 за час на экземпляр (us-east-1). Для 5 прогретых экземпляров — ~$54/мес. Оправдано, если SLA требует p99 < 300 мс.

Go или Rust runtime сокращают время инициализации до 50 мс. Если команда знает JavaScript, используйте esbuild для бандлинга — это снижает холодный старт Node.js примерно до 300 мс, устраняя время загрузки node_modules.

Функции для тёплой поддержки — EventBridge пингует Lambda каждые 5 минут, чтобы не давать ей уйти в холод. Дёшево (~$0,30/мес), но не гарантирует прогрев при масштабировании выше одного экземпляра.

Выбор базы данных при serverless масштабировании

Lambda открывает новое соединение с базой данных при каждом холодном старте. При 500 параллельных Lambda PostgreSQL RDS исчерпывает лимит соединений (обычно 100–500 в зависимости от instance class). Три решения:

DynamoDB On-Demand: HTTP API, не TCP-соединения, масштабируется до нуля вместе с Lambda. Для метаданных передачи (сессии, ссылки, журналы скачиваний) DynamoDB проще. Недостаток: ограниченные паттерны запросов без вторичных индексов.

Aurora Serverless v2: масштабируется от 0,5 ACU и поддерживает обычный SQL. Data API устраняет проблему с пулом соединений — Lambda вызывает HTTP-эндпоинт вместо TCP. Холодный старт Aurora v2 — 2–5 секунд при масштабировании от нуля.

RDS Proxy: пул соединений между Lambda и RDS. Lambda подключается к Proxy, Proxy к базе. Лишний слой (~$0,015/ч), но позволяет сохранить PostgreSQL без переработки схемы.

Для большинства систем передачи DynamoDB — верный выбор: нагрузка хорошо структурирована (поиск по sessionId, userId, shareToken), доступ паттернизирован.

API Gateway, HTTP API и граничные варианты

Для serverless-системы передачи файлов сравните три варианта:

| Вариант | Стоимость | JWT-аутентификация | Преобразование запросов | WebSocket | |---|---|---|---|---| | REST API Gateway | $3,50/M | Через Authorizer | Полное | Нет | | HTTP API | $1,00/M | Нативно | Минимальное | Нет | | WebSocket API | $1,00/M + $0,0008/млн сообщений | Через Authorizer | Нет | Да | | CloudFront Functions | $0,10/M | Нет | JS скрипты | Нет |

Для передачи файлов HTTP API покрывает 90% случаев. REST API нужен, если требуется кастомный маппинг ответов или интеграция с API Keys. CloudFront Functions используйте для простых редиректов или добавления заголовков безопасности на edge.

Паттерны аутентификации

Два паттерна для serverless передачи файлов:

Аутентифицированные пользователи: JWT через Amazon Cognito или собственный IdP. HTTP API Lambda Authorizer проверяет подпись токена, кладёт claim'ы (userId, plan) в контекст события. Lambda получает event.requestContext.authorizer.userId без обращения к базе данных.

Анонимные ссылки для скачивания: при создании передачи генерируйте 256-битный криптографически стойкий токен (crypto.randomBytes(32).toString('hex')), храните его хэш в DynamoDB. Получатель предъявляет токен в URL — Lambda ищет по хешу. Время поиска O(1), без сессий, без куки.

Для 152-ФЗ: если ссылки содержат персональные данные (имя отправителя, email получателя), они должны передаваться по TLS и не логироваться в чистом виде. Убедитесь, что CloudFront или API Gateway не записывают полные URL с токенами в CloudWatch Logs — маскируйте через Log Filter.

Структура затрат и неожиданности масштабирования

Реальные затраты serverless системы передачи при 100 000 передач/мес, средний файл 50 MB:

| Компонент | Затраты/мес | |---|---| | Lambda (5M вызовов, 200 мс) | ~$1,00 | | API Gateway HTTP API (5M запросов) | ~$5,00 | | S3 хранилище (5 TB, 30-дневное истечение) | ~$115 | | S3 запросы (PUT + GET) | ~$5,00 | | CloudFront исходящий (5 TB) | ~$425 | | DynamoDB On-Demand | ~$2,00 | | Итого | ~$553 |

Крупнейшая статья — исходящий трафик CloudFront/S3, не Lambda. Cloudflare R2 с нулевым исходящим трафиком снижает эту цифру до ~$128 при тех же объёмах.

Главная ловушка масштабирования — бесконечный цикл повторов. Если Lambda записывает объект в S3, который триггерит другую Lambda, которая записывает объект, — EventBridge создаёт рекурсию. Устанавливайте Dead Letter Queue, используйте разные prefix для входящих и обработанных файлов, ограничивайте максимальное количество повторов в EventBridge.

Мониторинг и отладка serverless систем

CloudWatch Logs Insights — первый инструмент при расследовании инцидентов. Запрос для поиска медленных выполнений:

fields @timestamp, @duration, @requestId
| filter @duration > 2000
| sort @duration desc
| limit 50

AWS X-Ray трассирует весь путь: API Gateway → Lambda → DynamoDB → S3. Включите активную трассировку в Lambda (TracingConfig: Active). X-Ray даст карту сервисов и покажет, где время уходит — DynamoDB write vs S3 presign vs внешний API.

Три метрики для мониторинга:

Lambda ConcurrentExecutions — если приближается к лимиту аккаунта (1000 по умолчанию), запросите увеличение через AWS Support
Lambda Throttles — Lambda отклоняет вызовы при превышении concurrency; настройте алерт при > 0
API Gateway 5xxError — любой процент выше нуля требует расследования

Когда serverless перестаёт быть правильным

Serverless не подходит для трёх сценариев:

Стабильно высокая нагрузка: если Lambda постоянно загружена при 1 000 параллельных выполнениях, Fargate или EC2 Auto Scaling обойдутся дешевле — Lambda тарифицирует каждый вызов, а не время простоя.

Длинные WebSocket-сессии: Lambda с WebSocket API Gateway имеет лимит сессии в 2 часа и тарифицирует за открытое соединение. Для долгих интерактивных сессий передачи файлов (например, совместная работа в реальном времени) WebSocket-сервер на EC2/ECS эффективнее.

Требования air-gapped или локального развёртывания: Lambda работает только в AWS. Если регуляторные требования — например, хранение данных в изолированной инфраструктуре ФСБ-сертифицированного ЦОД без внешних облачных вызовов — исключают AWS, рассмотрите OpenFaaS или Knative на собственном оборудовании.

HexaTransfer использует serverless-архитектуру для масштабирования до нуля в периоды низкой активности и автоматического пика без ручного планирования ёмкости. Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.