Serverless-обработка файлов: Lambda + S3 trigger под ключ

Serverless-обработка файлов: Lambda + S3 trigger под ключ

При загрузке изображений в S3 нужно автоматически генерировать thumbnails, но Lambda не справляется с большими файлами. Нужна отказоустойчивая архитектура с очередями и мониторингом. Мы — команда с опытом serverless-разработки — построили десятки таких систем. В этой статье разберём типовую архитектуру, обработку ошибок и подводные камни.

Lambda + S3 trigger — классический serverless паттерн для обработки файлов. Файл загружается в S3, событие автоматически запускает Lambda, которая обрабатывает файл и сохраняет результат. Не нужен постоянно работающий сервер, масштабирование автоматическое. Однако без правильной схемы с очередями вы рискуете потерять события. Экономия на инфраструктуре может достигать 70% по сравнению с выделенным сервером, а стоимость обработки одного файла снижается в 3-5 раз. Рассмотрим, как построить production-grade обработку с очередями, DLQ и мониторингом.

Какие задачи решает Lambda + S3 и базовая архитектура

Типовые задачи: генерация thumbnail при загрузке изображения, конвертация видео в разные форматы и разрешения, обработка CSV/Excel файлов с импортом данных в БД, PDF-генерация из шаблонов, антивирусное сканирование загружаемых файлов, OCR и извлечение текста из документов, трансформация данных (XML → JSON, нормализация).

Базовая архитектура:

[Пользователь] → S3 upload → [S3 Event Notification] ↓ [Lambda Function] ↓ [Обработанный файл → S3 Output] [Метаданные → DynamoDB] [Нотификация → SQS/SNS] 

# S3 bucket для входящих файлов resource "aws_s3_bucket" "uploads" { bucket = "myapp-uploads" } # S3 bucket для обработанных файлов resource "aws_s3_bucket" "processed" { bucket = "myapp-processed" } # Объединённая конфигурация: S3 → SNS → SQS resource "aws_s3_bucket_notification" "upload_trigger" { bucket = aws_s3_bucket.uploads.id topic { topic_arn = aws_sns_topic.file_events.arn events = ["s3:ObjectCreated:*"] } } resource "aws_sns_topic_subscription" "to_sqs" { topic_arn = aws_sns_topic.file_events.arn protocol = "sqs" endpoint = aws_sqs_queue.file_processing.arn } 

Как масштабировать обработку при пиковых нагрузках?

Lambda масштабируется автоматически, но при резком всплеске загрузок может возникнуть троттлинг. Мы используем SQS-очередь для буферизации: S3 → SNS → SQS → Lambda. Это гарантирует, что ни одно событие не потеряется. При превышении лимита concurrent executions очередь накапливает сообщения, и Lambda обрабатывает их по мере освобождения. Для критичных задач настраиваем Reserved Concurrency.

Обработчик Lambda и большие файлы

import boto3 import json import os from urllib.parse import unquote_plus from PIL import Image import io s3 = boto3.client('s3') def handler(event, context): results = [] for record in event['Records']: bucket = record['s3']['bucket']['name'] key = unquote_plus(record['s3']['object']['key']) try: result = process_image(bucket, key) results.append({'key': key, 'status': 'success', **result}) except Exception as e: print(f"Error processing {key}: {e}") results.append({'key': key, 'status': 'error', 'error': str(e)}) return results def process_image(bucket: str, key: str) -> dict: # Скачать оригинал obj = s3.get_object(Bucket=bucket, Key=key) image_data = obj['Body'].read() image = Image.open(io.BytesIO(image_data)) thumbnails = {} for size_name, (width, height) in [('sm', (150, 150)), ('md', (400, 400)), ('lg', (800, 800))]: thumb = image.copy() thumb.thumbnail((width, height), Image.LANCZOS) buffer = io.BytesIO() thumb.save(buffer, format=image.format or 'JPEG', quality=85) buffer.seek(0) output_key = key.replace('images/', f'thumbnails/{size_name}/') s3.put_object( Bucket=os.environ['OUTPUT_BUCKET'], Key=output_key, Body=buffer, ContentType=f'image/{(image.format or "JPEG").lower()}' ) thumbnails[size_name] = output_key return {'thumbnails': thumbnails, 'original_size': image.size} 

Lambda имеет ограничения: /tmp до 10 ГБ, timeout до 15 минут, память до 10 ГБ. Для файлов >100 МБ применяем стриминг, обрабатывая данные по частям без загрузки в память целиком.

Почему SNS+SQS надёжнее прямого вызова Lambda?

S3 event notifications не поддерживают DLQ напрямую. Если Lambda завершится ошибкой, событие теряется. Схема с SNS и SQS гарантирует доставку: неудачные вызовы после N попыток попадают в DLQ. Вы сможете проанализировать и перезапустить обработку. Это соответствует best practices AWS для продакшена.

Lambda vs ECS: что выбрать?

Для обработки изображений и документов Lambda проще и дешевле. Для видео-транскодинга используем MediaConvert.

Конфигурация Lambda для обработки файлов

resource "aws_lambda_function" "processor" { filename = "processor.zip" function_name = "file-processor" role = aws_iam_role.processor.arn handler = "handler.handler" runtime = "python3.12" timeout = 300 memory_size = 1024 ephemeral_storage { size = 2048 } environment { variables = { OUTPUT_BUCKET = aws_s3_bucket.processed.bucket } } } 

Мониторинг и метрики

• Число обработанных файлов в час
• Среднее время обработки по типу файла
• Error rate + содержимое DLQ
• Lambda duration distribution

CloudWatch Dashboard с этими метриками + алерт при росте DLQ.

Что входит в работу и ориентировочные сроки

• Разработка Lambda-функции на Python (или Node.js/Go) под ваш тип файлов
• Инфраструктура Terraform / Pulumi с S3, SNS, SQS, DLQ
• Настройка мониторинга CloudWatch + алерты
• Код-ревью и тестирование на нагрузку до 1000 файлов/мин
• Документация архитектуры и инструкция по деплою
• Обучение команды заказчика (1-2 часа)
• Поддержка 2 недели после сдачи

Ориентировочные сроки:

• Анализ требований и прототип — 2-3 дня
• Полный pipeline с DLQ, мониторингом — 4-6 дней
• Интеграция с вашим приложением (API Gateway, Cognito — опционально) — 2-5 дней

Реальные сроки зависят от сложности обработки. Свяжитесь с нами — оценим ваш проект за 1 день. Закажите консультацию и получите предварительную оценку без обязательств.