Блог

Моя архитектура — AWS Gateway — Lambda — RDS, я получаю данные от клиентов в виде файлов xlsx.

У меня есть 2 шага

1. Обработайте файл и сохраните его в таблицах транзакций.

2. После утверждения пользователем обработайте данные в активные таблицы.

Мой вопрос касается больших файлов, из-за ограничений по времени (AWS gateway 30 секунд, Lambda 15 минут) и синхронного процесса я не могу завершить процессы. Пожалуйста, предложите мне какую-либо службу в AWS, которая может выполнять длительные задания, которые должны постоянно взаимодействовать с RDS, для сравнения файловых данных с системными данными.

Как правило, вам нужно, чтобы все HTTP-запросы были как можно короче, что означает, что вы никогда не выполняете никакой реальной работы в рамках HTTP-запроса. Вся фактическая работа должна выполняться в лямбда-функциях, которые были вызваны каким-либо другим способом, а не API Gateway. Общий поток будет примерно таким:

1. Клиент загружает большой файл, взамен получает уникальный идентификатор для этой загрузки.
2. Сервер анализирует файл в записи базы данных.
3. Сервер начинает обработку этих записей базы данных.
4. Клиент может запросить статус обработки в любой момент, используя идентификатор.

В качестве примера я реализовал подобную систему следующим образом:

1. Браузер загружает большой файл Excel, этот файл считывается и записывается в базу данных строка за строкой, партиями по сотни строк за раз, все помечены одним и тем же случайным идентификатором UUID. Затем файл естественным образом удаляется при завершении запроса. Это пакетное чтение / запись оптимизированы, поэтому даже очень большие файлы могут быть загружены в базу данных за считанные секунды.
2. В качестве последнего действия перед завершением процесса загрузки сообщение SQS помещается в очередь с идентификатором UUID загруженных записей.
3. Очередь SQS вызывает лямбда-функцию, которая запрашивает все записи с этим UUID и помещает новые сообщения SQS в очередь с индивидуальными идентификаторами каждой записи партиями по несколько десятков (например, сообщения для «обработать запись 1-20», «21-40» и т.д.).
4. Очередь снова вызывает другой обработчик Lambda, который обрабатывает каждую запись одну за другой.

Итак, большая загрузка была разбита на отдельные записи, затем отдельные пакеты записей, затем каждая запись обрабатывается индивидуально, и каждый отдельный шаг занимает не более нескольких секунд и распределяется по отдельным экземплярам Lambda.

Это не только позволяет обрабатывать множество записей параллельно, но и никогда не приближается к 15-минутному тайм-ауту Lambda. HTTP-запросы также никогда не приближаются к 30-секундному пределу, поскольку начальный этап анализа и сохранения не занимает много времени, и каждый последующий запрос просто должен просматривать базу данных для определения статуса обработки и ничего не делает сам по себе. В зависимости от ваших потребностей, если даже начальный этап анализа и сохранения займет больше 30 секунд, вы можете загрузить файл на S3, а затем запустить лямбда-функцию для его обработки оттуда.

Если какой-либо из этих шагов, даже такой минимизированный и разбитый, как этот, занимает больше времени, чем 15-минутный тайм-аут Lambda, то Lambda — неподходящая платформа для этой работы.

1. Обработайте файл и сохраните его в таблицах транзакций.
Мой вопрос касается больших файлов

API Gateway имеет некоторые ограничения по полезной нагрузке, поэтому он действительно не предназначен для передачи большей полезной нагрузки.

Обычной практикой для большого содержимого является использование службы API для возврата предварительно указанного URL-адреса, который может быть легко использован клиентом для загрузки содержимого в S3

Затем вы можете использовать другой ресурс API или события S3 для вызова действия при создании объекта (запустить процесс, пакетное задание, …).

2. После утверждения пользователем обработайте данные в активные таблицы.

Теперь вопрос в том, что такое процесс утверждения, что такое «обработка данных», сколько времени это может занять, какие ресурсы необходимы.

Если предполагается, что это длительный процесс с несколькими этапами, возможно, использование функции AWS Step для координации задач может быть хорошим вариантом, но это зависит от ваших вариантов использования.

Для длительных заданий есть AWS Batch, EMR (или другой вычислительный ресурс) или даже SQS Lambda, если вам удастся разбить работу на управляемые части..