Amazon AWS Lambda Tutorial — Руководство ULTIMATE (Скачать PDF)

Amazon Web Services (AWS) предоставляет инфраструктуру для размещения и запуска ваших приложений на разных уровнях абстракции.

Самым очевидным решением для размещения кода, конечно же, является аренда машины без поддержки, настройка операционной системы и установка всего необходимого программного обеспечения. Вы можете сделать это с Amazon EC2, хотя этот сервис больше известен арендой виртуальных машин, работающих на физических хостах, предоставляемых Amazon. В обоих решениях вы должны заботиться об используемой операционной системе и установке серверного программного обеспечения (например, Tomcat).

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

С Amazon Lambda уровень абстракции поднимается еще на один шаг выше. С Lambda вы больше не заботитесь о виртуальных машинах и их масштабировании самостоятельно. Все, что вам нужно сделать, это предоставить Amazon некоторый код (обычно в форме подготовленного jar-файла), и Amazon заботится о его выполнении от вашего имени. В отличие от Amazon Beanstalk, вас не заботит ни количество виртуальных машин, используемых для выполнения, ни количество балансировщиков нагрузки. Amazon обещает выполнять ваш код так часто, как это требуется. И вы платите только за время, потраченное на его выполнение, а не за время работы ваших виртуальных машин. Последний пункт чрезвычайно интересен для операций, которые не выполняются на регулярной основе, или если вы только начинаете новый бизнес. Если вам не нужен ваш сервис, вы ничего не платите. С другой стороны, если ваш бизнес начинается и у вас за ночь появляются сотни новых клиентов, вам не нужно заботиться об аренде новых серверов или об изменении лимитов, в которых будет работать Amazon.

Но эта свобода также связана с тем, что вы не знаете, в какой среде выполняется ваш код, и не имеете возможности использовать локальное состояние. Особенно тот факт, что ваш код не имеет состояния, должен учитываться с самого начала вашего проекта. Конечно, вы можете использовать хранилища данных, такие как Amazon S3, Amazon DynamoDB или даже собственное хранилище данных, развернутое как «нормальный» экземпляр EC2, но методы, которые вы собираетесь реализовать, получают только свои параметры и могут возвращать значение, как статический метод в Java. Но это должно быть понятно, если вы представите, что Amazon собирается развернуть ваш код на любой виртуальной машине, на которую он установлен, и вызывает ее с параметрами, предоставленными вызывающей стороной. Инфраструктура не заботится о количестве выполнений определенного экземпляра вашего кода и не направляет все вызовы от одного и того же клиента на одну и ту же виртуальную машину. Вы можете инициализировать статическую переменную для кэширования часто используемых структур данных, но вы должны иметь в виду, что эти структуры используются всеми потоками выполнения и могут не инициализироваться, если ваш код выполняется в первый раз на новой машине.

Вы можете вызывать лямбда-функции в ответ на различные события. Когда конкретный сегмент S3 изменяется или данные вставляются или удаляются из таблицы DynamoDB. Вы можете отобразить HTTP-запросы, поступающие из Интернета, к определенной функции Lambda, используя шлюз API. Или вы просто вызываете код, используя вызовы API из AWS SDK. Таким образом, лямбда-функции могут использоваться как триггеры в классических системах баз данных или могут использоваться для создания законченных приложений.

Код для Amazon Lambda может быть написан на разных языках: Node.js, Java, Go, C # и Python. В этом руководстве мы сосредоточимся, конечно, на Java, но для небольших функций вы можете рассмотреть язык сценариев, который не нужно компилировать и предоставлять в определенном формате архива.

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

Следующие концепции составляют Amazon Lambda:

• Лямбда-функция: это пользовательский код, который вы написали и который будет выполняться инфраструктурой Amazon.
• Источник события: служба, которая запускает выполнение вашей лямбда-функции.
• Нисходящие ресурсы: другие сервисы, которые вызываются вашим кодом.
• Потоки журналов. Ваш код может создавать выходные данные журналов, собираемые инфраструктурой Amazon.

Функция Lambda — это обычный метод Java, выполняемый инфраструктурой Amazon. Когда вы загружаете свой код (то есть файл jar), вы можете указать, какой метод Java связан с конкретной функцией Lambda. Инфраструктура передает любые данные о событиях в функцию в качестве первого параметра. Ваша функция может оценивать эти данные и вызывать любую дальнейшую логику.

