Детальный разбор AWS Lambda

Автор оригинала: Georgi Velinov
  • Перевод

Перевод статьи подготовлен специально для студентов курса «Облачные сервисы». Интересно развиваться в данном направлении? Смотрите мастер-класс Егора Зуева (TeamLead в компании InBit) «AWS EC2 сервис» и присоединяйтесь к ближайшей группе курса: старт 26 сентября.



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


AWS Lambda


AWS Lambda — это событийно-ориентированный сервис бессерверных вычислений, который позволяет выполнять код без выделения и администрирования серверов и дополнять другие сервисы AWS на основе пользовательской логики. Lambda автоматически реагирует на различные события (так называемые триггеры), например на HTTP-запросы через Amazon API Gateway, изменение данных в корзинах Amazon S3 или таблицах Amazon DynamoDB; либо можно запустить свой код через вызовы API, используя AWS SDK и переходы между состояниями в AWS Step Functions.


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


Когда переходить на Lambda?


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


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


Lambda позволяет выполнять широкий спектр задач. Так, благодаря поддержке CloudWatch можно создавать отложенные задания и автоматизировать отдельные процессы. Нет никаких ограничений по характеру и интенсивности использования сервиса (учитываются расход памяти и время), и вам ничто не мешает планомерно работать над полноценным микросервисом на основе Lambda.


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


Итак, если вы не хотите заниматься выделением и администрированием вычислительных ресурсов — попробуйте AWS Lambda; если вам не нужны тяжелые, ресурсоемкие вычисления — также попробуйте AWS Lambda; если ваш код выполняется периодически — все правильно, вам стоит попробовать AWS Lambda.


Безопасность


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


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


Если говорить конкретно об AWS Lambda, то AWS отвечает за управление нижележащей инфраструктурой, связанными базовыми сервисами, операционной системой и платформой приложений. В то время как клиент несет ответственность за безопасность своего кода, хранение конфиденциальных данных, контроль доступа к ним, а также к сервису и ресурсам Lambda (Identity and Access Management, IAM), в том числе в пределах используемых функций.


На схеме ниже представлена модель общей ответственности, применимая к AWS Lambda. Сфера ответственности AWS окрашена в оранжевый цвет, а ответственность клиента — в голубой. Как видите, AWS берет на себя больше ответственности за приложения, развертываемые на сервисе.



Модель общей ответственности, применимая к AWS Lambda


Среда выполнения Lambda


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


Сервис Lambda разделен на две плоскости. Первая — плоскость управления. Согласно Википедии, плоскость управления (control plane) — это часть сети, отвечающая за транспортировку сигнального трафика и маршрутизацию. Она является главным компонентом, принимающим глобальные решения о выделении, обслуживании и распределении рабочих нагрузок. Кроме того, плоскость управления выступает в роли сетевой топологии поставщика решения, отвечающей за маршрутизацию трафика и управление им.


Вторая плоскость — плоскость данных. У нее, как и у плоскости управления, свои задачи. Плоскость управления предоставляет API для управления функциями (CreateFunction, UpdateFunctionCode) и контролирует взаимодействие Lambda с другими сервисами AWS. Плоскость данных управляет API вызовов (Invoke API), который запускает функции Lambda. После вызова функции плоскость управления выделяет либо выбирает существующую, заранее подготовленную для этой функции среду выполнения, а затем выполняет в ней код.


AWS Lambda поддерживает множество языков программирования, включая Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 и другие, через соответствующие среды выполнения. AWS регулярно их обновляет, распространяет исправления безопасности и выполняет прочие операции по обслуживанию этих сред. Lambda позволяет использовать и другие языки при условии, что вы сами внедрите соответствующую среду выполнения. И тогда уже вам придется заниматься ее обслуживанием, в том числе следить за безопасностью.


Как все это работает и как сервис будет выполнять ваши функции?


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



Модель изоляции в AWS Lambda


