У меня есть то, что я назову «микросервисом», работающим на AWS Lambda (использующем node.js).
По сути, он выдает сжатые сводки, взятые из нескольких сотен мегабайт двоичного блоба. Существует множество возможных выходов, и предварительная генерация всех возможностей невозможна, и он должен быть достаточно отзывчивым (в худшем случае менее секунды), поскольку к нему обращаются (через API Gateway) с интерактивных веб-страниц, которые позволяют быстро изменять параметры. Шаблоны доступа в блобе по сути случайны, хотя любое созданное резюме обычно будет иметь доступ только к ~0,1-1% от общего объема данных. Данные и шаблоны доступа не очень совместимы с хранением данных в базе данных (хотя см. упоминание DynamoDB ниже).
Мой текущий подход заключается в том, чтобы разместить большой двоичный объект на S3 и кэшировать его локально обработчиками Lambda между вызовами Lambda (как буфер в коде javascript с областью действия вне функции обработчика; очевидно, что память Lambda настроена достаточно большой). Экземпляры обработчиков кажутся достаточно постоянными, чтобы после запуска сервера он работал хорошо и очень отзывчиво. Однако есть как минимум пара недостатков:
Первоначальная скорость извлечения данных из S3, по-видимому, составляет около 50–60 Мбайт/с (что, по-видимому, согласуется с другими отчетами о пропускной способности S3, которые я видел), поэтому при первом доступе может возникнуть раздражающая задержка в несколько секунд.
В связи с предыдущим пунктом, если клиент очень активен и/или увеличивается пользовательская нагрузка, запускается больше экземпляров сервера, и пользователи могут обнаружить, что их запросы направляются на экземпляры, которые зависли при извлечении большого двоичного объекта данных, что приводит к раздражающим сбоям в работе клиента, который в остальном работает без сбоев.
Я открыто признаю, что, вероятно, ожидаю слишком многого от того, что на самом деле задумано как "не сохраняющий состояние" сервис, поскольку в нем на самом деле есть большой кусок состояния (двоичный blob), но мне интересно, можно ли что-то сделать, чтобы улучшить ситуацию. Обратите внимание, что данные не особенно сжимаемы (можно было бы убрать 1/3, но это не тот порядок величины, который я ищу, или, по крайней мере, это просто часть решения в лучшем случае).
Есть ли какие-нибудь предложения, как быстрее загрузить данные в Lambda? Я себе представляю что-то вроде этого:
Извлеките свои данные из другого места, куда у Lambdas гораздо более высокая пропускная способность... но из чего? DynamoDB (разделенная на столько 400 тыс. двоичных записей, сколько нужно)? ElastiCache? Что-то еще в "меню" AWS, чего я не заметил.
Используйте какой-нибудь хитрый трюк (какой?), чтобы «предварительно разогреть» экземпляры лямбда-выражений.
Вы используете совершенно не тот инструмент для работы; используйте... вместо этого? (Мне действительно нравится модель Lambda; не нужно беспокоиться обо всех этих процессах подготовки экземпляров и автоматического масштабирования, просто сосредоточьтесь на функциональности).
Если недавно анонсированные предложения Google или Microsoft, подобные Lambda (о которых я мало что знаю), обладают какими-либо атрибутами, которые могли бы лучше помочь в этом варианте использования, это тоже было бы очень интересной информацией.
Один из вариантов, который я рассматривал, — это запаковка двоичных данных в «пакет развертывания», но ограничение в 250 МБ для него слишком мало для некоторых предполагаемых вариантов использования (даже если большой двоичный объект сжат).
решение1
Если двоичный blob составляет всего несколько сотен мегабайт, вы можете просто включить его в свою функцию как «зависимость». Вы можете добавить его как файл вместе с вашим кодом и ссылаться на него соответствующим образом.
Другим вариантом было бы иметь две лямбда-функции. Одна функция ничего не делает, кроме как обслуживает блоб (который вы создаете, как указано выше, отправляя блоб с помощью функции), а затем вы можете использовать таймер (по сути cron), чтобы «щекотать» эту функцию каждую минуту, чтобы она оставалась активной. Затем ваша вторая лямбда выполняет работу, и первое, что она делает при запуске, — вызывает первую лямбду, чтобы получить блоб. Вызовы лямбда-лямбда имеют высокую пропускную способность, поэтому время запуска не должно быть проблемой.
Идеальным решением было бы найти способ суммировать данные и сохранить их в DynamoDB, но, судя по всему, вы уже пробовали этот способ, и он не показался вам разумным.