Эксплуатация Lambda: проектирование приложений Часть 3

В серии из трёх постов «Эксплуатация Lambda» я раскрою важные темы для разработчиков, архитекторов и системных администраторов, которые управляют и обслуживают AWS Lambda-приложения.

Часть 1 показывает, как работать с лимитами сервиса (Service Quotas), когда запрашивать их расширение, и как проектировать приложения с учётом этих лимитов.

Часть 2 раскрывает аспекты масштабирования, а также двух видов параллелизма: «по-запросу» (on-demand) и Provisoned Concurrency.

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

Выбор и управление средой исполнения в Lambda функциях

Lambda изначально поддерживает набор из типичных сред исполнения, включая Python, Node.js, Java, .NET, и другие. Если вы хотите использовать другую среду исполнения, например PHP или Perl, вы можете воспользоваться пользовательской средой исполнения. Есть список сред исполнения поддерживаемых коммьюнити для широкого спектра языков программирования, также вы можете сделать свою собственную. Lambda клиенты могут запускать Erlang, COBOL, Haskell, и практически любую другую среду исполнения, необходимую для их рабочих нагрузок.

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

Среды исполнения и производительность

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

Разные среды исполнения имеют разные профили производительности в вычислительных сервисах, таких как Lambda. Например, Python и Node.js быстро стартуют и имеют приемлемую общую производительность. Java гораздо медленнее инициализируются, но во время работы может быть довольно быстрой. Язык программирования Go может быть очень производительным как при старте, так и во время работы. Если производительность критична для работы вашего приложения, то определите и сравните профили производительности сред исполнения, прежде чем разрабатывать само приложение.

Множественные среды исполнения в рамках одного приложения

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

Например, Lambda функция, которая преобразует JSON между сервисами, вы можете выбрать для бизнес-логики Node.js. Другая функция, обрабатывающая данные, может использовать Python среду исполнения. И они обе могу сосуществовать в рамках единого бессерверного приложения.

Управление AWS SDK в Lambda функциях

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

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

Чтобы узнать больше, ознакомьтесь с разделом “Creating a layer containing the AWS SDK” по ссылке.

Сетевая инфраструктура и настройка VPC

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

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

По умолчанию, Lambda функции имеют доступ в интернет. Однако, если вы добавили конфигурацию доступа к клиентской VPC для Lambda функции, у неё не будет доступа в интернет. Если вам все же нужно получить доступ в интернет, настройте NAT инстанс или Amazon NAT Gateway. Также, вы можете использовать VPC точки доступа для возможности взаимодействия с поддерживаемыми AWS сервисами по приватным каналам.

Высокая доступность Lambda сервиса зависит от нескольких зон доступности внутри региона, где запущена функция. Когда вы создаёте Lambda функцию без VPC конфигурации, она автоматически доступна во всех зонах доступности внутри региона. Когда вы настраиваете VPC доступ, вы выбираете какие зоны доступности могут быть использованы для Lambda функции. Таким образом, для обеспечения высокой доступности убедитесь, что функция имеет доступ хотя бы к двум зонам доступности.

Lambda сервис использует Network Function Virtualization платформу для предоставления NAT из Lambda VPC к клиентской VPCs. Она настраивает необходимые эластичные сетевые интерфейсы (ENI) в момент создания или обновления функции. Также во время этой настройки, ENI из вашего аккаунта делаются доступными для нескольких сред исполнения Lambda, что позволяет Lambda более эффективно использовать ограниченные сетевые ресурсы, когда функция масштабируется.

Так как ENI это конечные ресурсы, и существует изменяемый лимит в 350 ENI на регион, вы должны мониторить используемые ENI, если вы настраиваете ваши Lambda функции для доступа в VPC. В общем случае это значит, что, если вы увеличиваете ваши лимиты параллелизации для Lambda, вам нужно оценить, нужно ли увеличение лимитов по ENI в том числе. Если вы достигните лимитов по ENI, Lambda-функции с настроенным доступом в VPC будут подвержены тротлингу.

Большинство бессерверных сервисов могут быть использованы без настройки доступа к VPC, в то время как сервисы на базе инстансов требуют такой настройки:

Чтобы узнать больше, читайте How VPC networking works with Lambda functions.

Сравнение режимов запуска Lambda

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

Синхронные вызовы хорошо подходят для быстро-выполняемых Lambda-функций. Хотя Lambda функция могут работать до 15 минут, синхронная вызывающая сторона может иметь более короткий таймаут. Например, API Gateway имеет 29-секундный интеграционный таймаут, поэтому Lambda функция, выполняемая дольше 29 секунд, не сможет завершиться успешно. При синхронных вызовах, если Lambda функция завершается некорректно, перезапуск обработки должен координироваться на вызывающей стороне.

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

Чтобы узнать больше, читайте “Invoking AWS Lambda functions” и “Introducing AWS Lambda Destinations”.

Выводы

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