Пробуйте новое: популярные варианты использования AWS Lambda и 5 главных инструментов для работы с ней

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

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

Оптимизация затрат при работе с AWS Lambda

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

К примеру, при увеличении оперативной памяти вдвое время может сократиться более чем в два раза.

Давайте посмотрим на этот график. Здесь самые низкие издержки достигаются на отрезке от 1024 до 1536 МБ. Хотя поначалу могло казаться, что для наибольшей экономии нужно ставить базисные 128 МБ.

Мониторинг по CloudWatch

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

В примере ниже приведены три следующих метрики:

Из первого графика видно, что около 12:00 значительно возросло количество обращений к лямбда-функции. На втором графике видно, что время выполнения функции в среднем составляет около 1000 миллисекунд. На третьем — фиксируется высокий показатель ошибок. Все вместе дает немало поводов к размышлению о выполнении лямбды, падении тайминга и полученных фейлах.

Также через сервис CloudWatch происходит логирование данных из лямбда-функции.

То есть все, что отправляется в STDOUT (log или print), отправляется именно в CloudWatch. Там для каждой лямбда-функции создается своя лог-группа, внутри которой собираются стримы.

Стрим — это вся информация из логов от функции, от одного экземпляра энвайромента. Если у вас было несколько обращений к функции за короткое время, и она все время работала, это будет собрано в одном стриме.

Путь к нему состоит из даты первого исполнения, версии лямбда-функции и рандомного хеша из цифр:

На следующей иллюстрации представлен пример логов лямбда-функции, которая была написана выше. Есть три обращения к лямбде, когда трижды передавалось имя John. И все это с интервалом в несколько секунд трижды собиралось в этом отчете:

В первом логе обратите внимание на принт Loading function во второй строке, который объявлен вне лямбда-функции. Он нигде не повторяется. В этом случае для Python не происходит никакого импорта библиотек для уже созданного окружения.

Также в первом логе есть важный блок Init Duration. Это время на загрузку кода, создание окружения и выполнение всех импортов и самого кода вне метода обработчика. Фактически это все, что происходит при холодном старте: подключение к разным базам данных и сервисам, где хранятся секреты. При повторном использовании среды этого уже происходить не будет.

Пермиссии

В инфраструктуре сервисов AWS предусмотрено четкое разделение доступов на чтение и выполнение для различных ресурсов даже в одном аккаунте. Для этого используется механизм сервиса Identity Access Management. Он предполагает создание Policy — ​​политик. Описания объясняют, какой ресурс и к чему имеет доступ.

Здесь все строго ограничено: невозможно даже сделать запись в CloudWatch без Policy на разрешение изменения в логах. Мы в нашей команде часто создаем предел на функцию консоли, в дашборде AWS, чтобы он автоматически подставлял такие пермиссии к ролям.

Для лямбда-функции существуют два типа политик:

• Политики ресурса (на схеме слева)

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

• Политики выполнения

Указывают, к каким ресурсам может обращаться функция. Эти политики существуют как отдельные сущности и могут быть расшарены между несколькими лямбдами. Также здесь прописываются действия, которые должны осуществиться, и ресурс, к которому есть доступ. Для этого используется ARM (Amazon Resource Name), выступающий идентификатором ресурса.

Layers

Это удобный способ упаковки библиотек и зависимостей, если их следует использовать совместно для нескольких лямбда-функций. Сам по себе это ZIP-архив, который для окружения лямбда-функции распаковывается в директорию opt. Он может быть публичным или приватным.

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

Вот пример распределения лейеров. Лямбда-функции 1 и 3 совместно используют библиотеки. Лямбда функции 2 и 3 делят ассеты. Например, шаблоны писем или HTML, к которым они будут иметь доступ:

Популярные варианты использования лямбда-функции

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

Начнем по строкам сверху вниз:

• Первый вариант начинается с эндпоинта, созданного с помощью API Gateway.
• Далее расположен Kinesis Data Streams. Он получает информацию из стрима пользователей и передает ее в лямбда-функцию.
• Последняя же обрабатывает и фильтрует данные, которые затем хранятся в DynamoDB. Так, скажем, устроена аналитика действий пользователей в сфере рекламы.
Курс English For Tech: Speaking&Listening від Enlgish4IT.
Після курсу ви зможете найкраще презентувати свої досягнення, обговорювати проекти та вирішувати повсякденні завдання англійською мовою. Отримайте знижку 10% за промокодом TCENG.
Дізнатись про курс

В следующем Use Case по API Gateway следует лямбда-функция. Фактически она и есть веб-приложение Flask или Fastapi (на них пишутся функции).

