Лямбда архитектура что это

Обновлено: 09.01.2025

Автор Анна Вичугова Категория Kafka, Machine Learning, Spark, Статьи

Вчера мы рассказали, что такое лямбда-архитектура. Сегодня рассмотрим Каппа – альтернативный подход к проектированию Big Data систем. Читайте в нашей статье, зачем нужна эта концепция, каковы ее достоинства и недостатки, чем Каппа отличается от Лямбда, где это используется на практике и при чем тут Apache Kafka с Machine Learning.

Зачем нужна Каппа-архитектура и как она устроена

При всех достоинствах Лямбда-архитектуры, главным недостатком этого подхода к проектированию Big Data систем считается его сложность из-за дублирования логики обработки данных в холодном и горячем путях. Поэтому в 2014 году была предложена Каппа – альтернативная модель, которая потребляет меньше ресурсов, но отлично подходит для обработки событий в режиме реального времени [1].

В отличие от лямбда, в Каппа-архитектуре потоковые данные проходят по одному пути. Все данные принимаются как поток событий в распределенном и отказоустойчивом едином журнале – логе событий. Там события упорядочиваются, и текущее состояние события изменяется только при добавлении нового события. Аналогично уровню ускорения лямбда-архитектуры, вся обработка событий выполняется во входном потоке и сохраняется как представление в режиме реального времени. Если необходимо повторно вычислить весь набор данных, как на пакетном уровне в лямбда-архитектуре, поток воспроизводится заново. Для своевременного завершения вычислений используется параллелизм [2].

Функциональное уравнение, которое определяет запрос Big Data, в Каппа-архитектуре будет выглядеть так [1]:

Query = K (New Data) = K (Live streaming data)

Это уравнение означает, что все запросы могут быть обработаны путем применения функции Каппа (К) к real-time потокам данных на скоростном уровне.

Таким образом, можно сказать, что Каппа-архитектура – это упрощение Лямбда-подхода к проектированию Big Data систем, когда из модели удален уровень пакетной обработки данных. При этом каноническое хранилище данных представляет собой неизменяемый журнал только для добавления информации. Из журнала данные сразу передаются в систему потоковых вычислений, по необходимости обогащаясь данными из неканонического хранилища (сервисный уровень). Цель сервисного уровня – предоставить оптимизированные ответы на запросы. Однако эти хранилища не являются каноническими (неизменяемыми): их можно в любой момент стереть и восстановить из канонического Data Store [3].

Для реализации Каппа-архитектуры используются следующие технологии Big Data [3]:

канонические хранилища для постоянного логгирования событий, например, Apache Kafka, Apache Pulsar, Amazon Quantum Ledger Database, Amazon Kinesis, Amazon DynamoDB Streams, Azure Cosmos DB Change Feed, Azure EventHub и другие подобные системы;
фреймворки потоковых вычислений, например, Apache Spark, Flink, Storm, Samza, Beam, Kafka Streams, Amazon Kinesis, Azure Stream Analytics и другие streaming-системы;
на сервисном уровне может использоваться практически любая база данных, резидентная (в памяти) или постоянная, в т.ч. хранилища специального назначения, например, для полнотекстового поиска.

Где используется K-подход и причем здесь Apache Kafka

Итак, Kappa-архитектура целесообразна для таких корпоративных моделей обработки данных, где [1]:

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

Lambda или Kappa: что и когда выбирать

Прежде всего отметим, что при общих целях построения надежной и быстрой системы обработки больших данных, подходы лямбда и каппа не конкурируют друг с другом, а могут использоваться вместе для разных случаев. В частности, для надежной работы с озером данных (Data Lake) на базе Apache Hadoop и моделями машинного обучения для прогнозирования будущих событий на основе исторических данных, следует выбрать Лямбда-подход. С другой стороны, если необходимо недорого развернуть Big Data систему для эффективной обработки уникальных событий в реальном времени без исторического анализа, Каппа-архитектура отлично справится с этой задачей. Каппа подходит для тех алгоритмов Machine Learning, которые обучаются в режиме онлайн и не нуждаются в пакетном уровне. Таким образом, для Kappa характерны следующие достоинства [1]:

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

Тем не менее, отсутствие пакетного уровня может привести к ошибкам при обработке информации или при обновлении базы данных. Поэтому в Каппа-архитектуре возникает потребность в диспетчере исключений для повторной обработки данных или сверки [1]. В следующей статье мы поговорим про процессы и инструменты обеспечения качества больших данных с помощью Apache Spark, Airflow и других Big Data фреймворков. А тему архитектуры продолжим здесь.

Как реализовать Лямбда или Каппа-архитектуру на базе Apache Kafka, Spark и других фреймворках больших данных, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Автор Анна Вичугова Категория Flink, Internet of Things, Статьи

Добавляя в наши курсы для дата-инженеров интересные кейсы, сегодня рассмотрим, как реализовать Лямбда-архитектуру для комплексной аналитики больших данных с помощью Apache Flink, Kafka и Cassandra на примере системы интернета вещей. Объединение пакетной и потоковой обработки данных средствами Flink API и библиотек этого фреймворка.

Постановка задачи на примере IoT-системы

Несмотря на разделение технологий обработки Big Data на пакетную и потоковую парадигму, тенденция к их совместному использованию и объединению в рамках одного решения становится все более четкой. Современному бизнесу нужен потоковый сбор и аналитика больших данных в режиме реального времени вместе с классическими пакетными заданиями. При этом потоковые и пакетные данные должны быть объединены перед тем, как их можно будет визуализировать и обрабатывать как объединенный набор данных. Именно эту идею реализует последняя версия вычислительного фреймворка Apache Flink, о чем мы писали здесь и здесь.

Чтобы продемонстрировать, как это работает, рассмотрим пример системы интернета вещей (Internet Of Things, IoT) по анализу данных о событиях станции измерения воздуха с ежечасным измерением набора показателей с девяти датчиков: содержание различных веществ, дата, время, температура и влажность.

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

Архитектура Данных

Код курса

Ближайшая дата курса

Длительность обучения

24 ак.часов

Стоимость обучения

60 000 руб.

Гибридная архитектура для пакетной и потоковой обработки с Apache Flink

Идея лямбда-архитектуры впервые была представлена Натаном Марцем более 10 лет назад, в 2011 году. Lambda-архитектура содержит три уровня:

пакетный (batch)обрабатывает все пакетные данные из баз или озер данных
уровень скорости (speed) обрабатывает все потоковые данные в режиме реального времени, делая новые данные доступными с минимальной задержкой;
уровень обслуживания (serving)отвечает за слияние очищенных данных с двух других уровней и предоставление их приложениям.

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

Источником потоковых данных будет Apache Kafka, а пакетных – объектно-реляционная СУБД PostgreSQL. Лямбда-архитектура системы подготовки данных для конечного использования (визуализации и BI-приложений) реализована с помощью пакетных и потоковых заданий Apache Flink и NoSQL-СУБД Cassandra.

С Flink можно использовать один и тот же код для обработки пакетных и потоковых данных, поскольку фреймворк рассматривает пакеты как ограниченные потоки. Это уникальное преимущество Flink по сравнению с Apache Spark или Storm. Также Flink дает большую гибкость для сложных преобразований, позволяя писать код на Java, Python и SQL. Apache Flink состоит из нескольких компонентов, каждый из которых содержит определенные функции для различных структур данных (поток данных или таблица) и сценариев использования:

обработка сложных событий (Complex Event Processing, CEP) – CEP-библиотека предоставляет API для указания шаблонов событий в виде регулярных выражений или конечных автоматов. Благодаря интеграции библиотеки CEP с API Flink DataStream шаблоны можно распространять на потоки данных. Эта библиотека часто применяется для таких приложений, как обнаружение сетевых вторжений, мониторинг бизнес-процессов и обнаружение мошенничества.
DataSet API– основной программный интерфейс Flink для приложений пакетной обработки. Его примитивы включают сопоставление, сокращение, соединения, совместную группировку и итерации. Все операции поддерживаются алгоритмами и структурами данных, которые работают с сериализованными данными в памяти и перебрасываются на диск при превышении лимита. Алгоритмы обработки данных Flink DataSet API подобны традиционным операторами СУБД, такими как гибридное хэш-соединение или внешняя сортировка слиянием.
Gelly – библиотека для масштабируемой обработки и анализа графов. Gelly реализована поверх DataSet API и интегрирована с ним. Gelly включает встроенные алгоритмы, такие как распространение меток, перечисление треугольников и ранжирование страниц, а также предоставляет Graph API, упрощающий реализацию пользовательских графовых алгоритмов.