Второй параметр вашей лямбда-функции — это объект контекста. Его можно использовать для взаимодействия со средой выполнения AWS. Например, вы можете запросить оставшееся время выполнения до завершения вашей функции.

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

В этой главе объясняется, как реализовать функции Lambda, и описываются различные аспекты, связанные с инфраструктурой Lambda.

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

В предыдущем разделе мы увидели, как реализовать простой обработчик. Но мы не ограничены этим конкретным форматом.

Вместо реализации интерфейса RequestHandler мы также можем использовать простой Java-класс, который не реализует никаких конкретных интерфейсов. Следующий класс сделает то же самое:

RequestHandler интерфейса RequestHandler Lambda SDK также предоставляет интерфейс RequestStreamHandler . Этот интерфейс обеспечивает реализацию метода, который использует InputStream для ввода и OutputStream качестве возвращаемого значения:

Чтобы преобразовать InputStream в String , мы используем библиотеку Apache commons-io:

Теперь мы можем реализовать ту же логику, что и выше:

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

Вы можете использовать объект Context для взаимодействия со средой выполнения вашей функции Lambda. Следовательно, Context предоставляет ряд свойств, к которым может обращаться ваша функция. Следующая лямбда-функция показывает, как вернуть некоторую интересную информацию из Context :

В приведенном выше примере мы возвращаем следующие свойства:

• awsRequestId: это идентификатор, связанный с текущим запросом. Этот идентификатор остается прежним при повторных попытках.
• functionName: имя лямбда-функции, как определено в AWS.
• functionVersion: версия функции.
• memoryLimitInMB: ограничение памяти, которое мы установили для этой функции.
• Остальная часть времени: количество миллисекунд, оставшихся до завершения выполнения.

Когда мы загружаем приведенный выше класс и настраиваем его как лямбда-функцию «returnContext», мы получаем следующий пример вывода:

Обратите внимание, что мы сократили лимит памяти до 256 ГБ, что отлично отражается в примере вывода.

Как упоминалось ранее, вы можете использовать операторы журнала для отслеживания выполнения вашего кода. Эти строки журнала отправляются в Amazon CloudWatch и сохраняются там для последующего анализа.

Простейшая форма регистрации — использовать System.out :

Запуск этой функции с именем «logContext» создаст следующие события журнала в CloudWatch:

До сих пор мы использовали экземпляры java.lang.String качестве входных и выходных параметров. Тем не менее, мы не ограничены этим. Вместо этого мы можем использовать произвольные сложные структуры данных и позволить Amazon Lambda отобразить входные данные на экземпляры классов вашей модели и на экземпляры наших классов ответов.

В следующем примере мы будем использовать класс Order качестве входных данных для нашей функции Lambda и класс Response качестве возвращаемого значения:

Как видите, обработчик запроса принимает только один параметр типа Order . Если мы не используем его, мы можем опустить объект Context . Класс Order представляет собой простой POJO с методами получения и установки для полей productId и amount . Amazon Lambda автоматически сериализует любую данную строку JSON в эту структуру.

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

Реализация обработчика просто выводит предоставленные значения. После этого он создает новый экземпляр Response и заполняет его текущей отметкой времени, а также состоянием. Выполнив этот простой обработчик, вы увидите следующий вывод:

Вместе с log4j приведенный выше код полностью независим от Amazon AWS и поэтому может быть протестирован или использован повторно в различных средах исполнения.

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

• Ваша функция не завершается до истечения времени ожидания.
• Входные данные не могут быть проанализированы.
• Выполнение достигает предела ресурса (например, предела памяти).

Если вызов функции не инициируется источником на основе потока (например, потоки Amazon Kinesis или DynamoDB), мы должны различать синхронный и асинхронный вызов.

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

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

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

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

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

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

Для бесперебойной обработки пакетов Amazon Lambda при необходимости увеличит число одновременных экземпляров в больших фрагментах. Размер порции зависит от региона, в котором вы работаете. В регионе ЕС (Лондон) вы получите 500 новых экземпляров одновременно, а в ЕС (Франкфурт) вы получите 1000 и 3000 в ЕС (Ирландия). Amazon будет увеличивать количество одновременных экземпляров, пока их количество не станет достаточным для обработки всех запросов. Это также уменьшит количество экземпляров, если они больше не нужны.

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

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

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