Изоляция сред выполнения реализована с помощью нескольких механизмов. На высшем уровне каждой среды присутствуют отдельные копии следующих компонентов:


  • Код функции
  • Любые слои Lambda, выбранные для функции
  • Среда выполнения функции
  • Минимальное пользовательское пространство на базе Amazon Linux

Для изоляции разных сред выполнения применяются следующие механизмы:


  • cgroups — ограничение доступа к ресурсам ЦП, памяти, пропускной способности накопителей и сети для каждой среды выполнения;
  • namespaces — объединение в группы ID процессов, ID пользователей, сетевых интерфейсов и других ресурсов, которыми управляет ядро Linux. Каждая среда выполнения работает в своем пространстве имен;
  • seccomp-bpf — ограничение системных вызовов, которые можно использовать в среде выполнения;
  • iptables и routing tables — изоляция сред выполнения между собой;
  • chroot — предоставление ограниченного доступа к нижележащей файловой системе.

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


Хотя несколько сред выполнения одной учетной записи AWS могут выполняться на одной microVM, ни при каких обстоятельствах microVM не могут совместно использоваться разными учетными записями AWS. Для изоляции microVM в AWS Lambda используется всего два механизма: экземпляры EC2 и Firecracker. Изоляция гостей (guest isolation) в Lambda на основе экземпляров EC2 применяется с 2015 года. Firecracker — это новый гипервизор с открытым исходным кодом, специально разработанный AWS для бессерверных рабочих нагрузок и представленный в 2018 году. Физическое оборудование, на котором выполняются microVM, совместно используется рабочими нагрузками разных учетных записей.


Сохранение сред и состояний процессов


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


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


Передача данных вызовов


Интерфейс Invoke API можно задействовать в двух режимах: в режиме событий и в режиме «запрос — ответ». В режиме событий вызов добавляется в очередь для последующего выполнения. В режиме «запрос — ответ» функция вызывается мгновенно с предоставленной полезной нагрузкой, после чего возвращается ответ. И в том и в другом случае функция выполняется в среде Lambda, но с различными путями полезной нагрузки.


Во время вызовов типа «запрос — ответ» полезная нагрузка поступает от API обработки запросов (API Caller), такого как AWS API Gateway или AWS SDK, в балансировщик нагрузки, а затем — в службу выполнения вызовов Lambda (Invoke Service). Последняя определяет подходящую среду для выполнения функции и передает туда полезную нагрузку, чтобы завершить вызов. Балансировщик нагрузки получает трафик с TLS-защитой через Интернет. Трафик в пределах сервиса Lambda — после балансировщика нагрузки — проходит через внутренний VPC в определенном регионе AWS.



Модель обработки вызовов AWS Lambda: режим «запрос — ответ»


Вызовы по событиям могут выполняться незамедлительно либо добавляться в очередь. В некоторых случаях очередь реализована с помощью сервиса Amazon SQS (Amazon Simple Queue Service), который передает вызовы в службу выполнения вызовов Lambda посредством внутреннего опрашивающего процесса (poller). Передаваемый трафик защищен TLS, при этом какое-либо дополнительное шифрование данных, хранящихся в Amazon SQS, не предусмотрено.


Вызовы по событиям не возвращают ответы — любую ответную информацию Lambda Worker попросту игнорирует. Вызовы на основе событий Amazon S3, Amazon SNS, CloudWatch и других источников обрабатываются сервисом Lambda в режиме событий. Вызовы из потоков Amazon Kinesis и DynamoDB, вызовы очередей SQS, балансировщика нагрузки приложений и API Gateway обрабатываются в режиме «запрос — ответ».


Мониторинг


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


Amazon CloudWatch
Собирает различные статистические данные, такие как количество запросов, продолжительность выполнения запросов и число запросов, завершившихся ошибкой.


Amazon CloudTrail
Позволяет вести журналы, непрерывный мониторинг и сохранять сведения об активности в учетной записи, связанные с вашей инфраструктурой AWS. У вас будет полная хронология действий, выполненных с помощью консоли AWS Management Console, AWS SDK, инструментов командной строки и других сервисов AWS.


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


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


