Блог

У меня есть требование, при котором один запрос API генерирует 1000 отдельных независимых задач.

Сегодня мы запускаемся как приложение на языке Си в одном экземпляре EC2 c5.9xlarge и распределяем задачи по всем потокам экземпляра EC2.

Задачи:

1. На 100% привязаны к процессору, нет ввода-вывода или внешнего взаимодействия, они выполняют много вычислений.
2. Они на 100% независимы, между задачами при их выполнении нет взаимосвязи / зависимостей.
3. Используйте только небольшой объем памяти.
4. По завершении сгенерируйте некоторый вывод. Выходные данные всех задач объединяются / консолидируются в единую полезную нагрузку ответа, размер которой в json составляет менее 3 КБ.

Полезная нагрузка ответа должна включать 100% задач, недопустимо отсутствие выходных данных задачи.

При текущей архитектуре, игнорирующей сетевые переходы, время обработки составляет менее 1,5 секунд.

Я рассматриваю возможность переноса этого на AWS Lambda, потому что:

1. Запросы редкие / прерывистые со значительными периодами бездействия
2. Lambda может быть дешевле — когда я принимаю во внимание разработку, тестирование, контроль качества и производство и т. Д., Стоимость экземпляров EC2 становится проблемой
3. Lambda может быть более масштабируемой — в текущей архитектуре для обработки одного запроса требуется один экземпляр EC2. Если я хочу обрабатывать 7 запросов одновременно (в период сбоя) Мне нужно было бы подготовить 7 экземпляров EC2. Учитывая мое время отклика в 1,5 секунды, я не считаю, что динамическое масштабирование ec2 полезно в данном случае.
4. Возможно, с помощью Lambda я могу либо повысить свою производительность (сократить время отклика с 1,5 секунд), либо ИЛИ повысить точность моих вычислений, выполнив еще более 1000 задач, но все равно в течение 1,5 секунд.

Я понимаю, что AWS Lambda поддерживает языки (Java, Go, PowerShell, Node.js (C #, Python и Ruby code) вряд ли будут такими же быстрыми, как C, однако я думаю, что при некоторой целенаправленной оптимизации разница во времени обработки задачи будет незначительной и более чем компенсируется большим потенциалом параллелизма Lambda. Я рад использовать любой язык. Честно говоря, в центре внимания этого вопроса находится не выбор языка, а архитектура. Я понимаю, что разные языковые реализации будут иметь разные характеристики в отношении времени запуска и выполнения.

Моя первоначальная идея состоит в том, чтобы разветвлять каждую задачу на отдельные лямбды, а затем объединять результаты.

Я заметил, что в этой статье автор описывает задержку блокировки примерно на 50 мс только при вызове await lambda.InvokeAsync(). Это само по себе потенциально является ограничителем моих требований к производительности.

Я также подумал, следует ли мне использовать архитектуру на основе очереди, записав 1000 сообщений с запросом задачи в очередь и разрешив запускать 1000 лямбд для их одновременной обработки. Однако затем мне нужно объединить результаты, предположительно, записав все выходные данные в другой SQS, где обработчик результатов может объединить их. На самом деле у меня будет несколько запросов, выполняемых одновременно, поэтому архитектуру необходимо масштабировать для поддержки этого.

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

Как вы можете видеть, есть значительные неизвестные, будет ли AWS Lambda в конечном итоге соответствовать моим требованиям к производительности (1000 задач за 1,5 секунды), если да, то какова рекомендуемая архитектура, особенно в отношении сбора ответов с разветвлением.