Перед нами монолит, не являющийся хорошей практикой, но это решение оправдано. Ведь так можно избавиться от потерь времени на холодном старте.

Схема организована следующим образом:

• Сначала эта веб-программа принимает запрос от пользователя.
• Далее следует асинхронный вызов функции, которая должна осуществлять API call в сторонний сервис IP-телефонии. То есть происходит передача массива информации о пользователях, их номерах телефонов и т.д.
• Эта лямбда-функция в переменных окружения будет иметь токен на доступ к сервису IP-телефонии. При этом у веб-приложения разрешения нет, поэтому схема достаточно секьюрна. Следовательно можно сразу вернуть респонс инициатору запроса, не дожидаясь обращения к стороннему сервису. Перебор пользователей в одной лямбда-функции или запуск множества функций для каждого пользователя IP-телефонии будет осуществляться фоново для отдельной функции-обработчика.

Третья строчка на схеме определяет работу с базой данных. В ней лямбда-функция подключена к базе данных через RDS Proxy. Это хорошая практика, ведь инстанций в лямбде может быть множество. То есть в базу данных будут поступать десятки обращений. RDS Proxy помогает избежать возможных проблем. Прокси собирает все подключения от лямбда-функции и устанавливает единое подключение к реляционной базе данных.

Поскольку в этой схеме отсутствуют Gunicorn, Nginx или Apache, разработчику достаточно подключить какую-нибудь библиотеку. Есть только способ handler для обработки реквеста от API Gateway.

Например, для Flask этот способ — Lambda middleware, подключаемая к Flask-применению. Он трансформирует ивент от API Gateway в нечто более читающее и похожее на WSGI-реквест от вашего HTTP-сервера.

Для асинхронных фреймворков типа Fastapi существует несколько библиотек, которые запускают программу в асинхронном цикле. Внутри цикла они также трансформируют ивент от API Gateway в объект, альтернативный ASGI-реквесту.

Самый низкий пример на схеме показывает загрузку пользователем файлов непосредственно в S3 в обход эндпойнта и лямбда-функции. В ответ на ей ивент срабатывает определенный триггер. Он вроде говорит: нужно сохранить информацию о загруженном файле в базу данных и метаданные вроде времени загрузки. Все это записывается в ивент, который формируется в S3. Лямбда-функции остается только получить эти данные и записать их в реляционную базу данных.

Фреймворки и инструменты для работы с AWS Lambda

1 AWS Serverless Application Model

На мой взгляд, это самый удобный и гибкий инструмент для написания лямбда-функций. Он разработан и поддерживается Amazon.

SAM состоит из двух частей:

• первая — консольная утилита для инициализации, деплоя и тестирования проектов;
• вторая — это YAML для описания ресурсов.

Причем, это необязательно должна быть лямбда-функция. Допустимы как serverless-ресурсы, вроде DynamoDB и Aurora, так и обычные амазонские. Также здесь можно расписать все роли с правами доступа.

2AWS Command Line Interface

Основная консольная утилита для работы с аккаунтом. Если работаете с TensorFlow, возможно, вам понадобится генерировать креды и токены. Их можно прописать с помощью этой утилиты. Практически все фреймворки для разработки лямбда-функций — надстройка AWS CLI.

3Serverless Framework

Своеобразный шаблон, где описываются нужные ресурсы. Serverless Framework поддерживает работу с Azure и Google Cloud.

4AWS Chalice

Одновременно консольная утилита и Python библиотека для разработки serverless-приложений. В этом случае вам не нужно описывать свойства ресурсов в шаблонах, как это необходимо с YAML.

Все операции выполняются с помощью декораторов, предоставляемых функциям, написанным в Chalice. Далее эта утилита перед деплоем с помощью консоли подхватывает все данные и разворачивает. Очень удобно и быстро.

5AWS Amplify

Мощный фреймворк для фулстек-разработки. Представляет собой консольную утилиту с набором библиотек для фронтенда. К примеру, можно разработать сервис для авторизации пользователей без понимания принципов работы самого AWS.

Вам достаточно прочитать документацию, чтобы за несколько операций в консоли создать Amplify At Authorization. Потом так же читаете документацию с фронтенда — и в самом проекте импортируете, например, класс для React. Он уже реализует форму авторизации и локально сохранит токен.

Правда, из-за определенных ограничений это иногда работает «на костылях». Например, в SAM можно вписать в шаблон нужные ресурсы, чтобы утилита сама генерировала все необходимое. А у Amplify в принципе нет такой реализации. Если вы впишете что-то самостоятельно, то при последующем обновлении ресурса или изменении его свойств система все сотрет. Итак, используйте этот фреймворк осторожно.

---

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