Заключение


AWS Lambda предлагает мощный набор инструментов для создания безопасных и масштабируемых приложений. Многие методы обеспечения безопасности и соответствия нормативным требованиям в AWS Lambda не отличаются от используемых в остальных сервисах AWS, хотя есть исключения. По состоянию на март 2019 года Lambda соответствует требованиям SOC 1, SOC 2, SOC 3, PCI DSS, закону США о преемственности и подотчетности медицинского страхования (HIPAA) и другим нормативам. Поэтому, когда задумаетесь о реализации очередного приложения, рассмотрите сервис AWS Lambda — возможно, он как нельзя лучше подходит для вашей задачи.

OTUS. Онлайн-образование
534,11
Цифровые навыки от ведущих экспертов
Поделиться публикацией

Комментарии 17

    +1
    Нет никаких ограничений по характеру и интенсивности использования сервиса (учитываются расход памяти и время)

    Дадада. Просто попробуйте сделать на Lambda задачу, которая выполняется полчаса.

      +2
      Тоже удивило это предложение.
      Даже в официальной документации сказано, что есть ограничения.
      0
      Как происходит самый первый вызов лямбды? Выделяется микровм, заливается код и только потом передается управление handler функции? Или как минимум одна микровм всегда наготове?
        0
        Выделяется микровм, заливается код и только потом передается управление handler функции?

        Более-менее так, да. Холодный старт у лямбды (сравнительно) долгий — несколько секунд, если я не путаю.

      0

      Насколько сложно делать лямбды на языках, не входящих в список поддерживаемых из коробки?

        0

        Зависит от того, насколько вы готовы писать свой рантайм. Я этого не делал, но примеры, которые я видел, сложными не были — там все сводится к HTTP-интерфейсу.

          0

          Для компилируемых языков выглядит довольно просто, спасибо!

            0

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

              0

              О, раз у вас, судя по всему, есть опыт.


              Я тут лениво попиливаю замену почившему сохабру, которая состоит из двух компонентов: запускаемый раз в минуту скрейпер постов (уже давно готово и работает) и веб-морда к этому всему (ну и постгрес для хранения БД). Разумно ли для чего-то из этого использовать лямбду, или, если у меня уже, скажем, есть машина в Хецнере, лучше использовать её, а AWS использовать только для RDS?

                0

                Считать надо, если вкратце.


                С одной стороны, веб-морду на Лямбде делать странно (ну, на мой вкус); публичную, по крайней мере (если для себя одного, то можно и на Лямбде). С другой стороны, если сайт будет снаружи AWS, то можно влететь на стоимость data transfer (из RDS), да и просто latency будет выше.


                Но это все умозрительно, я такие задачи не решал.

                  0

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


                  Надо запросы оптимизировать, или хотя бы какой-то кеш в памяти держать. Вытаскивать раз в минуту 120 тысяч рядов для того, чтобы отобрать из них 10-20-100, которые надо обновить, почти физически неприятно. Но, увы, я не знаю постгрес и SQL достаточно, чтобы адекватно сформулировать соответствующий запрос.

                  0

                  А зачем вам RDS? DynamoDB будет достаточно и бесплатно

                    0

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

                +1
                Прежде чем писать свой рантайм, рекомендую взглянуть на Fargate или ECS. Возможно, вам будет проще упаковать ваше приложение в контейнер.

                Ну и если вы для Haskell хотите рантайм, то вот — Haskell runtime for AWS Lambda.
                  +1

                  Спасибо!


                  Чем хорошо репутацию иметь — можно даже язык не уточнять.

              0

              Многое зависит от того, есть ли официальный runtime. Мы много пишем лямбд на расте, runtime удобный (https://github.com/awslabs/aws-lambda-rust-runtime) и потому писать просто :)

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое