Рекомендации по AWS Lambda

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

Это меньше сервера?

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

AWS Lambda

AWS Lambda - это FaaS (функция как услуга), которая является одним из самых мощных сервисов, предоставляемых Amazon Web Services. Lambda - это служба бессерверных вычислений, которая позволяет пользователям запускать свой код без предоставления серверов и управления ими. Поскольку Lambda доступна на всех популярных языках, разработчик может легко использовать Lambda для реализации серверной части своего веб-приложения, и ему не нужно думать о выделении новых серверов, их масштабировании, безопасности серверов и обо всем остальном, потому что AWS позаботится обо всем. Эти проблемы позволили пользователям Lambda просто больше сосредоточиться на своей бизнес-логике, а код был защищен и масштабируем в контексте приложения.

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

Лямбда под капотом

Лямбда-сервис можно разделить на 2 основные части: плоскость управления и плоскость данных. Плоскость управления отвечает за управление такими API-интерфейсами, как CreateFunction, UpdateFunctionCode, PublishLayerVersion, а также за все интеграции с другими сервисами AWS. Данные, находящиеся в состоянии покоя в плоскости управления, защищены AWS KMS, а протокол TLS используется для обеспечения защиты данных при передаче.

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

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

Лучшие практики AWS Lambda

В этой статье мы обсудим передовые методы работы с AWS Lambda в трех основных направлениях. Которые,

Код функции и зависимости
Конфигурация функций
Ведение журнала и мониторинг

Код функции и зависимости

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

Отделить обработчик лямбда от служебной логики

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

Повторно использовать среду выполнения

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

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

Используйте переменные среды для управления рабочими параметрами

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

Разверните общий код на уровне лямбда

Лямбда-слой - это ZIP-архив, который может содержать дополнительный код или данные. При настройке среды выполнения лямбда извлекает содержимое уровня в каталог / opt среды выполнения. Используя уровни лямбда, код и зависимости могут быть легко разделены между несколькими функциями. А также путем добавления тяжелых зависимостей, таких как AWS SDK, который, вероятно, будет повторно использоваться во многих лямбда-функциях, мы можем значительно уменьшить размер пакета лямбда-функции, что приведет к более быстрому развертыванию.

Следите за размером упаковки

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

Избегайте использования рекурсивного кода

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

Конфигурация функций

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

Одна лямбда, одна роль IAM

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

Контролируемый доступ к VPC для лямбда

Лямбда-функции всегда работают в общем VPC и могут отправлять сетевые запросы на любой адрес через общедоступный Интернет, включая другие API AWS. А частные VPC используются, чтобы убедиться, что некоторые ресурсы работают в частном порядке, а другие службы получают доступ к этим частным ресурсам в контролируемой среде. Поэтому важно убедиться, что доступ VPC включен только для лямбда-функции, которой требуется доступ к этим ресурсам. Также важно отметить, что после включения функции VPC добавление трафика, поступающего от лямбда-функции, регулируется правилами маршрутизации VPC.

Зарезервированный параллелизм для критических функций

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

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

Найдите правильный баланс между памятью и временем выполнения

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

Регистрация и мониторинг

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

Настроить журналы AWS CloudWatch

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

Настроить облачные будильники для одновременных запросов

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

AWS X-Ray

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

AWS Config

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

Заключение

Lambda - это сервис бессерверных вычислений, предлагаемый AWS, который следует модели Function as a Service. Это избавляет от большинства проблем, о которых может беспокоиться разработчик, и позволяет пользователю больше сосредоточиться на бизнес-логике. В то же время это может привести к тому, что разработчик совершит ошибки при настройке или написании кода из-за разной природы среды выполнения Lambda. Поэтому важно помнить о передовых методах, чтобы обеспечить выполнение бизнес-логики в оптимизированной защищенной среде.

Больше контента на plainenglish.io