Краткий экскурс в AWS Lambda
Что это?
AWS Lambda: это вычислительный сервис, который позволяет запускать код практически для любого типа приложения или серверной службы — и все это без необходимости администрирования. AWS Lambda выполняет все администрирование за вас, включая обслуживание сервера и операционной системы, выделение ресурсов и автоматическое масштабирование, мониторинг кода и ведение журнала. Все, что вам нужно сделать — это предоставить свой код на одном из языков, которые поддерживает AWS Lambda.
Зачем ее использовать?
- Деньги. Вы платите только за то время, когда сервис работает.
- Скорость. Сама по себе лямбда поднимается и работает очень быстро.
- Удобство. Лямбда имеет много возможностей по интеграции с сервисами AWS.
- Производительность. Параллельно может выполняться, в зависимости от региона максимально от 1000 до 3000 экземпляров. И при желании, этот лимит можно поднять, написав в поддержку.
У этого подхода есть и свои минусы, вы не можете управлять операционной системой на который выполняется код, не можете контролировать ЦП, память и ресурсы. Всем этим занимается AWS.
Все что вы можете, это выбрать язык, из поддерживаемых AWS Lambda.
Что могёт?
Ниже представлен краткий перечень основных функций AWS Lambda. Далее все рассмотрим по порядку.
1. Triggers
Triggers — это «возбудители» лямбды. В некотором роде лямбду можно сравнить с PHP, в том плане, что для нас она выполняется и умирает. Далее мы подробно рассмотрим механизм работы. Пока нужно понимать что лямбда, это одна функция, которая выполняется по запросу из триггеров.
Ниже список всех возможных триггеров:
API Gateway
AWS IoT
Alexa Skills Kit
Alexa Smart Home
Application Load Balancer
CloudFront
CloudWatch Events
CloudWatch Logs
CodeCommit
Cognito Sync Trigger
DynamoDB
Kinesis
S3
SNS
SQS
Для каждого из них вам нужно будет настроить уникальные параметры, которые доступны для этих триггеров. Также вы можете настроить несколько триггеров на одну лямбду. От типа триггера зависит, будет лямбда выполняться синхронно или асинхронно.
Notice: Обратите внимание, что лямбду можно заставить выполниться, так и с помощью AWS CLI, AWS SDK в ручном режиме, передавая все необходимые параметры. В том числе будет она выполняться синхронно или нет
Давайте разберем на примере:
1. API Gateway — позволяет дергать лямбду по http запросу и требует вернуть результат пользователю. Такая операция не может выполняться асинхронно, т.к. требует ответа. Для синхронных операций некоторые функции недоступны.
2. SQS — к примеру, если наша лямбда обрабатывает сообщения от SQS, возвращать результат никуда не нужно и она может выполняться асинхронно. При асинхронном выполнении появляется несколько новых возможностей, к примеру, мы можем настроить повторное выполнение в случае ошибки, или отправлять такие запросы дальше в «мертвую» очередь SQS.
2. Permissions to AWS Services
Это сервисы AWS к которым лямбда имеет доступ по умолчанию. Что это значит? В функции которую вы будете писать всегда можно подключить AWS SDK и без ключей или каких либо параметров авторизации вы сможете использовать доступные сервисы. Все доступные сервисы вы определяете в IAM Role которую используете для этой лямбды.
Для каждого используемого языка есть своя SDK, которая умеет общаться с основными сервисами AWS.
Notice: для каждой лямбды вы настраиваете IAM Role от лица который будет запускаться лямбда
3. VPC
Вы можете настроить виртуальную сеть для вашей лямбды, например для безопасного подключения к RDS.
4. Online Editor
Также AWS Lambda предоставляет возможность редактировать код вашей функции напрямую с интерфейса в вашем браузере.
5. Logging
Все запросы на лямбду логируются в CloudWatch, туда же записываются данные по времени выполнения и памяти, эти данные могут очень помочь для установки лимитов. Также в коде есть возможность логировать собственные данные(к примеру в Node.js через console.log).
Дополнительно вы всегда можете увидеть статистику по использованию лямбды на вкладке Monitoring
6. Environment Variables
У вас есть возможность передавать безопасно в код переменные окружения, что позволяет настраивать важные части системы без доставки кода. Есть возможность шифрования переменных окружения через ключи.
Notice: Обратите внимание, что есть список заранее подготовленных переменных окружения
7. Code
Теперь самая интересная часть, сама по себе лямбда состоит из нескольких частей.
1. Layers — нижний слой. Он не обязателен, но если для использования лямбды вам нужно добавить какие-то библиотеки, то их нужно класть отдельно от основного кода, так вы сильно экономите на объеме основного кода и быстродействии самой функции.
Слои в AWS Lambda чем-то похожи на слои в докере, в том плане, что они перманенты относительно функции, и их нужно изменять отдельно. Также их можно переиспользовать в других лямбдах.
2. Function Environment — в коде должна обязательно находится функция, которая непосредственно будет выполняться при каждом запуске лямбды(Handler). О ней ниже. А перед ней находится ее окружение, которое мы задаем. Дело в том, что управление ресурсами происходит таким образом, что это окружение, хранится отдельно от функции какое-то время после ее завершения. И при следующем старте, возобновляется, не тратя на инициализацию время и ресурсы. Таким образом, все что возможно, нужно проинициализировать до самой функции, к примеру конфигурации, подключение библиотек и т.п.
3. Handler — непосредственно сам по себе выполняемый код, в зависимости от языка, определяется по разному. Для примера возьмем Node.Js. Для того что бы ваш код выполнился, нужно:
- js файл — 1шт
- exports.yourFunction = () => {//Ваш код} — 1шт
По умолчанию запускается index.js и ищет в нем функцию с именем «handler». Затем выполняет ее. Ваша функция может быть асинхронной в коде. На синхронное выполнение лямбды это не влияет.
Ниже пример кода, постараюсь описать что происходит там:
//AWS SDK уже встроен, его не нужно загружать отдeльно
var AWS = require('aws-sdk'); // только подключить
//Все что вам нужно, лучше подключать здесь
//Это пример с API Gateway.
//Если проще, то это обычный http запрос
exports.handler = async(event, context) => {
//В event нам приходит вся инфа о запросе
//В context нам приходит текущий контекст aws lambda функции:
// почему была запущена, кем и прочая вспомогательная инфа
console.log('testing cloud watch');
// ^ Таким образом мы можем писать в Cloud Watch кастомные сообщения
return {
//Таким образом мы отвечаем на http запрос, думаю ниже все понятно
statusCode: 200,
body: 'Hello world',
headers: {}
};
};
exports.handler = (event, context, callback) => {
//Это второй вариант с callback,
//в каких-то случаях это может быть удобнее
callback(
null, //<- Первый параметр, это если вам нужно вернуть ошибку
{ // Второй параметр это успешно
statusCode: 200,
body: 'Hello world'
}
);
};
8. Версионирование
Сервис поддерживает удобное версионирование. Вкратце мы каждой загруженной копии можем выдавать версию. И добавлять алиасы, которые указывают на какую-то версию. Как это работает? Смотрите на схемку ниже
И так, теперь давайте разберемся что нужно сделать, чтобы получить то — что мы видим на диаграмме
Состояние первое
- Создать первую версию нашей лямбды. Вместе с первой версией у нас создается указатель на версию "$LATEST". Он всегда указывает на последнюю добавленную версию
- Добавить алиас «Dev». Тут мы выбираем куда привязать, у нас есть несколько вариантов — создать указатель на конкретный номер версии, в нашем случае «1», привязать указатель к "$LATEST", или привязать к другому алиасу. В данном случае мы прикрепляем к указателю "$LATEST", и теперь наш «Dev» алиас всегда будет указывать на последнюю ветку, так мы можем всегда на дев окружении тестировать наше приложение с последней версией лямбды. И если вдруг нам понадобится проверить, как оно работает на старой версии, нужно будет просто переключить в триггере алиас или изменить у алиаса ссылку на версию, не трогая наше приложение
- Добавить алиас «Stage» и привязать его к первой версии нашей лямбды
- Добавить алиас «Prod» и повторить, что мы делали для «Stage»
Notice: вот тут описано как работать с алиасами на практике. Практическая часть по lambda будет в следующей статье вместе с SQS
И так, сейчас мы получили что-то непонятное, по сути 3 алиаса ссылаются на одну версию, непонятно. Но ничего, все по порядку
Второе состояние
- Создать вторую версию нашей лямбды(Возможно добавить второй вывод «Hello world»). Тут хочу отметить, что в этот момент "$LATEST" будет смотреть сразу на вторую версию. И так как «Dev» привязан к "$LATEST", то он тоже будет смотреть на вторую версию.
- Далее, мы хотим чтобы наш «Stage» смотрел на вторую версию. Сейчас он привязан к версии «1». Тут нам нужно вручную поменять версию на которую указывает «Stage».
- Радуемся. Мы получили то — что видим как второе состояние на графике. То есть, наш «Prod» смотрит на первую версию, а «Dev» и «Stage» на вторую.
Третье состояние
Теперь, чтобы получить третье состояние, нам достаточно просто добавить еще пару строк в наш код и будет третья версия нашей лямбды. И «Dev» будет смотреть теперь на нее.
Резюмируем
И так, что мы имеем?
Маленькую. Быструю. Относительно дешевую. Автомасштабируемую. Версионируемую. Функцию.
В этой статье мы рассмотрели только теоретическую часть, знакомство с этим сервисом. Так же как и с SQS в прошлой статье. В следующей статье мы рассмотрим как эти два сервиса взаимодействуют друг с другом и в практической форме научимся их настраивать, использовать.