Можно ли поддерживать функцию AWS Lambda в тепле?

Есть несколько частей моего приложения, которые не могут позволить себе дополнительную 1-2-секундную задержку, вызванную циклом «замораживания-оттаивания», через который проходят функции Lambda, когда они новые или не используются в течение некоторого периода времени.

Как сохранить эти функции Lambda в горячем состоянии, чтобы AWS не приходилось постоянно их повторно инициализировать? Это касается как 1) редко используемых функций, так и 2) недавно развернутых функций.

В идеале есть пропущенная мной настройка, называемая «согреться», которая увеличивает стоимость лямбда-функций, но всегда поддерживает функцию в тепле и готовности к ответу, но я почти уверен, что этого не существует.

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


person samcorcos    schedule 18.03.2017    source источник
comment
Использование чего-то вроде таймера CloudWatch для периодической проверки связи с функцией - единственный способ выполнить то, что вы хотите в данный момент.   -  person Mark B    schedule 18.03.2017
comment
Спасибо @MarkB. У вас есть представление об идеальном интервале? Кажется, я не могу найти никаких конкретных цифр в документации Lambda. Мы говорим о пингах за 1 минуту? Пинги за 1 час?   -  person samcorcos    schedule 18.03.2017
comment
Как ни странно, я думаю, вам нужно что-то в диапазоне от 5 до 15 минут. Объявите глобальную переменную вне обработчика, затем внутри обработчика установите для этой переменной значение из _ 1_ только если он еще не установлен ... затем записать значение переменной. По сути, это дает вам уникальный идентификатор контейнера, который вы можете использовать для отслеживания повторного использования контейнера и определения эффективности вашей стратегии. Сохраните время в аналогичной переменной и увеличивающем счетчике, и вы получите хорошую перспективу.   -  person Michael - sqlbot    schedule 18.03.2017
comment
@ Michael-sqlbot Я провел несколько тестов (см. Ссылку) и, похоже, интервал не так уж и важен ... Мысли? medium.com/@SamCorcos/ < / а>   -  person samcorcos    schedule 21.03.2017
comment
Еще одна вещь, на которую стоит обратить внимание, заключается в том, что вы здесь держите один контейнер готовым к работе ... но один контейнер обрабатывает только один параллельный запрос за раз. (Модель биллинга на основе времени выполнения + памяти не имела бы смысла, иначе, не говоря уже об увеличении сложности). Если второй запрос поступает, когда первый контейнер уже обрабатывает первый, этот второй запрос все равно будет видеть задержку раскрутки ... если, конечно, вам не удалось сохранить два (или любое другое количество) контейнеров готовыми. Но с увеличением трафика эта проблема со временем решается сама собой.   -  person Michael - sqlbot    schedule 21.03.2017
comment
@ Michael-sqlbot имеет смысл, спасибо за разъяснения. Я пошел дальше и соответствующим образом обновил статью.   -  person samcorcos    schedule 22.03.2017
comment
@ Michael-sqlbot инженерная сторона iPlayer, которую я добавил в качестве ответа ниже, предполагает иное. Они предварительно нагревают один контейнер для последующей параллельной обработки сотен запросов. Если бы ваше предположение было верным, это не сработало бы.   -  person Jonathan    schedule 12.10.2017
comment
@ Джонатан, мое предположение не является предположением. Вы можете легко наблюдать это, создав глобальную переменную, заполнив ее случайным значением, если оно не определено, а затем выставив его значение в лямбда-ответе или журналах. Добавьте к этому счетчик, увеличивающийся с каждым вызовом. Они служат идентификатором контейнера и счетчиком запросов. Я подозреваю, что авторы этого поста не полностью подтвердили свои предположения и пришли к выводу, что они делают то, чего не делают. Проверьте и посмотрите, что вы найдете.   -  person Michael - sqlbot    schedule 12.10.2017
comment
Вдобавок, если задуматься, 200 одновременных вызовов в одном контейнере будут работать ужасно, потому что 200 задач будут конкурировать за ЦП и память. Если нет, то как система узнала, что нужно запускать эти 200 вызовов в контейнере на машине с 200 ядрами и 300 ГиБ ОЗУ? Задать вопрос - значит ответить на него ... Так не может быть.   -  person Michael - sqlbot    schedule 12.10.2017


Ответы (1)


BBC опубликовала прекрасную статью о разработке iPlayer, в которой описывается аналогичная проблема.

Они решили вызывать функцию каждые несколько минут с помощью запланированных событий CloudWatch.

Так что теоретически он должен просто оставаться там, но может и не остаться. Итак, мы назначили мероприятие по расписанию, чтобы контейнер «оставался теплым». Мы вызываем функцию каждые пару минут, чтобы не производить никакой обработки, а чтобы убедиться, что у нас есть готовая модель. Это составляет очень небольшой процент вызовов, но помогает нам смягчить условия гонки при загрузке модели (мы также искусственно ограничиваем количество лямбд, вызываемых параллельно, в качестве дополнительной меры).

person Jonathan    schedule 12.10.2017