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