Используйте таймеры CloudWatch, чтобы разморозить функции и сократить время отклика с 3 секунд до пары сотен миллисекунд

Использование бессерверной архитектуры дает множество преимуществ, и существуют сотни отличных статей, превозносящих ее достоинства, но одним болезненным недостатком является зачастую медленное время отклика бессерверных функций, которые используются нечасто.

Это связано с тем, что иногда контейнер, в котором была создана функция, не используется повторно. Поэтому для некоторых запросов AWS необходимо повторно подготовить контейнер с вашим кодом, прежде чем он сможет обработать запрос.

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

С другой стороны, бывают случаи, когда ваш код просто замораживается в контейнере, который можно «разморозить» перед обработкой новых запросов, что занимает всего миллисекунды.

В идеале у AWS должна быть опция типа «согреться», которую вы могли бы переключить и согласиться платить больше, чтобы AWS постоянно поддерживал неиспользуемый контейнер в рабочем состоянии. Увы, это еще не реализовано (пока?), Поэтому наш следующий лучший вариант - использовать таймер CloudWatch.

CloudWatch Таймер

Как предложил Майкл в Stack Overflow, вам нужно будет проверять связь с лямбда-функцией каждые 5–15 минут, чтобы она оставалась теплой. Это проще, чем можно было ожидать.

Сначала откройте консоль AWS (и да, есть способ сделать это через CLI) и перейдите в CloudWatch. Оттуда перейдите к Events и щелкните Create rule. Установите тип события Schedule, и мы будем запускать это событие каждые 1 минуту.

Затем выберите из списка Targets лямбда-функцию, на которую вы хотите настроить таргетинг, и сохраните. затем вам нужно будет придумать имя и описание.

Вот и все! Теперь вы проверяете свою лямбда-функцию каждую минуту.

Как протестировать

Чтобы проверить, действительно ли наш таймер поддерживает функцию, мы собираемся создать функцию, которая хранит уникальный awsRequestId в переменной с именем containerID в глобальной области (вне отдельной функции).

Технически это не идентификатор контейнера, но он сообщит нам, используется ли контейнер повторно для последующего запроса, поскольку мы пишем в него только в том случае, если значение еще не было определено.

После того, как вы развернете эту функцию, установите таймер и подождите некоторое время, вы можете проверить журналы CloudWatch и увидеть, что containerID сохраняется во всех запросах, что говорит нам о том, что AWS сохраняет функции в теплом состоянии, если есть менее 1 минуты между вызовами.

Итак, ради науки я пошел дальше и создал интервальные таймеры на 1–15 минут, а также 30, 45 и 60-минутные интервалы для хорошей оценки. Это должно дать нам представление о том, как долго AWS поддерживает эти контейнеры в тепле.

Полученные результаты

Перенесемся на 8 часов вперед, и у нас есть результаты. Я надеялся, что результаты будут достаточно интересными, чтобы создать причудливую диаграмму, но вместо этого я нашел этот шаблон для всех функций.

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

Даже при 1-часовом пинге один и тот же контейнер продолжался несколько часов подряд (изображение ниже).

Таким образом, может показаться (по крайней мере, из этого эксперимента), что частота пингов не имеет большого значения ...

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

Если у вас есть идеи о том, как мы могли бы улучшить эти результаты, или если у вас есть основания полагать, что эти результаты недействительны по какой-либо конкретной причине, дайте мне знать в комментариях.

Сэм Коркос - соучредитель CarDash, поставщика услуг автомобильного консьержа, который избавляет от хлопот, связанных с автосервисом, уходом и техническим обслуживанием. Он также является автором Learn Phoenix и основателем Sightline Maps.