Таким образом, Flink предлагает несколько библиотек для типовых сценариев обработки данных. Библиотеки встроены в API и не являются полностью автономными, а могут интегрироваться друг с другом и использоваться совместно. Чтобы показать, как это работает, продолжим разбор примера с IoT-системой.

Hadoop для инженеров данных

Код курса

Ближайшая дата курса

Длительность обучения

40 ак.часов

Стоимость обучения

100 000 руб.

Конвейеры обработки горячих и исторических данных

Чтобы подготовить и объединить потоковые и исторические данные для конечной аналитики и визуализации, построим два конвейера: для слоя скорости и пакетного слоя.

Для чтения данных из PostgreSQL нужен JDBC-коннектор. Поэтому используется JdbcInputFormatBuilder пакета JDBC-коннектора Flink, куда передаются необходимые параметры, чтобы создать поток данных со схемой Row:

InsertQuery – это SQL-запрос вставки, который обеспечивает согласованность данных. Пакетный уровень записывает только исторические данные, а уровень скорости работает с ними некоторое время назад, когда они были текущими. Поэтому пакетный уровень переопределяет данные из уровня скорости, поскольку он более точен и заслуживает доверия. Следует убедиться, что уровень скорости не вставляет никаких данных с существующими первичными ключами, а пакетный уровень имеет возможность перезаписывать существующие строки с тем же первичным ключом. Этого можно добиться, настроив ограничение первичного ключа в таблице и определив действие при нарушении ограничения для каждого задания. Таким образом, нужна только одна стандартная таблица и не требуется отдельного сервиса для слияния данных: они уже упорядочены по первичным ключам, а конфликтов и дубликатов нет. Все внешние службы, которым нужны предварительно обработанные данные, могут получить доступ к СУБД Cassandra с помощью классических методов, используя коннекторы, REST API и пр.

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

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

В последствии данные обрабатываются до состояния пригодного к употреблению разнообразными пользователями. Это могут быть внутренние дашборды; отчёты партнёрам; результаты, которые идут в продакшн и влияют на поведение продукта. Эти операции могут быть довольно сложными и включать несколько источников данных. Но по большей части мы с этим справляется внутри BigQuery с помощью SQL+UDF. Результаты сохраняются в отдельные таблицы там же.

Очевидным способом организации этого процессинга является создание расписания операций. Если данные подгружаются ежедневно в час ночи, то мы настроим процессинг на 01:05. Если этот источник данных подгружается в районе 5й минуты каждого часа, то настроим процессинг на 10ю минуту каждого часа. Промежутки в 5 минут для пользователей не критичны и предполагается, что всё должно работать.
Но мир жесток! Данные не всегда приходят вовремя. Или вообще не приходят, если не починить. Если твоя часовая загрузка закончилась на 11й минуте, а трансформация запускалась на 10й – то пожалуйста, жди ещё час чтобы увидеть эти данные в дэшборде. А если операция использует несколько источников, то ситуация будет ещё веселее.

Более того, подгружаемые сырые данные не всегда верны (данные вообще всегда не верны!). Периодически данные приходится чистить или перезагружать. И тогда нужно перезапустить все операции и с корректными параметрами, чтобы всё починилось.

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

Это реально большая проблема. И как же ещё решить?

Решение №1 – убрать проблемные детали

Если процессинг приводит к проблемам, то не надо его делать! Не надо делать вообще никакой процессинг и хранить промежуточные результаты. Как только пользователю нужны результаты, всё должно вычисляться на лету из сырых данных. Учитывая скорость BigQuery это вполне реалистично. Особенно если все что вы делаете с данными это GROUP BY date и count(1), и нужны только данные за последние 14 дней.

Большинство аналитики работает именно с такими запросами. Поэтому мы данное решение активно используем. Но этот подход не работает со сложными трансформациями.

