Обработка против расщепления пакетного файла с Sqs и Lambda

Question

Я хочу обработать разные пакетные файлы, используя архитектуру S3-SQS-Lambda и рассматривая 3 возможных подхода к проектированию

1. Вариант 1. Обработка пакетного файла целиком за один раз

   • Файл доставлен на S3
   • Первая лямбда сработает и создаст сообщение в SQS
   • Вторая лямбда сработает и обработает пакетный файл одновременно

2. Вариант 2 - обработка командного файла с каждым сообщением, обрабатываемым отдельно

   • Файл доставлен на S3
   • Сначала Lambda будет запускать и создавать сообщения в SQS для каждой строки в пакетном файле, причем каждая строка соответствует сообщению
   • Вторая лямбда сработает и будет обрабатывать одно сообщение за раз

3. Вариант 3 - Обработка пакетного файла с одновременной обработкой нескольких сообщений

   • Файл доставлен на S3
   • Сначала Lambda будет запускать и создавать сообщения в SQS для каждой строки в пакетном файле, причем каждая строка соответствует сообщению
   • Вторая лямбда сработает и будет обрабатывать несколько сообщений одновременно

Я склонен использовать вариант 3, поскольку он представляется средним с точки зрения архитектуры, масштабируемости, обработки / стоимости, но хотел бы получить от экспертов указания о том, как они сравнивают эти варианты.

Answer 1

Предпочитайте простоту, пока у вас не возникнет доказанная потребность в сложности.

Все три из этих параметров выглядят архитектурно обоснованными Но для разных условий:

1. Это не требует дополнительной инфраструктуры для управления вами. До тех пор, пока одна лямбда всегда может выполнить пакет в течение приемлемого периода времени, я бы всегда предпочел этот вариант. Это просто и легко рассуждать о.
2. Используйте это, если вы можете продемонстрировать, что обработка каждого сообщения в пакете занимает несколько секунд, и вы хотите проработать пакет как можно быстрее. Это связано с тем, что вы будете выполнять параллельную работу, выполняя эту работу, что потребует дополнительной сложности и накладных расходов, поэтому, если обработка сообщения займет всего несколько мс, вы не сможете сэкономить время и будете лучше работать с ним. вариант ...
3. Используйте эту опцию, если размер пакета из файла слишком велик для своевременной обработки одной лямбды (например, вариант 1 не подходит), и в результате экспериментов вы обнаружили, что равно идеальный размер пакета (например, накладные расходы на разделение и запуск лямбды преобладают при небольшом количестве сообщений, но, скажем, при 100 сообщениях, он становится быстрее обрабатывать параллельно).

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