Одна проблема – это сложность кода. Если сложить все операции в один SQL запрос, то его будет не прочитать. К счастью это решается за счёт таблиц типа view (представления). Это логические таблицы в BigQuery, данные в них не хранятся, а генерируются из SQL-запроса на лету. Это сильно упрощает код.

Но другая проблема – это производительность. Здесь всё плохо. Не важно какие быстрые и дешёвые современные базы данных. Если запустить сложную трансформацию на одном годе исторических данных, это займёт время и будет стоить денег. Других вариантов нет. Эта проблема делает данную стратегию неприменимой в довольно большом проценте случаев.

Решение № 2 – построить сложную систему

Если нет возможности обойтись без системы управления процессингом, то нужно построить эту систему хорошо. Не просто расписание выполнения скриптов в cron, а система мониторинга загрузки данных, которая определяет когда и какие трансформации запускать. Наверное паттерн pub/sub тут очень подходит.

Но есть проблема. Если построить сложную систему более менее просто, то вот поддерживать её и ловить баги – это очень сложно. Чем больше кода, тем больше проблем.

По счастью есть и третье решение.

Решение № 3 – лямбда архитектура! …ну, типа того

Лямбда архитектура – это знаменитый подход к процессингу данных, который использует преимущества обработки данных по расписанию и в реальном времени:

*Как нормально перевести на русский не знаю, batch job – это что пакетное задание? Кто знает, подскажите!

Обычно это все строится с использованием нескольких решений. Но мы используем по сути тот же трюк просто внутри BigQuery.

И вот как это работает:

Процессинг по расписанию (Batch layer). Мы ежедневно выполняем SQL-запросы, которые трансформируют данные имеющиеся на текущий момент, и сохраняем результаты в таблицы. У всех запросов следующая структура:

Результаты этого запроса будут сохранены в table_static (перезапишут её). Да, BigQuery позволяет сохранять результаты запроса в таблице, которая использовалась в этом запросе. В итоге мы берём старые, уже посчитанные данные (чтобы их не пересчитывать) и соединяем с новыми данными. X дней – это выбранный период, за который мы хотим пересчитать данные, чтобы учесть все возможные корректировки сырых данных. Предполагается что за X дней (сколько – это индивидуально для источника) все корректировки уже будут внесены, всё что сломалось починится и данные уже больше не будут меняться.

Доступ в реальном времени (Speed layer + Serving layer). Эти обе задачи объединены в один SQL-запрос:

Да, это тот же самый запрос! Его мы сохраняем как представление (view) с именем table_live и все пользователи (дэшборды, другие запросы, и т.п.) тянут результаты из этого представления. Так как представления в BigQuery хранятся на логическом уровне (только запрос, не данные), каждый раз при обращении он будет пересчитывать последние X дней на лету и все изменения в изначальных данных будут отражены в результатах.

Так как запрос в обоих случаях одинаковый, то в реальности, чтобы избежать дупликации кода, ежедневный запрос (из batch layer) выглядит так:

(и сохраняем результаты в table_static)

PS Если любите использовать таблицы разбитые по датам в BigQuery (мы очень любим), то есть решение и для этого. Но это тема для другого поста. Подсказка – функции для работы с этими таблицами не ругаются, если часть таблиц – это только представления.

PPS Если бы представления в BigQuery поддерживали кешинг (как это работает с обычными запросами), это было бы реально круто. Это по сути сделало бы их материализованными (materialized views). И эффективность нашего подхода стала бы ещё выше. Если вы согласны – здесь можно поставить звёздочку, чтобы эту фичу быстрее реализовали.

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

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

Вторая плоскость — плоскость данных. У нее, как и у плоскости управления, свои задачи. Плоскость управления предоставляет API для управления функциями (CreateFunction, UpdateFunctionCode) и контролирует взаимодействие Lambda с другими сервисами AWS. Плоскость данных управляет API вызовов (Invoke API), который запускает функции 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 файлы существуют в течение всего жизненного цикла среды выполнения. За счет этого возможно аккумулирование результатов нескольких вызовов, что особенно полезно для таких затратных операций, как загрузка моделей машинного обучения.

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

Вы можете производить мониторинг и аудит функций 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 — возможно, он как нельзя лучше подходит для вашей задачи.

Читайте также: